impl Trait is an existential type, not a subtype relationship. And it doesn't really mean "Liskov substitutable" either. After all, it names a single type, just un-named.
> would making an working implementation (that makes a lot of arbitrary choices about syntax, efficiency etc.) advance the conversation?
I don't know. It might, but it's also possible that the team has other objections I'm not aware of.
> impl Trait is an existential type, not a subtype relationship. And it doesn't really mean "Liskov substitutable" either. After all, it names a single type, just un-named.
Well, "impl Iterator<Item=i32>" is clearly not the same thing as "Vec<i32>", but "Vec<i32>" is Liskov-substitutable for it. AFAICS it meets every definition of a subtype unless you take the position that "impl Iterator<Item=i32>" isn't a type at all, which begs the question of what "impl Iterator<Item=i32>" is - certainly it's something more than syntax sugar for "Vec<i32>", and it looks like a type and largely quacks like a type AFAICS.
`Vec<i32>` or `vec::IntoIter<i32>` being a subtype of `impl Iterator<Item=i32>` would imply that you could take have a vec of type `Vec<impl Iterator<Item=i32>>` and have many structs of different types stuffed in, that all implement `Iterator<Item=i32>`. You can't do that, ergo, it's not a subtype.
> would making an working implementation (that makes a lot of arbitrary choices about syntax, efficiency etc.) advance the conversation?
I don't know. It might, but it's also possible that the team has other objections I'm not aware of.