Skip to content

Documentation for Vec::leak doesn't ackowledge dropping of excess capacity #79240

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

Closed
TheOnlyMrCat opened this issue Nov 20, 2020 · 4 comments
Closed
Labels
A-collections Area: `std::collections` E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@TheOnlyMrCat
Copy link

TheOnlyMrCat commented Nov 20, 2020

When using one of the functions to convert a Vec<T> to a [T], excess capacity of the vector is dropped, leaving the slice with only the elements which have been initialised in memory.

This behaviour is acknowledged in the documentation for Vec::into_boxed_slice, but not in the documentation for Vec::leak.

@jonas-schievink jonas-schievink added A-collections Area: `std::collections` E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Nov 20, 2020
@chansuke
Copy link
Contributor

I'd like to work on this.

@rustbot claim

@JohnTitor
Copy link
Member

@rustbot release-assignment

@yaymukund
Copy link
Contributor

As per this comment by m-ou-se in chansuke's PR:

This example doesn't demonstrate any leaking. .into_boxed_slice() returns a Box, which the slice variable will own.

The issue this PR was originally trying to fix is that the documentation doesn't promise this function drops excess capacity. However, I don't think that's something we want to fix. Instead, I think it'd be better if leak explicitly does not drop the excess capacity. But for that, there's an RFC which has been standing still for a while: rust-lang/rfcs#2969

Should this be closed in favor of the linked RFC?

@JohnTitor
Copy link
Member

Hm, makes sense, though the RFC PR has been closed. I think it'd be great if we could provide some explanation for it but it seems it's not time to do right now. Okay, I'm going to close this for now, thanks for pointing out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-collections Area: `std::collections` E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants