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).
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 ________________________________ From: Remi Forax <[email protected]> Sent: 26 January 2023 14:16 To: Angelos Bimpoudis <[email protected]> Cc: amber-spec-experts <[email protected]> Subject: [External] : Re: Draft JEP on Primitive types in patterns, instanceof, and switch > From: "Angelos Bimpoudis" <[email protected]> > To: "amber-dev" <[email protected]> > 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 > "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$ ] I see no point to make the same mistake. Otherwise, the rest is fine. Rémi
