lambda expression parameters
John Rose
john.r.rose at oracle.com
Wed Jul 17 14:03:37 PDT 2013
On Dec 18, 2012, at 6:15 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> If "effectively final" were an option back then (don't know if it's something they thought about or not), I would bet we still wouldn't have 'final' parameters and local variables.
I was there. The language was too new back then (1996) for subtle rules like that. The user base was less tolerant of anything besides "simple, simple, simple". And we had no IDEs, and engineering friendly error messages from javac was a future want-to-have.
Apart from interactions with nested classes, it is slightly useful to extend constant-expression rules (which interact with switch cases, etc.) to defined local constants: { final int BITS_PER_BYTE = 8; ... } See JLS 4.12.4.
On Dec 18, 2012, at 3:55 PM, Michael Nascimento <misterm at gmail.com> wrote:
> I think they should be final when inferred.
+1 for inferring final also when inferring a type; feels like the magic on catch (X|Y ex)
Catching "x = 5" as a typo for "x == 5" is a very good target of opportunity. Throwing in the 'final' after inference does this for small lambdas which will be most common.
(x -> x++) // BAD
(x -> { int x1 = x; return x1++; }) // OK
((int x) -> x++) // OK
((final int x) -> x++) // BAD
— John
P.S. I agree with final-by-default in the Next Java. Not sure I'll be alive then.
More information about the lambda-dev
mailing list