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

[Remi Forax]

As Brian said, parameter names are part of the API,
Most if not all IDEs support @SuppressWarnings("unused") to said that an implementation will not use a specific parameter,
but there is no way to said that a parameter name should not be used in term of API.

So i'm in favor of D with the javadoc saying that a parameter named '_' should not be used.

Rémi


----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>, "John Rose" <john.r.rose at oracle.com>
> Cc: amber-dev at openjdk.java.net
> Envoyé: Samedi 1 Juillet 2017 14:39:25
> Objet: Re: [lambda-leftovers] Underscore parameter for abstract/native methods

> No, nothing stopping us from starting at A and then going to B/C/D.
> 
> On 6/30/2017 7:57 PM, Maurizio Cimadamore wrote:
>> Is there something that prevents us to go from, say A to C/D in steps,
>> rather than all at once?
>>
>> Seems to be that, being A about being conservative, it should keep
>> most doors open for whatever extension of '_' we might plan in the
>> future. Am I missing something?
>>
>> Maurizio
>>
>>
>> On 30/06/17 23:04, John Rose wrote:
>>> On Jun 30, 2017, at 2:38 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>>> And once we bring in methods, it raises tooling questions like "what
>>>> about Javadoc." So maybe the last step was the problem.
>>> If it's only javadoc that's the problem, then that's an easy call:
>>> we should Inconvenience the javadoc authors if it will help a
>>> tiny fraction of java developers.
>>>
>>> In fact, even if it is 20 tools (and it won't—e.g., reflection already
>>> handles missing parameter names), it's still arguably a pure
>>> question of whether it's good for developers, as long as the
>>> effect on tool writers is a temporary irritant.
>>>
>>> — John