Minor wording issue around effectively final definition

[Neal Gafter]

Sorry, the example should have been

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


Cheers,
Neal

On Mon, Feb 11, 2013 at 4:36 PM, Neal Gafter <neal at gafter.com> wrote:

> 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
>
>
>