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

forax at univ-mlv.fr forax at univ-mlv.fr
Thu Jan 26 22:25:52 UTC 2023


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 [
>> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/Double.html#isFinite(double)
>> | finite ] values, the sign, [
>> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/Math.html#getExponent(double)
>> | exponent ] , 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 [
>> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/StrictMath.html
>> | math libraries ] .
> 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" [ mailto:angelos.bimpoudis at oracle.com |
>>> <angelos.bimpoudis at oracle.com> ]
>>> To: "amber-dev" [ mailto:amber-dev at openjdk.org | <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://github.com/rust-lang/rust/issues/41255 |
>> 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/61d49bd7/attachment.htm>


More information about the amber-dev mailing list