Yield considered harmful

[Stephen Colebourne]

On 9 July 2010 23:13, Pavel Minaev <int19h at gmail.com> wrote:
> The hypothetical new syntax does not need to apply to "return" - it
> can apply to the lambda as a whole. E.g.:
>
>  words.forEach() {# word ->
>     if (word.contains("http")) {
>         return word;
>     }
>  }
>
> where # is a placeholder for something that distinguishes this form of
> lambda (a "block" in Ruby parlance) from a proper function. The
> meaning of "return" in the body of such a lambda is then adjusted, and
> "break" and "continue" are permitted.
>
> Such a lambda expression could furthermore have a distinct type, which
> could, for example, be used to prevent it from escaping the scope in
> which "break" and "continue" are meaningful (by restricting that type
> for return values, fields, captured mutable locals etc).

The option FCM-JCA outlined followed the strategy of using syntax to
enable two uses of "return"

Syntax A example:
  forEach(list, #(str) {  // looks more like an inner class
    if (str.length() > 3) return;  // local-return
    System.out.println(str);
  });

Syntax B example:
  list.each() for (String str) {  // looks like a code block
    if (str.length() > 3) return;  // lexical return
    System.out.println(str);
  }

In syntax A (ie. the current project Lambda), "return" is a
local-return. In syntax B (some future language change) "return" is
lexical (and the block might not even be implemented using a
"closure-like" technique). Thus, the two pieces of code are not
equivalent.

The point here is that using "return" now is not limiting to the
future addition of lexical "return" - so long as the *syntax* used
*now* is obvious (inner class like) and allows enough syntax space for
a future separate change (code abstraction like).

And any desire for adding lexical returns from syntax A in a future
release would use a new syntax, of which many have been proposed
(throw return, long return, methodname.return ....)

In summary, using "return" now does not constrain future options hence
"yield" is a distraction. The trick to keep future options open is the
right syntax choice.

Stephen