Split up the Iterator trait #17701
Assignees
Comments
And |
|
Note that this will happen as part of the stabilization process, and we're tackling |
aturon
added a commit
to aturon/rust
that referenced
this issue
Nov 26, 2014
This is an initial pass at stabilizing the `iter` module. The module is fairly large, but is also pretty polished, so most of the stabilization leaves things as they are. Some changes: * Due to the new object safety rules, various traits needs to be split into object-safe traits and extension traits. This includes `Iterator` itself. While splitting up the traits adds some complexity, it will also increase flexbility: once we have automatic impls of `Trait` for trait objects over `Trait`, then things like the iterator adapters will all work with trait objects. * Iterator adapters that use up the entire iterator now take it by value, which makes the semantics more clear and helps catch bugs. Due to the splitting of Iterator, this does not affect trait objects. If the underlying iterator is still desired for some reason, `by_ref` can be used. (Note: this change had no fallout in the Rust distro except for the useless mut lint.) * In general, extension traits new and old are following an [in-progress convention](rust-lang/rfcs#445). As such, they are marked `unstable`. * As usual, anything involving closures is `unstable` pending unboxed closures. * A few of the more esoteric/underdeveloped iterator forms (like `RandomAccessIterator` and `MutableDoubleEndedIterator`, along with various unfolds) are left experimental for now. * The `order` submodule is left `experimental` because it will hopefully be replaced by generalized comparison traits. * "Leaf" iterators (like `Repeat` and `Counter`) are uniformly constructed by free fns at the module level. That's because the types are not otherwise of any significance (if we had `impl Trait`, you wouldn't want to define a type at all). Closes rust-lang#17701 Due to renamings and splitting of traits, this is a: [breaking-change]
bors
added a commit
that referenced
this issue
Nov 26, 2014
This is an initial pass at stabilizing the `iter` module. The module is fairly large, but is also pretty polished, so most of the stabilization leaves things as they are. Some changes: * Due to the new object safety rules, various traits needs to be split into object-safe traits and extension traits. This includes `Iterator` itself. While splitting up the traits adds some complexity, it will also increase flexbility: once we have automatic impls of `Trait` for trait objects over `Trait`, then things like the iterator adapters will all work with trait objects. * Iterator adapters that use up the entire iterator now take it by value, which makes the semantics more clear and helps catch bugs. Due to the splitting of Iterator, this does not affect trait objects. If the underlying iterator is still desired for some reason, `by_ref` can be used. (Note: this change had no fallout in the Rust distro except for the useless mut lint.) * In general, extension traits new and old are following an [in-progress convention](rust-lang/rfcs#445). As such, they are marked `unstable`. * As usual, anything involving closures is `unstable` pending unboxed closures. * A few of the more esoteric/underdeveloped iterator forms (like `RandomAccessIterator` and `MutableDoubleEndedIterator`, along with various unfolds) are left experimental for now. * The `order` submodule is left `experimental` because it will hopefully be replaced by generalized comparison traits. * "Leaf" iterators (like `Repeat` and `Counter`) are uniformly constructed by free fns at the module level. That's because the types are not otherwise of any significance (if we had `impl Trait`, you wouldn't want to define a type at all). Closes #17701 Due to renamings and splitting of traits, this is a: [breaking-change]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When #17670 lands, we will no longer be able to make Iterator trait objects. The only method on Iterator which is object safe is
next, I assume we should therefore pull that out to its own trait and Iterator should extend that, but that means all implementers of Iterator will have to change. So, perhaps there is a better way.cc @aturon
The text was updated successfully, but these errors were encountered: