> On Aug 25, 2020, at 7:53 PM, Brian Goetz <brian.go...@oracle.com> wrote:
>
>
>>
>>> We can still ponder whether “default <pattern>” should issue a static error
>>> if the <pattern> is not total. We can furthermore ponder whether “default
>>> <pattern>” should require the <pattern> to be strongly total or just weakly
>>> total.
>>
>> On reflection, I believe that in addition to having a choice of `switch` or
>> `total-switch`, we should indeed be a little more careful about `default`
>> switch labels and break them down as follows:
>>
>> plain `default` as a switch label means the same as `case var _`
>> (which is always _strongly_ total on the type of the selector
>> expression)
>>
>> `default <enum constant>` and `default <string constant>` and `default
>> <int constant>` are not permitted
>>
>> `default <type pattern>` means the same thing as `case <type pattern>`
>> but it is a static error if the <type pattern> is not _strongly_
>> total on the type of the selector expression
>>
>> `default <deconstruction pattern>` means the same thing as `case
>> <deconstruction pattern>`
>> but it is a static error if the <deconstruction pattern> is not
>> _weakly_ total on the type of the selector expression
>
>
> FWIW, this is the same as I was going to propose. It is equivalent to the
> notion that the optional pattern is always at least weakly total, given that
> deconstruction patterns are the only ones that can currently be weakly total.
> I’ll add that in the last case, it is as if there is an implicit `case null:
> throw`.
>
> We might also consider requiring that `default` always be the last case
> (which is also a way to outlaw the dual defaults.) Given that the only
> residue from the only non-strongly-total pattern allowable is “null”, it
> seems better to allow only one default.
I concur; I stopped short of that in my previous message to highlight the fact
that it s a separate decision.
