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

[Remi Forax]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Gavin Bierman" <gavin.bierman at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 13 Octobre 2020 19:18:48
> Objet: Re: [patterns-instanceof] Spec for next version of Patterns in instanceof
> JEP

> 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.
oh, no, 
all my codes that does a "instanceof Object o" does not work anymore :) 

so good to me too. 

Rémi 

[...] 

> 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/ |
>> 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 | https://openjdk.java.net/jeps/394 ]

>>> On 5 Oct 2020, at 13:53, Gavin Bierman [ mailto:gavin.bierman at oracle.com |
>>> <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/ |
>>> 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/20201014/4c66ca88/attachment.htm>