<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:CALMUwcr7vGFN0szaqDnCUsS1iuaTBX__=dOGcFD-4mvOQLDGvg@mail.gmail.com">
<div dir="ltr">
<div>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.<br>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
<blockquote type="cite" cite="mid:CALMUwcr7vGFN0szaqDnCUsS1iuaTBX__=dOGcFD-4mvOQLDGvg@mail.gmail.com">
<div dir="ltr">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.<br>
</div>
</blockquote>
<br>
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.) <br>
<br>
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. <br>
<br>
(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.)<br>
<br>
<blockquote type="cite" cite="mid:CALMUwcr7vGFN0szaqDnCUsS1iuaTBX__=dOGcFD-4mvOQLDGvg@mail.gmail.com"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Jun 19, 2022 at 7:42
AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">brian.goetz@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> I haven't played with switch expressions, but I think of
them kind of <br>
> like this but much more performant...<br>
><br>
> int y = x == 0 ? 0 : x == 1 ? 2 : x == 2 ? 4 : x == 3 ?
6;<br>
<br>
I encourage you to broaden how you think of this. Yes, they
might be <br>
more performant (though they might not be -- a good compiler
can chew <br>
this up too), but that is is both a secondary, and a
dependent, <br>
benefit. The alternative is:<br>
<br>
int y = switch (x) {<br>
case 0 -> 0;<br>
case 1 -> 2;<br>
case 2 -> 4;<br>
default -> 6;<br>
}<br>
<br>
which I'm sure everyone finds more readable.<br>
<br>
The primary benefit is that you are using a simpler, more
constrained <br>
concept. A chain of ternaries or if-else can have arbitrary
and <br>
unrelated predicates, and offers less opportunity for
exhaustiveness <br>
checking. It involves unneeded repetition ("x ==
<something>") which is <br>
a place for errors to hide in. The fact that each predicate
in the <br>
chain above is of the form `x == <something>` is neither
mandated nor <br>
checked nor even obvious at first glance; this makes it harder
to read <br>
and more error-prone; you could easily fumble this for "z ==
2" and it <br>
would be hard to notice. Whereras a switch has a
distinguished operand; <br>
you are saying "this operand should match one of these cases",
and <br>
readers know it will match *exactly* one of those cases. That
is a more <br>
constrained statement, and by using a more specialized tool,
you can <br>
make the calculation more readable and less error-prone.<br>
<br>
The performance benefit, if there is one, comes from the fact
that you <br>
have performed a semantic "strength reduction", which is
potentially <br>
more optimizable. But that's a totally dependent benefit, one
which <br>
flows from having written more clear, specific code in the
first place.<br>
<br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>