Tracking issue for `drain` stabilization

[aturon]

The drain method was originally proposed in collections reform 2 and then adjusted in a follow-up RFC. The main remaining question for the API is the traits it uses to accept various kinds of ranges, which potentially interacts with inclusive ranges.

cc @bluss, who is working on an RFC to finish off this API.

[Gankra]

Current opinion: stabilize Vec and HashMap with Vec using an unstable trait -- most just want to be able to call drain(..) and shouldn't care about the trait as long as it will always accept certain concrete args.

VecDeque is using the V1 API still (@mystor was working on this)

BTree needs serious work in relation to the range API

LinkedList is very "whatever" for me. drain is basically "doing it wrong" for LinkedList IMO. Typical concerns around indexing apply here, though. Ship has kinda sailed in the form of split_off.

[bluss]

My draft is https://gist.github.com/bluss/9b0f84fbb477de87d9d8 I'm just looking for comments before I post it.

@gankro It sounds like you favour a collections trait solution for this. It's a good solution for multidispatch reasons, but apart from that, I don't really have a guiding star for when we do collections traits (like Extend) and when we don't.

[Gankra]

This issue also tracks collections_range, whose only consumer and fate is Vec::drain. (VecDeque should also use it per #27723)

[bluss]

RFC: rust-lang/rfcs/pull/1257

[aturon]

Nominating for stabilization in 1.6. I'm not sure how much of the API surface here we want to stabilize, but note that it's fine to stabilize the drain method even while it references a currently-unstable trait.

[Gankra]

[alexcrichton]

🔔 This issue is now entering its cycle-long final comment period for stabilization 🔔

Note that the trait bound on the functions will not be included as part of the stabilization here, just the functions and return types.

[alexcrichton]

This was discussed in the libs team triage meeting today and the decision was to stabilize