design spec: Are integers in zig guaranteed to have two's complement binary representation?

[andrewrk]

Thanks to this reddit post for the question.

On one hand, it may be nice to define integers to work this way, since this is probably how it will work on every machine. It would certainly be the least surprising. On the other hand, in the spirit of "communicate intent precisely", it isn't that hard to use appropriate functions for "serializing" integers as twos complement. This puts fewer limitations on the optimizer, and potentially could let us do some interesting safety features, with unused bits.

Note that currently according to the language reference, floats are guaranteed to have IEEE binary representation. The resolution to this issue probably applies to floats as well.

The language specification (#75) depends on this issue.

Note: status quo: integers are always stored in twos complement binary representation.

[AronParker]

I'd just like to add (I'm the guy who asked on reddit) that there is a C++ proposal to make integers two's complement which will probable be implemented in C++20.

In addition, even the C standards committee was in favour of it for its language.

So in the light of this, if even C and C++ plan to change their design (and they've always supported a wide range of architectures even exotic ones), I think it would be a great idea for zig.

[SpexGuy]

The reasoning here is similar to our choice to have explicitly sized integers instead of platform-dependent bit widths. Zig chooses correctness over performance here. This decision means that code that uses bitwise operators or @clz/@ctz is portable. It is also consistent with the decision on floats, to standardize IEEE754 behavor. This decision does not preclude a language extension or library adding ones complement or other integer or floating point types, but the uXX and iXX types are guaranteed to have twos complement representation.