[lambda-leftovers] Underscore parameter for abstract/native methods

[Brian Goetz]

So, a fair question is whether _ should be supported for methods at all, 
because (in many cases) method parameters are both declaration and 
implementation.  This feature started out for lambdas (whose parameters 
are pure implementation), and then got extended to catch formals (also 
pure implementation) and method parameters (not pure implementation.)  
And once we bring in methods, it raises tooling questions like "what 
about Javadoc." So maybe the last step was the problem.

Here's a menu of defensible options here:

A. Don't allow _ for method or constructor parameters.

B. Only allow _ for method parameters in *anonymous* classes. This has 
the advantage that it makes it easier to freely refactor lambdas to/from 
anon classes.

C. The option I proposed the other day -- only allow _ as a method 
parameter name for concrete class methods that are known to be an 
@Override of some other method.  This excludes all interface and 
abstract methods, constructors, and "initial declarations" of methods in 
base classes.

D. Allow it in all methods.


Now that this has been pointed out, I'm pretty down on D.  C is 
defensible, but likely will feel arbitrary.  B does has a nice symmetry 
to it, but it means it drags tooling support (Javadoc) into the 
feature.  And A avoids the problem entirely.  (Though, like with LVTI, 
people will inevitably ask "but what about private methods?  And they'd 
get the same answer, regarding source compatibility of modifier changes.)

Leaning towards A....

On 6/25/2017 6:51 AM, Tagir Valeev wrote:
> Hello!
>
> Currently in lambda-leftovers underscore is allowed as a parameter name for
> abstract methods. This looks dubious as normally underscore means that
> parameter is not used in the corresponding method/lambda/catch body, but
> there's no actual body and no parameter is actually used anyways (but could
> be used in abstract method implementations). I think, allowing underscores
> for interface methods may encorage bad practices of defining interfaces
> without readable parameter names:
>
> interface X {
>    void doSomething(int _, long _, String _);
> }
>
> Should not this be disabled?
>
> It's even worse for native methods, because underscore assumes that
> parameter is not used, but it does not limit the corresponding native
> implementation from using it.
>
> With best regards,
> Tagir Valeev.