@Thiago, I would propose that it throw a length_error as that's what I
believe the behavior would have been, had size_type been signed originally.

I can't say that I agree with you because if a signed integer API for this
were introduced, it would have to check for negative values regardless.
Unless I misunderstood that part of the objection.

Regarding the other peoples concerns, I understand and that all makes sense
to me.

Personally, I consider user code needing to do casts on pretty common code
to be undesirable, so while this is a "not very much to it" suggestion, I'd
consider it to be worthwhile.

Regardless, appreciate your time and feedback.


On Thu, Apr 16, 2026, 6:28 AM David Brown via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
> 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".)
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>