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

[Joseph D. Darcy]

+1.0000000000000001


-Joe


On 1/26/2023 3:50 PM, Brian Goetz wrote:
> 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/89c720a6/attachment.htm>