Lambdas in for-each loops

Remi Forax forax at
Wed Sep 5 05:36:20 PDT 2012

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


More information about the lambda-dev mailing list