Totality at switch statements

[Brian Goetz]

> As always, your answers are well thought out and have good points.  I 
> wonder if it would make sense to write up a design page, document the 
> choices and why one choice was picked over another.  Then, have your 
> team review it and then the world via JEP.  This way future and other 
> language designers can benefit from the information.  If some future 
> designer wants to change the language, they can read the document and 
> realize all the constraints and hidden pits.

We did something like that for a few of the features (see the FAQ / 
style guides Stuart Marks put together for Local Variable Type 
Inference, and for Text Blocks.)  It would be great to have them for all 
the features, and keep them updated as new questions come up and get 
answered here.  In a perfect world, we would!  But sometimes there are 
too many things to do.  We'd welcome contributions on this.

> I love that Java will require exhaustiveness in switch and provide the 
> feature for more data types.  It will do one of two things.  I can 
> either put all the cases and know that all situations are handled, OR 
> I can add a default and add error handling for an unexpected 
> situation.  It will help me write more robust code without having to 
> write as many unit tests.  As you pointed out, I will spend less time 
> debugging and furthermore writing a unit test to reproduce the problem.

Exactly!  And another benefit is that someone reading the code can tell 
whether you intended the switch to cover all the cases, or not, just by 
looking for a default / total case.  (Right now the positioning of 
`default` is unconstrained, as it always was, but we may require it 
float to the bottom, to make it easier to find the catch-all case.)

A subtle point about exhaustiveness that people don't often realize is 
that, when switching over a domain with exhaustiveness information 
(enums or sealed types), it is better *not* to have a default, and 
instead let the compiler insert a throwing default to catch separate 
compilation errors.  Because then, if someone adds a new enum constant 
or subtype later, you find out next compile time, rather than at run time.

(Which reminds me of another thing to add to my response to Hunor on the 
topic: because we add a throwing default to total switches that don't 
already have a catch-all case, this would be yet another subtle and 
surprising difference between switch expressions and switch statements.)

>
> On Sun, Jun 19, 2022 at 7:42 AM Brian Goetz <brian.goetz at oracle.com> 
> wrote:
>
>
>     > I haven't played with switch expressions, but I think of them
>     kind of
>     > like this but much more performant...
>     >
>     > int y = x == 0 ? 0 : x == 1 ? 2 : x == 2 ? 4 : x == 3 ? 6;
>
>     I encourage you to broaden how you think of this.  Yes, they might be
>     more performant (though they might not be -- a good compiler can chew
>     this up too), but that is is both a secondary, and a dependent,
>     benefit.  The alternative is:
>
>          int y = switch (x) {
>              case 0 -> 0;
>              case 1 -> 2;
>              case 2 -> 4;
>              default -> 6;
>          }
>
>     which I'm sure everyone finds more readable.
>
>     The primary benefit is that you are using a simpler, more constrained
>     concept.  A chain of ternaries or if-else can have arbitrary and
>     unrelated predicates, and offers less opportunity for exhaustiveness
>     checking.  It involves unneeded repetition ("x == <something>")
>     which is
>     a place for errors to hide in.  The fact that each predicate in the
>     chain above is of the form `x == <something>` is neither mandated nor
>     checked nor even obvious at first glance; this makes it harder to
>     read
>     and more error-prone; you could easily fumble this for "z == 2"
>     and it
>     would be hard to notice.  Whereras a switch has a distinguished
>     operand;
>     you are saying "this operand should match one of these cases", and
>     readers know it will match *exactly* one of those cases.  That is
>     a more
>     constrained statement, and by using a more specialized tool, you can
>     make the calculation more readable and less error-prone.
>
>     The performance benefit, if there is one, comes from the fact that
>     you
>     have performed a semantic "strength reduction", which is potentially
>     more optimizable.  But that's a totally dependent benefit, one which
>     flows from having written more clear, specific code in the first
>     place.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220619/64d3681e/attachment-0001.htm>