In Java, why can't I use a lambda as an enhanced for loop's Expression?

Question

Assume we have an Iterator<Integer> iterator. Because Iterable is a functional interface, we can write:

Iterable<Integer> iterable = () -> iterator;

We can then of course use iterable as an enhanced for loop's Expression:

for (Integer i : iterable) foo(i);

So why is

for (Integer i : () -> iterator) foo(i);

not allowed? (It results in the following compiler error:)

error: lambda expression not expected here
    for (Integer i : () -> iterator) foo(i);
                     ^

Making the target type explicit like

for (Integer i : (Iterable<Integer>) () -> iterator) foo(i);

obviously works, but why can the compiler not infer the λ-expression's target type if it is omitted? From the fact that the Expression is in λ notation, should it not be clear to the compiler that the target type cannot be an Array, and hence must be Iterable?

Is this just an oversight by the language designers, or is there something else I am missing here?

Answer 1

This is not just about lambda expression; it's about all poly expressions that require target typing.

One thing for sure is that this is not an oversight; the case was considered and rejected.

To quote an early spec :

http://cr.openjdk.java.net/~dlsmith/jsr335-0.9.3/D.html

Deciding what contexts are allowed to support poly expressions is driven in large part by the practical need for such features:

The expression in an enhanced for loop is not in a poly context because, as the construct is currently defined, it is as if the expression were a receiver: exp.iterator() (or, in the array case, exp[i]). It is plausible that an Iterator could be wrapped as an Iterable in a for loop via a lambda expression (for (String s : () -> stringIterator)), but this doesn't mesh very well with the semantics of Iterable.

My take is that, each invocation of Iterable.iterator() must return a new, independent iterator, positioned at the beginning. Yet, the lambda expression in the example (and in your example) returns the same iterator. This does not conform to the semantics of Iterable.

---

In any case, it seems unnecessary work to support target typing in for-each loop. If you already have the iterator, you can simply do

    iterator.forEachRemaining( element->{ ... } )

Or if you prefer old-school

    while(iterator.hasNext()) {
        Foo elment = iterator.next();

Neither are too bad; it's not worth complicating the language spec even more. (If we do want for-each to provide target typing, remember it needs to work for other poly expressions as well, like ?:; then for-each can become too difficult to understand in some cases. And in general, there are two possible target types, Iterable<? extends X> | X[], which is very difficult for the type inference system.)

---

The for-each construct could be considered a syntax sugar because lambda wasn't available. If the language already has lambda expression, it is really unnecessary to have a special language construct to support for-each; it can be done by library APIs.

Answer 2

In the Lambda Expressions documentation, they list the scenarios in which the target type can be inferred, specifically:

To determine the type of a lambda expression, the Java compiler uses the target type of the context or situation in which the lambda expression was found. It follows that you can only use lambda expressions in situations in which the Java compiler can determine a target type:

• Variable declarations

• Assignments

• Return statements

• Array initializers

• Method or constructor arguments

• Lambda expression bodies

• Conditional expressions, ?:

• Cast expressions

This scenario is none of these, so the target type cannot be inferred. I agree with you that the target type can never be an array (because an array is not a functional interface), but the documentation is clear that this is not one of these scenarios.

Specifically, in the JLS 15.27.3, it says:

A lambda expression is compatible in an assignment context, invocation context, or casting context with a target type T if T is a functional interface type (§9.8) and the expression is congruent with the function type of the ground target type derived from T.

• Assignment context - Assignment contexts allow the value of an expression to be assigned (§15.26) to a variable.
• Invocation context - Invocation contexts allow an argument value in a method or constructor invocation
• Casting context - Casting contexts allow the operand of a cast operator (§15.16) to be converted to the type explicitly named by the cast operator.

Clearly, this is none of these. The only one that's even possible is an Invocation context, but the enhanced for loop construct is not a method invocation.

---

As far as "why" this scenario is not allowed by the Java authors, I have no idea. Speaking to the mind of the writers of Java is generally outside the scope of Stack Overflow; I have attempted to explain why the code doesn't work, but I can't guess why they chose to write it this way.

Addendum, the explanation / discussion in @bayou.io's answer is still present in the final version of JSR-335:

Lambda expressions and method references may only appear in certain contexts, and their type and correctness are determined by this context. Other kinds of expressions in the existing language have already introduced dependencies on context, and this is a trend that seems likely to continue. Rather than treat each new feature in an ad-hoc manner, the introduction of poly expression and an explicit recognition that target types can influence expression types allows us to unify handling of context-dependent expressions under a single umbrella.

... snip

The expression in an enhanced for loop is not in a poly context because, as the construct is currently defined, it is as if the expression were a receiver: exp.iterator() (or, in the array case, exp[i]). It is plausible that an Iterator could be wrapped as an Iterable in a for loop via a lambda expression (for (String s : () -> stringIterator)), but this doesn't mesh very well with the semantics of Iterable.

Answer 3

As durron597 explains you can only use a lambda expression in situations in which the Java compiler can determine a target type.

In a for-each loop :

for ( FormalParameter : Expression ) Statement

The JLS says that :

The type of the Expression must be Iterable or an array type (§10.1), or a compile-time error occurs.

Which means two different types are allowed, not one as required for a lambda expression, thus there was no way to design the language in a way that lambda expressions would work in for-each loops. Not with the concept of lambda expression used.

When you add a cast then only one type is allowed, thus the compiler can determine a target type for the lambda expression. Which is why "Making the target type explicit" works.