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_at_[hidden]>
Sent: Thursday, July 16, 2026 3:54
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Yexuan Xiao <bizwen_at_[hidden]>
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.


On Wed, 15 Jul 2026 at 20:50, Yexuan Xiao via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
Where contiguous storage is unnecessary, deque can be used as an alternative to vector in C++. This usage is employed by a large amount of code. However, vector supports reserve while deque does not, which forces users and library authors to determine this property on their own using SFINAE or requires expressions. I performed an exact search on GitHub using regular expressions, and this pattern appeared 483 times(https://github.com/search?q=%2Fif%5Cs%2Bconstexpr%5Cs*%5C%28%5B%5E%29%5D*reserve%5B%5E%29%5D*%5C%29%2F&type=code); the vast majority of them use requires expressions, and these code snippets represent the needs of the most advanced C++ users. Martin Leitner-Ankerl's well-known library unordered_dense also does this and supports C++17 (https://github.com/martinus/unordered_dense/blob/e5b9441ecf193f3e1e8f954527fc76edee20d7eb/include/ankerl/unordered_dense.h#L2094). I believe the C++ standard library needs to provide this functionality to prevent users from reinventing it themselves.

Reference implementation:

template<class C>
    requires (!std::ranges::view<C>) && std::ranges::sized_range<C>
constexpr void to(C c, std::ranges::range_size_t<C> n)
{
    if constexpr (requires { c.reserve(n); }) {
        c.reserve(n);
    }
}

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals