Opting into totality

[Brian Goetz]

>> 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.