Comment author: @gasche

To understand the issue better I looked at how int32 is represented now in the compiler and runtime. It is a custom type, which means that polymorphic comparison/serialization function lookup the type-specific implementation. The compiler knows about a family of %int32_foo primitives for these types and replaces them by direct call to the underlying functions.

I think if we wanted good support for unsigned integers in the language adding abstract uint{32,64} types would be a good solution -- implemented as custom types with their own comparison/serialization, and their own compiler primitives.

Comment author: @hcarty

That's fine too. There was a mailing list post that I can't find now which lead me to believe that separate unsigned types/modules wouldn't be welcome. If we can have fully separate types then that should make them simpler for users to find and understand too.

Comment author: @alainfrisch

It seems really bad to mix signed and unsigned ints of the same size in a single type. I'm not aware of any high-level language that does that.

So unsigned ints would be new built-in types; they need to be built-in because the optimizer needs to know about them, at least to support local unboxing and constant folding. We'd also need to provide operations such as "/" and "mod", and I guess this would impact the runtime system (primitives) and/or the various backends. So this is really not a "pure stdlib" proposal.

How common is the need for unboxed int types? Can you provide some typical usage scenarios?

as they are not easy to add externally:

Can you elaborate on that part? I guess that in both cases (stdlib or external), there would be a need for new C primitives.

Comment author: @hcarty

Here is the post: http://caml.inria.fr/pub/ml-archives/caml-list/2004/07/f1c483068cc62075c916f7ad7d640ce0.fr.html, and a related Stack Overflow response: http://stackoverflow.com/a/12181662 - those are why the initial request is/was for additional operations on the existing types.

If separate types and operations are an option then, again, that seems like a better solution.

As far as external libraries, the biggest issues are optimization (can a user-defined integer type ever be as efficient as one that is built in?) and bigarray support. I've run into both, primarily when working with serialization formats which assume the presence of unsigned integers.

Comment author: @paurkedal

I think int63 and uint63 types would also be useful, considering that they are unboxed on 64 bit targets, while int on 32 bit targets may be too small for some applications.

Comment author: @yallop

There's a pull request with an implementation of unsigned 32-bit and 64-bit integers here:

#1201

Unsigned operation on Int32, Int64 and nativeint where added by @nojb in #1458 and will be available starting from 4.08.

I think we can close this.