length's type.

[Kevin Bailey]

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