Call for bikeshed -- break replacement in expression switch

John Rose 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-experts mailing list