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

[Brian Goetz]

Floating point is tricky!

On 1/26/2023 5:25 PM, forax at univ-mlv.fr wrote:
> Ahhh,
> so i'm the one to blame, here.
>
> For whatever reason, i get the representational equivalence wrong.
>
> Thanks for the explanation Joe, i stand corrected.
>
> Rémi
>
> ------------------------------------------------------------------------
>
>     *From: *"joe darcy" <joe.darcy at oracle.com>
>     *To: *"Remi Forax" <forax at univ-mlv.fr>, "Angelos Bimpoudis"
>     <angelos.bimpoudis at oracle.com>
>     *Cc: *"amber-dev" <amber-dev at openjdk.org>
>     *Sent: *Thursday, January 26, 2023 11:04:20 PM
>     *Subject: *Re: Draft JEP on Primitive types in patterns,
>     instanceof, and switch
>
>     Switching on floating-point values is perfectly well-defined.
>     Despite common presentation to the contrary, floating-point
>     numbers are not "fuzzy," they are a precisely-defined subset of
>     real numbers, with some notable special cases.
>
>
>     As mentioned in the draft JEP, the matching for floating-point
>     values should use representational equivalence, quoting from
>     java.lang.Double:
>
>
>         The two floating-point values represent the same IEEE 754
>         /datum/. In particular, for finite
>         <https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/Double.html#isFinite(double)>
>         values, the sign, exponent
>         <https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/Math.html#getExponent(double)>,
>         and significand components of the floating-point values are
>         the same. Under this relation:
>
>           * |+0.0| and |-0.0| are distinguished from each other.
>           * every bit pattern encoding a NaN is considered equivalent
>             to each other
>           * positive infinity is equivalent to positive infinity;
>             negative infinity is equivalent to negative infinity.
>
>         Expressions implementing this equivalence relation include:
>
>           * |Double.doubleToLongBits(a) == Double.doubleToLongBits(b)|
>           * |Double.valueOf(a).equals(Double.valueOf(b))|
>           * |Double.compare(a, b) == 0|
>
>         Note that representation equivalence is often an appropriate
>         notion of equivalence to test the behavior of math libraries
>         <https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/StrictMath.html>.
>
>
>
>     So, under this approach you could have
>
>
>     switch(d) {
>
>         case -0.0 -> ...
>         case +0.0 -> ...
>         case NaN -> ... // Handles all NaNs
>       ...
>
>     }
>
>
>     Operationally, this could be desugared to switching over a long by
>     first mapping the double to long via doubleToLongBits (and *not*
>     raw-long-bits).
>
>
>     HTH,
>
>
>     -Joe
>
>
>     On 1/26/2023 5:15 AM, Remi Forax wrote:
>
>
>
>         ------------------------------------------------------------------------
>
>             *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
>
>             "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://github.com/rust-lang/rust/issues/41255
>
>         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-dev/attachments/20230126/1c690550/attachment.htm>