[pattern-switch] Summary of open issues

[Brian Goetz]

So, scorecard:

  - I think the totality, exhaustiveness, and nullity problems are now 
put to bed in a consistent and principled manner, along with a 
reasonable new job for "default" that doesn't leave it to rot.  
Remaining is:
    - How does a switch opt into totality, other than by being an 
expression switch?

  - Guards: there's a bikeshed to be painted, what's stopping you guys?

  - Restrictions on instanceof: proposed, under discussion.


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