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

[Brian Goetz]

This seems to cleverly sidestep the issue of pattern totality (by 
outlawing the total type pattern on the RHS of instanceof for now) and 
leave us room to go either way in the future.  So, +1.

I think you can drop

If the value of the/RelationalExpression/is the null reference, then the 
result is|false|.

because you already say

  * A value,/V/, that is not the null reference value matches a type
    test pattern of type/T/if/V/can be cast to/T/without raising
    a|ClassCastException|, in which case the value/V/is assigned to the
    pattern variable declared by the type test pattern; and it does not
    match otherwise.

When it comes time to have patterns that do match null, we can expand 
14.30.3 at that time; that seems better than backpedaling in 15.20.2.


On 10/12/2020 3:55 PM, Gavin Bierman wrote:
> Following the announcement of JEP 394 [1] the latest version of the spec is now available at:
>
> http://cr.openjdk.java.net/~gbierman/jep394/latest/
>
> I have fixed the bugs spotted by Brian in the previous draft. I have also tidied up the treatment of annotations (See sections 9.6.4.1 and 9.7.4 along with the refactored grammar for type test patterns 14.20.1.1)
>
> Still time to pass on comments!
> Gavin
>
> [2] https://openjdk.java.net/jeps/394
>
>> On 5 Oct 2020, at 13:53, Gavin Bierman <gavin.bierman at oracle.com> 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/20201013/eb283aa1/attachment.htm>