Sorry, meant to thank you for pointing this out. You are correct in that (i) when writing these I wrote them side-by-side, and (ii) when we fixed up the text surrounding top-level/member/local I forgot to put them side-by-side again to check there wasn’t any stray old text. Ug.
(It’s also super annoying that the section numbers don’t match to make this even better!) Alex spotting a small issue that will break up this nice symmetry some more: the restriction on the canonical name excludes the neat trick that we play compiling out enums with constants that have bodies into a sealed hierarchy (as we need to have permitted subclasses that are anonymous classes). It’s fixable but we have to special case enum classes :-( Thanks again, Gavin > On 23 Apr 2021, at 21:19, John Rose <john.r.r...@oracle.com> wrote: > > On Apr 20, 2021, at 2:00 AM, Gavin Bierman <gavin.bier...@oracle.com> wrote: >> >> >> http://cr.openjdk.java.net/~gbierman/jep409/latest/ > > Out of curiosity I compared the two large new sections > on permits, 8.1.4 and 9.1.4, perhaps to find unintentional > divergences. Here are the differences I found FYI, > aside from than the required differences arising > from section numbering and the parallel terminology > of interfaces and lists. > >> The optional permits clause in a [C/I] declaration {specifies, lists} the >> [C/I]s > >> It is a compile-time error if {the same class, a class or interface} is >> {specified, named} more than once in a {, single} permits clause > >> The permitted direct sub[C/I]s of a sealed [C/I] are the [C/I]s listed by >> its permits clause, or, if [C/I] lacks a permits clause, each {, top level >> or member} [C/I] declared in the same compilation unit as [C/I] (7.3) which >> has a canonical name (6.7) > > This last one is especially odd, since “top level or member” > seems redundant when “has a canonical name” is specified. > The latter condition is in both places, and is more pertinent. > > Also, this comment was in the class section, but there was no > parallel comment in the interface section: > >> This means that if a sealed class C lacks a permits clause one will be >> inferred that contains all the top-level and member classes in the same >> compilation unit that list C as their direct superclass. The requirement of >> having a canonical name means that no local classes or anonymous classes >> will be considered. > > Perhaps you added the “canonical name” and did not replace > all of the predecessor language about “top level or member”? > > (As expected, I found no substantive differences.) > > — John
