[patterns-instanceof] Spec for next version of Patterns in instanceof JEP

[Gavin Bierman]

> On 5 Oct 2020, at 16:20, Brian Goetz <brian.goetz at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20201008/76c157c3/attachment.htm>