On Thu, 2 Apr 2026 at 18:24, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thursday, 2 April 2026 01:32:56 Pacific Daylight Time Jan Schultke via
> Std-
> Proposals wrote:
> > - Separate the sign bit from the rest of the representation. This
> makes
> > negation and absolutes incredibly cheap, regardless of the dynamic
> size
> > of the integer. It also makes it cheap to query whether the integer is
> > negative.
>
> I'm curious why you'd want a sign-magnitude implementation. It seems to me
> that adding numbers is a far more common operation than negating them.
> Subtractions don't need to be implemented as negation plus addition.
>

To my knowledge, most implementations use such a representation. Not
separating the sign bit comes with a lot of problems:

   - Checking if a number is negative requires indirection. This check is a
   really common operation.
   - Negation and taking absolutes is O(n) instead of O(1).
   - You have to rethink signed 64-bit integers for the small case. uint64
   and a sign bit lets you represent any signed or unsigned 64-bit integer in
   an obvious way, and you should be able to store any standard integer
   without allocations.



> I also don't see how that implies querying the sign wouldn't be cheap.
> It's
> always O(1) anyway. If the worry is that of dereferencing the pointer to
> non-
> short object, you can always do double book-keeping of the sign bit.
>

You could, but if you're storing the sign bit in the container anyway, I
don't see what you could hope to get out of baking the sign into the limbs
as well. I'm not aware of any implementation that does such double
book-keeping.