On Monday, 12 February 2024 at 19:56:09 UTC, H. S. Teoh wrote:
But regardless, IMNSHO any programmer worth his wages ought to learn what an unsigned type is and how it works. A person should not be writing code if he can't even be bothered to learn how the machine that's he's programming actually works.
I'd like to note that even C++20 onwards has `.ssize`, which is signed size.
I do use lengths in arithmetic sometimes, and that leads to silent bugs currently. On the other hand, since going from 16 bits to 32 and then 64, in my user-side programs, I had a flat zero bugs because some length was 2^{31} or greater -- but at the same time not 2^{32} or greater. So, in D, I usually `to!int` or `to!long` them anyway. Or cast in performance-critical places.
Another perspective. Imagine a different perfect world, where programmers just had 64-bit integers and 64-bit address space, everywhere, from the start. A clean slate, engineers and programmers designing their first hardware and languages, but with such sizes already feasible. Kinda weird, but bear with me a bit. Now, imagine someone proposing to make sizes unsigned. Wouldn't that be a strange thing to do? The benefit of having a universal arithmetic type for everything, from the ground up -- instead of two competing types producing bugs at glue points -- seems to far outweigh any potential gains. Unsigned integers could have their small place, too, for bit masks and microoptimizations and whatnot, but why sizes? The few applications that really benefit from sizes of [2^{63}..2^{64}) would be the most odd ones, deserving some workarounds.
Right now though, we just have to deal with the legacy, in software, hardware, and mind -- and with the fact that quite some environments are not 64-bit.
Ivan Kazmenko.
