Bitten by the lambda parameter name

[Maurizio Cimadamore]

On 15/07/13 16:32, Maurizio Cimadamore wrote:
> On 15/07/13 16:28, Remi Forax wrote:
>> On 07/15/2013 05:13 PM, Maurizio Cimadamore wrote:
>>> On 15/07/13 15:52, Remi Forax wrote:
>>>> This snippet not compile,
>>>>     Kind kind = ...
>>>>     partySetMap.computeIfAbsent(kind, kind -> new 
>>>> HashSet<>()).add(party);
>>>>
>>>> Each time I write more than a hundred lines of codes that use some 
>>>> lambdas,
>>>> I fall into this trap.
>>>>
>>>> It's very annoying !
>>>>
>>>> Rémi
>>>>
>>>>
>>> Annoying yes - but there is a reason for it? If we provide special 
>>> scoping for lambda parameters then we will never be able to add 
>>> control abstraction syntax in a nice way; not saying that it's 
>>> something we want - but it's good to have option open at least.
>>
>> It's a crystal ball argument, in the future if we do that then ...
>> It usually doesn't work because between now and the future, the way 
>> the feature will be introduced will change.
>>
> Well, yes and no - I remember we discussed a lot whether a lambda 
> should look (semantically) more like a block or an inner class. We 
> decided it should look like the former. This is a consequence of that 
> decision. I think that mixing and matching semantics on a by-need 
> basis is not a good idea.
And - one might argue the code you are trying to write is not that 
readable in the first place (adding random suffixes just to get it 
through javac is not very elegant readability-wise, but it does convery 
the concept that the two references of 'kind' which occur very close one 
to the other are indeed unrelated).

Maurizio
>
> Maurizio
>> In this peculiar case, if we add control abstraction syntax we will 
>> use a different syntax,
>> so it's very annoying for no reason.
>>
>>>
>>> Maurizio
>>
>> Rémi
>>
>