diff options
| author | bors <bors@rust-lang.org> | 2019-05-12 06:24:10 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2019-05-12 06:24:10 +0000 |
| commit | 16e356ebdfa42b754c1497f1c58caacbe2f25d03 (patch) | |
| tree | bad4da2fcfd6cda2059d84d8afbd8a97b4b7453d /src/libstd/sys/unix/stack_overflow.rs | |
| parent | d28e948b92d85b5b93f48075d010f799cf9642b6 (diff) | |
| parent | 0545375ca6822b4b140cd853f368473d69b76227 (diff) | |
| download | rust-16e356ebdfa42b754c1497f1c58caacbe2f25d03.tar.gz rust-16e356ebdfa42b754c1497f1c58caacbe2f25d03.zip | |
Auto merge of #60396 - cuviper:ordered-retain, r=scottmcm
Document the order of {Vec,VecDeque,String}::retain
It's natural for `retain` to work in order from beginning to end, but
this wasn't actually documented to be the case. If we actually promise
this, then the caller can do useful things like track the index of each
element being tested, as [discussed in the forum][1]. This is now
documented for `Vec`, `VecDeque`, and `String`.
[1]: https://users.rust-lang.org/t/vec-retain-by-index/27697
`HashMap` and `HashSet` also have `retain`, and the `hashbrown`
implementation does happen to use a plain `iter()` order too, but it's
not certain that this should always be the case for these types.
r? @scottmcm
Diffstat (limited to 'src/libstd/sys/unix/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions