Hello, Gavin! In general, the spec draft looks good. I have a question about annotations. Currently section 9.6.4.1. @Target says:
9. Local variable declarations (including loop variables of for statements and resource variables of try-with-resources statements) (§14.4, §14.14.1, §14.14.2, §14.20.3) Corresponds to java.lang.annotation.ElementType.LOCAL_VARIABLE Should not it be extended to include pattern variables as well? With best regards, Tagir Valeev. On Thu, Sep 19, 2019 at 4:30 PM Gavin Bierman <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> > > 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
