Support for primitive types in instanceof and type patterns

[Dan Heidinga]

It's good to hear that you and others are thinking through the details on
how float/doubles will work.

I still have some concern with user-intuition when writing pattern matching
code over floating point values if users base their intuition on their
experience with widening casts to float.  There's a great sample program
(JLS Example 5.1.2-1) which shows the loss of precision when casting a
large int to a float which I would try to express with pattern matching
roughly as:

record FloatBox(float f) {}
int big = 1234567890;
FloatBox box = new FloatBox(big);
if (box instanceof FloatBox(int i)) {
   // pattern won't match here
}

I think users would be surprised reading the code that the pattern doesn't
match because converting back to an int would lose precession.

The equivalent non-pattern code would be pretty clear that it accepted the
loss of precession:

if (box instanceof FLoatBox) {
  int i = (int)box.f();
  ....
}

Users will find it confusing when the pattern seems to match "sometimes"
though this is likely due to existing confusion related to floating types.
Maybe expanding on the expected implementation will make it easier to build
a mental model for when the match will succeed?

--Dan


On Tue, Nov 15, 2022 at 6:13 PM Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

> On 11/15/2022 12:13 PM, Brian Goetz wrote:
> >
> >
> > On 11/15/2022 2:55 PM, Dan Heidinga wrote:
> >> Hi Angelos,
> >>
> >> The overall direction and writeup for this looks good to me.  I think
> >> we need to be more specific about how doubles & floats fit into this
> >> though as they are perpetual source of special cases.
> >
> > Indeed, floating point is the gift that keeps on giving.
> >
> > Joe recently did some nice work in the spec of Float and Double,
> > outlining the various different ways in which floats can be compared.
> > This allows language features like pattern matching, casting, and
> > switch to appeal to "compared by FooBar comparison", rather than
> > spelling it out for each use.
> >
> >
> FYI, the new text in question is:
>
>
> https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/lang/Double.html#fpNumericalEq
>
> For the cases in the draft JEP, there have been separate discussions
> working through the details. Putting aside how it might be implemented,
> for the
>
>     floating-point type -> integral type
>
> cases, conceptually if the same real number can be presented in the
> floating-point type and the integral type, then the conversion is exact.
> (While floating-point values are often thought of as "fuzzy," each
> finite floating-point value represents some particular real number.
> Finite binary floating-point values are sums of the powers of 2 where
> the exponent difference of the powers is bounded by the significand
> width of the floating-point format in question.) The main special case
> is how conversion of -0.0 to an integral type is defined for purposes of
> instanceof. The desired double -> float behavior can be inferred from
> IEEE 754 concepts.
>
> HTH,
>
> -Joe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20221116/710bbd87/attachment.htm>