> On Aug 25, 2020, at 2:08 PM, Brian Goetz <brian.go...@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.
