Re:Value-Oriented Programming
by lmm on Friday August 31, 2018 @04:28PM
(#17888428)
What's the distinction you're drawing? Certainly with "impl trait", any concrete type that conforms to "Iterator<Item = i32>" seems to be a subtype of "impl Iterator<Item = i32>" in every meaningful sense (e.g. Liskov substitutability).
[ Parent
| on HN ]
Re:Value-Oriented Programming
by steveklabnik on Friday August 31, 2018 @04:55PM
(#17888573)
I’m not drawing a distinction, I’m repeating what those who know more about types than me say. Maybe those people are wrong, but if so our docs need updated!
(I think it’s because traits aren’t types, and therefore can’t be subtypes. But I’m not 100% sure and my copy of TAPL is thousands of miles away at the moment...)
Ok, I guess, this only works with trait objects or generics, so traits themselves aren't types in the formal sense (as suggested by others. I am not a type system expert nor do I have formal CS theory education).
As I understand (which again, might be flawed, please correct me), it would be more better to say that a type parameter bounded by a trait is a type, and a type implementing that trait is a subtype of the parameter?
But trait objects have types, and such can be subtyped, correct? That is, I can use a `&Bar` where a `&TraitFoo` is expected if `impl TraitFoo for Bar`.
I think the point is that `&TraitFoo` would never be expected - that there was no way to have that be the type of a term in the first place? I don't think that can reasonably be said to be true in the days of impl trait though.