Can the expression before the :: refer to any method parameters? Of
course, it would still expect to pass those parameters into the
method, so it's /weird/ to have the same parameter used in both ways,
but does it make sense to forbid it?
Yes, it makes sense to forbid. Here's why.
The framing of
method declaration = behavior literal
is meant to suggest that the thing on the RHS can be computed ONCE, and
that's the "body" of the method. Therefore, it should only be
computable based on what is known in the context of the method (static
state for static methods, instance state for instance method.) It is
not merely a shorthand for "take the method ref, turn it into a lambda,
and then turn the body of that lambda into a method body."
So the thing on the left of the :: must be something that could be, say,
the RHS of a field initializer of the appropriate static-ness.
Now we want to introduce a second way to use method references, where
that creation/evaluation distinction doesn't exist.
Same distinction. You can think of the creation as happening in <init>
/ <clinit>.
Now, a fair question is: when should we evaluate that LHS? And, is it
an error or warning if that LHS is, for example, a nonfinal field? Good
question! Thanks for bringing this up.
Finally, to my earlier screed about the trade-offs of "multiple ways
to do the same thing" I want to add a nice (very paraphrased) point
that was made on reddit by a now-deleted account. (Thanks, mystery
person.) Offering users a choice between two ways to do the same thing
isn't /just/ offering them a choice. It's also burdening them with
having to read and maintain code that made each of those choices, for
whatever reasons that may be unknowable now.
Yes, this is a valid concern. It will spur the usual "when should I use
an anonymous class vs named class" FAQs, style guide wars, etc. FWIW,
the C# folks went through this, there was the usual noise at the
beginning, but after the dust settled, the concise method bodies (the
arrow form, they don't have the stronger form) has become a fairly
popular feature.
