Date: Thu, 16 Apr 2026 09:28:54 +0100
On Thu, 16 Apr 2026 at 02:32, Evan Teran via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> I had an idea for a simple library level addition which would avoid some
> boiler plate that I find myself needing to write often, and suspect that
> others do too. The instructions say to float the idea first, so this is in
> in a nutshell:
>
> I am interested in proposing a **signed integral overload** for reserve()
> in all standard containers that currently accept only an unsigned
> size_type. The goal is to improve ergonomics and safety when reserving
> capacity based on signed computations such as std::ptrdiff_t results from
> std::distance.
> Today, users who want to avoid conversion warnings (which I personally
> consider a best practice) must manually convert from signed to unsigned,
> often after performing explicit negative checks which are easy to forget to
> do. I would propose it as a template restricted to std::signed_integral so
> the extra cost of the negative value check is only paid for signed types
> and to avoid ambiguity with the existing size_type based implementation.
>
> Essentially it amounts to adding this:
>
> template <std::signed_integral S>
> void reserve(S n); // throws std::length_error if n is negative, otherwise
> behaves as if reserve(static_cast<size_type>(n)) were called.
>
> Perhaps something similar with resize(), but for now I'm happy to start
> small and focused.
>
> So two questions:
>
> 1. Would there be any interest in such a proposal?
>
I think this has very little benefit. It doesn't change the semantics of
anything (except maybe for the unordered containers, where it would change
a bad_alloc exception to length_error), it just suppresses -Wconversion
diagnostics that you might get today. So it just removes the need to do an
explicit cast, performing that same cast inside the function instead.
But it would make every call to reserve compile slower, because now
overload resolution (and constraint satisfaction) would have to be done. If
it enabled useful new semantics or improved safety, that additional
compile-time cost might be acceptable. But it doesn't make anything safer,
it just avoids some warnings. Calling reserve with a negative value would
still fail in similar way, your code would not be any safer or more robust.
> 2. I understand that if there were interest, then meeting attendance is
> needed to move forward, is this in person, or can it be via video
> attendance?
>
All meetings are "hybrid" meetings meaning attendance can be in-person or
remote. Attendance isn't necessary if somebody else can champion the
proposal.
std-proposals_at_[hidden]> wrote:
> I had an idea for a simple library level addition which would avoid some
> boiler plate that I find myself needing to write often, and suspect that
> others do too. The instructions say to float the idea first, so this is in
> in a nutshell:
>
> I am interested in proposing a **signed integral overload** for reserve()
> in all standard containers that currently accept only an unsigned
> size_type. The goal is to improve ergonomics and safety when reserving
> capacity based on signed computations such as std::ptrdiff_t results from
> std::distance.
> Today, users who want to avoid conversion warnings (which I personally
> consider a best practice) must manually convert from signed to unsigned,
> often after performing explicit negative checks which are easy to forget to
> do. I would propose it as a template restricted to std::signed_integral so
> the extra cost of the negative value check is only paid for signed types
> and to avoid ambiguity with the existing size_type based implementation.
>
> Essentially it amounts to adding this:
>
> template <std::signed_integral S>
> void reserve(S n); // throws std::length_error if n is negative, otherwise
> behaves as if reserve(static_cast<size_type>(n)) were called.
>
> Perhaps something similar with resize(), but for now I'm happy to start
> small and focused.
>
> So two questions:
>
> 1. Would there be any interest in such a proposal?
>
I think this has very little benefit. It doesn't change the semantics of
anything (except maybe for the unordered containers, where it would change
a bad_alloc exception to length_error), it just suppresses -Wconversion
diagnostics that you might get today. So it just removes the need to do an
explicit cast, performing that same cast inside the function instead.
But it would make every call to reserve compile slower, because now
overload resolution (and constraint satisfaction) would have to be done. If
it enabled useful new semantics or improved safety, that additional
compile-time cost might be acceptable. But it doesn't make anything safer,
it just avoids some warnings. Calling reserve with a negative value would
still fail in similar way, your code would not be any safer or more robust.
> 2. I understand that if there were interest, then meeting attendance is
> needed to move forward, is this in person, or can it be via video
> attendance?
>
All meetings are "hybrid" meetings meaning attendance can be in-person or
remote. Attendance isn't necessary if somebody else can champion the
proposal.
Received on 2026-04-16 08:29:11
