On 16/04/2026 12:05, Ell via Std-Proposals wrote:
> On Thursday, April 16th, 2026 at 6:51 AM, Steve Weinrich via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> I find it very interesting that folk think the argument should be signed. I have found that a very large percentage of ints should really be unsigned as negative values are not permitted in normal usage.
>> As an example, I have used, and seen, this an uncountable number of times:
>>
>> T array[10];
>>
>> for (int i = 0; i < 10; ++i) { stuff }
>>
>> I have been embracing unsigned ints more and more in an effort to make it clear that negative values are not permitted.
>
> There's some sense in using signed int for induction variables, because
> overflow being UB gives the compiler more room to optimize. With an
> unsigned int, the compiler must consider the case where the value wraps
> around (not in this specific example, but in general), which means you
> have to be more careful about the specific types.
>
> https://godbolt.org/z/Kv1afGjaf
>

Yes, there are a number of constructs where using unsigned int can lead
to unexpected inefficiencies (not just fewer optimisation
opportunities). You see it on 64-bit systems if you have something like
"x[i++]" when "i" is a 32-bit unsigned int. In general, you'll see it
anywhere you are adding a larger type to a smaller unsigned type in a
loop, and doing arithmetic on the unsigned type.

If you want to use an unsigned type for an index like this, it is more
efficient (and arguably more "correct") to use "size_t" rather than
unsigned int. (Using "unsigned long" in your godbolt example gives the
same results as using "int".)