> On 5 Oct 2020, at 16:20, Brian Goetz <brian.go...@oracle.com> wrote: > > > I have one concern: > >> The second condition eliminates pointless instances of pattern matching >> where the expression will always match the pattern. In particular, the null >> literal is not compatible with any type test pattern. > > I am not sure I agree with this framing. We need to separate the semantics > of _patterns_ from the semantics of `instanceof`. A total pattern (var x, > Object x, total type pattern) _does_ match null. We may exclude some > patterns from `instanceof`, but that doesn't change their semantics. I think > we should get ahead of this, rather than plan on patching it later.
Yes, I had spotted this. Apologies, I put the error condition in the wrong section - in matching rather than in instanceof - although it’s effect right now is the same. I shall move it. > Even more so: > >> The null reference value does not match any type test pattern. > > According to the discussions surrounding switch, this is not true. The null > reference value matches any type pattern _that is total on the static type of > the operand_. Again, we've got to separate the semantics of the type > pattern, from what `instanceof` does with a type pattern. We get several > shots at null before we actually match the pattern: we can eliminate some > matches statically at compile time, and we can eliminate others by giving > semantics to instanceof before we ask "does it match the pattern." So we > should be careful in which of these three buckets we put our null hostility. Yes, spotted this also! I have refactored the semantics. In fact, for now we don’t need to give a case about null reference value matching, as it is caught by the instanceof rules. > Overall, though, I am super-happy with how this spec has landed. At the > beginning, we we a bit fearful of how intrusive it would be; in the end, > there is basically just the obvious set of new sections: pattern syntax, > pattern scoping, pattern operational semantics. That the diffs are almost > entirely "adding new sections" looks like winning to me. Further, > looking ahead, adding both new kinds of patterns (e.g., deconstruction > patterns) and new places that use patterns (e.g., pattern assignment) will > have an obvious place to go. Thanks. For now section 14.30 looks a little “over-structured”, but it was carefully designed to be able to grow gracefully. Now this is JEP 394 (yay!), I will build a new version of the spec and put it in a more memorable place shortly. I will announce on this list when it is available. Gavin
