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

[Red IO]

I don't see why we need a language change here. Why not add safecast
methods and is in bounds methods in the primitive wrapper classes. Like:
Byte.isInBounds(56L)
And
byte b = Byte.castOrThrow(56L);
Or
Optional<Byte> b = Byte.cast(56L);
Of cause the latter one would be quite inefficient in the current (pre
Valhalla) world.

I don't see many cases where someone might switch on a primitive and have
many cases like in the examples (float to int, long, byte..)

Great regards
RedIODev

On Fri, Jan 27, 2023, 12:06 Remi Forax <forax at univ-mlv.fr> wrote:

> ----- Original Message -----
> > From: "Ron Pressler" <ron.pressler at oracle.com>
> > To: "Stephen Colebourne" <scolebourne at joda.org>
> > Cc: "amber-dev" <amber-dev at openjdk.org>
> > Sent: Friday, January 27, 2023 9:59:36 AM
> > Subject: Re: Draft JEP on Primitive types in patterns, instanceof, and
> switch
>
> >> On 26 Jan 2023, at 22:01, Stephen Colebourne <scolebourne at joda.org>
> wrote:
> >>
> >>  In this context, `42` is *not* an `int` at all - it is a literal.
> There is no
> >>  conversion here,
> >> `42` is typed as a `byte` because of the assignment. `42` is never, at
> >> any stage, an `int`.
> >
> >
> > See JLS §3.10.1 and §5.2.
> >
> >
> >> There is simply no comparison here. Dog and Animal are subtypes of
> >> Pet, a concept that has been baked into the language since day one,
> >> and is fully understood by all. By contrast, there is absolutely no
> >> subtyping relationship between int, byte and short
> >
> >
> > Whether or not there’s any comparison here is debatable, but until, like,
> > five minutes ago switch couldn’t switch on types, and now that switch
> *must*
> > switch on type relationships is an eternal cornerstone of Java?
> >
> > Also, you may want to look at JLS §4.10.1.
> >
> >
> >> saying that the language should now examine not only the type but also
> >> the value of the instance in order to determine flow control.
> >
> >
> > I believe switch has examined values to determine control flow for quite
> some
> > time now.
> >
> >
> >> The root cause of the issue here is trying to treat Object hierarchy
> >> conversion and conversion between different primitive types as being
> >> somehow equivalent.
> >
> >
> > Not equivalent. Rather, the JEP generalises patterns into a concept that
> > encompasses
> > both. It reinterprets what patterns are about: "Despite having been
> restricted
> > to
> > reference types, instanceof is in principle about asking whether an
> upcoming
> > cast of a
> > value to a type would succeed without loss of information or error.”
> >
> > Given that patterns, as a new general concept, are all about
> reinterpreting old
> > concepts
> > and extrapolating from them, pointing out that other extrapolations are
> possible
> > is not
> > exactly calling out the emperor’s new clothes.
>
> The problem with extrapoling/re-interpreting is where to stop, where to
> draw the line.
> Most languages that have C as ancestor have tried to separate the
> different casts into different categories, considering using the same
> syntax for different kind of casts as a mistake.
> Re-interpreting "instanceof" as a question if any casts will succeed and
> not just reference casts is a huge leap of faith that feels backward.
>
> Generations of Java developers have a pretty good grasp of the difference
> between subtyping and primitive conversions, this proposal acts as a
> wrecking ball and shatter that.
> By example, you can not override a method that returns a double with a
> method that returns an int because overriding is about subtyping
> relationship, not conversion (for the history, Neal Gafter had implemented
> method overriding that allow primitive conversions in javac in one of the
> early versions of Java 1.5 but to it was decided to not go that path).
>
> I agree that revisiting concepts is something we have to do, but breaking
> the difference between subtyping and primitive conversions for a corner
> case, in isolation, is a decision hard to understand.
>
> >
> > — Ron
> >
> > P.S.
> >
> > The tone of your email was a jot hysterical, which did not aid
> comprehension and
> > was implacably annoying.
>
> Stephen is like a lot of us, invested in Java.
>
> > Maybe tone it down next time
>
> Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230127/0d1d7ea3/attachment.htm>