Lambdas in for-each loops
Remi Forax
forax at univ-mlv.fr
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,
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)
Rémi
More information about the lambda-dev
mailing list