> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> Envoyé: Lundi 31 Août 2020 15:35:32
> Objet: Re: [pattern-switch] Opting into totality
> Totality is a term that language designers like, but may not be all that
> evocative to users. So switch-total might not exactly turn on the light bulb
> for them. In this manner, “sealed” has a useful connotation that has nothing
> to
> do with sealed types: non-leakiness: a sealed switch doesn’t leak any
> unprocessed values!
> Test driving ...
> sealed switch (x) { … }
> sealed-switch (x) { … }
> switch-sealed (x) { … }
> “A switch may be sealed with the sealed modifier; expression switches are
> implicitly sealed. The set of case patterns for a sealed switch must be total
> with some remainder; synthetic throwing cases are inserted for the remainder.”
Those are all "snitch" moves, let's avoid that because all you said about
having more than one kind of switch still apply.
Here are some facts that can help us,
- there is not a lot of existing switches in the wild
- as you said, there is a very good chance that the switch on types become the
dominant switch.
Now, divide and conquer,
1/ a switch on type (statement or expression) should always be non leaky
2a/ add a warning on all existing leaky statement switches forcing them to have
a default if not exhaustive
2b/ for an exhaustive enum switch, add a warning if the switch has a default.
and if there is no default, let the compiler add a "default -> throw ICCE",
it's a breaking change but it should be ok because IDEs currently ask for a
default in a switch on enums.
explanations
for 1/, it's about designing with the future in mind, if most switch are switch
on types, let have the right behavior
for 2a/, ask users to fix leaky statement switches, even if we introduce a
selaed-switch, we will need this warning to gradually move to a better world.
for 2b/, ask users to fix exhaustive enum switches so it works like a switch on
type.
I may be wrong with the idea of adding a "default -> throw" on enum switches
without a default, it may break a lot of codes, but i believe it worth the try.
And BTW, we should also emit a warning if the default is in the middle of the
switch, again to drive user to think in term of switch on type constraints.
Rémi
>> On Aug 31, 2020, at 9:25 AM, Brian Goetz < [ mailto:brian.go...@oracle.com |
>> brian.go...@oracle.com ] > wrote:
>> I think this is the main open question at this point.
>> We now have a deeper understanding of what this means, and the shape of the
>> remainder. Totality means not only “spot check me that I’m right”, but also
>> “I
>> know there might be some remainder, please deal with it.” So totality is not
>> merely about type checking, but about affirmative handling of the remainder.
>> Expression switches automatically get this treatment, and opting _out_ of
>> that
>> makes no sense for expression switches (expressions must be total), but
>> statement switches make sense both ways (just like unbalanced and balanced
>> if-else.) Unfortunately the default has to be partial, so the main question
>> is,
>> how do we indicate the desire for totality in a way that is properly
>> evocative
>> for the user?
>> We’ve talked about modifying switch (sealed switch), a hyphenated keyword
>> (total-switch), a trailing modifier (switch case), and synthetic cases
>> (“default: unreachable”). Of course at this point it’s “just syntax”, but I
>> think our goal should be picking something that makes it obvious to users
>> that
>> what’s going on is not merely an assertion of totality, but also a desire to
>> handle the remainder.
>>> - How does a switch opt into totality, other than by being an expression
>>> switch?
