Draft JEP on Primitive types in patterns, instanceof, and switch

[forax at univ-mlv.fr]

> From: "Angelos Bimpoudis" <angelos.bimpoudis at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.org>
> Sent: Thursday, January 26, 2023 2:55:31 PM
> Subject: Re: Draft JEP on Primitive types in patterns, instanceof, and switch

> Thanks for the quick reply.

> I think there is one important factor here. By quickly inspecting the issues in
> the links, IIUC, the semantics of floating-point constants there follow the
> semantics of == ​. So -0 and 0 compare equal there (e.g., [
> https://github.com/rust-lang/rust/issues/41620#issuecomment-300587182 |
> https://github.com/rust-lang/rust/issues/41620#issuecomment-300587182 ] ).

> The JEP follows the road of "representation equivalence" as described in [
> https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Double.html#fpNumericalEq
> |
> https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Double.html#fpNumericalEq
> ]

In terms of semantics Double::equals may be better than double == double, this seems to be the direction that Java is choosing (Valhhalla also used Double::equals for value types containing a double). 

But it means that introducing a "when" is not a valid refactoring 
case double 3.14 -> ... 
can not be refactored to 
case double x when x == 3.14 -> ... 

Most of my students thinks in terms of equivalence, breaking this kind of refactoring make the proposed semantics not intuitive. 

That's why i think it's better to not allow double/float constants, so people have to be explicit about the semantics they want. 

regards, 
Rémi 

> From: Remi Forax <forax at univ-mlv.fr>
> Sent: 26 January 2023 14:16
> To: Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
> Cc: amber-spec-experts <amber-spec-experts at openjdk.org>
> Subject: [External] : Re: Draft JEP on Primitive types in patterns, instanceof,
> and switch
> > From: "Angelos Bimpoudis" <angelos.bimpoudis at oracle.com>
> > To: "amber-dev" <amber-dev at openjdk.org>
> > Sent: Thursday, January 26, 2023 10:48:47 AM
> > Subject: Draft JEP on Primitive types in patterns, instanceof, and switch

> > Hello all,

> > I would like to share this draft JEP with you about primitive types in patterns,
> > instanceof, and switch:

> > [ https://openjdk.org/jeps/8288476 | https://openjdk.org/jeps/8288476 ]

> > "Enhance pattern matching by allowing primitive types to appear anywhere in
> > patterns. Extend instanceof to support primitive types, and extend switch to
> > allow primitive constants as case labels."

> > Comments very much welcomed!

> > Many thanks,
> > Angelos

> I still think that the semantics proposed for pattern matching on primitive
> types is useless complexity with the perverse side effect of normalizing the
> usage of "default" in pattern matching (too many examples of this JEP are using
> "default") but we already discussed that.

> Allowing switching on double and float constants is just wrong.
> Rust is actually trying to remove that feature
> [ [
> https://urldefense.com/v3/__https://github.com/rust-lang/rust/issues/41255__;!!ACWV5N9M2RV99hQ!NfJ7KspB447oMGi0NoEyXC6s_w3vD1N-SBu5hiD4kMVAkmwDWPNbymH83iOnrkakPoayD6vwGwuB5NvedJfjH9LU$
> |
> https://urldefense.com/v3/__https://github.com/rust-lang/rust/issues/41255__;!!ACWV5N9M2RV99hQ!NfJ7KspB447oMGi0NoEyXC6s_w3vD1N-SBu5hiD4kMVAkmwDWPNbymH83iOnrkakPoayD6vwGwuB5NvedJfjH9LU$
> ] | [
> https://urldefense.com/v3/__https://github.com/rust-lang/rust/issues/41255__;!!ACWV5N9M2RV99hQ!NfJ7KspB447oMGi0NoEyXC6s_w3vD1N-SBu5hiD4kMVAkmwDWPNbymH83iOnrkakPoayD6vwGwuB5NvedJfjH9LU$
> |
> https://urldefense.com/v3/__https://github.com/rust-lang/rust/issues/41255__;!!ACWV5N9M2RV99hQ!NfJ7KspB447oMGi0NoEyXC6s_w3vD1N-SBu5hiD4kMVAkmwDWPNbymH83iOnrkakPoayD6vwGwuB5NvedJfjH9LU$
> ] ]

> I see no point to make the same mistake.

> Otherwise, the rest is fine.

> Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230126/fb3c46e6/attachment-0001.htm>