Skip to content

Consider adding Vec::try_with_capacity(_in) and friends #91913

Open
@poliorcetics

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::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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

C-feature-requestCategory: A feature request, i.e: not implemented / a PR.T-libsRelevant to the library team, which will review and decide on the PR/issue.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions