Sorry, I was writing it in the Mail app, so there were two mistakes. Naming it try_reserve might imply that the function can fail, but compared to reserve, it doesn't carry that implication, so I think reserve is a suitable name. I just came up with a new idea:
if the container doesn't have a reserve function, then its size must be greater than or equal to n; otherwise, it's UB. This addresses the two concerns you had. Here is my revised implementation:
template<class C>
requires (!std::ranges::view<C>) && std::ranges::sized_range<C>
constexpr void reserve(C &c, std::ranges::range_size_t<C> n)
{
if constexpr (requires { c.reserve(n); }) {
c.reserve(n);
} else {
assert(n <= c.max_size());
}
}
Alternatively, it could also throw bad_alloc, as inplace_vector's reserve does.
From: Jan Schultke <janschultke@googlemail.com>
Sent: Thursday, July 16, 2026 3:54
To: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
Cc: Yexuan Xiao <bizwen@nykz.org>
Subject: Re: [std-proposals] Proposal: ranges::reserve
Firstly, you probably intended to call it "reserve" and to pass C by reference in your reference implementation.
Secondly, it doesn't feel very "ranges-like" to fall back onto doing nothing rather than falling back onto a slower version of the same thing. For example, ranges::distance will painstakingly advance forward iterators to compute distances if need be, and ranges::size
falls back onto taking iterator differences, or is simply ill-formed.
What you're proposing is very novel and exotic because it silently does nothing even if you do something incredibly nonsensical like calling ranges::reserve with a std::array. Perhaps it should be called ranges::try_reserve then.
Anyway, I can see the utility in this idea; I'm just not sure how it would fit into the surrounding design.