[pattern-switch] Opting into totality

[Dan Smith]

> On Sep 4, 2020, at 3:29 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> The brittleness comes from the fact that, if you miss a case of a sealed type, not only do you not find out your switch isn't total any more, but your remainder rejection goes away.

And this isn't just a problem when you write the switch. Adding cases to an enum is a common thing to do; I assume adding cases to a sealed class will be, too. When that happens, a previously-total switch will silently start to fall out.


> On Sep 4, 2020, at 3:51 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> So we have { expression, statement } x { arrow, colon } switches, and the totality rules are: a switch is total if it is an expression switch, or it has any non-constant patterns.  Total switches then get an implicit throwing default if they have no strongly total pattern.  That's a kind of irregular shape, but possibly justifiable.  

Things that I dislike here:

- Switch statements don't support optimistically-total switching on enums. Meanwhile, switch expressions *do* support optimistically-total switching on enums. It's a great feature.

- To do an "if without else" switch with constants, you leave off the default. To do an "if without else" switch with patterns, you have to include the default (with an empty body). Seems like noise to me, but more importantly, it's hard to remember which one to do.

As you suggest, it just seems really hard to keep track of these ad hoc rules.

Meanwhile, providing some syntax to assert that a switch should get total treatment, and claiming that switch expressions have this property implicitly, seems totally fine to me. It's consistent (oops, I used that word) with, say, how things declared in interfaces have certain implicit properties.

So I appreciate the brainstorming, but personally don't really see a problem that needs solving here. (Other than the syntax bikeshed.)