Minor wording issue around effectively final definition

[Dan Smith]

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