Consider adding Vec::try_with_capacity(_in) and friends

[poliorcetics]

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::VecDeque
  • std::vec::Vec
• try_with_capacity(capacity: usize) -> Result<.., TryReserveError> (see all types):
  • std::collections::BinaryHeap
  • std::collections::VecDeque
  • std::collections::hash_map::HashMap
  • std::collections::hash_set::HashSet
  • std::ffi::OsString
  • std::io::BufReader
  • std::io::BufWriter
  • std::io::LineWriter
  • std::path::PathBuf
  • std::string::String
  • std::vec::Vec

@rustbot label T-libs C-feature-request T-libs-api

Aside: I'm not sure if this falls under A-allocators

[poliorcetics]

@rustbot claim

[poliorcetics]

Related to #91789

[TennyZhuang]

Related to #86942

[dpaoliello]

I've added this for Vec: #95051

[kornelski]

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_reserve calls finish_grow which deliberately is not inline. However finish_grow takes old and new Layout as arguments, which adds code bloat at the call site, and does unnecesary checks for reallocation. OTOH with_capacity inlines to a very simple rustc_alloc call and an alloc error handler call, and try_with_capacity could be even leaner.

[kornelski]

@rustbot claim

[c410-f3r]

What is the status of this feature? IFAICT, there are no listed concerns.

[poliorcetics]

From what I can tell, no one has implemented the methods nor has anyone asked for stabilization of those that were (I think).

[kornelski]

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 allowing try_ 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 the try_ and _in combinations.

[c410-f3r]

Thank you guys.

Looks like the try_ matter should be brought up to the lib team, otherwise progress won't be made.