Bitten by the lambda parameter name

[John Rose]

On Jul 17, 2013, at 9:48 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> I personally don't think it's a strong enough case; when I read
> x->++x, I'll see this is a new x, and the new x is being incremented.

Many of the Java language safety rules (including local shadowing rules) are not designed for the people on this mailing list.  They are designed for the other 99% of programmers, who are not so eager to process language corner cases.  And shadowing, however natural its logic is, gets experienced as a corner case, often enough to cause bugs in the field.  (No I don't have survey numbers.)

The value of anti-shadowing rules is less when declarations are more visible and/or can be placed in fewer syntactic locations.  This is why class members can participate in shadowing:  Class members generally occupy their own lines of code.  Parameters and locals are often declared inside other constructs (method headers, for loops), so they are harder to see.  Therefore, multiple competing definitions of these constructs are more confusing.  Guess which category lambda parameters fall in?  Hint:  A lambda parameter declaration can be one token long, and embedded in an expression.

So, regardless of how it outrages syntax-savvy users, I think it is better to forbid having lambda parameters participate in shadowing.

The two proposed use cases of (foo) -> (expr_not_containing_foo) seem especially wrong-headed to me.  Why *must* we allow users to have the exact name "foo", for a variable that isn't even used?  Because it is so important to insert a clever comment that the formal parameter "foo" (though unused) is known to the programmer to have the same value as an uplevel variable named "foo"?  There are other ways to comment code than choose a name for an unused variable!

— John