Thanks Maurizio. I have tweaked the two definitions to be more clearly aligned.
Gavin > On 21 Oct 2019, at 10:57, Maurizio Cimadamore > <maurizio.cimadam...@oracle.com> wrote: > > Hi Gavin, > looks good, and I note that you also tweaked instanceof to use a "bi-modal" > semantics - e.g. instanceof Type | Pattern. > > On that note, I find that the section which speaks about 'type instance of' > could use same cleanup you did on patterns: > > " > > If a cast of the RelationalExpression to the ReferenceType would be rejected > as a compile-time error (15.16 > <https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.16>), > then the instanceof expression likewise produces a compile-time error. In > such a situation, the result of the instanceof expression could never be true. > > If the casting conversion of the RelationalExpression to the ReferenceType > makes use of a narrowing reference conversion which is unchecked (5.1.6.2 > <https://docs.oracle.com/javase/specs/jls/se11/html/jls-5.html#jls-5.1.6.2>), > then a compile-time error occurs. > " > > The text here looks a bit redundant, and similar to what you had in the > previous version of the spec. Perhaps you could use same cleanups as what you > did in 14.30.2 (which, btw, looks great!) > > Maurizio > > > > On 21/10/2019 10:50, Gavin Bierman wrote: >> A second, and hopefully final, draft language spec for JEP 305 (Pattern >> matching for instanceof) is available at: >> >> http://cr.openjdk.java.net/~gbierman/jep305/jep305-20191021/specs/patterns-instanceof-jls.html >> >> <http://cr.openjdk.java.net/~gbierman/jep305/jep305-20191021/specs/patterns-instanceof-jls.html> >> >> <http://cr.openjdk.java.net/~gbierman/jep305/jep305-20191021/specs/patterns-instanceof-jls.html> >> >> <http://cr.openjdk.java.net/~gbierman/jep305/jep305-20191021/specs/patterns-instanceof-jls.html> >> >> Apart from a small number of minor corrections, the two main changes are: >> >> 1. We are relaxing the conditions around the typing of the instanceof >> operator, as discussed on the EG list a little while ago. The second operand >> is no longer required to be a reifiable type, but we require the type of the >> expression can be convertible to the type by casting conversion, and that >> casting conversion does not make use of an unchecked narrowing reference >> conversion. >> >> 2. The specification for patterns will not now appear in a new chapter, but >> in a new section 14.30. (Sections 14.22-14.29 will remain unused for now, to >> allow for further language evolution.) >> >> As always, please email me any comments/thoughts/bugs. >> >> Thanks, >> Gavin >> >>> On 19 Sep 2019, at 10:28, Gavin Bierman <gavin.bier...@oracle.com> >>> <mailto:gavin.bier...@oracle.com> wrote: >>> >>> A draft language spec for JEP 305 (Pattern Matching for instanceof) is >>> available at: >>> >>> http://cr.openjdk.java.net/~gbierman/jep305/jep305-20190918/specs/patterns-instanceof-jls.html >>> >>> <http://cr.openjdk.java.net/~gbierman/jep305/jep305-20190918/specs/patterns-instanceof-jls.html> >>> >>> <http://cr.openjdk.java.net/~gbierman/jep305/jep305-20190918/specs/patterns-instanceof-jls.html> >>> >>> <http://cr.openjdk.java.net/~gbierman/jep305/jep305-20190918/specs/patterns-instanceof-jls.html> >>> >>> Comments are welcomed on all aspects, but I draw your attention to a couple >>> of things that we’d like your feedback on: >>> >>> 1. The instanceof operator restricts the type to be a reifiable reference >>> type. The spec currently keeps that restriction for type test patterns too. >>> But should we go further, i.e. will people expect to be able to say the >>> following (given that this *declares* a pattern variable l)? >>> >>> if (o instanceof List<Integer> l) { >>> … >>> } >>> >>> 2. We’d like to keep the possibility open for merging of multiple pattern >>> declarations, where it makes sense. For example: >>> >>> if (a instanceof Foo f || b instanceof Foo f) { >>> … // Like to be able to use f here >>> } >>> >>> The current spec explicitly calls out cases like these as compile-time >>> errors, to allow for forwards compatibility if we add this feature. But >>> what do you think of this feature? (We have textually multiple declarations >>> of a pattern variable, but they are “merged”, so they are really the same >>> thing…) >>> >>> 3. [Only for spec nerds] I am proposing to add a new Chapter 16 to discuss >>> patterns (at the moment it’s short, but we’re planning for it to grow). The >>> existing Chapters 16-19 will be renumbered to 17-20. Will this renumbering >>> cause problems for anyone? >>> >>> >>> Thanks, >>> Gavin
