<div dir="auto">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:<div dir="auto">Byte.isInBounds(56L)</div><div dir="auto">And </div><div dir="auto">byte b = Byte.castOrThrow(56L);</div><div dir="auto">Or</div><div dir="auto">Optional<Byte> b = Byte.cast(56L);</div><div dir="auto">Of cause the latter one would be quite inefficient in the current (pre Valhalla) world. </div><div dir="auto"><br></div><div dir="auto">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..) </div><div dir="auto"><br></div><div dir="auto">Great regards </div><div dir="auto">RedIODev </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 27, 2023, 12:06 Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- Original Message -----<br>
> From: "Ron Pressler" <<a href="mailto:ron.pressler@oracle.com" target="_blank" rel="noreferrer">ron.pressler@oracle.com</a>><br>
> To: "Stephen Colebourne" <<a href="mailto:scolebourne@joda.org" target="_blank" rel="noreferrer">scolebourne@joda.org</a>><br>
> Cc: "amber-dev" <<a href="mailto:amber-dev@openjdk.org" target="_blank" rel="noreferrer">amber-dev@openjdk.org</a>><br>
> Sent: Friday, January 27, 2023 9:59:36 AM<br>
> Subject: Re: Draft JEP on Primitive types in patterns, instanceof, and switch<br>
<br>
>> On 26 Jan 2023, at 22:01, Stephen Colebourne <<a href="mailto:scolebourne@joda.org" target="_blank" rel="noreferrer">scolebourne@joda.org</a>> wrote:<br>
>> <br>
>>  In this context, `42` is *not* an `int` at all - it is a literal. There is no<br>
>>  conversion here,<br>
>> `42` is typed as a `byte` because of the assignment. `42` is never, at<br>
>> any stage, an `int`.<br>
> <br>
> <br>
> See JLS §3.10.1 and §5.2.<br>
> <br>
> <br>
>> There is simply no comparison here. Dog and Animal are subtypes of<br>
>> Pet, a concept that has been baked into the language since day one,<br>
>> and is fully understood by all. By contrast, there is absolutely no<br>
>> subtyping relationship between int, byte and short<br>
> <br>
> <br>
> Whether or not there’s any comparison here is debatable, but until, like,<br>
> five minutes ago switch couldn’t switch on types, and now that switch *must*<br>
> switch on type relationships is an eternal cornerstone of Java?<br>
> <br>
> Also, you may want to look at JLS §4.10.1.<br>
> <br>
> <br>
>> saying that the language should now examine not only the type but also<br>
>> the value of the instance in order to determine flow control.<br>
> <br>
> <br>
> I believe switch has examined values to determine control flow for quite some<br>
> time now.<br>
> <br>
> <br>
>> The root cause of the issue here is trying to treat Object hierarchy<br>
>> conversion and conversion between different primitive types as being<br>
>> somehow equivalent.<br>
> <br>
> <br>
> Not equivalent. Rather, the JEP generalises patterns into a concept that<br>
> encompasses<br>
> both. It reinterprets what patterns are about: "Despite having been restricted<br>
> to<br>
> reference types, instanceof is in principle about asking whether an upcoming<br>
> cast of a<br>
> value to a type would succeed without loss of information or error.”<br>
> <br>
> Given that patterns, as a new general concept, are all about reinterpreting old<br>
> concepts<br>
> and extrapolating from them, pointing out that other extrapolations are possible<br>
> is not<br>
> exactly calling out the emperor’s new clothes.<br>
<br>
The problem with extrapoling/re-interpreting is where to stop, where to draw the line.<br>
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. <br>
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.<br>
<br>
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.<br>
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).<br>
<br>
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.<br>
<br>
> <br>
> — Ron<br>
> <br>
> P.S.<br>
> <br>
> The tone of your email was a jot hysterical, which did not aid comprehension and<br>
> was implacably annoying.<br>
<br>
Stephen is like a lot of us, invested in Java.<br>
<br>
> Maybe tone it down next time<br>
<br>
Rémi<br>
</blockquote></div>