JarredAllen: > if we make `!: Iterator<!>`, then extend fallback such that `impl Iterator<!>` can coerce to an iterator over any type I have a somewhat harder time imagining a language design principle based on which to coerce any `impl Iterator<Item = !>` to a (new, anonymous, wrapping) type implementing `impl Iterator<Item = T>` for any (particular) other type; compared to my previously mentioned idea of coercing `!` to an (new, anonymous, uninhabited) type implementing `impl Iterator<Item = T>`. Both features would require some amount of introspection into the method signature of the trait[1] but the latter seems conceptually simpler IMO (and more narrow) as it only deals with uninhabited types. I suppose that @idanarye now mentioned above sounds relevant though idanarye: > trait bounds cannot define covariance and contravariance and I think indeed such a coercion of an `impl Iterator<Item = !>` to an `impl Iterator<Item = T>` sounds - arguably - like something that might come out of any “trait variance” design ideas, after all. Specifically, similar coercions are sometimes desirable for coercing between `impl Fn…` kind of types (e.g. in a manner mirroring the variances of `fn` pointer types), in particular the `Output` type of `FnOnce` is comparable to the `Item` type of `Iterator`.[2] * * * 1. and based on language design choices presumably also an opt-in ↩︎ 2. On the other hand, as long as `Fn…` traits are not user-implementable yet, I can also imagine other designs to achieve their variance that don’t involve coercing to anonymous wrapper types, but instead some way of promising through the trait system the existence of other generic instantiations of the _same_ closure type. (This could allow achieving _true subtyping_ between the original and coerced closure types, in cases where the argument types also were subtypes. Note that `!` is not actually in a true subtyping relation to other types either, further complicating the story in any case, if it’s meant to apply to `!` -> `T` coercions for the `Output` type.) ↩︎

For `Iterator` specifically, I use `[].into_iter()`.

Or, I have no idea how hard this would be to implement, but if we make `!: Iterator<!>`, then extend fallback such that `impl Iterator<!>` can coerce to an iterator over any type. That would solve this problem of which item type to use.

String.prototype.replace() with a global regular expression and a function has iterated over the interesting parts of a string since 1999, long before array extras like forEach() and filter(). It is …

There are cases in practice where a type wants to implement `Iterator` (or at least `IntoIter`) two different ways. `&str` is a good example, as an iteration over it can plausibly return either `u8` or `char` (Rust currently deals with this situation by using `.bytes()` and `.chars()` methods to return an appropriate iterable rather than implementing `Iterator` on `&str` directly). So it doesn't seem too ridiculous for a type to want to implement `Iterator` for two different element types. For what it's worth, I consider associated types to be one of the most dangerous features of Rust, in the sense that it is hard to gain confidence that the compiler implements them correctly (and yet if the compiler implements them incorrectly, it can lead to unsoundness in safe code). The alternative would be to make them type parameters instead, using `Iterator<T>` rather than `Iterator<Item=T>`, and in that case it would be plausible to `impl<T> Iterator<T> for !`.

A case that's often disappointing is that stuff like this doesn't work: fn foo() -> impl Iterator<Item = i32> { todo!() }

Sawyer47: > In other words, it would make sense for `!` to implement Iterator for all possible `Item` types, not just `!`? It does not make sense, but it would be useful. In other words, a lot of code requires `impl Iterator<Item = SomeSpecificT>`, so for the implementation of `Iterator` for `!` to be useful it would have to support all those cases. However it does not make sense because `<! as Iterator>::Item` is a single type, so which one is it? Even if you make `!` coercible to something else that implements `Iterator`<Item = SomeSpecificT>` it still won't work because coercions are not attempted when a generic type is expected. Sawyer47: > If so, doesn't the same logic applies to `std::ops::Not`? If would make sense for `!` to implement `Not` for all possible associated `Output` types. Yes, the implementation of `Not` for `!` is not ideal and has the same issues as an hypothetic implementation of `Iterator` for `!`

I wonder why did we make `Item` an associated type instead of a type parameter of `trait Iterator`? One possible reason I can think of is making `.collect()` works better, but are there any other reasons?

I wonder why did we make `Item` an associated type instead of a type parameter of `trait Iterator`? One possible reason I can think of is making `.collect()` works better, but are there any other reasons?