On Thu, 16 Apr 2026, 23:32 Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Thursday, 16 April 2026 09:07:58 Pacific Daylight Time Evan Teran via
> Std-
> Proposals wrote:
> > @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.
>
> Making a throwing API would make people use the unsigned API even with a
> signed calculation just to avoid the runtime check for the throw. If
> anything,
> just make it a precondition.
>
> But maybe don't: why is the value negative in the first place? It's often
> because a calculation unexpectedly underflowed. If reserve(0) would
> effectively
> just be shrink_to_fit(), why would reserve(-1) be any different?
>

vector::reserve and hive::reserve never shrink capacity, and since P0966R1
basic_string::reserve doesn't shrink either.





> What's more, what is the prior art? The Qt containers that do use signed
> types
> for indices and sizes have a prior behaviour: reserve(-1) is the same as
> reserve(0), which is squeeze() / shrink_to_fit().
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>