From maurizio.cimadamore at oracle.com Mon Oct 2 16:44:27 2023 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 2 Oct 2023 17:44:27 +0100 Subject: JLS primitive type in patterns draft In-Reply-To: References: Message-ID: <9dbbbfc9-5744-8b77-64ff-a0a068431dd1@oracle.com> Hi Aggelos, I did a pass on the primitive pattern JEP: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html Here are some comments: * `A widening primitive conversion of a byte to an int is unconditionally exact. Any value that b holds is representable exactly in an int. As a result, the value of i will always represent, exactly the same information that the variable b holds:` Here it is not very clear where does "b" comes from. It is shown in the code snippet, of course, but the text reads funny because it comes before the snippet. One simple fix would be to move the snippet around: ``` A widening primitive conversion of a byte to an int is unconditionally exact: ??? byte b = ... ??? int i = (int) b; Any value that b holds is representable exactly in an int. As a result, the value of i will always represent, exactly the same information that the variable b holds. ``` * `A conversion C from a type S to a type P for a value x is exact if ...` - I presume you mean that "x" has type S ? If so, would be helpful to spell it out clearly? * `... then |C| is exact if the run-time test |S instanceof P| returns |true|.` - should't this be `x instanceof P` ? * In general, when you deal with multiple conversions (e.g. boxing followed by narrowing followed by XYZ), it is not clear to me that it's worth spelling out all of the combinations? You have defined when a widening is exact. And, we are also defining when an unboxing is exact (e.g. if the source object is not null). Boxing is always exact. As for narrowing you are defining that using instanceof. So... can't we just say that any conversion that is composed of multiple exact conversions is itself exact? (if so, the text can be simplified quite a bit?) * `... if |S| and |P| are both integral types and either of them is |char|,` isn't it the case that this must also be a narrowing conversion? Because if it's widening you already have said that going from any integral to any integral is also exact. * `Otherwise, if both S and P are primitive types, then:` - does this section have to spell out all cases? Or can we say that, again we just issue `x instanceof P` and then we explain how this behaves somewhere else (e.g. in chapter 15) ? * `An inexact conversion may either result in an exception and will not yield any value or may in no exceptions and will yield a value. In the latter case, loss of information has occured.` - this sentence seems to have some issues, especially in the second part (missing "result"?) * `The narrowing reference conversion` -> `A narrowing reference conversion` (same for the para below) * `/P/ contains a pattern with a primitive type /p` /where do we say that e.g. `int x` covers `int` ? This para seems to be about boxing * In 14.11.1.2, I see many references to "T", which is not introduced in this section * "then the result is true if the value of the RelationalExpression could be cast to the primitive type exactly, and false otherwise." Maybe add a reference to the section on exact conversion? Cheers Maurizio // -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Mon Oct 9 13:45:47 2023 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Mon, 9 Oct 2023 13:45:47 +0000 Subject: Draft Spec for Second Preview of String Templates (JEP 459) Message-ID: <7E60F5FB-3C76-4EB6-9B9C-273B9E1FAE58@oracle.com> Dear experts: The first draft of a spec covering JEP 459 (String Templates (Second Preview)) is now available at: https://cr.openjdk.java.net/~gbierman/jep459/latest Feel free to contact me directly or on this list with any comments. Thanks Gavin > On 5 Oct 2023, at 13:20, Mark Reinhold wrote: > > https://openjdk.org/jeps/459 > > Summary: Enhance the Java programming language with string > templates. String templates complement Java's existing string literals > and text blocks by coupling literal text with embedded expressions and > template processors to produce specialized results. This is a preview > language feature and API. > > - Mark From gavin.bierman at oracle.com Mon Oct 9 14:57:37 2023 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Mon, 9 Oct 2023 14:57:37 +0000 Subject: Updated spec for Preview of Statements before super (JEP 447) Message-ID: Dear experts: An updated spec covering JEP 447 (Statements before super (Preview)) is now available at: https://cr.openjdk.java.net/~gbierman/jep447/latest Feel free to contact me directly or on this list with any comments. Thanks Gavin From amaembo at gmail.com Tue Oct 10 05:33:13 2023 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 10 Oct 2023 07:33:13 +0200 Subject: Draft Spec for Second Preview of String Templates (JEP 459) In-Reply-To: <7E60F5FB-3C76-4EB6-9B9C-273B9E1FAE58@oracle.com> References: <7E60F5FB-3C76-4EB6-9B9C-273B9E1FAE58@oracle.com> Message-ID: Hello, experts! Probably it's possible to fix the small thing I wrote before? Namely, the type of template expression and its thrown exceptions are determined by the template expression class signature (namely, the instantiation of R and E generic parameters of Processor) and ignoring the actual signature of the process() method, which may have covariant return type and thrown exception type declared. This looks out of sync with the rest of Java. Example: public final class TemplateTest { interface AnyProcessor extends StringTemplate.Processor {} static class IntProcessor implements AnyProcessor { @Override public Integer process(StringTemplate stringTemplate) { return 123; } } public static void main(String[] args) { // error: incompatible types: java.lang.Object cannot be converted to java.lang.Integer Integer xyz = new IntProcessor()."hello"; // error: unreported exception java.lang.Throwable; must be caught or declared to be thrown Object xyz2 = new IntProcessor()."hello"; } } I'm not sure whether current behavior is explicitly stated in the spec draft, but the reference implementation behaves this way. I would expect this code to be compilable. Note that we have a similar implicit method invocation construct, try-with-resources, and it respects the actual signature of the close() method (namely, declared exceptions). I think that similarly we should respect the actual method signature here. With best regards, Tagir Valeev. On Mon, Oct 9, 2023 at 4:46?PM Gavin Bierman wrote: > > Dear experts: > > The first draft of a spec covering JEP 459 (String Templates (Second Preview)) is now available at: > > https://cr.openjdk.java.net/~gbierman/jep459/latest > > Feel free to contact me directly or on this list with any comments. > > Thanks > Gavin > > > > On 5 Oct 2023, at 13:20, Mark Reinhold wrote: > > > > https://openjdk.org/jeps/459 > > > > Summary: Enhance the Java programming language with string > > templates. String templates complement Java's existing string literals > > and text blocks by coupling literal text with embedded expressions and > > template processors to produce specialized results. This is a preview > > language feature and API. > > > > - Mark From forax at univ-mlv.fr Tue Oct 10 06:38:53 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 10 Oct 2023 08:38:53 +0200 (CEST) Subject: Draft Spec for Second Preview of String Templates (JEP 459) In-Reply-To: References: <7E60F5FB-3C76-4EB6-9B9C-273B9E1FAE58@oracle.com> Message-ID: <650454758.18377906.1696919933520.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Tagir Valeev" > To: "Gavin Bierman" > Cc: "amber-spec-experts" > Sent: Tuesday, October 10, 2023 7:33:13 AM > Subject: Re: Draft Spec for Second Preview of String Templates (JEP 459) > Hello, experts! > > Probably it's possible to fix the small thing I wrote before? Namely, > the type of template expression and its thrown exceptions are > determined by the template expression class signature (namely, the > instantiation of R and E generic parameters of Processor) and ignoring > the actual signature of the process() method, which may have covariant > return type and thrown exception type declared. This looks out of sync > with the rest of Java. Example: > > public final class TemplateTest { > interface AnyProcessor extends StringTemplate.Processor Throwable> {} > > static class IntProcessor implements AnyProcessor { > @Override > public Integer process(StringTemplate stringTemplate) { > return 123; > } > } > > public static void main(String[] args) { > // error: incompatible types: java.lang.Object cannot be > converted to java.lang.Integer > Integer xyz = new IntProcessor()."hello"; > // error: unreported exception java.lang.Throwable; must be > caught or declared to be thrown > Object xyz2 = new IntProcessor()."hello"; > } > } > > I'm not sure whether current behavior is explicitly stated in the spec > draft, but the reference implementation behaves this way. I would > expect this code to be compilable. > > Note that we have a similar implicit method invocation construct, > try-with-resources, and it respects the actual signature of the > close() method (namely, declared exceptions). I think that similarly > we should respect the actual method signature here. The enhanced for-loop also uses the precise iterator type not java.util.Iterator. I agree with Tagir, they should all work the same way. > > With best regards, > Tagir Valeev. regards, R?mi > > On Mon, Oct 9, 2023 at 4:46?PM Gavin Bierman wrote: >> >> Dear experts: >> >> The first draft of a spec covering JEP 459 (String Templates (Second Preview)) >> is now available at: >> >> https://cr.openjdk.java.net/~gbierman/jep459/latest >> >> Feel free to contact me directly or on this list with any comments. >> >> Thanks >> Gavin >> >> >> > On 5 Oct 2023, at 13:20, Mark Reinhold wrote: >> > >> > https://openjdk.org/jeps/459 >> > >> > Summary: Enhance the Java programming language with string >> > templates. String templates complement Java's existing string literals >> > and text blocks by coupling literal text with embedded expressions and >> > template processors to produce specialized results. This is a preview >> > language feature and API. >> > > > > - Mark From angelos.bimpoudis at oracle.com Tue Oct 10 15:26:22 2023 From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis) Date: Tue, 10 Oct 2023 15:26:22 +0000 Subject: JLS primitive type in patterns draft In-Reply-To: <9dbbbfc9-5744-8b77-64ff-a0a068431dd1@oracle.com> References: <9dbbbfc9-5744-8b77-64ff-a0a068431dd1@oracle.com> Message-ID: Thank you for the review, Maurizio. I addressed your comments. * `Otherwise, if both S and P are primitive types, then:` - does this section have to spell out all cases? Or can we say that, again we just issue `x instanceof P` and then we explain how this behaves somewhere else (e.g. in chapter 15) ? Exactness (5.5.1) is referenced from two points: 15.20.2 and 14.30.3. That is the rationale for not concentrating part of exactness in chapter 15. The new (latest) URL now includes the JEP number: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html Many thanks! ________________________________ From: Maurizio Cimadamore Sent: 02 October 2023 18:44 To: Angelos Bimpoudis ; amber-spec-experts Subject: JLS primitive type in patterns draft Hi Aggelos, I did a pass on the primitive pattern JEP: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html Here are some comments: * `A widening primitive conversion of a byte to an int is unconditionally exact. Any value that b holds is representable exactly in an int. As a result, the value of i will always represent, exactly the same information that the variable b holds:` Here it is not very clear where does "b" comes from. It is shown in the code snippet, of course, but the text reads funny because it comes before the snippet. One simple fix would be to move the snippet around: ``` A widening primitive conversion of a byte to an int is unconditionally exact: byte b = ... int i = (int) b; Any value that b holds is representable exactly in an int. As a result, the value of i will always represent, exactly the same information that the variable b holds. ``` * `A conversion C from a type S to a type P for a value x is exact if ...` - I presume you mean that "x" has type S ? If so, would be helpful to spell it out clearly? * `... then C is exact if the run-time test S instanceof P returns true.` - should't this be `x instanceof P` ? * In general, when you deal with multiple conversions (e.g. boxing followed by narrowing followed by XYZ), it is not clear to me that it's worth spelling out all of the combinations? You have defined when a widening is exact. And, we are also defining when an unboxing is exact (e.g. if the source object is not null). Boxing is always exact. As for narrowing you are defining that using instanceof. So... can't we just say that any conversion that is composed of multiple exact conversions is itself exact? (if so, the text can be simplified quite a bit?) * `... if S and P are both integral types and either of them is char,` isn't it the case that this must also be a narrowing conversion? Because if it's widening you already have said that going from any integral to any integral is also exact. * `Otherwise, if both S and P are primitive types, then:` - does this section have to spell out all cases? Or can we say that, again we just issue `x instanceof P` and then we explain how this behaves somewhere else (e.g. in chapter 15) ? * `An inexact conversion may either result in an exception and will not yield any value or may in no exceptions and will yield a value. In the latter case, loss of information has occured.` - this sentence seems to have some issues, especially in the second part (missing "result"?) * `The narrowing reference conversion` -> `A narrowing reference conversion` (same for the para below) * `P contains a pattern with a primitive type p` where do we say that e.g. `int x` covers `int` ? This para seems to be about boxing * In 14.11.1.2, I see many references to "T", which is not introduced in this section * "then the result is true if the value of the RelationalExpression could be cast to the primitive type exactly, and false otherwise." Maybe add a reference to the section on exact conversion? Cheers Maurizio -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Fri Oct 13 09:13:22 2023 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Fri, 13 Oct 2023 09:13:22 +0000 Subject: Draft Spec for Second Preview of String Templates (JEP 459) In-Reply-To: References: <7E60F5FB-3C76-4EB6-9B9C-273B9E1FAE58@oracle.com> Message-ID: <58F7FEF8-F4FA-4579-814D-D26CC901067A@oracle.com> Hi Tagir, Apologies for not replying sooner. Yes, this is an excellent suggestion - improving the precision of typing template expressions is a very welcome change :-) I have updated the spec, and the compiler will be updated shortly. Thanks, Gavin > On 10 Oct 2023, at 06:33, Tagir Valeev wrote: > > Hello, experts! > > Probably it's possible to fix the small thing I wrote before? Namely, > the type of template expression and its thrown exceptions are > determined by the template expression class signature (namely, the > instantiation of R and E generic parameters of Processor) and ignoring > the actual signature of the process() method, which may have covariant > return type and thrown exception type declared. This looks out of sync > with the rest of Java. Example: > > public final class TemplateTest { > interface AnyProcessor extends StringTemplate.Processor Throwable> {} > > static class IntProcessor implements AnyProcessor { > @Override > public Integer process(StringTemplate stringTemplate) { > return 123; > } > } > > public static void main(String[] args) { > // error: incompatible types: java.lang.Object cannot be > converted to java.lang.Integer > Integer xyz = new IntProcessor()."hello"; > // error: unreported exception java.lang.Throwable; must be > caught or declared to be thrown > Object xyz2 = new IntProcessor()."hello"; > } > } > > I'm not sure whether current behavior is explicitly stated in the spec > draft, but the reference implementation behaves this way. I would > expect this code to be compilable. > > Note that we have a similar implicit method invocation construct, > try-with-resources, and it respects the actual signature of the > close() method (namely, declared exceptions). I think that similarly > we should respect the actual method signature here. > > With best regards, > Tagir Valeev. > > On Mon, Oct 9, 2023 at 4:46?PM Gavin Bierman wrote: >> >> Dear experts: >> >> The first draft of a spec covering JEP 459 (String Templates (Second Preview)) is now available at: >> >> https://cr.openjdk.java.net/~gbierman/jep459/latest >> >> Feel free to contact me directly or on this list with any comments. >> >> Thanks >> Gavin >> >> >>> On 5 Oct 2023, at 13:20, Mark Reinhold wrote: >>> >>> https://openjdk.org/jeps/459 >>> >>> Summary: Enhance the Java programming language with string >>> templates. String templates complement Java's existing string literals >>> and text blocks by coupling literal text with embedded expressions and >>> template processors to produce specialized results. This is a preview >>> language feature and API. >>> >>> - Mark From amaembo at gmail.com Fri Oct 13 19:44:45 2023 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 13 Oct 2023 21:44:45 +0200 Subject: Draft Spec for Second Preview of String Templates (JEP 459) In-Reply-To: <58F7FEF8-F4FA-4579-814D-D26CC901067A@oracle.com> References: <7E60F5FB-3C76-4EB6-9B9C-273B9E1FAE58@oracle.com> <58F7FEF8-F4FA-4579-814D-D26CC901067A@oracle.com> Message-ID: Looks great, thank you! Tagir On Fri, Oct 13, 2023, 11:13 Gavin Bierman wrote: > Hi Tagir, > > Apologies for not replying sooner. Yes, this is an excellent suggestion - > improving the precision of typing template expressions is a very welcome > change :-) > > I have updated the spec, and the compiler will be updated shortly. > > Thanks, > Gavin > > > On 10 Oct 2023, at 06:33, Tagir Valeev wrote: > > > > Hello, experts! > > > > Probably it's possible to fix the small thing I wrote before? Namely, > > the type of template expression and its thrown exceptions are > > determined by the template expression class signature (namely, the > > instantiation of R and E generic parameters of Processor) and ignoring > > the actual signature of the process() method, which may have covariant > > return type and thrown exception type declared. This looks out of sync > > with the rest of Java. Example: > > > > public final class TemplateTest { > > interface AnyProcessor extends StringTemplate.Processor > Throwable> {} > > > > static class IntProcessor implements AnyProcessor { > > @Override > > public Integer process(StringTemplate stringTemplate) { > > return 123; > > } > > } > > > > public static void main(String[] args) { > > // error: incompatible types: java.lang.Object cannot be > > converted to java.lang.Integer > > Integer xyz = new IntProcessor()."hello"; > > // error: unreported exception java.lang.Throwable; must be > > caught or declared to be thrown > > Object xyz2 = new IntProcessor()."hello"; > > } > > } > > > > I'm not sure whether current behavior is explicitly stated in the spec > > draft, but the reference implementation behaves this way. I would > > expect this code to be compilable. > > > > Note that we have a similar implicit method invocation construct, > > try-with-resources, and it respects the actual signature of the > > close() method (namely, declared exceptions). I think that similarly > > we should respect the actual method signature here. > > > > With best regards, > > Tagir Valeev. > > > > On Mon, Oct 9, 2023 at 4:46?PM Gavin Bierman > wrote: > >> > >> Dear experts: > >> > >> The first draft of a spec covering JEP 459 (String Templates (Second > Preview)) is now available at: > >> > >> https://cr.openjdk.java.net/~gbierman/jep459/latest > >> > >> Feel free to contact me directly or on this list with any comments. > >> > >> Thanks > >> Gavin > >> > >> > >>> On 5 Oct 2023, at 13:20, Mark Reinhold > wrote: > >>> > >>> https://openjdk.org/jeps/459 > >>> > >>> Summary: Enhance the Java programming language with string > >>> templates. String templates complement Java's existing string literals > >>> and text blocks by coupling literal text with embedded expressions and > >>> template processors to produce specialized results. This is a preview > >>> language feature and API. > >>> > >>> - Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Wed Oct 18 14:36:09 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Wed, 18 Oct 2023 09:36:09 -0500 Subject: JLS primitive type in patterns draft In-Reply-To: References: <9dbbbfc9-5744-8b77-64ff-a0a068431dd1@oracle.com> Message-ID: On Tue, Oct 10, 2023 at 11:09?AM Angelos Bimpoudis < angelos.bimpoudis at oracle.com> wrote: > The new (latest) URL now includes the JEP number: > > > https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html > I have a small comment regarding ?5.5.1: > If a conversion is exact then it is guaranteed that it will yield a value. *An > inexact conversion may yield a value regardless whether it was exact or > not.* > That second sentence is awkwardly phrased ("regardless whether"). Would this be clearer? > If a conversion is exact then it is guaranteed that it will yield a value.* > An inexact conversion may or may not yield a value.* > -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Wed Oct 18 14:44:28 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Wed, 18 Oct 2023 09:44:28 -0500 Subject: JLS primitive type in patterns draft In-Reply-To: References: <9dbbbfc9-5744-8b77-64ff-a0a068431dd1@oracle.com> Message-ID: On Wed, Oct 18, 2023 at 9:36?AM Archie Cobbs wrote: > On Tue, Oct 10, 2023 at 11:09?AM Angelos Bimpoudis < > angelos.bimpoudis at oracle.com> wrote: > >> The new (latest) URL now includes the JEP number: >> >> >> https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html >> > > I have a small comment regarding ?5.5.1: > >> If a conversion is exact then it is guaranteed that it will yield a >> value. *An inexact conversion may yield a value regardless whether it >> was exact or not.* >> > That second sentence is awkwardly phrased ("regardless whether"). > > Would this be clearer? > >> If a conversion is exact then it is guaranteed that it will yield a value.* >> An inexact conversion may or may not yield a value.* >> > Sorry, ignore that, I was misinterpreting this. Maybe this would be slightly better: If a conversion is exact then it is guaranteed that it will yield a value. > *An inexact conversion may yield a value, but information could be lost.* > -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From angelos.bimpoudis at oracle.com Wed Oct 18 15:57:24 2023 From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis) Date: Wed, 18 Oct 2023 15:57:24 +0000 Subject: JLS primitive type in patterns draft In-Reply-To: References: <9dbbbfc9-5744-8b77-64ff-a0a068431dd1@oracle.com> Message-ID: Updated. Thank you for spotting, Archie. ________________________________ From: Archie Cobbs Sent: 18 October 2023 16:44 To: Angelos Bimpoudis Cc: Maurizio Cimadamore ; amber-spec-experts Subject: Re: JLS primitive type in patterns draft On Wed, Oct 18, 2023 at 9:36?AM Archie Cobbs > wrote: On Tue, Oct 10, 2023 at 11:09?AM Angelos Bimpoudis > wrote: The new (latest) URL now includes the JEP number: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html I have a small comment regarding ?5.5.1: If a conversion is exact then it is guaranteed that it will yield a value. An inexact conversion may yield a value regardless whether it was exact or not. That second sentence is awkwardly phrased ("regardless whether"). Would this be clearer? If a conversion is exact then it is guaranteed that it will yield a value. An inexact conversion may or may not yield a value. Sorry, ignore that, I was misinterpreting this. Maybe this would be slightly better: If a conversion is exact then it is guaranteed that it will yield a value. An inexact conversion may yield a value, but information could be lost. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Thu Oct 19 00:00:40 2023 From: davidalayachew at gmail.com (David Alayachew) Date: Wed, 18 Oct 2023 20:00:40 -0400 Subject: Reconstruction expression with explicit deconstuctor (REWED) In-Reply-To: References: Message-ID: Adding -comments On Sat, Sep 23, 2023 at 10:54?AM Attila Kelemen wrote: > Note: I think you would have a better chance, if you sent the email to > "amber-spec-comments" than "observers", since the people who can actually > make changes are more likely to read the "comments" list. > > That said, I don't really see the usefulness of such a syntax (and adding > new syntax in itself is a detriment). That is, if I understood you > correctly, then your example would replace this: > > ``` > Point p = ...; > Point pp = new Point(p.x() + 2, 0); > ``` > > which is shorter and a lot more obvious. And if we were to go to more > complicated things (many properties), then it doesn't help that much, > because as far as I understand you, your proposal is still positional in > its deconstruction pattern, and the positional nature is usually what is > awkward in structures with many properties. > > > Harrison Chikwe ezt ?rta (id?pont: 2023. szept. > 23., Szo, 12:01): > >> Hi, >> >> I think that it is very useful to have when working with immutable >> objects. >> >> For the purposes of this mail, let's call the design described in the >> ambro-doc[1]: >> reconstruction expression with implicit deconstructor (aka REWID). >> >> Has it been considered to make the deconstructor pattern explicit in the >> reconstruction >> expression (aka REWED)? >> Doing so may remove the requirement to make names more significant in the >> language. >> >> For example, given the following: >> >> Point p = ...; >> Point pp = p with(int x, int y) { x += 2; y = 0; } >> >> We can interpret the reconstruction expression above as: >> >> . Find a deconstructor and constructor pair that has a signature that >> matches (int, int) >> . Deconstruct the target with the deconstructor >> . Execute the block on RHS >> . Invoke the constructor with the result. >> >> If we split the reconstruction expression into three steps: >> >> 1. Extraction >> 2. Transformation >> 3. Construction >> >> In REWID users are required only to do step 2 (transformation) and the >> system handles 1 and 3. Whereas in REWED users are required to do step 1 >> and 2 >> and the system handles just step 3. >> >> # Other forms of REWED >> >> 1. Explicit Named deconstructor pattern >> >> Point pp = p with Point(int x, int y) {...} >> >> 2. Explicit Var deconstructor pattern >> >> Point pp = p with var(int x, int y) {...} >> >> 3. Explicit Unnamed deconstructor pattern >> >> Point pp = p with(int x, int y) {...} >> >> >> We can extend form 1 to include factory pattern: >> >> Point pp = p with Point.factory(int x, int y) {...} >> >> >> # Advantages >> >> 1. No need to make names significant. >> 2. Can be combined with other patterns (e.g. unnamed pattern, var pattern) >> >> Point pp = p with(int x, _) { x = 0; } >> >> >> Nyehamene. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Thu Oct 19 00:01:42 2023 From: davidalayachew at gmail.com (David Alayachew) Date: Wed, 18 Oct 2023 20:01:42 -0400 Subject: Reconstruction expression with explicit deconstuctor (REWED) In-Reply-To: References: Message-ID: Also adding @amber-dev On Wed, Oct 18, 2023 at 8:00?PM David Alayachew wrote: > Adding -comments > > On Sat, Sep 23, 2023 at 10:54?AM Attila Kelemen < > attila.kelemen85 at gmail.com> wrote: > >> Note: I think you would have a better chance, if you sent the email to >> "amber-spec-comments" than "observers", since the people who can actually >> make changes are more likely to read the "comments" list. >> >> That said, I don't really see the usefulness of such a syntax (and adding >> new syntax in itself is a detriment). That is, if I understood you >> correctly, then your example would replace this: >> >> ``` >> Point p = ...; >> Point pp = new Point(p.x() + 2, 0); >> ``` >> >> which is shorter and a lot more obvious. And if we were to go to more >> complicated things (many properties), then it doesn't help that much, >> because as far as I understand you, your proposal is still positional in >> its deconstruction pattern, and the positional nature is usually what is >> awkward in structures with many properties. >> >> >> Harrison Chikwe ezt ?rta (id?pont: 2023. szept. >> 23., Szo, 12:01): >> >>> Hi, >>> >>> I think that it is very useful to have when working with immutable >>> objects. >>> >>> For the purposes of this mail, let's call the design described in the >>> ambro-doc[1]: >>> reconstruction expression with implicit deconstructor (aka REWID). >>> >>> Has it been considered to make the deconstructor pattern explicit in the >>> reconstruction >>> expression (aka REWED)? >>> Doing so may remove the requirement to make names more significant in >>> the language. >>> >>> For example, given the following: >>> >>> Point p = ...; >>> Point pp = p with(int x, int y) { x += 2; y = 0; } >>> >>> We can interpret the reconstruction expression above as: >>> >>> . Find a deconstructor and constructor pair that has a signature that >>> matches (int, int) >>> . Deconstruct the target with the deconstructor >>> . Execute the block on RHS >>> . Invoke the constructor with the result. >>> >>> If we split the reconstruction expression into three steps: >>> >>> 1. Extraction >>> 2. Transformation >>> 3. Construction >>> >>> In REWID users are required only to do step 2 (transformation) and the >>> system handles 1 and 3. Whereas in REWED users are required to do step 1 >>> and 2 >>> and the system handles just step 3. >>> >>> # Other forms of REWED >>> >>> 1. Explicit Named deconstructor pattern >>> >>> Point pp = p with Point(int x, int y) {...} >>> >>> 2. Explicit Var deconstructor pattern >>> >>> Point pp = p with var(int x, int y) {...} >>> >>> 3. Explicit Unnamed deconstructor pattern >>> >>> Point pp = p with(int x, int y) {...} >>> >>> >>> We can extend form 1 to include factory pattern: >>> >>> Point pp = p with Point.factory(int x, int y) {...} >>> >>> >>> # Advantages >>> >>> 1. No need to make names significant. >>> 2. Can be combined with other patterns (e.g. unnamed pattern, var >>> pattern) >>> >>> Point pp = p with(int x, _) { x = 0; } >>> >>> >>> Nyehamene. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Thu Oct 19 00:23:49 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 18 Oct 2023 20:23:49 -0400 Subject: Reconstruction expression with explicit deconstuctor (REWED) In-Reply-To: References: Message-ID: <4cf8babc-a3cf-69a6-2189-e571198ebe2d@oracle.com> (cross-posting to -comments is discouraged) If we are reconstructing something as trivial as a Point, we might not even use a reconstruction expression, since an ordinary constructor invocation is probably good enough (it only has two components, and we're changing at least one of them.) Now imagine you are reconstructing something with a dozen components, which is where reconstruction expressions offer more value.? I don't think people would be very happy with a syntax like ??? thingie with Thingie(var a, var b, var c, var d, var e, ???????????????????????? var f, var g, var h, var i, var j) { a = 3 } On 10/18/2023 8:01 PM, David Alayachew wrote: > Also adding @amber-dev > > On Wed, Oct 18, 2023 at 8:00?PM David Alayachew > wrote: > > Adding -comments > > On Sat, Sep 23, 2023 at 10:54?AM Attila Kelemen > wrote: > > Note: I think you would have a better chance, if you sent the > email to "amber-spec-comments" than "observers", since the > people who can actually make changes are more likely to read > the "comments" list. > > That said, I don't really see the usefulness of such a syntax > (and adding new syntax in itself is a detriment). That is, if > I understood you correctly, then your example would replace this: > > ``` > Point p = ...; > Point pp = new Point(p.x() + 2, 0); > ``` > > which is shorter and a lot more obvious. And if we were to go > to more complicated things (many properties), then it doesn't > help that much, because as far as I understand you, your > proposal is still positional in its deconstruction pattern, > and the positional nature is usually what is awkward in > structures with many properties. > > > Harrison Chikwe ezt ?rta (id?pont: > 2023. szept. 23., Szo, 12:01): > > Hi, > > I think that it is very useful to have when working with > immutable objects. > > For the purposes of this mail, let's call the design > described in the ambro-doc[1]: > reconstruction expression with implicit deconstructor (aka > REWID). > > Has it been considered to make the deconstructor pattern > explicit in the reconstruction > expression (aka REWED)? > Doing so may remove the requirement to make names more > significant in the language. > > For example, given the following: > > Point p = ...; > Point pp = p with(int x, int y) { x += 2; y = 0; } > > We can interpret the reconstruction expression above as: > > . Find a deconstructor and constructor pair that has a > signature that matches (int, int) > . Deconstruct the target with the deconstructor > . Execute the block on RHS > . Invoke the constructor with the result. > > If we split the reconstruction expression into three steps: > > 1. Extraction > 2. Transformation > 3. Construction > > In REWID users are required only to do step 2 > (transformation) and the > system handles 1 and 3. Whereas in REWED users are > required to do step 1 and 2 > and the system handles just step 3. > > # Other forms of REWED > > 1. Explicit Named deconstructor pattern > > ? ?Point pp = p with Point(int x, int y) {...} > > 2. Explicit Var deconstructor pattern > > ? ?Point pp = p with var(int x, int y) {...} > > 3. Explicit Unnamed deconstructor pattern > > ? ?Point pp = p with(int x, int y) {...} > > > We can extend form 1 to include factory pattern: > > ? ?Point pp = p with Point.factory(int x, int y) {...} > > > # Advantages > > 1. No need to make names significant. > 2. Can be combined with other patterns (e.g. unnamed > pattern, var pattern) > > ? ?Point pp = p with(int x, _) { x = 0; } > > > Nyehamene. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Thu Oct 19 01:04:27 2023 From: davidalayachew at gmail.com (David Alayachew) Date: Wed, 18 Oct 2023 21:04:27 -0400 Subject: Reconstruction expression with explicit deconstuctor (REWED) In-Reply-To: <4cf8babc-a3cf-69a6-2189-e571198ebe2d@oracle.com> References: <4cf8babc-a3cf-69a6-2189-e571198ebe2d@oracle.com> Message-ID: Apologies for the incorrect cross post. I see what you mean. The value that I saw was if Thingie from your example had an alternative deconstructor that only outputted a and b. That way, the default is the given deconstructor, but you can opt into using a separate deconstruction pattern (deconstructor, static pattern, or instance pattern) instead of the default. On Wed, Oct 18, 2023 at 8:23?PM Brian Goetz wrote: > (cross-posting to -comments is discouraged) > > If we are reconstructing something as trivial as a Point, we might not > even use a reconstruction expression, since an ordinary constructor > invocation is probably good enough (it only has two components, and we're > changing at least one of them.) > > Now imagine you are reconstructing something with a dozen components, > which is where reconstruction expressions offer more value. I don't think > people would be very happy with a syntax like > > thingie with Thingie(var a, var b, var c, var d, var e, > var f, var g, var h, var i, var j) { a = 3 } > > > > On 10/18/2023 8:01 PM, David Alayachew wrote: > > Also adding @amber-dev > > On Wed, Oct 18, 2023 at 8:00?PM David Alayachew > wrote: > >> Adding -comments >> >> On Sat, Sep 23, 2023 at 10:54?AM Attila Kelemen < >> attila.kelemen85 at gmail.com> wrote: >> >>> Note: I think you would have a better chance, if you sent the email to >>> "amber-spec-comments" than "observers", since the people who can actually >>> make changes are more likely to read the "comments" list. >>> >>> That said, I don't really see the usefulness of such a syntax (and >>> adding new syntax in itself is a detriment). That is, if I understood you >>> correctly, then your example would replace this: >>> >>> ``` >>> Point p = ...; >>> Point pp = new Point(p.x() + 2, 0); >>> ``` >>> >>> which is shorter and a lot more obvious. And if we were to go to more >>> complicated things (many properties), then it doesn't help that much, >>> because as far as I understand you, your proposal is still positional in >>> its deconstruction pattern, and the positional nature is usually what is >>> awkward in structures with many properties. >>> >>> >>> Harrison Chikwe ezt ?rta (id?pont: 2023. >>> szept. 23., Szo, 12:01): >>> >>>> Hi, >>>> >>>> I think that it is very useful to have when working with immutable >>>> objects. >>>> >>>> For the purposes of this mail, let's call the design described in the >>>> ambro-doc[1]: >>>> reconstruction expression with implicit deconstructor (aka REWID). >>>> >>>> Has it been considered to make the deconstructor pattern explicit in >>>> the reconstruction >>>> expression (aka REWED)? >>>> Doing so may remove the requirement to make names more significant in >>>> the language. >>>> >>>> For example, given the following: >>>> >>>> Point p = ...; >>>> Point pp = p with(int x, int y) { x += 2; y = 0; } >>>> >>>> We can interpret the reconstruction expression above as: >>>> >>>> . Find a deconstructor and constructor pair that has a signature that >>>> matches (int, int) >>>> . Deconstruct the target with the deconstructor >>>> . Execute the block on RHS >>>> . Invoke the constructor with the result. >>>> >>>> If we split the reconstruction expression into three steps: >>>> >>>> 1. Extraction >>>> 2. Transformation >>>> 3. Construction >>>> >>>> In REWID users are required only to do step 2 (transformation) and the >>>> system handles 1 and 3. Whereas in REWED users are required to do step >>>> 1 and 2 >>>> and the system handles just step 3. >>>> >>>> # Other forms of REWED >>>> >>>> 1. Explicit Named deconstructor pattern >>>> >>>> Point pp = p with Point(int x, int y) {...} >>>> >>>> 2. Explicit Var deconstructor pattern >>>> >>>> Point pp = p with var(int x, int y) {...} >>>> >>>> 3. Explicit Unnamed deconstructor pattern >>>> >>>> Point pp = p with(int x, int y) {...} >>>> >>>> >>>> We can extend form 1 to include factory pattern: >>>> >>>> Point pp = p with Point.factory(int x, int y) {...} >>>> >>>> >>>> # Advantages >>>> >>>> 1. No need to make names significant. >>>> 2. Can be combined with other patterns (e.g. unnamed pattern, var >>>> pattern) >>>> >>>> Point pp = p with(int x, _) { x = 0; } >>>> >>>> >>>> Nyehamene. >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angelos.bimpoudis at oracle.com Tue Oct 24 22:49:18 2023 From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis) Date: Tue, 24 Oct 2023 22:49:18 +0000 Subject: Fw: JEP 455: Non-enhanced switch statements In-Reply-To: References: Message-ID: Hello all! Yuriy pointed out a valid point. 1) Should we treat float/double/boolean/longs as a new addition to the non-enhanced switch (old switch) and support anything new that comes with that? or 2) Should we treat those data types equally with all the pre-existing ones? I am strongly in favour of the 2) for the shake of symmetry and uniformity in what the user will assume, thus I will fix the bug. What do others think? ________________________________ From: Yuriy Maslyanko Sent: 24 October 2023 21:57 To: Angelos Bimpoudis Cc: compiler-dev at openjdk.org Subject: JEP 455: Non-enhanced switch statements Hi Angelos, Section 14.11.2 of https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html#jls-14.11.2 has this note: For compatibility reasons, switch statements that are not enhanced switch statements are not required to be exhaustive. Noticed that if the switch selector statement is float/double/boolean (in this case it?s a non-enhanced switch statement), the code shown below fails with ?error: the switch statement does not cover all possible input values?: static boolean check = false; public static boolean testMethod() { double v1 = 1d; switch ( v1 ) { case 1d: check = true; break; } return check; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Oct 25 08:50:22 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 25 Oct 2023 10:50:22 +0200 (CEST) Subject: JEP 455: Non-enhanced switch statements In-Reply-To: References: Message-ID: <1561586376.34535743.1698223822038.JavaMail.zimbra@univ-eiffel.fr> > From: "Angelos Bimpoudis" > To: "amber-spec-experts" > Cc: "Yuriy Maslyanko" > Sent: Wednesday, October 25, 2023 12:49:18 AM > Subject: Fw: JEP 455: Non-enhanced switch statements > Hello all! Hello Angelos, > Yuriy pointed out a valid point. > 1) Should we treat float/double/boolean/longs as a new addition to the > non-enhanced switch (old switch) and support anything new that comes with that? > or > 2) Should we treat those data types equally with all the pre-existing ones? > I am strongly in favour of the 2) for the shake of symmetry and uniformity in > what the user will assume, thus I will fix the bug. > What do others think? We have already discuss that, when we have introduce the switch on objects. The question is not what our current users will assume now but how the whole semantics of switch will be see let say 5 years from now, when people are used to use the switch on objects. The old switch is not a feature used a lot, we expected the new switch on objects to be used a lot more, so at some points, most of the switches will be switches on object so the semantics of the old switch will be the outlier. So the switch on float/double should behave like on objects, i.e. be hexaustive by default. It's the same reason why adding a "case null" or a "where" condition transforms the switch to the new semantics. And there is another reason to make the switch on float/double exhaustive, the matching of a cases on primitive types can be partial, when we discussed that feature this is was obvious for some of us (me included). By making the switch exhaustive, we actually help users to understand the actual semantics, because the compiler will requires a "default" if the pattern matching is not total. regards, R?mi > From: Yuriy Maslyanko > Sent: 24 October 2023 21:57 > To: Angelos Bimpoudis > Cc: compiler-dev at openjdk.org > Subject: JEP 455: Non-enhanced switch statements > Hi Angelos, > Section 14.11.2 of [ > https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html#jls-14.11.2 > | > https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html#jls-14.11.2 > ] has this note: > For compatibility reasons, switch statements that are not enhanced switch > statements are not required to be exhaustive. > Noticed that if the switch selector statement is float/double/boolean (in this > case it?s a non-enhanced switch statement), the code shown below fails with > ?error: the switch statement does not cover all possible input values?: > static boolean check = false; > public static boolean testMethod() { > double v1 = 1d; > switch ( v1 ) { > case 1d: > check = true; > break; > } > return check; > } -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Wed Oct 25 16:25:09 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 25 Oct 2023 12:25:09 -0400 Subject: JEP 455: Non-enhanced switch statements In-Reply-To: <1561586376.34535743.1698223822038.JavaMail.zimbra@univ-eiffel.fr> References: <1561586376.34535743.1698223822038.JavaMail.zimbra@univ-eiffel.fr> Message-ID: We have two not-great choices here: ?- Treat otherwise-boring switches on long/float/double/boolean (and their boxes) as legacy primitive switches, omitting the enhanced exhaustiveness checking; ?- Treat switching on float/double/boolean and their boxes as triggering the enhanced exhaustiveness checking. It is unfortunate that we have to have a carve-out for "old" switches, because this means an irregular and possibly-surprising boundary in the language, which users will have to learn (sometimes learning the hard way.)? But we do, and we accepted it as the cost of turbo-charging switch (new selector types, new case labels, better exhaustiveness, guards, null support, etc.)? Ideally we will have a path to gently guiding users away from the legacy behavior to the point where we are eventually comfortable promoting some warnings to errors, and this issue goes away, but that will surely take a long time, and I won't dwell on it here. In the meantime, we have a choice of "which of these two irregular boundaries do we want the user to reason about": ?- A statement switch is exempt from exhaustiveness checking if it does not use patterns, null cases, guards, or switch on anything other than {byte,char,short,int}, their boxes, enums, or strings, or ?- A statement switch is exempt from exhaustiveness checking if it does not use patterns, null cases, guards, or switch on anything other than a primitive, their boxes, enums, or strings. Remi makes the argument for the first path, on the basis of "let's freeze the legacy behavior to the legacy rules." This is a reasonable argument.? However, the opposite argument is also reasonable; that "typical user intuition" about "old switch" is closer to "primitives, boxes, enums, and strings", and that allowing the remaining primitive types to fit into the old model may minimize cognitive load on the user.? (It is easier to keep track of "primitives" than "the primitives that we thought were reasonable to switch over in 1995", since that set is kind of arbitrarily chosen.) So while I don't have an answer, I do think that both possible answers have merit :) On 10/25/2023 4:50 AM, Remi Forax wrote: > > > ------------------------------------------------------------------------ > > *From: *"Angelos Bimpoudis" > *To: *"amber-spec-experts" > *Cc: *"Yuriy Maslyanko" > *Sent: *Wednesday, October 25, 2023 12:49:18 AM > *Subject: *Fw: JEP 455: Non-enhanced switch statements > > Hello all! > > > Hello Angelos, > > > Yuriy pointed out a valid point. > > 1)?Should we treat float/double/boolean/longs as a new addition to > the non-enhanced switch (old switch) and support anything new that > comes with that? > > or > > 2) Should we treat those data types equally with all the > pre-existing ones? > > I am strongly in favour of the 2) for the shake of symmetry and > uniformity in what the user will assume, thus I will fix the bug. > > What do others think? > > > We have already discuss that, when we have introduce the switch on > objects. > The question is not what our current users will assume now but how the > whole semantics of switch will be see let say 5 years from now, when > people are used to use the switch on objects. > The old switch is not a feature used a lot, we expected the new switch > on objects to be used a lot more, so at some points, most of the > switches will be switches on object so the semantics of the old switch > will be the outlier. > So the switch on float/double should behave like on objects, i.e. be > hexaustive by default. > It's the same reason why adding a "case null" or a "where" condition > transforms the switch to the new semantics. > > And there is another reason to make the switch on float/double > exhaustive, the matching of a cases on primitive types can be partial, > when we discussed that feature this is was obvious for some of us (me > included). > By making the switch exhaustive, we actually help users to understand > the actual semantics, because the compiler will requires a "default" > if the pattern matching is not total. > > regards, > R?mi > > > ------------------------------------------------------------------------ > *From:* Yuriy Maslyanko > *Sent:* 24 October 2023 21:57 > *To:* Angelos Bimpoudis > *Cc:* compiler-dev at openjdk.org > *Subject:* JEP 455: Non-enhanced switch statements > > Hi Angelos, > > Section 14.11.2 of > https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html#jls-14.11.2 > > has this note: > > For compatibility reasons, |switch| statements that are not > enhanced |switch| statements are not required to be exhaustive. > > Noticed that if the switch selector statement is > float/double/boolean (in this case it?s a non-enhanced switch > statement), the code shown below fails with ?error: the switch > statement does not cover all possible input values?: > > ??? static boolean check = false; > > ??? public static boolean testMethod() { > > ??????? double v1 = 1d; > > ??????? switch ( v1 ) { > > ??????????? case 1d: > > ??????????????? check = true; > > ??????????????? break; > > ??????? } > > ??????? return check; > > ??? } > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Oct 27 13:56:26 2023 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 27 Oct 2023 14:56:26 +0100 Subject: Fw: JEP 455: Non-enhanced switch statements In-Reply-To: References: Message-ID: I think I agree. While coupling the notion of enhanced swith with that of exhaustiveness has been a good way to define some kind of line between old and new behavior, I think it might perhaps be wiser to enforce exhaustiveness on a more data-dependent way - e.g. what is the type we're switching on? If it's an enum, or a sealed class, I see some value in enforcing some kind of exhaustiveness analysis. But for strings and numbers, it is not clear to me that enforcing exhaustiveness at the statement level makes sense. Sure, if I define a class that interprets all the JVM bytecodes, I could always forget to handle one of them if my interpreter logic is a big int switch. But perhaps, in such cases, we would suggest a design where the opcodes are modelled using records implementing a single sealed interface, or some enum (thereby also getting exhaustiveness checks for free) ? Unfortunately enum is that one case where compatibility dictates that we can't be exhaustive, which is a little sad... but I think that's the best we can do? Maurizio On 24/10/2023 23:49, Angelos Bimpoudis wrote: > Hello all! > > Yuriy pointed out a valid point. > > 1)?Should we treat float/double/boolean/longs as a new addition to the > non-enhanced switch (old switch) and support anything new that comes > with that? > > or > > 2) Should we treat those data types equally with all the pre-existing > ones? > > I am strongly in favour of the 2) for the shake of symmetry and > uniformity in what the user will assume, thus I will fix the bug. > > What do others think? > > ------------------------------------------------------------------------ > *From:* Yuriy Maslyanko > *Sent:* 24 October 2023 21:57 > *To:* Angelos Bimpoudis > *Cc:* compiler-dev at openjdk.org > *Subject:* JEP 455: Non-enhanced switch statements > > Hi Angelos, > > Section 14.11.2 of > https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html#jls-14.11.2 > > has this note: > > For compatibility reasons, |switch| statements that are not enhanced > |switch| statements are not required to be exhaustive. > > Noticed that if the switch selector statement is float/double/boolean > (in this case it?s a non-enhanced switch statement), the code shown > below fails with ?error: the switch statement does not cover all > possible input values?: > > ??? static boolean check = false; > > ??? public static boolean testMethod() { > > ??????? double v1 = 1d; > > ??????? switch ( v1 ) { > > ??????????? case 1d: > > ??????????????? check = true; > > ??????????????? break; > > ??????? } > > ??????? return check; > > ??? } > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Fri Oct 27 14:28:01 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 27 Oct 2023 10:28:01 -0400 Subject: Fw: JEP 455: Non-enhanced switch statements In-Reply-To: References: Message-ID: <098aad6c-ed9e-ff81-00f9-e8508fff02ef@oracle.com> > > Unfortunately enum is that one case where compatibility dictates that > we can't be exhaustive, which is a little sad... but I think that's > the best we can do? > What we do for enums is do exhaustiveness checking based on the compile-time state of the world, and generate a synthetic default clause that deals with separately-compiled changes.? (Same with sealed types.)? This works pretty well, as it lets us type-check a (new) switch like ??? int wavelengthNm = switch (trafficLightColor) { ??????? case RED -> 700; ??????? case YELLOW -> 580; ??????? case GREEN -> 540; ??? } and not require a "silly" default, while offering runtime protection against novel colors showing up at runtime, and notifying the user at a subsequent compile if something unexpectedly changed. From maurizio.cimadamore at oracle.com Fri Oct 27 14:29:59 2023 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 27 Oct 2023 15:29:59 +0100 Subject: Fw: JEP 455: Non-enhanced switch statements In-Reply-To: <098aad6c-ed9e-ff81-00f9-e8508fff02ef@oracle.com> References: <098aad6c-ed9e-ff81-00f9-e8508fff02ef@oracle.com> Message-ID: Sure - but this logic is only applied to switch expression featuring enums AFAIK - switch statements with enums are non-exhaustive (and I think that will have to stay that way). Maurizio On 27/10/2023 15:28, Brian Goetz wrote: > >> >> Unfortunately enum is that one case where compatibility dictates that >> we can't be exhaustive, which is a little sad... but I think that's >> the best we can do? >> > > What we do for enums is do exhaustiveness checking based on the > compile-time state of the world, and generate a synthetic default > clause that deals with separately-compiled changes.? (Same with sealed > types.)? This works pretty well, as it lets us type-check a (new) > switch like > > ??? int wavelengthNm = switch (trafficLightColor) { > ??????? case RED -> 700; > ??????? case YELLOW -> 580; > ??????? case GREEN -> 540; > ??? } > > and not require a "silly" default, while offering runtime protection > against novel colors showing up at runtime, and notifying the user at > a subsequent compile if something unexpectedly changed. From brian.goetz at oracle.com Fri Oct 27 14:33:29 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 27 Oct 2023 10:33:29 -0400 Subject: Fw: JEP 455: Non-enhanced switch statements In-Reply-To: References: <098aad6c-ed9e-ff81-00f9-e8508fff02ef@oracle.com> Message-ID: > Sure - but this logic is only applied to switch expression featuring > enums AFAIK - switch statements with enums are non-exhaustive (and I > think that will have to stay that way). Slight correction: switch statements on enum selectors *that don't use patterns or guards or case null* are non-exhaustive.? IOW, the current carve-out for non-exhaustiveness is "if you don't use any of the new switch features." As to "will have to stay that way", I guess it depends on timeframe.? I can see a path of gradually increasing warnings ("totalize that switch with a default clause, dude") turning to error in a decade or so? From maurizio.cimadamore at oracle.com Fri Oct 27 14:37:25 2023 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 27 Oct 2023 15:37:25 +0100 Subject: Fw: JEP 455: Non-enhanced switch statements In-Reply-To: References: <098aad6c-ed9e-ff81-00f9-e8508fff02ef@oracle.com> Message-ID: No disagreement here. But I'd still point out that I'd rather see exhaustiveness being associated with the type being switched on, rather than on whether the switch body happens to use certain features or not. For sealed types we're lucky, because switching on them wasn't possible before - so if those get exhaustive, fine. But I'm not sure making a switch statement on e.g. an Object selector exhaustive simply because it's a "new form" is necessarily useful? I think exhaustiveness is the most useful when there's a fixed amount of things to check. Maurizio On 27/10/2023 15:33, Brian Goetz wrote: > >> Sure - but this logic is only applied to switch expression featuring >> enums AFAIK - switch statements with enums are non-exhaustive (and I >> think that will have to stay that way). > > Slight correction: switch statements on enum selectors *that don't use > patterns or guards or case null* are non-exhaustive.? IOW, the current > carve-out for non-exhaustiveness is "if you don't use any of the new > switch features." > > As to "will have to stay that way", I guess it depends on timeframe.? > I can see a path of gradually increasing warnings ("totalize that > switch with a default clause, dude") turning to error in a decade or so? From angelos.bimpoudis at oracle.com Sun Oct 29 19:01:53 2023 From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis) Date: Sun, 29 Oct 2023 19:01:53 +0000 Subject: Fw: JEP 455: Non-enhanced switch statements In-Reply-To: References: <098aad6c-ed9e-ff81-00f9-e8508fff02ef@oracle.com> Message-ID: I am now a bit more convinced that freezing the old handling at the old spec is a clean approach. The new data types confirm the presence of an enhanced switch. So, the behaviour of the patch was a feature in the end (I will adjust the spec of course--the place that Yuriy pointed us to). Supporting the new types to the old-style switch with new-style semantics opens questions about equality (would need to be the same between the old and the new), about a new translation for a not-enhanced switch but supporting the new types with old style semantics. It would be also necessary to avoid the translation with MatchException? which is a feature of the enhanced switch. We see that there are a lot of consequences for an enhancement that, as Remi says, belongs to the new pattern matching mechanism and not to the old-style switch. This also confirms that old-handling+old spec should not be altered indeed. ________________________________ From: amber-spec-experts on behalf of Maurizio Cimadamore Sent: 27 October 2023 16:37 To: Brian Goetz ; amber-spec-experts at openjdk.org Subject: Re: Fw: JEP 455: Non-enhanced switch statements No disagreement here. But I'd still point out that I'd rather see exhaustiveness being associated with the type being switched on, rather than on whether the switch body happens to use certain features or not. For sealed types we're lucky, because switching on them wasn't possible before - so if those get exhaustive, fine. But I'm not sure making a switch statement on e.g. an Object selector exhaustive simply because it's a "new form" is necessarily useful? I think exhaustiveness is the most useful when there's a fixed amount of things to check. Maurizio On 27/10/2023 15:33, Brian Goetz wrote: > >> Sure - but this logic is only applied to switch expression featuring >> enums AFAIK - switch statements with enums are non-exhaustive (and I >> think that will have to stay that way). > > Slight correction: switch statements on enum selectors *that don't use > patterns or guards or case null* are non-exhaustive. IOW, the current > carve-out for non-exhaustiveness is "if you don't use any of the new > switch features." > > As to "will have to stay that way", I guess it depends on timeframe. > I can see a path of gradually increasing warnings ("totalize that > switch with a default clause, dude") turning to error in a decade or so? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sun Oct 29 19:39:05 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 29 Oct 2023 15:39:05 -0400 Subject: Fw: JEP 455: Non-enhanced switch statements In-Reply-To: References: <098aad6c-ed9e-ff81-00f9-e8508fff02ef@oracle.com> Message-ID: At the same time, we should consider a lint warning for non-exhaustive old-style switches, which a recommendation to make them exhaustive with `default:` or `default -> {}`, depending on the switch style. On 10/29/2023 3:01 PM, Angelos Bimpoudis wrote: > I am now a bit more convinced that freezing the old handling at the > old spec is a clean approach. The new data types confirm the presence > of an enhanced switch. So, the behaviour of the patch was a feature in > the end (I will adjust the spec of course--the place that Yuriy > pointed us to). > > Supporting the new types to the old-style switch with new-style > semantics opens questions about equality (would need to be the same > between the old and the new), about a new translation for a > not-enhanced switch but supporting the new types with old style > semantics. It would be also necessary to avoid the translation with > |MatchException|? which is a feature of the enhanced switch. > > We see that there are a lot of consequences for an enhancement that, > as Remi says, belongs to the new pattern matching mechanism and not to > the old-style switch. This also confirms that old-handling+old spec > should not be altered indeed. > ------------------------------------------------------------------------ > *From:* amber-spec-experts on > behalf of Maurizio Cimadamore > *Sent:* 27 October 2023 16:37 > *To:* Brian Goetz ; > amber-spec-experts at openjdk.org > *Subject:* Re: Fw: JEP 455: Non-enhanced switch statements > No disagreement here. But I'd still point out that I'd rather see > exhaustiveness being associated with the type being switched on, rather > than on whether the switch body happens to use certain features or not. > > For sealed types we're lucky, because switching on them wasn't possible > before - so if those get exhaustive, fine. > > But I'm not sure making a switch statement on e.g. an Object selector > exhaustive simply because it's a "new form" is necessarily useful? I > think exhaustiveness is the most useful when there's a fixed amount of > things to check. > > Maurizio > > On 27/10/2023 15:33, Brian Goetz wrote: > > > >> Sure - but this logic is only applied to switch expression featuring > >> enums AFAIK - switch statements with enums are non-exhaustive (and I > >> think that will have to stay that way). > > > > Slight correction: switch statements on enum selectors *that don't use > > patterns or guards or case null* are non-exhaustive. IOW, the current > > carve-out for non-exhaustiveness is "if you don't use any of the new > > switch features." > > > > As to "will have to stay that way", I guess it depends on timeframe. > > I can see a path of gradually increasing warnings ("totalize that > > switch with a default clause, dude") turning to error in a decade or so? -------------- next part -------------- An HTML attachment was scrubbed... URL: