Subtyping describes an abstraction with which you can substitute any implementation that conforms to that abstraction's signature (Liskov substitution). Subclassing instead typically imposes both subtyping and behavioural inheritance. So as a rough approximation:
An OO language where you were forced to specify subtyping by implementing interfaces, but you could separately declare some implementations you inherited from without that also applying a subtyping relationship with those types, then that would be a proper separation of concerns.
Oversimplifying for this context: subclassing is reusing the implementation of a parent class, subtyping is when a type can be substituted for a (parent) class for some given functionality. It's confusing because it's not always easy to explain what constitutes "substitute", e.g. see "Liskov Substitution Principle". In some languages there might not be any class or interface relationship between subclasses - they just have the right functions that do the right things.
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.
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.
Interface implementation = subtyping
Class inheritance = subclassing + subtyping, ie. inheriting behaviour + subtyping
An OO language where you were forced to specify subtyping by implementing interfaces, but you could separately declare some implementations you inherited from without that also applying a subtyping relationship with those types, then that would be a proper separation of concerns.
Oleg discusses the issues in further detail here: http://okmij.org/ftp/Computation/Subtyping/