Finalizing in JDK 16 - Pattern matching for instanceof

[Brian Goetz]

>>
>> Proposed: An `instanceof` expression must be able to evaluate to both 
>> true and false, otherwise it is invalid.  This rules out strongly 
>> total patterns on the RHS.  If you have a strongly total pattern, use 
>> pattern assignment instead.
>
> Makes sense to me, but one question: would this restriction "must be 
> able to evaluate to both true and false” be applied to 
> _every_ `instanceof` expression, or only those that have a pattern to 
> right of the `instanceof` keyword?  I ask because if it is applied to 
> _every_ `instanceof` expression, this would represent an incompatible 
> change to the behavior of `x instanceof Object`, among others.  Is it 
> indeed the intent to make an incompatible change to the language?

Well, it's more of an aspiration than a rule -- based on what we already 
do.  We already use some form of this to rule out bad casts:

     String s = ...
     if (s instanceof Integer)  { ... }
     // Error, incompatible types

So here, we have a candidate instanceof that would always be false, 
which the compiler can derive by type analysis, and was always 
rejected.  It would be joined by

     if (s instanceof Object o) { ... }

because Object o is total in this case, but not

     if (s instanceof Object)

because this _can_ yield either true (if s is not null) or false (if it 
is.)

The reality is that the natural semantics of `instanceof <type>` and the 
semantics of pattern matching disagree in one small place.  But it still 
made more sense to extend instanceof to patterns rather than create a 
new "matches" operator, so we patch that small place by not allowing us 
to ask the confusing question.

>>
>> Like with lambda parameters, I am now thinking that we gave in to the 
>> base desire to fix a past mistake, but in a way that doesn't really 
>> make the language better or safer, just more complicated.  Let's back 
>> this one out before it really bites us.
>
> I agree with this analysis.  It does suggest that we should consider 
> whether to extend the syntax of a type pattern from `T x` to `[final] 
> T x`, and the syntax of a deconstruction pattern from `D(Q) [v]` to 
> `[final] D(Q) [v]` (in the latter case, `final` may be present only if 
> `v` is also present), so that the user can choose to mark a pattern 
> binding variable as `final`.  (This is something that could be added 
> right away or later.)

Exactly so.  This would further be doubling down on the pleasing pun 
between variable declaration and type patterns.  I don't think we need 
it now, but some day we might feel it is missing, and if so, there's a 
ready answer that requires no new bikesheds to be harmed.


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