groovy
  1. groovy
  2. GROOVY-4681

implement final for local variables

    Details

    • Type: Task Task
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.x
    • Component/s: Compiler
    • Labels:
      None
    • Number of attachments :
      1

      Description

      a final modifier on a local variable of some kind is currently ignored by groovy. Instead groovy should give a compile time error if final is used but the variable gets still a value

        Activity

        Hide
        Paul King added a comment -

        Attaching a spike. This is too strict in that it requires initialization at declaration time, e.g. this is correctly detected:

        final x = 3
        x = 4            // error
        (x, y) = [5, 6]  // also an error
        

        but will reject the following valid code:

        final x
        x = 2
        
        Show
        Paul King added a comment - Attaching a spike. This is too strict in that it requires initialization at declaration time, e.g. this is correctly detected: final x = 3 x = 4 // error (x, y) = [5, 6] // also an error but will reject the following valid code: final x x = 2
        Hide
        Paul King added a comment -

        A revised patch handling parameters and only local variables with an initial default value. Some questions in my mind:

        • Should EmptyExpression check be outside VariableExpression
        • Do we need to visit defaultValue in VariableScopeVisitor or VariableExpression
        • Is there a better way rather than pushing defaultValue into VariableExpression
        • Should we be handling multiple assignment cases better
        • And the big TODO of dealing with local variables that don't have an initial expression
        Show
        Paul King added a comment - A revised patch handling parameters and only local variables with an initial default value. Some questions in my mind: Should EmptyExpression check be outside VariableExpression Do we need to visit defaultValue in VariableScopeVisitor or VariableExpression Is there a better way rather than pushing defaultValue into VariableExpression Should we be handling multiple assignment cases better And the big TODO of dealing with local variables that don't have an initial expression
        Hide
        Paul King added a comment -

        Updated patch - excludes method parameter logic as that is already committed

        Show
        Paul King added a comment - Updated patch - excludes method parameter logic as that is already committed
        Hide
        Paweł Gdula added a comment -

        Is there any plan to fix this?

        Show
        Paweł Gdula added a comment - Is there any plan to fix this?
        Hide
        Mauro Molinari added a comment -

        This is especially annoying when you're dealing with statically compiled Groovy classes, for which the expectation for a compile-time error is even higher.

        Show
        Mauro Molinari added a comment - This is especially annoying when you're dealing with statically compiled Groovy classes, for which the expectation for a compile-time error is even higher.
        Hide
        Hendy Irawan added a comment -

        +1 for this, especially with @CompileStatic / @TypeChecked but I'd say this applies for dynamic as well

        Show
        Hendy Irawan added a comment - +1 for this, especially with @CompileStatic / @TypeChecked but I'd say this applies for dynamic as well

          People

          • Assignee:
            Unassigned
            Reporter:
            blackdrag blackdrag
          • Votes:
            8 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated: