Totality at switch statements

[Nathan Reynolds]

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.

Eclipse will give me a warning if there are missing cases but not missing
ternaries.  I really like that feature.  It means I can add an enum and
Eclipse will let me know all the places I need to fix.  Sadly, I can ignore
these warnings and waste a lot of time debugging the missing cases.

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.

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/45707e23/attachment.htm>