Bitten by the lambda parameter name

[Remi Forax]

On 07/15/2013 05:32 PM, 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.
>
> Maurizio

What we have discussed was: should the lambda be an object (have an 
identity etc) or not ?
A lambda is an anonymous function, neither an anonymous class nor a block.

Rémi

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