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

[Brian Goetz]

Good thought!  

Yes, unnamed parameters are entirely an implementation detail.  There’s a spectrum from local variables (pure implementation detail) to abstract methods (pure interface declaration), with public concrete methods being somewhere in the middle.  

Let’s say we drew the line as you suggest — outlaw _ for abstract methods.  As you say, these are interface declaration — and an unnamed parameter in an interface declaration could easily be confused for “this parameter may not be used”, which is probably not what is meant.  

Now, what about default methods?  Really, the same argument applies — this is an interface declaration, even though it happens to have a fallback implementation.  

OK, what about non private concrete methods?  Here we’re on shaky ground.  On the one hand, this is an interface too — on the other hand, it is an implementation.  But …. under what conditions would someone want to leave a parameter unnamed in a concrete method?  This really only happens when the method overrides a declaration from elsewhere.  

So, I think a sensible and consistent way to draw this line for method parameters would be:
 - Only allowed in concrete class methods that override a declaration from somewhere else.  



> On Jun 25, 2017, at 12:51 PM, Tagir Valeev <amaembo at gmail.com> 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.