Lambdas in for-each loops

[Maurizio Cimadamore]

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())) {
     ...
   }
>
> 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.

Maurizio
> Rémi
>