Repository navigation
VecDeque::new allocates #68990
Description
Activity
@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
headandlen()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 :)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
const fnsince that was the keyword I first tried searching for, and it hasn't been mentioned here yet.I started experimenting with this and it's quite annoying that if
VecDequeis in a half-broken state (during refactoring), tests segfault, becauseVecDequeis 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"?Please link to the API Change Proposal where we lock in this guarantee, as well as zero-alloc
From<Vec<T>>.Per https://github.com/rust-lang/rust/pull/102991’s description there is no such guarantee (yet)
I've noticed that
VecDeque::newallocates. 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::newdoes not heap-allocate either.cc @rust-lang/libs