<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:CAJSbYaVf3TfkoiRqZ5DUV+ZwCG6xzbYUD3qGjXuP0=pPzxNsJg@mail.gmail.com">
<div dir="ltr">Surely, the totality is necessary at
switch expressions, but forcing it at a statement is
questionable.</div>
</blockquote>
<br>
I understand why you might feel this way; indeed, when we made this
decision, I knew that we would get mails like this one. There were
a number of forces that pushed us in this direction; I will try to
explain some of them, but I don't expect the explanation to be
compelling to all readers. <br>
<br>
One of the things that makes upgrading `switch` difficult is that
developers have an existing mental model of what switch "is" or "is
for", and attempted upgrades often challenge these models. But the
goal here is not simply to make switch "better" in a number of ways
(better exhaustiveness checking, better null handling, patterns,
smoother syntax). Of course we like these improvements, but the
goal is bigger. But it's easier to be aware of the role switch
plays today, than the role we expect it to play tomorrow, so these
improvements might feel more like "forced improvements for the sake
of some abstract ivory tower purity." <br>
<br>
<blockquote type="cite" cite="mid:CAJSbYaVf3TfkoiRqZ5DUV+ZwCG6xzbYUD3qGjXuP0=pPzxNsJg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">It can be
helpful for the programmers to check the totality in those
cases when the intent is that. But it is quite common to
create a switch statement that doesn't handle all of the
possibilities. <br>
</div>
</div>
</blockquote>
<br>
This raises two questions: <br>
<br>
- Why is it so common? <br>
- Is it good that it is common? <br>
<br>
One of the reasons it is common is that the switch statement we had
is so weak! The set of types you can switch over is limited. The
set of things you can put in case labels is limited. The set of
things you can do is limited (until recently, you were forced to do
everything with side-effects.) The switch statement we have in Java
was copied almost literally from C, which was designed for writing
things like lexers that look at characters and accumulate them
conditionally into buffers. Partiality is common in these weak use
cases, but in the use cases we want to support, partiality is more
often a bug than a feature. So saying "it is common" is really
saying "this is what we've managed to do with the broken, limited
switch statement we have today." Great that we've been able to do
something with it, but we shouldn't limit our imagination to what
we've been able to achieve with such a limited tool. <br>
<br>
To my other question, try this thought experiment: if switch was
total from day 1, requiring a `default: ;` case to terminate the
switch (which really isn't that burdensome), when you were learning
it back then, would you even have thought to complain? Would you
even have *noticed*? If there was a budget for complaining about
switch in that hypothetical world, I would think 99% of it would
have been spent on fallthrough, rather than "forced default". <br>
<br>
<blockquote type="cite">Why would it be different using patterns?
Why is it beneficial to force totality? </blockquote>
<br>
Because patterns don't exist in a vacuum. There's a reason we did
records, sealed classes, and patterns together; because they work
together. Records let us easily model aggregates, and sealed types
let us easily model exhaustive choices (records + sealed classes =
algebraic data types); record patterns make it easy to recover the
aggregated state, and exhaustive switches make it easy to recover
the original choice. We expect that the things people are going to
switch over with patterns, will have often been modeled with sealed
classes. <br>
<br>
Java has succeeded despite having gotten many of the defaults
wrong. We've all had to learn "make things private unless they need
to be public." "Make fields final unless they need to be mutable."
It would have been nice if the language gave us more of a nudge, but
we had to learn the hard way. Switch partiality is indeed another
of those wrong defaults; you don't notice it until it is pointed out
to you, but then when you think about it for enough time, you
realize what a mistake it was. <br>
<br>
In the current world, partiality is the default, and even if a
switch is total, it may not be obvious (unless you explicitly say
"default"); flipping this around, a switch with default is a sign
that says "hey, I'm partial." Partiality is an error-prone
condition that is worth calling attention to, so flipping this
default is valuable -- and we have an opportunity to do so without
breaking compatibility. <br>
<br>
The value of totality checking is under-appreciated, in part because
until recently there were so few sources of exhaustiveness
information in the language (basically, enums). But many
non-exhaustive switches are an error waiting to happen; the user
thinks they have covered all the cases (either in fact, or in
practicality). But something may happen elsewhere that undermines
this assumption (e.g., a new enum constant or subtype was added.)
With totality, we are made aware of this immediately, rather than
having to debug the runtime case where a surprising value showed
up. <br>
<br>
Worse, now the language has switch expressions, which *must* be
total. Having one kind of switch be total and another not is
cognitive load that users (and students) have to carry. (Yes, there
are still asymmetries in switch that have this effect; that's not a
reason to load up with more.) But it gets even worse, because
refactoring from a switch expression to a switch statement means you
lost some safety that you were depending on when you wrote the
original code, and may not be aware of this. <br>
<br>
If you've not programmed with sealed types or equivalent, it is easy
to underestimate how powerful this is. I'd like us to be able to
get to a world where we almost never use "default" in switch, unless
we are deliberately opting into partiality -- in which case the
"default" is a reminder to future maintainers that this is a
deliberately partial switch. <br>
<br>
<blockquote type="cite" cite="mid:CAJSbYaVf3TfkoiRqZ5DUV+ZwCG6xzbYUD3qGjXuP0=pPzxNsJg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">This check
can be an IDE feature. <br>
</div>
</div>
</blockquote>
<br>
Yes, that was one of the choices. And we considered that. And it
is reasonable that you wish we'd made another choice. But, be aware
you are really arguing "make the language less safe and more
error-prone, please" -- and ask yourself why you think its a good
idea to make the language less uniform and less safe? I think
you'll find that the reason is mostly "someone moved my cheese."
(<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Who_Moved_My_Cheese%3F">https://en.wikipedia.org/wiki/Who_Moved_My_Cheese%3F</a>). <br>
<br>
<blockquote type="cite" cite="mid:CAJSbYaVf3TfkoiRqZ5DUV+ZwCG6xzbYUD3qGjXuP0=pPzxNsJg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">Honestly I
feel that the rule, when the totality is forced, is dictated
simply by the necessity of backward compatibility. What will
happen if a new type (for example double) will be allowed for
the selector expression? The backward compatibility wouldn't
be an issue, but it would be weird behaving differently with
an int compared to a double, so I guess the totality won't be
forced. What would happen if the finality requirement was
removed, and the equality could be checked for all types? What
about the totality check in this imagined future?</div>
</div>
</blockquote>
<br>
I don't really understand what you're getting at in this paragraph,
but I'll just point out that it really underscores the value of a
uniform switch construct. You're saying "but I don't see how you'll
get there from legacy int switches, so therefore its inconsistent"
(and implicitly, one unit of inconsistency is as bad as a million.)
But you don't seem to be equally bothered by the much more impactful
inconsistency we'd have if expression switches were total and
statement switches were not. <br>
<br>
You are correct that there are legacy considerations that will make
it harder to get to a fully uniform construct (but, there's still
things we can do there.) But that's not an excuse to not design
towards the language we want to have, when we can do so at such
minor inconvenience. <br>
<br>
But the main thing I want you to consider is: right now, the switch
we have is very, very limited, and so we've convinced ourselves it
is "for" the few things we've been able to do with it. By making it
more powerful (and combining it with complementary features such as
pattern matching, and sealing), these few cases -- which right now
feel like the whole world of switch -- will eventually recede into
being the quirky odd cases. <br>
<br>
<blockquote type="cite" cite="mid:CAJSbYaVf3TfkoiRqZ5DUV+ZwCG6xzbYUD3qGjXuP0=pPzxNsJg@mail.gmail.com">
<div dir="ltr">Additionally, there are issues with the "empty"
default clause. In the JEP the "default: break;" was
recommended, but interestingly it doesn't work with the arrow
syntax. ("default -> break;" is a compile time error, only
the "default: {break;}" is possible.) We can use both the
"default: {}" and "default -> {}", which is fine. But while
the "default:" is possible (without body), the "default ->"
is an error. I don't know what is the reason behind it. Allowing
an empty body with the arrow syntax would make the actual
solution a little bit cleaner.</div>
</blockquote>
<br>
This is a fair observation; this should probably be cleaned up. <br>
<br>
<blockquote type="cite" cite="mid:CAJSbYaVf3TfkoiRqZ5DUV+ZwCG6xzbYUD3qGjXuP0=pPzxNsJg@mail.gmail.com">
<div dir="ltr">It would be possible to allow the programmer to
mark the intended totality. Maybe a new keyword would be too
much for this purpose. </div>
</blockquote>
<br>
Yes, we considered this, and came to the conclusion that the problem
is the wrong default. Adding a new keyword for "total switch" is
bad in three ways: it is, as you say, "too much"; it doesn't fix the
underlying problem; and the cases in which it most needs to be used,
people will probably forget to use it. <br>
<br>
<br>
</body>
</html>