Thanks for the feedback Tagir! Gavin
> On 19 Sep 2019, at 11:06, Tagir Valeev <amae...@gmail.com> wrote: > > Hello, Gavin! > > Chapter renumbering is somewhat disturbing to us, though not that it's > totally problematic. E.g. we have comments like this spilled in the > code: > > // see JLS chapter 16 [1] > > After the renumbering, such references will become ambiguous, or at > least we would need to specify JLS versions everywhere. > > Isn't it possible to discuss patterns in chapter 19 instead? In this > case, only existing chapter 19 "Syntax" will be renumbered to chapter > 20 which looks ok as I never saw the references to this chapter. This > aligns with the introduction of the "Type inference" chapter in Java > SE 8. It was introduced as Chapter 18, despite it has relations with > expressions, so placing it after Chapter 15 would look more logical. > That time only the "Syntax" chapter was renumbered (from 17 to 18). In > general JLS chapters are quite self-contained, so the actual order > looks not that important to me. Preserving the numbering for Chapters > 16-18 looks more important. > > With best regards, > Tagir Valeev. > > [1] > https://github.com/JetBrains/intellij-community/blob/3b2289a1d445acb39b9a529aa7c1559d31c87b6a/java/java-analysis-impl/src/com/intellij/codeInsight/daemon/impl/analysis/HighlightControlFlowUtil.java#L215 > > 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
