Unsigned Integers (was: Support for 64-bit pointers)

[Johannes Kuhn]

Custom primitive types are just half of the story - even if you can 
define your own ubyte, existing APIs probably won't accept your ubyte[].

The problem is converting your ubyte[] to byte[] - and if the object 
header of the array says "I'm an array of ubyte", then you can't simply 
change that.

So, while Valhalla may indeed bring cheap custom types - switching to a 
custom type would break compatibility with existing APIs.
And changing the type of all elements in an array is not so easy with 
Java - who reifies the array type in the object header.

Haskell gets away with its coerce - because it erases all type 
information at runtime. And that's why you can't cast or do some kind of 
instanceof in Haskell. Different tradeoff.

On 01-Jan-21 21:52, Mark Raynsford wrote:
> On 2021-01-01T21:23:09 +0100
> Johannes Kuhn <info at j-kuhn.de> wrote:
> 
>> To chime in - there is already limited support for unsigned int /
>> unsigned long.
> 
> The issue here is the lack of primitive classes, and those are being
> worked on in Valhalla. We can define all of the operations required to
> make a class behave almost identically to an unsigned integer today -
> as long as we're willing to live with the values of that class having
> the same performance characteristics as the primitive wrappers
> (Integer, Double, etc).
> 
> I have no doubt whatsoever that Java will sprout all kinds of new
> numeric types (unsigned, complex, etc) when Valhalla is ready, but it's
> not ready yet. Unsigned types won't happen as part of Panama.
> 

Yes, unsigned fist-class types won't happen as part of Panama.

As I wrote, I see this more as language feature - so "__unsigned byte[]" 
and "byte[]" are interchangeable - otherwise it would either be useless 
or make existing APIs incompatible.

- Johannes