Bitten by the lambda parameter name

[Remi Forax]

On 07/15/2013 05:59 PM, Zhong Yu wrote:
> On Mon, Jul 15, 2013 at 10:34 AM, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> 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
> It is also very annoying that this doesn't compile
>
>          int x = 1;
>
>          {
>              int x = 2;
>          }
>
> It is too hard to give a distinct name to every variable. Remi is
> right this is a big PITA.

No, I'm fine with this.
You don't need two different things to be named with the same name,
so the rule on block helps to catch bugs.

With a lambda, it's the opposite, you need to find two names for the 
same thing,
and this stupid rule bugs me.

Rémi

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