Tracking issue for `shrink_to` feature

[ordovicia]

Steps

• Implementation (Implement shrink_to method on collections #49400)
• Remove assert as suggested in Tracking issue for shrink_to feature #56431 (comment)
  • Resolved in Trying to shrink_to greater than capacity should be no-op #81335
• Stabilization

Questions

• Does this need an RFC?

cc @Diggsey

[kennytm]

Someone needs to update BinaryHeap::shrink_to to point to this issue.

[ordovicia]

I was just doing it 😄

[Amanieu]

Currently the shrink_to method will panic if the given capacity is greater than the current one. I think this should be changed to silently ignore such cases instead.

I can see shrink_to being particularly useful when you want to reuse an existing allocation for something different (for example another pass of a multi-pass algorithm). The container will usually be empty at this point and you just want to ensure that a large allocation used for one pass doesn't clog up memory for the rest of the program's lifetime.

[ErichDonGubler]

I would agree with @Amanieu here -- I've just recently found a case where shrink_to would be handy, particularly if it silently no-op'd in the case of capacity actually being smaller than the specified maximum.

[Amanieu]

I have changed the behavior in hashbrown to no-op if the current capacity is smaller than the minimum (https://github.com/Amanieu/hashbrown/pull/67). There is currently still an assert in the libstd wrapper around hashbrown that panics though.

[In-line]

IMHO I would prefer shrink_to not to panic. I think it is better to return Result<usize, TooSmallError> or maybe Option<usize>?

Ok(..) would contain previous capacity.
Err(...) will be returned in case of failure, containing required minimum.

With this change if I need code to panic, I will just unwrap(), but with current behavior it seems to be error prone.