VecDeque::new allocates

[gnzlbg]

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

[sfackler]

rust-lang/rfcs#1173

[zaharidichev]

@sfackler Can I take a stab at that?

[sfackler]

Sure

[zaharidichev]

@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]

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]

@zaharidichev are you still looking into this?

[whatisaphone]

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]

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]

This can be closed now that #102991 is merged.