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

VecDeque::new allocates #68990

Closed
gnzlbg opened this issue Feb 9, 2020 · 12 comments
Closed

VecDeque::new allocates #68990

gnzlbg opened this issue Feb 9, 2020 · 12 comments
Labels
A-collections Area: `std::collections` C-enhancement Category: An issue proposing an enhancement or a PR with one. I-slow Issue: Problems and improvements with respect to performance of generated code. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@gnzlbg
Copy link
Contributor

gnzlbg commented Feb 9, 2020

I've noticed that VecDeque::new allocates. We don't guarantee that it doesn't, but this felt inconsistent with, e.g., Vec::new, for which we do guarantee that it does not allocate.

I'm not sure what the appropriate venue is for discussing this, but I think it would make sense to remove the surprise here and guarantee that VecDeque::new does not heap-allocate either.

cc @rust-lang/libs

@jonas-schievink jonas-schievink added A-collections Area: `std::collections` C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. I-slow Issue: Problems and improvements with respect to performance of generated code. labels Feb 9, 2020
@sfackler
Copy link
Member

sfackler commented Feb 9, 2020

rust-lang/rfcs#1173

@zaharidichev
Copy link

@sfackler Can I take a stab at that?

@sfackler
Copy link
Member

Sure

@zaharidichev
Copy link

@sfackler, since this is my first take on an issue here, I wonder whether there is a mentor for this one (sorry not sure you are the right person to ask). Also, should I start with an RFC (or pre RFC) on that one. Seems the sensible approach to take is to use head and len() and avoid the requirement to always have at least one slot, even when empty (rust-lang/rfcs#1173 (comment)). Any suggestions arem ore than welcome :)

@sfackler
Copy link
Member

sfackler commented Mar 1, 2020

There's no need for an RFC for these kind of small behavior changes.

Removing the one-empty slot requirement is one option, which may require adding a separately tracked length field. You could alternatively try to special-case the capacity 0 case, but it might be hard to ensure all of the corner cases are handled properly.

@lcnr
Copy link
Contributor

lcnr commented Mar 25, 2020

@zaharidichev are you still looking into this?

@whatisaphone
Copy link
Contributor

I'll just mention const fn since that was the keyword I first tried searching for, and it hasn't been mentioned here yet.

@Kobzol
Copy link
Contributor

Kobzol commented Apr 1, 2022

I started experimenting with this and it's quite annoying that if VecDeque is in a half-broken state (during refactoring), tests segfault, because VecDeque is probably used in the implementation of the test suite. Is there a way to say that "I want to run the test suite using stage0, but I want to test a modified implementation of std"?

@joboet
Copy link
Member

joboet commented Dec 2, 2022

This can be closed now that #102991 is merged.

@riking
Copy link

riking commented Dec 2, 2022

Please link to the API Change Proposal where we lock in this guarantee, as well as zero-alloc From<Vec<T>>.

@SimonSapin
Copy link
Contributor

Per https://github.com/rust-lang/rust/pull/102991’s description there is no such guarantee (yet)

@Sp00ph
Copy link
Member

Sp00ph commented Dec 5, 2022

cc #105127 #105128

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-collections Area: `std::collections` C-enhancement Category: An issue proposing an enhancement or a PR with one. I-slow Issue: Problems and improvements with respect to performance of generated code. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests