Lambdas in for-each loops

[Sergey Kuksenko]

On 09/05/2012 04:36 PM, 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) {
>       ...
>     }
>
> 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)
At such case I have a serious question - why for-each loop doesn't allow 
to use Iterator? Why do we need only Iterable (and arrays of course) ?
May be it may sense to expand for-each loop itself and detach the 
problem from lambda? it looks like we something like project Coin2.0 for 
such things.


>
> Rémi
>
>


-- 
Best regards,
Sergey Kuksenko