expression switch vs. procedural switch

[John Rose]

On Mar 13, 2018, at 4:47 PM, Kevin Bourrillion <kevinb at google.com> wrote:
> 
> 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.

That's strictly true only in today's language, where it is also true
that there's no such thing as an expression switch.  In the future,
exhaustiveness is an interesting possibility for statement switches
also.  For legacy reasons (unless we redesign from scratch) it will
require a special marking on s-switches, where it will be a requirement
of e-switches.  That kind of nod to legacy is usually not big enough
to warrant shifting our scope to a from-scratch e-switch.  Although
it will be a pebble in the shoe.

Anyway, the different you are noting in e-switches is not that deep.
You get the same effects (required exhaustivness) if you refactor
the e-switch to an s-switch, with an assignment to a blank local
as the mechanism for exporting the value you want.  In that case,
exhaustiveness checks are in the current language, as DA rules.

(And note that if an e-switch delivers a second value, it will play
with DA rules, just like an s-switch that delivers 2 values.
So DA rules are common to both switches.)

Also, even for e-switches an explicit exhaustiveness marker is
desirable.  For both kinds of switches, there are cases where
the user wants to say, "I know I have covered all the possibilities"
and thus turn off the effects of exhaustiveness checking, including
DA rules and whatever DA-like rule we define for e-switches.

Summary:  No, I don't buy that e-switches are so special.

> And case order matters when fall-through can exist.

Case order will also matter with pattern switches.
Sometimes cases won't even be linearly orderable,
when multiple supertyping is in play.
Thats a much stronger reason to watch for case order
than fallthough (which is pretty terrible).

So when I see a bunch of case statements in legacy code, I say to myself,
"how nice that those guys are all disjoint, so I can edit my code the way
I want, and the compiler can do an O(1) lookup".  I don't see a different
kind of switch than something where cases overlap.  In that latter case,
the compiler might still manage an O(1) lookup, and the compiler/IDE
will guide me to prevent misordering.

> 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?

I regard the bridge between them as very wide.  You might be
more selective.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180313/63b11250/attachment-0001.html>