expression switch vs. procedural switch

[Kevin Bourrillion]

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>