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
