length's type.

[Ivan Kazmenko]

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.