[patterns-instanceof] Spec for next version of Patterns in instanceof JEP
forax at univ-mlv.fr
Wed Oct 14 12:53:07 UTC 2020
> 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
> 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.
all my codes that does a "instanceof Object o" does not work anymore :)
so good to me too.
> On 10/12/2020 3:55 PM, Gavin Bierman wrote:
>> Following the announcement of JEP 394  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 126.96.36.199 and 9.7.4 along with the refactored grammar
>> for type test patterns 188.8.131.52)
>> Still time to pass on comments!
>>  [ 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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the amber-spec-experts