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

[Brian Goetz]

Overall I really like the simplification of merging pattern variables 
into locals, just with more complex scopes.  The revised definition of 
effective finality is very natural.  This will all pay off further when 
we add pattern assignment statements.

The obvious caveat is that you have to search the entire text for "local 
variable" and consider whether you need to qualify with "that is not a 
pattern variable".  I suspect you've already done this.

In 4.12.3, the comment on DA sounds like it doesn't apply to pattern 
variables.  And strictly, it doesn't, but this would be a good place to 
mention that the scoping of a pattern variable coincides with where that 
variable would be DA.  I see this in 4.12.5 but a more general statement 
where you introduce pattern variables would be nice, even if it is a 
note rather than normative text.

5.5.  I think of `instanceof` as having two forms:

     o instanceof Type
     o instanceof Pattern

This phrasing ("converted to the type indicated by the second operand") 
is consistent with the first, but I think needs a few more words to be 
consistent with the second?  Every pattern has a "principal type" 
(making up a term); the principal type of a type pattern `T t` is `T`; 
the principal type of a deconstruction pattern `D(...)` is `D`.  (The 
definition for other kinds of patterns like constant patterns or 
declared patterns are straightforward enough to define as needed.)

(I assume the stuff on scoping and operational semantics of pattern 
matching is unchanged, so I skimmed that.)

The shadowing rules still leave room for "flow refinement" as a later 
feature, where you have a local:

     Object p;
     if (p instanceof Point p) { ... }

where the latter p is considered a type refinement of the former.  We've 
discussed this before, and it seems a reasonable feature to leave on the 
"maybe leave room for later" list, but we surely don't have to do 
anything about it now.


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.

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.


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.





On 10/5/2020 8:53 AM, Gavin Bierman wrote:
> Dear all:
>
> A draft of the spec for the Patterns in instanceof feature that we plan to
> finalize in JDK 16 is now available:
>
> http://cr.openjdk.java.net/~gbierman/8250623/latest/
>
> [NB: The URL will change once we have a JEP number, and will be announced.]
>
> The changes are the same as those in the second preview that was released in
> Java SE 16, except for minor editorial changes and the following:
>
> - To lift the restriction that pattern variables are implicitly final. This
>    allows pattern variables to be considered as a strict subset of local
>    variables. A number of simplifications to the spec result from this change.
>
> - To make it a compile-time error for an expression of type _S_ to be matched
>    against a pattern of type _T_, where _S_ is a subtype of _T_. (This pattern
>    match will always succeed and is then pointless. The opposite case, where a
>    pattern match will always fail is already a compile-time error.)
>    
> Comments welcome!
>
> Gavin

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