[External] : Re: Treatment of total patterns (was: Reviewing feedback on patterns in switch)

[Brian Goetz]

> You can say you only change the semantics of switch not the semantics 
> of pattern matching, but the idea that you can separate the two is 
> confusing.

 From a mathematical point of view, it is quite clear.  We define a `x 
matches P` relation.  In this relation, `Object o` matches all values of 
x, including null.

Then, we define the semantics of `instanceof` and `switch`.  For 
example, `x instanceof P` means: "if x is null, then false, otherwise 
evaluates to `x matches P`."  The construct gets to decide when to 
evaluate the pattern.

This is just like how we separate the inference machinery from how 
inference is used (differently) to produce a result for diamond or var.

What you're saying, I think, is that most users don't separate the 
layers like this; their understanding of pattern matching is conflated 
with how pattern contexts like switch/instanceof work. And that is 
surely true.  But having a clear definition of how pattern matching 
works, and a clear definition of how switch/instanceof use pattern 
matching, allows the users who *do* want to understand, to do so more 
easily, because we've separated the concepts.

> PS: the feedback about the fact that it's not clear if a switch allows 
> null or not can also be seen as a symptom of the fact that the notion 
> of total pattern is not obvious for everybody (and having no syntax 
> hint does not help).

I think this is the real issue; leaning on totality is more sound and 
less ad-hoc, but harder to learn.  You'd like to make that easier to 
learn by introducing more syntax; I'm saying that this is (a) more 
complicated in the long run, and (b) way over-rotating towards treatment 
of null.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220128/40a56ea0/attachment-0001.htm>