expression switch vs. procedural switch
Kevin Bourrillion
kevinb at google.com
Tue Mar 13 23:47:45 UTC 2018
On Tue, Mar 13, 2018 at 2:21 PM John Rose <john.r.rose at oracle.com> wrote:
(Or is "fallthrough" the phenomenon where several case labels converge
> to one statement? I am doubtful that is what you mean because it seems
> expression switches are very likely to need to reply to several target
> values with one expression, just as with statement switches.)
>
Nope, I just consider that to be multiple labels on a statement group, as
implied by JLS 14.11.
C is a tautology, so I'm not sure what it tells us. Are you saying that
> order-invariance is an important property for expressions but not
> statements?
>
Yeah, it follows from the absence of fall-through, and I retract listing
it. :-) I was just in the mode of noting various ways we like that
expression switches are simple.
> D is an extension of A, upgrading the branch-free property to the
> absence of all side effects, making s-switches like lambdas. I do
> *not* think this is a realistic goal, not even for a highly disciplined
> shop like Google.
>
I have no illusions of preventing side effects. I simply don't place much
value on those use cases when evaluating usability of the feature. This was
really more relevant to my other thread.
The way I see it, D is undesirable, A is necessary to the physics
> of expressions but doesn't tell us anything about the nature of
> e-switch, and B and C apply to both kinds of switches. So
> there's nothing here that teaches us to treat e-switch as
> something with its own special mission defined by its limitations.
>
I think "B and C apply to both" is an oversimplification for both B and C.
Only expression switches are exhaustive (whether via default or not) by
their very nature. And case order matters when fall-through can exist.
However, even if this argument is entirely valid, it still seems to be more
relevant to a scenario where we get to design "both kinds" of switch at
once in a brand new language. The fact that procedural switch has already
been around 20+ years is the major reason why I'm advocating that we leave
it alone.
> Instead, I very much believe in Brian's design heuristic of
> running a refactoring exercise over switch use cases, to make
> sure that there is (when possible) an easy transition between
> s-switch and e-switch.
>
I would add "for the subset of switch statements that we consider to be
expression-shaped", but maybe this is where we have some disagreement?
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180313/16ea8772/attachment.html>
More information about the amber-spec-experts
mailing list