Support for primitive types in instanceof and type patterns

[Dan Heidinga]

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.

The JEP says:
> Once instanceof becomes meaningful for primitive types, this provides an
obvious interpretation
> for primitive type patterns (and reference type patterns as applied to a
primitive target):
> "could I cast the match target to the type in this pattern without error
or loss of precision?"

This makes sense for most of the primitives we like to think about (int,
byte, char, short, long) but may be more complicated for doubles and
floats. Conversions to & from float/double are hard to validate that there
will be no loss of precision.  if we require exact conversions for them,
we'll find that they can only be applied in very narrow cases.  Is that the
intention or do we need a more flexible notion of "without error or loss of
precision" doubles and floats?

For example, "JLS 5.1.2 Widening Primitive Conversion" which is one of the
valid conversions in a casting context indicates that:
      "A widening primitive conversion from int to float, or from long to
float, or from long to
       double, may result in loss of precision, that is, the result may
lose some of the least
       significant bits of the value."

It would be good to expand on what the expected behaviour for floats /
doubles when used with instanceof.

This shouldn't take away from the overall direction of the JEP which I
think is the right approach - it's just a corner case we need to clarify.

--Dan


On Mon, Nov 14, 2022 at 6:21 PM Angelos Bimpoudis <
angelos.bimpoudis at oracle.com> wrote:

> Dear experts,
>
> The draft JEP for adding support for primitive types in instanceof​ and
> type patterns, that has been previously discussed on this list, is
> available at:
>
> https://bugs.openjdk.org/browse/JDK-8288476
>
> Suggestions are welcomed!
> Angelos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20221115/338f6fdd/attachment.htm>