[pattern-switch] Summary of open issues

[Brian Goetz]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200814/43941303/attachment.htm>