<div dir="auto"><div>But reference type casts are fundamentally different from primitive number type casts.<div dir="auto">When we cast rather with instanceof or just an plain old cast we don't alter memory at all. We simply get a reference to the previous memory location with a more specific type. Primitives are copied when casted (at least as far as I know). Sure the cost of copying a primitive is equal or smaller than creating a reference but the concept is a different one.</div><div dir="auto">byte is not a subtype of int. </div><div dir="auto">It's more like (not valid syntax):</div><div dir="auto">int i = new int(5);</div><div dir="auto">byte b = new byte(i);</div><div dir="auto">They are not related in their types besides the (valid) simple conversions the compiler can do. It's like we would allow:</div><div dir="auto">StringBuilder b = (StringBuilder) "original";</div>Because there is an available conversion between them. Actually some languages like C# do that. But I don't think Java should go that route. </div><div dir="auto"><br></div><div dir="auto">Great regards </div><div dir="auto">RedIODev <br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, Jan 27, 2023, 13:29 Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Because, at least the way I read it — and perhaps the motivation needs to be clarified — the point is not so much how to just solve the problem of primitive ranges, but how to best understand patterns. Patterns are a language feature; widening and narrowing conversions for both references and primitives — with or without explicit casts — are also a language feature. <br>
<br>
The interesting insight in the proposal is about how the patterns language feature interacts with the narrowing conversion language feature. It points out that patterns makes narrowing reference conversion (JLS §5.1.6), aka “downcasts”, safe for reference types, and so it’s a reasonable generalisation to have patterns also make narrowing primitive conversions (JLS §5.1.3) safe as well. If patterns are a “narrowing conversion safeifier” language feature, they should work with all of the language’s narrowing conversions.<br>
<br>
— Ron<br>
<br>
> On 27 Jan 2023, at 11:21, Red IO <<a href="mailto:redio.development@gmail.com" target="_blank" rel="noreferrer">redio.development@gmail.com</a>> wrote:<br>
> <br>
> 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:<br>
> Byte.isInBounds(56L)<br>
> And <br>
> byte b = Byte.castOrThrow(56L);<br>
> Or<br>
> Optional<Byte> b = Byte.cast(56L);<br>
> Of cause the latter one would be quite inefficient in the current (pre Valhalla) world. <br>
> <br>
> 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..) <br>
> <br>
> Great regards <br>
> RedIODev <br>
<br>
</blockquote></div></div></div>