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

[Tagir Valeev]

Hello!

I see that A was selected and currenty I support it. Just a short opinion
against C for the record. There are many cases when method does not
override another one, but has to declare some parameters. Examples:
- public static void main: using main(String[] _) would indicate that
command line parameters are not used.
- name parameter in BootstrapMethodFactory: often it's unnecessary
- some annotation-based APIs when method annotation directs a framework to
call this method reflectively with specific parameters (but some of them
are not used actually)
- a lambda with unused parameter which was converted to a method for
convenient use as a method reference

So covering traditional inheritance, but not covering these cases looks
arbitrary indeed.

With best regards,
Tagir Valeev.

On Sat, Jul 1, 2017 at 12:38 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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.
>>
>
>