Opting into totality

[Brian Goetz]

> I have thought about what you have just said; (a) I agree, and (b) have made me realize that I have unnecessarily and unreasonably conflated the o.t. issue with the fallthrough issue.  So let me try once more.  For context, here are the three important paragraphs again, and the only changes I have made are to remove from the third paragraph the sentences that address fallthrough and fallout:

While we're doing a conflation inventory, here's another candidate 
(which I will soon reject after drawing the distinction): totality 
checking vs automatic residue handling.  The interesting cases here all 
involve getting the compiler to do TWO categories of extra work for the 
user that is not done on old-school (partial, statement) switches:

  - Validating that the cases are (optimistically) total, or giving a 
compile error
  - Inserting synthetic cases to throw on the residue of optimistic totality

I'm not seriously suggesting that we should treat them as separate 
features, as much as observing that we may still only be circling the 
target.  In thinking about it this morning, I initially thought that a 
better axis for dividing the problem would be on the "shape" of the 
switch; some switches are "tree shaped" (type-hierarchy-based switches 
which lean hard on partial ordering of cases, usually culminating in 
catch-alls) and some are "star shaped" (all of the traditional switch 
examples, plus many switches over sealed types.)   I initially thought 
that `switch case` was mostly about the latter shape, but then I 
realized this is a false distinction; both produce residue, even when no 
sealing or enums are involved, as a side-effect of the fact that we want 
to not force users to spell out all the silly cases.

The pervasiveness of o.t., and the complex shape of residue that comes 
out of even well-behaved switches, says to me the place worth spending 
complexity budget on is not totality, but _optimistic totality with 
residue_.  (Strong totality is just residue = empty; weak totality is 
just residue = { null }, so collapsing these all may make sense.)  
Because, the set of switches that are truly total with no optimism and 
no residue is pretty simple, and probably doesn't need an awful lot of 
help.  (For comparison, we don't need the language to help us assert 
than an if ... else chain is total; if the last entry is an "else", 
we're there.)  So I'm happy collapsing these two sub-features, but I 
want to keep the focus on the optimistic/residue part, because that's 
where the value is.

We already have a 2x2 matrix of orthogonal choices that we started with: 
{ statement, expression } x { arrow, colon }, and we're not going to 
pare back that space.  So let's look at the other dimension, which 
you've currently got as { "single point of totality", optimistic 
totality, partiality }.

Given the lack of clear boundary between the tree-shaped and star-shaped 
switches with respect to their residue, I'm not sure the distinction 
between SPoT and optimistic totality carries its weight, and we can 
collapse these into "X-total vs partial", where X-total means both 
totality checking and automatic residue rejection.  The interesting part 
is validating that the programmer has contributed enough totality that 
the compiler can fill in the gaps -- let's highlight that.

To pick a different syntax for purposes of exposition, suppose we had 
`total-switch` variant of `switch`.  A `total-switch` would require that 
(a) the cases be at least optimistically total and (b) would insert 
additional throwing cases to patch any unhandled residue.  And we could 
do this with any of the combinations that lead to X-totality -- a 
default clause (strongly total), a weakly total deconstruction pattern 
(residue = null), an optimistically total set of type patterns for 
sealed types (residue = { null, novel }), and all the more complicated 
ones -- distinguishing between these cases doesn't seem interesting.  In 
this model, `default` just becomes a shorthand for "everything else, 
maybe with destructuring."

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

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