> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Gavin Bierman" <gavin.bier...@oracle.com>, "amber-spec-experts" > <amber-spec-experts@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.bier...@oracle.com | >>> <gavin.bier...@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
