Minor wording issue around effectively final definition

[Neal Gafter]

Here is one example that does not work right according to the spec:

if (false) {
    int i;
    i = 2; // i is both definitely assigned and definitely unassigned here
    Runnable r = () => { int j = i; }; // error: i not effectively final
}


One way to fix this section of the spec is to remove the words "and not
definitely assigned" twice where they appear in the definition of
effectively final.

On Mon, Feb 11, 2013 at 10:53 AM, Dan Smith <daniel.smith at oracle.com> wrote:

> On Feb 11, 2013, at 7:00 AM, Srikanth S Adayapalam <
> srikanth_sankaran at in.ibm.com> wrote:
>
> > Hello !
> >
> >  0.6.1 (4.12.4) reads:
> >
> > A local variable or a method, constructor, lambda, or exception
> parameter is effectively final if it is not final but it never occurs as
> the left hand operand of an assignment operator (15.26) or as the operand
> of an increment or decrement operator (15.14, 15.15). [jsr335-4.12.4-10]
>
> > In addition, a local variable whose declaration lacks an initializer is
> effectively final if all of the following are true: [jsr335-4.12.4-20]
> >
> >       • It is not final. [jsr335-4.12.4-20-A]
> >       • Whenever it occurs as the left-hand operand of an assignment
> operator, it is definitely unassigned and not definitely assigned before
> the assignment (that is, it is definitely unassigned and not definitely
> assigned after the right-hand operand of the assignment) (16).
> >
> > I think the first sentence meant to say, never occurs as the left hand
> operand of a *compound* assignment operator.
>
> The intent is to cover both compound and simple assignments.
>
> The first sentence says that if you never assign to a variable, it's
> effectively final.
>
> The second sentence says that if you _do_ assign to a variable, it may
> still be effectively final if the assignment is the _first_ assignment.
>
> Note that there's a restriction, separate from "effectively final," that a
> variable must be definitely assigned wherever it is referenced, including
> in a compound assignment.
>
> I think the complexities you're worried about are bundled up inside the
> definitions of "definitely unassigned" and "definitely assigned".  But if
> you're unsure, feel free to share a concrete example of something you don't
> think will work right.
>
> —Dan