Call for bikeshed -- break replacement in expression switch
john.r.rose at oracle.com
Mon May 13 20:40:07 UTC 2019
On May 12, 2019, at 12:38 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> Digression: What’s so terrible about “return”, any why is it OK for lambdas but not OK for switches?
Although I like Lisp (block foo … (return-from foo x) …),
I buy your argument that "unwind the current call frame"
is different enough from "transfer control within the
current call frame", enough to merit syntactic difference.
There's a very subtle difference in Java (but not in Lisp)
between call frames and blocks which you didn't mention
directly but which tips the balance for me: A Java call
frame has side-effectable locals (because Java is an
imperative language, as you said). Thus, a block which
exits to the current call frame can also push side effects
to that call frame, while a block that unwinds to a
different call frame cannot push side effects to enclosing
variable bindings, because they will be in a different
call frame. That's a difference that is usually ignored
when reasoning about Java programs, thanks to the
implicitly final rule. Using distinct syntaxes for
same-frame block exits and different-frame unwinds
adds a little extra help to programmers to keep
track of the difference. It doesn't matter that programmers
usually don't care about the difference; having a syntax
difference might help them avoid surprise errors,
and allow them to keep the semantic differences
at a non-distracting subliminal level.
Thus, if I have to say "return" I know I can't return
an extra value by side effects, since all my up-level
variables will be final (implicitly or not). And if I
say "yield" I know I can return an extra value, if
I need to, by punching it into some visible local.
More information about the amber-spec-observers