From daniel.smith at oracle.com Wed Dec 2 19:39:00 2020 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 2 Dec 2020 12:39:00 -0700 Subject: [sealed-classes] Spec for next version of Sealed Classes In-Reply-To: References: <8B135BD4-664A-4D0B-A092-24D0CD7265F4@oracle.com> <2DBCF829-E5CA-44B7-9C9C-81B093CB7704@oracle.com> Message-ID: <8FE363EC-C6E4-4371-B022-6FDF459A42C7@oracle.com> > On Nov 24, 2020, at 5:44 AM, Chris Hegarty wrote: > > Dan, > >> On 29 Oct 2020, at 21:29, Dan Smith wrote: >> >>> ... >> >>> "C does not have its ACC_PUBLIC flag set (4.1) and the superclass belongs to a different run-time package than C.? - I get that there is a bidirectional accessibility relationship between the superclass and the subclass, but this seems at odds with JEP text: ?In particular, a subclass may be less accessible than the sealed class?. Why is this not that the superclass must have ACC_PUBLIC, and not the subclass? >> >> The goal of this rule is to simulate resolution without actually asking to perform it, since the class hasn't even been created yet. Part of resolution is access checking, so we simulate it here. >> >> The JEP says "a permitted subclass and its sealed superclass must be accessible to each other. However, permitted subclasses need not have the same accessibility as each other, or as the sealed class." >> >> Keep in mind we're talking now about language-level accessibility, which doesn't always map to JVM accessibility. > > Understood. My question is only related to accessibility in the JVM. > >> Anyway, some examples: >> public super, non-public sub, same package >> package-access super, private sub, same package >> public *and exported* super, public sub >> private super, public sub, same nest > > Thanks for these examples, they are helpful. > > Here is one more: > public super, non-public sub, same module, DIFF package > > The draft text [*] seems to explicitly disallow this (which I believe is incorrect, or at least I don?t understand why). > > [*] ? ... derivation fails with a IncompatibleClassChangeError: ... > * C does not have its ACC_PUBLIC flag set (4.1) and the superclass belongs to a different run-time package than C. ?" > > I believe that the intent is that ?SUPERCLASS does not have its ACC_PUBLIC flag set (4.1) and C belongs to a different run-time package than SUPERCLASS? - not the other way around. No? We're simulating resolution of a reference to C appearing in the superclass. (See "accessible to each other" in the JEP text I quoted.) If you were to actually resolve the reference to C (where C is non-public and in a different package), you would get an IAE, because the superclass can't "see" C. Thus, extending the superclass with C is disallowed. From john.r.rose at oracle.com Tue Dec 8 07:08:28 2020 From: john.r.rose at oracle.com (John Rose) Date: Mon, 7 Dec 2020 23:08:28 -0800 Subject: [statics] allowing static initializers in interfaces? In-Reply-To: <777327472.2212237.1605697087284.JavaMail.zimbra@u-pem.fr> References: <45928680-f4a2-d21e-665c-19de2d87e2c0@oracle.com> <777327472.2212237.1605697087284.JavaMail.zimbra@u-pem.fr> Message-ID: <776E5B90-E420-4FDD-B9C8-43D2F29EDF2E@oracle.com> In my latest (and probably 100th) lap around this set of obstacles, I?ve used a workaround like the following: interface Something { default someMethod(int x) { return x * Private.SOME_CON; } /*should be private*/ static final class Private { private Private() { } private static final int SOME_CON = 42; } } The private class can contain private nested classes, private static methods, and private constants, all inaccessible outside of the interface nest. A good use of private nested classes would be classes which provide one or more standard implementations of the interface. This pattern has the advantage of allowing a single-keyword upgrade when private classes are eventually allowed, and also a pretty small (though non-empty) API footprint today. ? John > ----- Mail original ----- >> De: "John Rose" >> ?: "Maurizio Cimadamore" >> Cc: "amber-spec-experts" >> Envoy?: Mercredi 18 Novembre 2020 09:07:18 >> Objet: Re: [statics] allowing static initializers in interfaces? > >> +1 from me too, and generally to heal the rift. >> The inability to put private classes (and other ?stuff?) >> in an interface makes it hard to support canonical >> algorithms in default methods, if they need auxiliary >> types. > > yes, > another example, in the patch introducing the new random generator API currently under review, there is this method > > default float nextFloat() { > return (nextInt() >>> 8) * 0x1.0p-24f; > } > > which a good example of why we also need private static final fields in interface. > > R?mi > From forax at univ-mlv.fr Tue Dec 8 07:21:12 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 8 Dec 2020 08:21:12 +0100 (CET) Subject: [statics] allowing static initializers in interfaces? In-Reply-To: <776E5B90-E420-4FDD-B9C8-43D2F29EDF2E@oracle.com> References: <45928680-f4a2-d21e-665c-19de2d87e2c0@oracle.com> <777327472.2212237.1605697087284.JavaMail.zimbra@u-pem.fr> <776E5B90-E420-4FDD-B9C8-43D2F29EDF2E@oracle.com> Message-ID: <835412012.867709.1607412072148.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "John Rose" > ?: "Remi Forax" > Cc: "Maurizio Cimadamore" , "amber-spec-experts" > Envoy?: Mardi 8 D?cembre 2020 08:08:28 > Objet: Re: [statics] allowing static initializers in interfaces? > In my latest (and probably 100th) lap around this > set of obstacles, I?ve used a workaround like the > following: > > interface Something { > default someMethod(int x) { return x * Private.SOME_CON; } > /*should be private*/ static final class Private { > private Private() { } > private static final int SOME_CON = 42; > } > } > > The private class can contain private nested classes, > private static methods, and private constants, all > inaccessible outside of the interface nest. A good use > of private nested classes would be classes which > provide one or more standard implementations > of the interface. > > This pattern has the advantage of allowing a single-keyword > upgrade when private classes are eventually allowed, and also > a pretty small (though non-empty) API footprint today. or you can write interface Something { default int someMethod(int x) { return x * new Object() { private static final int SOME_CON = 42; }.SOME_CON; } } and the JIT will happily remove new Object() + pop. and BTW, con is cunt in French, that why i urge my student to never use abbreviation :) > > ? John R?mi > >> ----- Mail original ----- >>> De: "John Rose" >>> ?: "Maurizio Cimadamore" >>> Cc: "amber-spec-experts" >>> Envoy?: Mercredi 18 Novembre 2020 09:07:18 >>> Objet: Re: [statics] allowing static initializers in interfaces? >> >>> +1 from me too, and generally to heal the rift. >>> The inability to put private classes (and other ?stuff?) >>> in an interface makes it hard to support canonical >>> algorithms in default methods, if they need auxiliary >>> types. >> >> yes, >> another example, in the patch introducing the new random generator API currently >> under review, there is this method >> >> default float nextFloat() { >> return (nextInt() >>> 8) * 0x1.0p-24f; >> } >> >> which a good example of why we also need private static final fields in >> interface. >> >> R?mi From forax at univ-mlv.fr Wed Dec 9 10:39:52 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 9 Dec 2020 11:39:52 +0100 (CET) Subject: Fwd: Should final fields in records be trusted or not trusted in 16? In-Reply-To: <7d1f2609-a894-9393-43f8-7295bc3e4d7a@oracle.com> References: <7d1f2609-a894-9393-43f8-7295bc3e4d7a@oracle.com> Message-ID: <1434527460.1950440.1607510392620.JavaMail.zimbra@u-pem.fr> forwarded to amber-spec-experts R?mi ----- Mail transf?r? ----- De: "mandy chung" ?: "amber-dev" Envoy?: Mercredi 9 D?cembre 2020 05:00:03 Objet: Should final fields in records be trusted or not trusted in 16? I need your help, amber experts, in understanding the conclusion on the amber-spec-experts discussion [1].? It isn't clear to me what it's agreed to do in Java SE 16. Remi raised in PR for JDK-8257596 [2] and so your clarification would help.? PR #1706 intends to fix the regression introduced by JDK-8255342 that removes non-specified JVM checks on classes with RecordComponents attributes.? This does not conflict with the work to implement the true TNSFF for all classes like JDK-8233873. One way I read [1] is that it's agreed to revisit the current approach [3] that makes final fields in record classes "read-only" by reflection and JIT optimization to trust final fields in records (note that JIT optimization is implementation-specific). Instead all final field values should be trusted as a constant (see JDK-8233873). If this is the agreement, I see two options for JDK 16: 1. Keep JDK-8247444 and fix the regression as proposed by PR #1706 [2] 2. Backout JDK-8247444 [4].? This involves spec change and we shall act on it quickly. Making all final field values trusted as a constant will be a separate enhancement regardless of which option it goes. Please clarify. Mandy [1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002630.html [2] https://github.com/openjdk/jdk/pull/1706 [3] https://bugs.openjdk.java.net/browse/JDK-8247444 [4] https://github.com/openjdk/jdk/compare/master...mlchung:backout-8247444 From chris.hegarty at oracle.com Wed Dec 9 16:58:50 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 9 Dec 2020 16:58:50 +0000 Subject: Should final fields in records be trusted or not trusted in 16? In-Reply-To: <1434527460.1950440.1607510392620.JavaMail.zimbra@u-pem.fr> References: <7d1f2609-a894-9393-43f8-7295bc3e4d7a@oracle.com> <1434527460.1950440.1607510392620.JavaMail.zimbra@u-pem.fr> Message-ID: <0F870CD3-E3F0-4A7E-BE09-BAD73BDC71F1@oracle.com> I see that the thread [1] tailed off without any real conclusion or consensus. Getting to a place where it is simple to add new kinds of classes whose non-static final fields are trusted is a worthy goal. I just question if doing so with a record attribute is the right move. Instead we can consider how best that could be achieved orthogonal to records. I see Mandy's PR as an intermediate step towards that goal. For now, we limit TNSFF to records and hidden classes, but eventually this can be superseded by a predicate on j.l.Class (or some such), which encompasses the aforementioned kinds of classes and possibly others. We have a material specification issue in Java 16 (as Mandy describes) - how to specify java.lang.reflect.Field::set. Mandy's PR resolves this issue while retaining TNSFF for record classes. This leaves the door open to further evolution to get to the above goal. -Chris. > On 9 Dec 2020, at 10:39, Remi Forax wrote: > > forwarded to amber-spec-experts > > R?mi > > ----- Mail transf?r? ----- > De: "mandy chung" > ?: "amber-dev" > Envoy?: Mercredi 9 D?cembre 2020 05:00:03 > Objet: Should final fields in records be trusted or not trusted in 16? > > I need your help, amber experts, in understanding the conclusion on the > amber-spec-experts discussion [1]. It isn't clear to me what it's > agreed to do in Java SE 16. Remi raised in PR for JDK-8257596 [2] and so > your clarification would help. PR #1706 intends to fix the regression > introduced by JDK-8255342 that removes non-specified JVM checks on > classes with RecordComponents attributes. This does not conflict with > the work to implement the true TNSFF for all classes like JDK-8233873. > > One way I read [1] is that it's agreed to revisit the current approach > [3] that makes final fields in record classes "read-only" by reflection > and JIT optimization to trust final fields in records (note that JIT > optimization is implementation-specific). Instead all final field values > should be trusted as a constant (see JDK-8233873). > > If this is the agreement, I see two options for JDK 16: > 1. Keep JDK-8247444 and fix the regression as proposed by PR #1706 [2] > 2. Backout JDK-8247444 [4]. This involves spec change and we shall act > on it quickly. > > Making all final field values trusted as a constant will be a separate > enhancement regardless of which option it goes. > > Please clarify. > > Mandy > [1] > https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002630.html > [2] https://github.com/openjdk/jdk/pull/1706 > [3] https://bugs.openjdk.java.net/browse/JDK-8247444 > [4] https://github.com/openjdk/jdk/compare/master...mlchung:backout-8247444 From maurizio.cimadamore at oracle.com Thu Dec 10 13:22:36 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 10 Dec 2020 13:22:36 +0000 Subject: Should final fields in records be trusted or not trusted in 16? In-Reply-To: <0F870CD3-E3F0-4A7E-BE09-BAD73BDC71F1@oracle.com> References: <7d1f2609-a894-9393-43f8-7295bc3e4d7a@oracle.com> <1434527460.1950440.1607510392620.JavaMail.zimbra@u-pem.fr> <0F870CD3-E3F0-4A7E-BE09-BAD73BDC71F1@oracle.com> Message-ID: <83bf2f96-1f9f-8d90-d2e2-2b1e9f5b3ddd@oracle.com> What Chris says. The immediate problem is that the Javadoc for Field::set is incorrect. Fixing it by mentioning presence of a bytecode attribute somewhere is not really a fix. Having better treatment for final fields for more classes is a noble goal - having restricted classes like records which act as pure data carrier is another noble goal. What is not noble IMHO, is the attempt to reuse the record classfile machinery (e.g. record attribute) to improve final field semantics even in things that are not records. Ideally there would be TWO attributes: the Record attribute and the PleaseMakeMyFinalFieldsFast attribute. But we don't have the latter (yet), and it's outside the scope of the work Chris and Mandy proposed (again, mainly about fixing the impl so that what the javadoc says is correct) to address the latter point. Which leaves us two options: * revert the changes which allowed the VM to trust record fields * keep trusting record fields, but on a more solid definition of what a record is (which is in line with what the JLS, and the reflection API say) Any other solution IMHO seems more like an hack to me. Maurizio On 09/12/2020 16:58, Chris Hegarty wrote: > I see that the thread [1] tailed off without any real conclusion or > consensus. > > Getting to a place where it is simple to add new kinds of classes whose > non-static final fields are trusted is a worthy goal. I just question if > doing so with a record attribute is the right move. Instead we can > consider how best that could be achieved orthogonal to records. > > I see Mandy's PR as an intermediate step towards that goal. For now, we > limit TNSFF to records and hidden classes, but eventually this can be > superseded by a predicate on j.l.Class (or some such), which encompasses > the aforementioned kinds of classes and possibly others. > > We have a material specification issue in Java 16 (as Mandy describes) - > how to specify java.lang.reflect.Field::set. Mandy's PR resolves this > issue while retaining TNSFF for record classes. This leaves the door > open to further evolution to get to the above goal. > > -Chris. > >> On 9 Dec 2020, at 10:39, Remi Forax wrote: >> >> forwarded to amber-spec-experts >> >> R?mi >> >> ----- Mail transf?r? ----- >> De: "mandy chung" >> ?: "amber-dev" >> Envoy?: Mercredi 9 D?cembre 2020 05:00:03 >> Objet: Should final fields in records be trusted or not trusted in 16? >> >> I need your help, amber experts, in understanding the conclusion on the >> amber-spec-experts discussion [1]. It isn't clear to me what it's >> agreed to do in Java SE 16. Remi raised in PR for JDK-8257596 [2] and so >> your clarification would help. PR #1706 intends to fix the regression >> introduced by JDK-8255342 that removes non-specified JVM checks on >> classes with RecordComponents attributes. This does not conflict with >> the work to implement the true TNSFF for all classes like JDK-8233873. >> >> One way I read [1] is that it's agreed to revisit the current approach >> [3] that makes final fields in record classes "read-only" by reflection >> and JIT optimization to trust final fields in records (note that JIT >> optimization is implementation-specific). Instead all final field values >> should be trusted as a constant (see JDK-8233873). >> >> If this is the agreement, I see two options for JDK 16: >> 1. Keep JDK-8247444 and fix the regression as proposed by PR #1706 [2] >> 2. Backout JDK-8247444 [4]. This involves spec change and we shall act >> on it quickly. >> >> Making all final field values trusted as a constant will be a separate >> enhancement regardless of which option it goes. >> >> Please clarify. >> >> Mandy >> [1] >> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002630.html >> [2] https://github.com/openjdk/jdk/pull/1706 >> [3] https://bugs.openjdk.java.net/browse/JDK-8247444 >> [4] https://github.com/openjdk/jdk/compare/master...mlchung:backout-8247444 From forax at univ-mlv.fr Thu Dec 10 14:11:31 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 10 Dec 2020 15:11:31 +0100 (CET) Subject: Should final fields in records be trusted or not trusted in 16? In-Reply-To: <83bf2f96-1f9f-8d90-d2e2-2b1e9f5b3ddd@oracle.com> References: <7d1f2609-a894-9393-43f8-7295bc3e4d7a@oracle.com> <1434527460.1950440.1607510392620.JavaMail.zimbra@u-pem.fr> <0F870CD3-E3F0-4A7E-BE09-BAD73BDC71F1@oracle.com> <83bf2f96-1f9f-8d90-d2e2-2b1e9f5b3ddd@oracle.com> Message-ID: <1804942293.487843.1607609491442.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "Chris Hegarty" , "Remi Forax" , "amber-spec-experts" > > Cc: "mandy chung" > Envoy?: Jeudi 10 D?cembre 2020 14:22:36 > Objet: Re: Should final fields in records be trusted or not trusted in 16? > What Chris says. > > The immediate problem is that the Javadoc for Field::set is incorrect. > Fixing it by mentioning presence of a bytecode attribute somewhere is > not really a fix. > > Having better treatment for final fields for more classes is a noble > goal - having restricted classes like records which act as pure data > carrier is another noble goal. > > What is not noble IMHO, is the attempt to reuse the record classfile > machinery (e.g. record attribute) to improve final field semantics even > in things that are not records. But what a record is ? For the VM, not for the language. If the definition is a class that contains a record attribute which is the current definition for the VM, then i don't see a problem if Scala Tuples or an immutable Kotlin data types are using the record Attribute. The real issue is that currently Field.set() is using the reflection API definition of a record instead of using the VM definition. > > Ideally there would be TWO attributes: the Record attribute and the > PleaseMakeMyFinalFieldsFast attribute. But we don't have the latter > (yet), and it's outside the scope of the work Chris and Mandy proposed > (again, mainly about fixing the impl so that what the javadoc says is > correct) to address the latter point. Which leaves us two options: > > * revert the changes which allowed the VM to trust record fields > * keep trusting record fields, but on a more solid definition of what a > record is (which is in line with what the JLS, and the reflection API say) There is a third choice see above. Forcing the semantics of Java into the VM is always a bad idea. We don't do that for any other constructs, lambda, enums, Java anonymous classes, etc. Worst, we already know that an inline record is not a record from the JLS POV. For Java 16, given that we are late in the process, i see no problem if the VM doesn't trust record fields as a temporary patch, if it's easier than to have Field.set() to ask if a class is a plain class or not. It's far better than having the the JLS definition of a record bolted into the VM. > > Any other solution IMHO seems more like an hack to me. I disagree, having the VM behaving strictly like Java is a hack. Microsoft has done that with .Net generics which are C# generics. I don't see the point of repeating the errors of the past. > > Maurizio R?mi > > On 09/12/2020 16:58, Chris Hegarty wrote: >> I see that the thread [1] tailed off without any real conclusion or >> consensus. >> >> Getting to a place where it is simple to add new kinds of classes whose >> non-static final fields are trusted is a worthy goal. I just question if >> doing so with a record attribute is the right move. Instead we can >> consider how best that could be achieved orthogonal to records. >> >> I see Mandy's PR as an intermediate step towards that goal. For now, we >> limit TNSFF to records and hidden classes, but eventually this can be >> superseded by a predicate on j.l.Class (or some such), which encompasses >> the aforementioned kinds of classes and possibly others. >> >> We have a material specification issue in Java 16 (as Mandy describes) - >> how to specify java.lang.reflect.Field::set. Mandy's PR resolves this >> issue while retaining TNSFF for record classes. This leaves the door >> open to further evolution to get to the above goal. >> >> -Chris. >> >>> On 9 Dec 2020, at 10:39, Remi Forax wrote: >>> >>> forwarded to amber-spec-experts >>> >>> R?mi >>> >>> ----- Mail transf?r? ----- >>> De: "mandy chung" >>> ?: "amber-dev" >>> Envoy?: Mercredi 9 D?cembre 2020 05:00:03 >>> Objet: Should final fields in records be trusted or not trusted in 16? >>> >>> I need your help, amber experts, in understanding the conclusion on the >>> amber-spec-experts discussion [1]. It isn't clear to me what it's >>> agreed to do in Java SE 16. Remi raised in PR for JDK-8257596 [2] and so >>> your clarification would help. PR #1706 intends to fix the regression >>> introduced by JDK-8255342 that removes non-specified JVM checks on >>> classes with RecordComponents attributes. This does not conflict with >>> the work to implement the true TNSFF for all classes like JDK-8233873. >>> >>> One way I read [1] is that it's agreed to revisit the current approach >>> [3] that makes final fields in record classes "read-only" by reflection >>> and JIT optimization to trust final fields in records (note that JIT >>> optimization is implementation-specific). Instead all final field values >>> should be trusted as a constant (see JDK-8233873). >>> >>> If this is the agreement, I see two options for JDK 16: >>> 1. Keep JDK-8247444 and fix the regression as proposed by PR #1706 [2] >>> 2. Backout JDK-8247444 [4]. This involves spec change and we shall act >>> on it quickly. >>> >>> Making all final field values trusted as a constant will be a separate >>> enhancement regardless of which option it goes. >>> >>> Please clarify. >>> >>> Mandy >>> [1] >>> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002630.html >>> [2] https://github.com/openjdk/jdk/pull/1706 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8247444 > >> [4] https://github.com/openjdk/jdk/compare/master...mlchung:backout-8247444 From chris.hegarty at oracle.com Thu Dec 10 14:35:20 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Dec 2020 14:35:20 +0000 Subject: Should final fields in records be trusted or not trusted in 16? In-Reply-To: <1804942293.487843.1607609491442.JavaMail.zimbra@u-pem.fr> References: <7d1f2609-a894-9393-43f8-7295bc3e4d7a@oracle.com> <1434527460.1950440.1607510392620.JavaMail.zimbra@u-pem.fr> <0F870CD3-E3F0-4A7E-BE09-BAD73BDC71F1@oracle.com> <83bf2f96-1f9f-8d90-d2e2-2b1e9f5b3ddd@oracle.com> <1804942293.487843.1607609491442.JavaMail.zimbra@u-pem.fr> Message-ID: > On 10 Dec 2020, at 14:11, forax at univ-mlv.fr wrote: >> ... > > There is a third choice see above. > > Forcing the semantics of Java into the VM is always a bad idea. > We don't do that for any other constructs, lambda, enums, Java anonymous classes, etc. > Worst, we already know that an inline record is not a record from the JLS POV. > > For Java 16, given that we are late in the process, i see no problem if the VM doesn't trust record fields as a temporary patch, if it's easier than to have Field.set() to ask if a class is a plain class or not. It's far better than having the the JLS definition of a record bolted into the VM. In my view, this is an ?everyone loses? option. If we do not prevent Field.set() from modifying the fields of a record class in Java 16, then it will be almost impossible to do so at some future point. The intermediate step that we?re proposing both allows for 1) TNSFF in record classes, and 2) an evolution path to a more general mechanism in the future. I do not see that no.1 is covered by option three. -Chris. From forax at univ-mlv.fr Thu Dec 10 14:43:24 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 10 Dec 2020 15:43:24 +0100 (CET) Subject: Should final fields in records be trusted or not trusted in 16? In-Reply-To: References: <7d1f2609-a894-9393-43f8-7295bc3e4d7a@oracle.com> <1434527460.1950440.1607510392620.JavaMail.zimbra@u-pem.fr> <0F870CD3-E3F0-4A7E-BE09-BAD73BDC71F1@oracle.com> <83bf2f96-1f9f-8d90-d2e2-2b1e9f5b3ddd@oracle.com> <1804942293.487843.1607609491442.JavaMail.zimbra@u-pem.fr> Message-ID: <1061579752.523439.1607611404823.JavaMail.zimbra@u-pem.fr> > De: "Chris Hegarty" > ?: "Remi Forax" > Cc: "Maurizio Cimadamore" , "amber-spec-experts" > , "mandy chung" > Envoy?: Jeudi 10 D?cembre 2020 15:35:20 > Objet: Re: Should final fields in records be trusted or not trusted in 16? >> On 10 Dec 2020, at 14:11, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >> wrote: >>> ... >> There is a third choice see above. >> Forcing the semantics of Java into the VM is always a bad idea. >> We don't do that for any other constructs, lambda, enums, Java anonymous >> classes, etc. >> Worst, we already know that an inline record is not a record from the JLS POV. >> For Java 16, given that we are late in the process, i see no problem if the VM >> doesn't trust record fields as a temporary patch, if it's easier than to have >> Field.set() to ask if a class is a plain class or not. It's far better than >> having the the JLS definition of a record bolted into the VM. > In my view, this is an ?everyone loses? option. > If we do not prevent Field.set() from modifying the fields of a record > class in Java 16, then it will be almost impossible to do so at some > future point. The intermediate step that we?re proposing both allows > for 1) TNSFF in record classes, and 2) an evolution path to a more > general mechanism in the future. I do not see that no.1 is covered by > option three. yeah, you maybe right because records is not a preview feature anymore, i've forgotten that important "detail". > -Chris. R?mi From brian.goetz at oracle.com Thu Dec 10 14:59:22 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 10 Dec 2020 09:59:22 -0500 Subject: Should final fields in records be trusted or not trusted in 16? In-Reply-To: <83bf2f96-1f9f-8d90-d2e2-2b1e9f5b3ddd@oracle.com> References: <7d1f2609-a894-9393-43f8-7295bc3e4d7a@oracle.com> <1434527460.1950440.1607510392620.JavaMail.zimbra@u-pem.fr> <0F870CD3-E3F0-4A7E-BE09-BAD73BDC71F1@oracle.com> <83bf2f96-1f9f-8d90-d2e2-2b1e9f5b3ddd@oracle.com> Message-ID: <63790385-4136-74f2-7eef-3191bac59e9b@oracle.com> > Which leaves us two options: > > * revert the changes which allowed the VM to trust record fields > * keep trusting record fields, but on a more solid definition of what > a record is (which is in line with what the JLS, and the reflection > API say) > > Any other solution IMHO seems more like an hack to me. Agreed.?? Either is fine here. There's an aspect here (again) of falling for the siren song of a "point hack" for an emotionally-laden general problem.? We all hate that final fields are not really final, and there's a risk of being blinded by that hatred.? (This siren sings to us about nullity and mutability too, whenever there's new language surface.) Remi a dit: > If the definition is a class that contains a record attribute which is the current definition for the VM, then i don't see a problem if Scala Tuples or an immutable Kotlin data types are using the record Attribute. That line of thinking is where tomorrow's problems come from!? No thanks! > Forcing the semantics of Java into the VM is always a bad idea. I think describing this particular thing as "forcing language semantics into the VM" is a bit of an exaggeration, but I certainly have no problem with the conclusion: revert the optimization and invest the dividend in making it more general. From maurizio.cimadamore at oracle.com Thu Dec 10 15:17:15 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 10 Dec 2020 15:17:15 +0000 Subject: Should final fields in records be trusted or not trusted in 16? In-Reply-To: <1804942293.487843.1607609491442.JavaMail.zimbra@u-pem.fr> References: <7d1f2609-a894-9393-43f8-7295bc3e4d7a@oracle.com> <1434527460.1950440.1607510392620.JavaMail.zimbra@u-pem.fr> <0F870CD3-E3F0-4A7E-BE09-BAD73BDC71F1@oracle.com> <83bf2f96-1f9f-8d90-d2e2-2b1e9f5b3ddd@oracle.com> <1804942293.487843.1607609491442.JavaMail.zimbra@u-pem.fr> Message-ID: On 10/12/2020 14:11, forax at univ-mlv.fr wrote: > I disagree, having the VM behaving strictly like Java is a hack. Microsoft has done that with .Net generics which are C# generics. I don't see the point of repeating the errors of the past. I think you are missing my broader point. I don't think that waving the "it's always a bad idea to have Java concepts inside the VM"? wand is a trick that can be always applied. While I generally I agree with you, the case of records does strike me as different from your typical feature, especially because there's so much reflection support in there. * Class:isRecord * Class:getRecordComponents There are so many promises implicit in this: for instance, let's look at getRecordComponents javadoc: " The components are returned in the same order that they are declared in the record header. The array is empty if this record class has no components. If the class is not a record class, that is isRecord() returns false, then this method returns null. Conversely, if isRecord() returns true, then this method returns a non-null value." Ok, so, if "isRecord" is true, then I will get some components out of this... but when does "isRecord" return true? "Returns true if and only if this class is a record class. The direct superclass of a record class is java.lang.Record"|| Now, while this is open to interpretation, my feeling is that "only if this class is a record class" will be read in a very precise way - the JLS way, to be explicit. The isEnum spec is even more explicit and says "Returns true if and only if this class was declared as an enum in the source code". Now, under the hood, yes, enums are just classes with a flag, but the Class::isEnum implementation has an explicit check on the enum supertype. In other words, the implementation of Class::isEnum and Class::isRecord are 100% aligned (apart from the fact that one is checking for presence of a flag and the other is checking for the presence of an attribute). I'd say this is a pretty strong precedent. Java reflection has always had a special relationship with Java (the language). So, IMHO, it's totally fine for methods in core reflection to refer to JLS properties (such as enum-ness or record-ness) and try to enforce those in the best way they can. So, to summarize: * j.l.Class::isRecord is consistent with j.l.Class::isEnum - so there's no bug there * we have other methods in the reflection API (Field::set and Class::getRecordComponents) which needs some kind of "is record" predicate * adding two subtly different predicates, and use one or the other depending on, well, convenience, still seems like an odd solution Maurizio From john.r.rose at oracle.com Thu Dec 10 19:46:02 2020 From: john.r.rose at oracle.com (John Rose) Date: Thu, 10 Dec 2020 11:46:02 -0800 Subject: Should final fields in records be trusted or not trusted in 16? In-Reply-To: References: <7d1f2609-a894-9393-43f8-7295bc3e4d7a@oracle.com> <1434527460.1950440.1607510392620.JavaMail.zimbra@u-pem.fr> <0F870CD3-E3F0-4A7E-BE09-BAD73BDC71F1@oracle.com> <83bf2f96-1f9f-8d90-d2e2-2b1e9f5b3ddd@oracle.com> <1804942293.487843.1607609491442.JavaMail.zimbra@u-pem.fr> Message-ID: <2BBFBC64-F214-45BD-8F49-6048281227BA@oracle.com> On Dec 10, 2020, at 6:35 AM, Chris Hegarty wrote: > > >> On 10 Dec 2020, at 14:11, forax at univ-mlv.fr wrote: >>> ... >> >> There is a third choice see above. >> >> Forcing the semantics of Java into the VM is always a bad idea. >> We don't do that for any other constructs, lambda, enums, Java anonymous classes, etc. >> Worst, we already know that an inline record is not a record from the JLS POV. >> >> For Java 16, given that we are late in the process, i see no problem if the VM doesn't trust record fields as a temporary patch, if it's easier than to have Field.set() to ask if a class is a plain class or not. It's far better than having the the JLS definition of a record bolted into the VM. > > In my view, this is an ?everyone loses? option. +100 The question is, must everyone lose this battle? I hope not. I am content, for the present, with a ?hacky? rule that says, as narrowly and restrictively as necessary, ?if it?s a JLS record, then the JVM defends the fields, period?. The hackiness can be lifted over time after we (hello Mandy!) figure out how to make final fields more uniformly trustable. We don?t have a complete solution yet, but that does not mandate protecting fields we know can merit special protection. Current examples of fields that enjoy special protection: - static finals (true forever) - fields of certain ?locked down? JDK classes (HotSpot ad hoc logic) - hidden classes (new feature, new behavior) - records (assuming non-rollback of JDK-8247444) Perhaps the more important defining feature of records is the restricted process by which instance are created: Via a canonical constructor. This is important to defend, even apart from the integrity of final fields. And this leads me to what I think is the most compelling reason for making a ?special pleading? for record fields (i.e., JDK-8247444): If we don?t defend record fields against reflective Field.set, we will open the gate for off-label creation of records *apart from the canonical constructor*. This subverts, not only a desirable set of optimizations on records, but also a crucial invariant, that every record comes from a CC invocation. Let?s not allow that; indeed that would be another aspect of ?everybody loses?. > If we do not prevent Field.set() from modifying the fields of a record > class in Java 16, then it will be almost impossible to do so at some > future point. The intermediate step that we?re proposing both allows > for 1) TNSFF in record classes, and 2) an evolution path to a more > general mechanism in the future. I do not see that no.1 is covered by > option three. Yes. I think given the life-cycle restrictions on records, even if our future more general evolution path for finals is *inconsistent* with what we did in JDK-8247444, we still win, because records have a special property. Let?s not dilute that property (having invested so much in records!), even if there is a risk that what we did in JDK-8247444 will be inconsistent with the future general facility. But (spoiler alert) I?m sure it won?t be; I?ve been watching this technology arc in the JVM for a long time, and I think JDK-8247444 is not a side-trip, but squarely along the center-line of what we want to do long term. ? John From john.r.rose at oracle.com Thu Dec 10 19:49:12 2020 From: john.r.rose at oracle.com (John Rose) Date: Thu, 10 Dec 2020 11:49:12 -0800 Subject: Should final fields in records be trusted or not trusted in 16? In-Reply-To: <2BBFBC64-F214-45BD-8F49-6048281227BA@oracle.com> References: <7d1f2609-a894-9393-43f8-7295bc3e4d7a@oracle.com> <1434527460.1950440.1607510392620.JavaMail.zimbra@u-pem.fr> <0F870CD3-E3F0-4A7E-BE09-BAD73BDC71F1@oracle.com> <83bf2f96-1f9f-8d90-d2e2-2b1e9f5b3ddd@oracle.com> <1804942293.487843.1607609491442.JavaMail.zimbra@u-pem.fr> <2BBFBC64-F214-45BD-8F49-6048281227BA@oracle.com> Message-ID: <9F7F4E44-B363-4798-AF38-A75D2F6BE260@oracle.com> On Dec 10, 2020, at 11:46 AM, John Rose wrote: > > We don?t have a complete solution yet, but that does not > mandate protecting fields we know can merit special > protection. (Oops, meant to say something like ?that incompleteness does not prevent us from protecting fields that we know today can merit special protection.?) From mandy.chung at oracle.com Thu Dec 10 20:12:20 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Dec 2020 12:12:20 -0800 Subject: Should final fields in records be trusted or not trusted in 16? In-Reply-To: <2BBFBC64-F214-45BD-8F49-6048281227BA@oracle.com> References: <7d1f2609-a894-9393-43f8-7295bc3e4d7a@oracle.com> <1434527460.1950440.1607510392620.JavaMail.zimbra@u-pem.fr> <0F870CD3-E3F0-4A7E-BE09-BAD73BDC71F1@oracle.com> <83bf2f96-1f9f-8d90-d2e2-2b1e9f5b3ddd@oracle.com> <1804942293.487843.1607609491442.JavaMail.zimbra@u-pem.fr> <2BBFBC64-F214-45BD-8F49-6048281227BA@oracle.com> Message-ID: On 12/10/20 11:46 AM, John Rose wrote: > On Dec 10, 2020, at 6:35 AM, Chris Hegarty > wrote: >> >> >>> On 10 Dec 2020, at 14:11, forax at univ-mlv.fr >>> wrote: >>>> ... >>> >>> There is a third choice see above. >>> >>> Forcing the semantics of Java into the VM is always a bad idea. >>> We don't do that for any other constructs, lambda, enums, Java >>> anonymous classes, etc. >>> Worst, we already know that an inline record is not a record from >>> the JLS POV. >>> >>> For Java 16, given that we are late in the process, i see no problem >>> if the VM doesn't trust record fields as a temporary patch, if it's >>> easier than to have Field.set() to ask if a class is a plain class >>> or not. It's far better than having the the JLS definition of a >>> record bolted into the VM. >> >> In my view, this is an ?everyone loses? option. > > +100 ?The question is, must everyone lose this battle? ?I hope not. > > I am content, for the present, with a ?hacky? rule that says, > as narrowly and restrictively as necessary, ?if it?s a JLS record, > then the JVM defends the fields, period?. > > The hackiness can be lifted over time after we (hello Mandy!) > figure out how to make final fields more uniformly trustable. > We don?t have a complete solution yet, but that does not > mandate protecting fields we know can merit special > protection. ?Current examples of fields that enjoy special > protection: > > ?- static finals (true forever) > ?- fields of certain ?locked down? JDK classes (HotSpot ad hoc logic) > ?- hidden classes (new feature, new behavior) > ?- records (assuming non-rollback of?JDK-8247444) > > Perhaps the more important defining feature of records is the > restricted process by which instance are created: ?Via a canonical > constructor. ?This is important to defend, even apart from the > integrity of final fields. ?And this leads me to what I think is the > most compelling reason for making a ?special pleading? for > record fields (i.e., JDK-8247444): ?If we don?t defend record fields > against reflective Field.set, we will open the gate for off-label > creation of records *apart from the canonical constructor*. > This subverts, not only a desirable set of optimizations on > records, but also a crucial invariant, that every record comes > from a CC invocation. ?Let?s not allow that; indeed that would > be another aspect of ?everybody loses?. > That's the merit of JDK-8247444 that final fields should be enforced as "read-only"? (except debugging).?? It also took future TNSFF into consideration: if the future ended up liking to open up final fields of a record class to be modifiable reflectively (I doubt that), `Field::set` spec could be updated to take out such restriction with no compatibility risk. >> If we do not prevent Field.set() from modifying the fields of a record >> class in Java 16, then it will be almost impossible to do so at some >> future point. The intermediate step that we?re proposing both allows >> for 1) TNSFF in record classes, and 2) an evolution path to a more >> general mechanism in the future. I do not see that no.1 is covered by >> option three. > > Yes. ?I think given the life-cycle restrictions on records, even if > our future more general evolution path for finals is *inconsistent* > with what we did in JDK-8247444, we still win, because records > have a special property. ?Let?s not dilute that property (having > invested so much in records!), even if there is a risk that what > we did in JDK-8247444 will be inconsistent with the future > general facility. ?But (spoiler alert) I?m sure it won?t be; I?ve > been watching this technology arc in the JVM for a long time, > and I think?JDK-8247444 is not a side-trip, but squarely along > the center-line of what we want to do long term. Mandy From amber-spec-experts-owner at openjdk.java.net Fri Dec 11 17:59:43 2020 From: amber-spec-experts-owner at openjdk.java.net (amber-spec-experts-owner at openjdk.java.net) Date: Fri, 11 Dec 2020 17:59:43 +0000 Subject: Your message to amber-spec-experts awaits moderator approval Message-ID: Your mail to 'amber-spec-experts' with the subject Re: Should final fields in records be trusted or not trusted in 16? Is being held until the list moderator can review it for approval. The reason it is being held: Post to moderated list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://mail.openjdk.java.net/mailman/confirm/amber-spec-experts/68e3b7a0f0f26ae946fcefa143d8c28198e0b49a From gmcddcmg at gmail.com Fri Dec 11 19:52:52 2020 From: gmcddcmg at gmail.com (Gene McDaniel) Date: Fri, 11 Dec 2020 11:52:52 -0800 Subject: Your message to amber-spec-experts awaits moderator approval In-Reply-To: References: Message-ID: Any email I sent was in error. Please disregard. Apologies for the disruption. On Fri, Dec 11, 2020 at 9:59 AM wrote: > Your mail to 'amber-spec-experts' with the subject > > Re: Should final fields in records be trusted or not trusted in > 16? > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post to moderated list > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > > https://mail.openjdk.java.net/mailman/confirm/amber-spec-experts/68e3b7a0f0f26ae946fcefa143d8c28198e0b49a > > From gavin.bierman at oracle.com Tue Dec 22 11:46:53 2020 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 22 Dec 2020 11:46:53 +0000 Subject: Specs update Message-ID: <8DAC379A-ED16-4C76-AE2A-776358F6C0A9@oracle.com> As we rampdown to JDK 16, the three spec bundles have been polished up a little. I?ve updated them all: * Records: http://cr.openjdk.java.net/~gbierman/jep395/latest/ * Pattern matching for instanceof: http://cr.openjdk.java.net/~gbierman/jep394/latest/ * Sealed Classes: http://cr.openjdk.java.net/~gbierman/jep397/latest/ Nearly all of the changes are just polishing up the language. However, the pattern matching spec did have a small, significant change: Given that we had already lifted the restriction that pattern variables were always final, we have now decided to allow pattern variables to support a `final` modifier. For example: if (e instanceof final String s) { // s is in scope and final here ... } You?ll see also in the pattern matching spec that we have taken the opportunity to tidy up the treatment of local variables in various places; this is old technical debt that we are paying down, but given that pattern variables are a subset of local variables we had an opportunity to finally do this. As always, further polishing may apply as they get inserted into the actual specs. If you have any comments please let me know. Wishing you all Happy Holidays and a better 2021! Gavin From mark at io7m.com Sun Dec 27 21:04:43 2020 From: mark at io7m.com (Mark Raynsford) Date: Sun, 27 Dec 2020 21:04:43 +0000 Subject: Unexpected compilation error with generic sealed interface Message-ID: <20201227210443.1d502b61@sunflower.int.arc7.info> Hello! A friend of mine handed me this example that fails to compile using JDK 17 EA 3: ~~ final class SealedExample { private SealedExample() { } // Compiles if you remove `sealed` or if `I` is not generic. sealed interface I { final class C implements I { } } static void f(final I x) { if (x instanceof I.C) { } } } ~~ The error is: ~~ src/main/java/SealedRecord.java:14: error: incompatible types: I cannot be converted to C if (x instanceof I.C) { ^ 1 error ~~ The error goes away if you remove the word "sealed" from the interface. In her words: "It breaks simple things like Option.". I can see the reasoning required on behalf of the compiler: You've handed me an I, and by the definition of I, there's exactly one class that could yield an I: C. I'm unsure of whether the compiler should be rejecting these definitions or not. -- Mark Raynsford | https://www.io7m.com From forax at univ-mlv.fr Sun Dec 27 22:40:50 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 27 Dec 2020 23:40:50 +0100 (CET) Subject: Unexpected compilation error with generic sealed interface In-Reply-To: <20201227210443.1d502b61@sunflower.int.arc7.info> References: <20201227210443.1d502b61@sunflower.int.arc7.info> Message-ID: <1575931505.744424.1609108850202.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "mark" > ?: "amber-spec-experts" > Envoy?: Dimanche 27 D?cembre 2020 22:04:43 > Objet: Unexpected compilation error with generic sealed interface > Hello! > > A friend of mine handed me this example that fails to compile using > JDK 17 EA 3: > > ~~ > final class SealedExample > { > private SealedExample() > { > > } > > // Compiles if you remove `sealed` or if `I` is not generic. > sealed interface I { > final class C implements I { } > } > > static void f(final I x) { > if (x instanceof I.C) { > > } > } > } > ~~ > > The error is: > > ~~ > src/main/java/SealedRecord.java:14: error: incompatible types: > I cannot be converted to C if (x instanceof I.C) { > ^ > 1 error > ~~ > > The error goes away if you remove the word "sealed" from the > interface. In her words: "It breaks simple things like Option.". > > I can see the reasoning required on behalf of the compiler: You've > handed me an I, and by the definition of I, there's exactly one > class that could yield an I: C. > > I'm unsure of whether the compiler should be rejecting these > definitions or not. Hi Mark, this is an interesting snippet, while i struggle to understand why someone want to write a code like that, I is parametrized by T but the only possible subclass implements I so T is useless here, anyway, the compiler should not reject that code so it's a bug. I've also tested with latest Eclipse and IntelliJ and in both cases it compiles fine. > > -- > Mark Raynsford | https://www.io7m.com R?mi From mark at io7m.com Mon Dec 28 10:33:03 2020 From: mark at io7m.com (Mark Raynsford) Date: Mon, 28 Dec 2020 10:33:03 +0000 Subject: Unexpected compilation error with generic sealed interface In-Reply-To: <1575931505.744424.1609108850202.JavaMail.zimbra@u-pem.fr> References: <20201227210443.1d502b61@sunflower.int.arc7.info> <1575931505.744424.1609108850202.JavaMail.zimbra@u-pem.fr> Message-ID: <20201228103304.1467696c@sunflower.int.arc7.info> On 2020-12-27T23:40:50 +0100 Remi Forax wrote: > Hi Mark, > this is an interesting snippet, while i struggle to understand why someone want to write a code like that, I is parametrized by T but the only possible subclass implements I so T is useless here, > anyway, the compiler should not reject that code so it's a bug. Hello! I think the original code was a collection of little functional data structures (Option, List, etc) to try out the combination of records and sealed classes. The code above is the result of removing things one by one until the result was a minimal example that would trigger the error. -- Mark Raynsford | https://www.io7m.com From vicente.romero at oracle.com Mon Dec 28 16:41:36 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 28 Dec 2020 11:41:36 -0500 Subject: Unexpected compilation error with generic sealed interface In-Reply-To: <20201228103304.1467696c@sunflower.int.arc7.info> References: <20201227210443.1d502b61@sunflower.int.arc7.info> <1575931505.744424.1609108850202.JavaMail.zimbra@u-pem.fr> <20201228103304.1467696c@sunflower.int.arc7.info> Message-ID: Hi, I believe this to be the same issue already addressed in [1], which has already been fixed in 16 and should be forward-ported to 17, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8258662 On 12/28/20 5:33 AM, Mark Raynsford wrote: > On 2020-12-27T23:40:50 +0100 > Remi Forax wrote: > >> Hi Mark, >> this is an interesting snippet, while i struggle to understand why someone want to write a code like that, I is parametrized by T but the only possible subclass implements I so T is useless here, >> anyway, the compiler should not reject that code so it's a bug. > Hello! > > I think the original code was a collection of little functional data > structures (Option, List, etc) to try out the combination of records > and sealed classes. > > The code above is the result of removing things one by one until the > result was a minimal example that would trigger the error. > From mark at io7m.com Mon Dec 28 16:53:02 2020 From: mark at io7m.com (Mark Raynsford) Date: Mon, 28 Dec 2020 16:53:02 +0000 Subject: Unexpected compilation error with generic sealed interface In-Reply-To: References: <20201227210443.1d502b61@sunflower.int.arc7.info> <1575931505.744424.1609108850202.JavaMail.zimbra@u-pem.fr> <20201228103304.1467696c@sunflower.int.arc7.info> Message-ID: <20201228165302.5a7f3318@sunflower.int.arc7.info> On 2020-12-28T11:41:36 -0500 Vicente Romero wrote: > Hi, > > I believe this to be the same issue already addressed in [1], which has > already been fixed in 16 and should be forward-ported to 17, Looks like it, yes! Didn't realize the same code had been submitted there. To be clear: The original symptom was an actual compiler crash. Now we just get a compilation error ("I cannot be converted to C"). An error is obviously better than a crash, but I don't think this code should result in an error at all. -- Mark Raynsford | https://www.io7m.com From vicente.romero at oracle.com Mon Dec 28 18:37:50 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 28 Dec 2020 13:37:50 -0500 Subject: Unexpected compilation error with generic sealed interface In-Reply-To: <20201228165302.5a7f3318@sunflower.int.arc7.info> References: <20201227210443.1d502b61@sunflower.int.arc7.info> <1575931505.744424.1609108850202.JavaMail.zimbra@u-pem.fr> <20201228103304.1467696c@sunflower.int.arc7.info> <20201228165302.5a7f3318@sunflower.int.arc7.info> Message-ID: On 12/28/20 11:53 AM, Mark Raynsford wrote: > On 2020-12-28T11:41:36 -0500 > Vicente Romero wrote: > >> Hi, >> >> I believe this to be the same issue already addressed in [1], which has >> already been fixed in 16 and should be forward-ported to 17, > Looks like it, yes! Didn't realize the same code had been submitted > there. I have realized that your code is almost the same as the bug I was referring to but it is not exactly equal. What you are reporting is another issue, it is great that you have discovered and reported it while we still have time to fix it in 16. I will file a bug an propose a fix for it. > > To be clear: The original symptom was an actual compiler crash. Now we > just get a compilation error ("I cannot be converted to C"). An > error is obviously better than a crash, but I don't think this code > should result in an error at all. > Thanks! Vicente