Type parameter versus type alias in trait

16

You can do these today:

fn f() -> impl Iterator {
    "".chars()
}

fn g() -> impl Iterator<Item = impl Display> {
    "".chars()
}

Where as this

trait IteratorWithInputItem<Item> { ... }
fn h() -> impl IteratorWithInputItem {
    "".chars()
}

Results in error[E0107] : missing generics for trait IteratorWithInputItem. And this:

fn i() -> impl IteratorWithInputItem<impl Display> {
    "".chars()
}

Results in error[E0666](:scream:): nested impl Trait is not allowed.

Playground.

You can also do

trait Foo {}
impl<T, U> Foo for T where T: Iterator<Item=U> {}

while you cannot instead do

impl<T, U> Foo for T where T: IteratorWithItemInput<U> {}

error[E0207]: the type parameter U is not constrained by the impl trait, self type, or predicates

Playground. This is a result of RFC 447 and I believe it has further implications for well-formedness via RFC 1214.

The above examples are some consequences. There's probably others related to coherence ala this thread and tricks like this, but I'll stop digging for now.

2 Likes