Groovy
  1. Groovy
  2. GROOVY-4681

implement final for local variables

    Details

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

      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

      There are no Sub-Tasks for this issue.

        Activity

        Jochen Theodorou created issue -
        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
        Paul King made changes -
        Field Original Value New Value
        Attachment finalForLocalVarsTooStrict.patch [ 55966 ]
        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
        Paul King made changes -
        Attachment finalForParamsAndLocalVarsPartial.patch [ 55996 ]
        Attachment astNodeChangesWithFinal.patch [ 55997 ]
        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
        Paul King made changes -
        Attachment finalForLocalVariables.patch [ 56012 ]
        Paul King made changes -
        Attachment astNodeChangesWithFinal.patch [ 55997 ]
        Paul King made changes -
        Attachment finalForLocalVarsTooStrict.patch [ 55966 ]
        Paul King made changes -
        Attachment finalForParamsAndLocalVarsPartial.patch [ 55996 ]
        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?
        Jochen Theodorou made changes -
        Fix Version/s 1.8.x [ 15750 ]
        Jochen Theodorou made changes -
        Component/s Compiler [ 13529 ]
        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
        Mark Thomas made changes -
        Project Import Sun Apr 05 13:32:57 UTC 2015 [ 1428240777691 ]
        Mark Thomas made changes -
        Workflow jira [ 12733612 ] Default workflow, editable Closed status [ 12745329 ]
        Mark Thomas made changes -
        Project Import Mon Apr 06 02:11:23 UTC 2015 [ 1428286283443 ]
        Mark Thomas made changes -
        Workflow jira [ 12971073 ] Default workflow, editable Closed status [ 12978806 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Jochen Theodorou
          • Votes:
            9 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:

              Development