Lambdas in for-each loops

[Remi Forax]

On 09/05/2012 03:15 PM, Maurizio Cimadamore wrote:
> On 05/09/12 13:36, Remi Forax wrote:
>> On 09/05/2012 01:29 PM, Maurizio Cimadamore wrote:
>>> On 05/09/12 11:52, Peter Levart wrote:
>>>> I don't know about compiler internals but "proceed" attempt in the 
>>>> above is
>>>> meant to represent some kind of attribution phase on the clone of 
>>>> the sub-tree
>>>> that represents the "exp" so that the unsuccessfull attribution 
>>>> effects can be
>>>> undone and re-tried with different input...
>>> I think the point is: is there enough value in the proposed feature 
>>> (add lambda support in for-each loop) to justify this increase in 
>>> complexity? If the main use case is to convert an existing iterator 
>>> into an Iterable instance, it seems to me that we can achieve a very 
>>> similar effect w/o any language modification and using an API-base 
>>> approach:
>>>
>>> for (String s : Iterables.asIterable(it)) { ... }
>>>
>>> Which, with some static import magic can be reduced to:
>>>
>>> for (String s : asIterable(it)) { ... }
>>>
>>> Which is even shorter than the lambda version.
>>>
>>> Maurizio
>>
>> It's not enough, this should work too,
>>   NavigableMap<String> map = ...
>>   for(String s: map::descendingIterator) {
>>     ...
>>   }
> Why?
>
> NavigableMap<String> map = ...
>   for(String s: asIterable(map.descendingIterator())) {
>     ...
>   }

right :)

>>
>> In my opinion, the spec should say that resolving a foreach is 
>> equivalent to trying to revolve two overloaded methods,
>> with:
>>   for(X x: expr)  {
>>    ...
>>   }
>> it should be equivalent to try to call method m of class Foo, like this
>>   class Foo {
>>     static void m(X[] array) { ... }
>>     static void m(Iterable<? extends X> iterable) { ... }
>>   }
>> with the call Foo.m(expr)
> Except that the contents of the class Foo would vary depending on X - 
> i.e. if X is a primitive the second method doesn't really make sense. 
> The class also might need primitive arrays version of the method m.

if X is primitive, there is no point to have the class Foo.

>
> Maurizio

Rémi