Hacker News new | ask | show | jobs
by kroltan 2851 days ago
As I understand it, subtyping is the actual conflation of interfaces (not necessarily a syntatical `interface`, but in the logical sense of "exposed things") into one type, and subclassing is direct extension, the so-called "is a" constraint.

For example, in Rust, there is no subclassing: There is no concrete type that is also another type. But there is subtyping, that is, a concrete type can be used where a interface (in Rust, called `trait`) is required, granted it implements that interface. Additionally, external sources can implement their interfaces unto existing external types.

In C#, you have subtyping+subclassing, but only as one. That is, you can have a concrete type B that is an A, and if A implements X, then B implements X. But you can't implement Y for A unless you have access to A's source. So if you want a type that is an A but also does Y, you _have_ to subclass A as a B, and implement Y on B.

1 comments

The only subtyping in Rust, in my understanding, is lifetimes with the : syntax. Traits are not subtypes.
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).
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.
Traits are subtyped, they are simply a restricted kind of value that makes them more tractable than general value subtyping.