Repository navigation
Consider adding Vec::try_with_capacity(_in) and friends #91913
Description
With try_reserve(_exact) stabilized, the following pattern is going to start cropping up (it already does in our internal code base):
let mut buf = Vec::new();
buf.try_reserve_exact(cap)?;Would adding one or two extra methods per container; try_with_capacity(capacity: usize) -> Result<.., TryReserveError> and try_with_capacity_in(capacity: usize, alloc: A) -> Result<.., TryReserveError> be appropriate ?
Note that the two-liner above works perfectly to the best of my knowledge, it is just a question of conciseness. I also find it makes intent clearer from the start, but other may have diverging opinions on this.
Affected types would be:
try_with_capacity_in(capacity: usize, alloc: A) -> Result<.., TryReserveError>(see all types):std::collections::VecDequestd::vec::Vec
try_with_capacity(capacity: usize) -> Result<.., TryReserveError>(see all types):std::collections::BinaryHeapstd::collections::VecDequestd::collections::hash_map::HashMapstd::collections::hash_set::HashSetstd::ffi::OsStringstd::io::BufReaderstd::io::BufWriterstd::io::LineWriterstd::path::PathBufstd::string::Stringstd::vec::Vec
@rustbot label T-libs C-feature-request T-libs-api
Aside: I'm not sure if this falls under A-allocators
Reacted by Paolo Barbolini, Patrick Poitras, Bob, Xuanwo, Kornel, Morten Lohne, jfldde, Soroush Mirzaei, Moritz Firsching, 12932 and 1 more
Reacted by Moritz Firsching
Reacted by nielsle
Activity
poliorcetics commentedon Dec 22, 2021
@rustbot claim
poliorcetics commentedon Jan 7, 2022
Related to #91789
TennyZhuang commentedon Jan 14, 2022
Related to #86942
dpaoliello commentedon Mar 29, 2022
I've added this for
Vec: #95051kornelski commentedon Jan 30, 2024
I'd like to revive this. Previous PR tried to add too many extra methods. Let's focus on just
try_with_capacity().There is a need for this method beyond convenience.
try_reservecallsfinish_growwhich deliberately is not inline. Howeverfinish_growtakes old and newLayoutas arguments, which adds code bloat at the call site, and does unnecesary checks for reallocation. OTOHwith_capacityinlines to a very simplerustc_alloccall and an alloc error handler call, andtry_with_capacitycould be even leaner.kornelski commentedon Jan 30, 2024
@rustbot claim
try_with_capacity for Vec, VecDeque, String
try_with_capacity for Vec, VecDeque, String
try_with_capacity for Vec, VecDeque, String
17 remaining items
Rollup merge of rust-lang#120504 - kornelski:try_with_capacity, r=Ama…
Unrolled build for rust-lang#120504
c410-f3r commentedon Jul 4, 2024
What is the status of this feature? IFAICT, there are no listed concerns.
poliorcetics commentedon Jul 4, 2024
From what I can tell, no one has implemented the methods nor has anyone asked for stabilization of those that were (I think).
kornelski commentedon Jul 4, 2024
try_with_capacity is implemented (unstable).
https://doc.rust-lang.org/nightly/std/vec/struct.Vec.html#method.try_with_capacity
The contentious issue was about potentially endless proliferation of
try_methods. This will probably remain controversial and block stabilization, until either somehow allowingtry_on everything becomes an accepted policy, or some other solution emerges that gives Rust something like method overloading or optional params to deal with all thetry_and_incombinations.c410-f3r commentedon Jul 4, 2024
Thank you guys.
Looks like the
try_matter should be brought up to the lib team, otherwise progress won't be made.eirnym commentedon Jun 5, 2026
I would prefer to stabilize these methods portion-wise (not all at once). Even try_with_capacity provides quite an improvement of potential error handling in libs and apps.
clubby789 commentedon Oct 22, 2026
This is implemented and this issue is referenced as a tracking issue.