Opting into totality

[Guy Steele]

> On Aug 25, 2020, at 2:08 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> . . .

[good analysis up to this point]

> Which leaves:
> 
>    { statement, expression } x { arrow, colon } x { switch, total-switch }
> 
> where an expression switch of any stripe is automatically upgraded to a total-switch of that type.

This description actually does not quite describe the current behavior: for an expression switch, if the type of the selector expression is enum, then the switch is _assumed_ to be total (the user need not supply a “default” label), but if the type is int or String, then the switch is _required_ to be total (the user must supply a default label).  Did you mean to suggest a change from this current behavior, so that the user would not need to supply a default label for the int and String versions?  (My guess is “no”.)
  
> I think this is still orthogonal (with the above caveat) since the fallthrough rules apply uniformly, and as mentioned above we can probably rehabilitate `default` so it can remain relevant in all the boxes.  (There are still some details to work out here, notably what to do about weakly total deconstruction patterns.)
> 
> The asymmetry where expression switches default to total, but statement switches default to partial is unfortunate, but we knew all along that was the necessary cost of rehabilitating switch rather than creating a parallel "snitch" (New Switch) construct. It's just the final payment is coming due now.
> 
> I would "strongly" prefer to not propagate `default` into patterns, but leave it as a behavior of switch.  I think our refined taxonomy of totality is now good enough to get us where we need to go without festooning pattern nesting with nullity knobs.  (I think that, if we have to include totality markers at every stage of the pattern syntax, we will have made a mistake somewhere else; as I mentioned to Remi when he brought up "var vs any" (which is just another spelling for default vs nothing), my objection is not to the syntax but to the amount of complexity budget it burns for a low-value thing -- raising ideally-ignorable corner cases into the user's direct field of view, when ideally we can define the natural positive space and let the rest fall into automatically handled residue.  If we have defined the pattern semantics correctly, I'm not sure anyone will notice.)

Yes, we may not need to introduce “default” as a marker of tagging subpatterns.  If we’re wrong, it can be introduced later.

> Which (if you buy all the above) leaves us with a bikeshed to paint on how to spell `total-switch` or `switch-case` or …  ?

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.