-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
VecDeque::new allocates #68990
Comments
@sfackler Can I take a stab at that? |
Sure |
@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 |
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. |
@zaharidichev are you still looking into this? |
I'll just mention |
I started experimenting with this and it's quite annoying that if |
This can be closed now that #102991 is merged. |
Please link to the API Change Proposal where we lock in this guarantee, as well as zero-alloc |
Per https://github.com/rust-lang/rust/pull/102991’s description there is no such guarantee (yet) |
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
The text was updated successfully, but these errors were encountered: