Bitten by the lambda parameter name

[Maurizio Cimadamore]

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.

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
>