Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for `shrink_to` feature #56431

Open
ordovicia opened this issue Dec 2, 2018 · 6 comments

Comments

Projects
None yet
6 participants
@ordovicia
Copy link
Contributor

commented Dec 2, 2018

Steps

  • Implementation (#49400)
  • Stabilization

Questions

  • Does this need an RFC?

cc @Diggsey

@kennytm

This comment has been minimized.

Copy link
Member

commented Dec 2, 2018

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

@ordovicia

This comment has been minimized.

Copy link
Contributor Author

commented Dec 2, 2018

I was just doing it 😄

Centril added a commit to Centril/rust that referenced this issue Dec 2, 2018

Rollup merge of rust-lang#56432 - ordovicia:shrink-to-issue, r=Centril
Update issue number of `shrink_to` methods to point the tracking issue

Tracking issue: rust-lang#56431

kennytm added a commit to kennytm/rust that referenced this issue Dec 3, 2018

Rollup merge of rust-lang#56432 - ordovicia:shrink-to-issue, r=Centril
Update issue number of `shrink_to` methods to point the tracking issue

Tracking issue: rust-lang#56431
@Amanieu

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2018

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

This comment has been minimized.

Copy link

commented Apr 3, 2019

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.

bors bot added a commit to rust-lang/hashbrown that referenced this issue Apr 22, 2019

Merge #67
67: Change shrink_to to not panic if min_capacity < capacity r=Amanieu a=Amanieu

cc rust-lang/rust#56431

Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
@Amanieu

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2019

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

This comment has been minimized.

Copy link

commented May 7, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.