]> git.lizzy.rs Git - rust.git/commitdiff
Rollup merge of #46262 - udoprog:linked-list-remove-if, r=dtolnay
authorkennytm <kennytm@gmail.com>
Mon, 27 Nov 2017 19:16:47 +0000 (03:16 +0800)
committerGitHub <noreply@github.com>
Mon, 27 Nov 2017 19:16:47 +0000 (03:16 +0800)
Introduce LinkedList::drain_filter

This introduces `LinkedList::remove_if`.

This operation embodies one of the use-cases where `LinkedList` would typically be preferred over `Vec`: random removal and retrieval.

There are a number of considerations with this:

Should there be two `remove_if` methods? One where elements are only removed, one which returns a collection of removed elements.

Should this be implemented using a draining iterator pattern that covers both cases? I suspect that would incur a bit of overhead (moving the element into the iterator, then into a new collection). But I'm not sure. Maybe that's an acceptable compromise to maximize flexibility.

I don't feel I've had enough exposure to unsafe programming in rust to be certain the implementation is correct. This relies quite heavily on moving around copies of Shared pointers to make the code reasonable. Please help me out :).

1  2 
src/liballoc/linked_list.rs

Simple merge