Add ..= to the parser
Add ..= to libproc_macro
Add ..= to ICH
Highlight ..= in rustdoc
Update impl Debug for RangeInclusive to ..=
Replace `...` to `..=` in range docs
Make the dotdoteq warning point to the ...
Add warning for ... in expressions
Updated more tests to the ..= syntax
Updated even more tests to the ..= syntax
Updated the inclusive_range entry in unstable book
Add Vec::drain_filter
This implements the API proposed in #43244.
So I spent like half a day figuring out how to implement this in some awesome super-optimized unsafe way, which had me very confident this was worth putting into the stdlib.
Then I looked at the impl for `retain`, and was like "oh dang". I compared the two and they basically ended up being the same speed. And the `retain` impl probably translates to DoubleEndedIter a lot more cleanly if we ever want that.
So now I'm not totally confident this needs to go in the stdlib, but I've got two implementations and an amazingly robust test suite, so I figured I might as well toss it over the fence for discussion.
Add method `String::retain`
Behaves like `Vec::retain`, accepting a predicate `FnMut(char) -> bool`
and reducing the string to only characters for which the predicate
returns `true`.
Behaves like `Vec::retain`, accepting a predicate `FnMut(char) -> bool`
and reducing the string to only characters for which the predicate
returns `true`.
Document unintuitive argument order for Vec::dedup_by relation
When trying to use `dedup_by` to merge some auxiliary information from removed elements into kept elements, I was surprised to observe that `vec.dedup_by(same_bucket)` calls `same_bucket(a, b)` where `b` appears before `a` in the vector, and discards `a` when true is returned. This argument order is probably a bug, but since it has already been stabilized, I guess we should document it as a feature and move on.
(`Vec::dedup` also uses `==` with this unexpected argument order, but I figure that’s not important since `==` is expected to be symmetric with no side effects.)
When trying to use dedup_by to merge some auxiliary information from
removed elements into kept elements, I was surprised to observe that
vec.dedup_by(same_bucket) calls same_bucket(a, b) where b appears
before a in the vector, and discards a when true is returned. This
argument order is probably a bug, but since it has already been
stabilized, I guess we should document it as a feature and move on.
(Vec::dedup also uses == with this unexpected argument order, but I
figure that’s not important since == is expected to be symmetric with
no side effects.)
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Alex Burka