On Tuesday, 13 February 2024 at 23:57:12 UTC, Ivan Kazmenko wrote:
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.
Personally, I don't have a problem with .length being unsigned.
How do you have a negative length? My problem is that the
language doesn't correctly compare signed and unsigned.
Earlier in the thread, people mentioned NOT mentioning other
languages but I just learned that Carbon correctly compares
signed and unsigned ints.
cheers
