[pattern-switch] Summary of open issues

[Brian Goetz]

It's a good time to check in on this list, because I think we've made a 
lot of progress in the last weak clearing away the layers of overgrowth 
that have gotten in the way of seeing a clear story.  Here's my summary 
of what's been cleared away.  (Reminder: this is the summary thread, so 
its for summary information only, if you want to argue with the specific 
points I'm making, take it to the right thread.)


Totality and patterns.  I think it's even more obvious at this point 
that the only realistic interpretation of `T t` as a pattern is that it 
is total on `T`, including null.  Anything else adds value-destroying 
complexity when we try to compose patterns.  But, it was hard to see 
this because ...

Nullity and switch.  We came at this with the mistaken assumption that 
"switches are just null-hostile."  But that was wrong.  After digging at 
it, we realized that the null-hostility of switch was an artifact of the 
limited domains to which switch had been originally applied.  When we 
zoom out, it becomes obvious that the null-hostility of switch is not 
scalable (we even tried to distort the semantics of patterns to try to 
accomodate it.)  The obvious move here is:

  - Allow `case null` in all reference switches, with the obvious semantics;
  - Enums, strings, and boxes get an implicit `case null: throw` at the 
top if there is no explicit `case null`;
  - Total patterns -- including default -- match null

So this means that _all_ switches are nullable, but these special target 
types bring their own special null defaults. While we first thought it 
might be the switch that was throwing, and then we thought maybe it was 
the (possibly implicit) default that was throwing, in reality, it is the 
invisible `case null` that comes with switching on these special types.

(Meta: this shows how much damage the "blow early, blow often" rule does 
-- by introducing ad-hoc rules to try to create a null-free playing 
field, trying to undo even one of these can take weeks of analysis to 
unravel.)

These two moves clear away almost all of the null hazards with switch, 
and put us on a principled foundation: with the exception of the legacy 
switch types, null is just another value that flows through patterns and 
switches, which can be matched, with the obvious and now-composible 
semantics.  I think this also should reduce the "totality is too subtle" 
concern, because we've put the null hostility into a more well-defined 
"box" -- switches are just nullable, so *of course* the nulls flow into 
the total pattern.


Separately, there are TWO issues regarding switch totality.  The first 
is how we can give statement switches the same error checking for 
totality that statement switches currently enjoy. I think there is npw 
room to cleanly repurpose `default` for this.

The second is, while tangentially related to nullity, is about 
_optimistic totality_.  The optimistic totality we embraced in 
expression switches over enums does not scale quite cleanly yet to 
sealed types, and specifically to _lifting_ type patterns over sealed 
types.  We have more work to do here.

(One of the underappreciated moves of the optimistic totality we did in 
12 is that it is _better_ to leave out the default clause when a switch 
is believed to be optimistically total, because it leads to better type 
checking -- omissions and separate compilation artifacts are detected at 
compile time rather than runtime.  We would like to get the same for 
sealing.)


So, summary:

  - Type patterns `T t` are total on U <: T, and `var t` is total on all 
types;
  - Total patterns match null;
- switches are not null hostile;
- `default` is a total switch case;
  - you can say `case null` in switch;
  - For switches on *enums, strings, and boxes*, there is an implicit 
`case null` that throws, but you can override this with an explicit 
`case null`.  (There's still some fine points to discuss here; if we 
want `case null` to be able to fall into default, then we can't require 
it be at the top.)
  - We can consider enhancing `default` to take a total destructuring 
pattern with minimal distortion;
  - We need to have a longer conversation about optimistic totality.

I think that's good progress for the week, as it checks off 3 of the 
items on this list.



On 8/14/2020 1:19 PM, Brian Goetz wrote:
> Here's a summary of the issues raised in the reviews of the 
> patterns-in-switch document.  I'm going to (try to) start a new thread 
> for each of them; let's not reply to this one with new topics (or with 
> discussion on these topics.)  I'll update this thread as we add or 
> remove things from the list.
>
>  - Is totality too subtle? (Remi) There is some concern that the 
> notion of using totality to subsume nullability (at least in nested 
> contexts) is sound, he is concerned that the difference between total 
> and non-total patterns may be too subtle, and this may lead to NPE 
> issues.  To evaluate this, we need to evaluate both the "is totality 
> too subtle" and the "how much are we worried about NPE in this 
> context" directions.
>
>  - Guards.  (John, Tagir) There is acknowledgement that some sort of 
> "whoops, not this case" support is needed in order to maintain switch 
> as a useful construct in the face of richer case labels, but some 
> disagreement about whether an imperative statement (e.g., continue) or 
> a declarative guard (e.g., `when <predicate>`) is the right choice.
>
>  - Exhaustiveness and null. (Tagir)  For sealed domains (enums and 
> sealed types), we kind of cheated with expression switches because we 
> could count on the switch filtering out the null. But Tagir raises an 
> excellent point, which is that we do not yet have a sound definition 
> of exhaustiveness that scales to nested patterns (do Box(Rect) and 
> Box(Circle) cover Box(Shape)?)  This is an interaction between sealed 
> types and patterns that needs to be ironed out.  (Thanks Tagir!)
>
>  - Switch and null. (Tagir, Kevin)  Should we reconsider trying to 
> rehabilitate switches null-acceptance?  There are several who are 
> questioning whether this is trying to push things too far for too 
> little benefit.
>
>  - Rehabilitating default.  The current design leaves default to rot; 
> it is possible it has a better role to play with respect to the 
> rehabilitation of switch, such as signalling that the switch is total.
>
>  - Restrictions on instanceof.  It has been proposed that we restrict 
> total patterns from instanceof to avoid confusion; while no one has 
> really objected, a few people have expressed mild discomfort.  Leaving 
> it on the list for now until we resolve some of the other nullity 
> questions.
>
>  - Meta. (Brian)  Nearly all of this is about null.  Is it possible 
> that everything else about the proposal is so perfect that there's 
> nothing else to talk about?  Seems unlikely.  I recommend we turn up 
> the attenuation knob on nullity issues to leave some oxygen for some 
> of the other flowers.
>
>