> From: "Brian Goetz" <brian.go...@oracle.com>
> To: "Tagir Valeev" <amae...@gmail.com>, "amber-spec-experts"
> <amber-spec-experts@openjdk.java.net>
> Sent: Thursday, February 3, 2022 5:35:13 PM
> Subject: Re: Control flow analysis for exhaustive pattern-switch statement
> Thanks Tagir for digging into this. This is good analysis.
> The decision to require completeness of enhanced switches was taken relatively
> late, so its quite possible we have left something out. And in the next round,
> when nested patterns come along, we need to formalize totality and remainder,
> which also intersects with this problem. So this is timely.
[...]
>> I understand that the same reasoning does not apply for switch over
>> enums, as for compatibility reasons, default behavior is to do
>> nothing. However, for patterns, uninitialized `x` cannot appear after
>> the switch, even if we recompile the sealed interface separately
>> adding one more inheritor.
> Slight correction: *statement* switches over enums. We've carved out a place
> where the only switches that are not total, are *statement* switches over the
> legacy types with the legacy switch labels. In that case, DU analysis picks up
> some of the slack.
> (It is still on our "to be considered" list whether it is worth it to allow
> statement switches to be explicitly marked as total to engage greater
> typechecking, or whether we want to embark on the decade-long path of warning
> increasingly loudly on non-total switches until we eventually make them
> illegal.)
Both options are not exclusive, we can have a switch marked as exhaustive AND
have a warning to nudge people to the "right" path.
I believe we should mark a way to mark switch as total but i would prefer to
have a syntax which is not something like total-switch which to me is a
regression given that we have decided to rehabilitate the switch instead of
using another keyword (what's Brian called the snitch approach).
If we try to summarize the approachs we have discussed, we have
- use a new keyword like "total-switch"
- use a new keyword inside the parenthesis of the switch, switch(total value) {
... }
- use default -> throw new AnException()
- use default -> throw; as a shortcut
The two later propositions are not good because adding a "default" make the
switch exhaustive but we are lose the typechecking when a new enum constant is
introduced.
The two former propositions are not good because it's a snitch in disguise.
I believe a good compromise might be to have a syntax inside the curly braces
like "default -> " but not using "default" because it's not the semantics we
want.
It just occurs to me that we can use an ellipsis (...) for that
switch(option) {
case READ -> { }
case WRITE -> { }
case READ_WRITE -> { }
... // this is a real syntax, it means that the switch is total
}
An ellipsis is an opt-in way to ask for an exhaustive checking, it will fail at
compile time if one of the constants is not listed, and in case of separate
compilation at runtime an error will be thrown.
[...]
> Thanks,
> -Brian
Rémi
