The value of Go and Rust, I think, is that they are object-oriented languages that try to avoid conflating classes with types.
If you think of a type as a set of possible values, then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype. The “is-a” relationship is saying “for all instances I of X, I is an instance of Y” which is essentially the definition of superset. That is what the Liskov Substitution Principle is about.
In C++ and other languages with support for object-oriented programming, a subclass is not necessarily a supertype: virtual functions can throw “I don’t make sense in this derived class”. And a supertype is not necessarily a subclass: templates offer the benefit of the doubt when it comes to static interfaces.
This mismatch leads, in my experience, to interfaces that are ill-specified at best and buggy at worst—so it’s nice to see those issues addressed.
If you think of a type as a set of possible values, then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype. The “is-a” relationship is saying “for all instances I of X, I is an instance of Y” which is essentially the definition of superset. That is what the Liskov Substitution Principle is about.
In C++ and other languages with support for object-oriented programming, a subclass is not necessarily a supertype: virtual functions can throw “I don’t make sense in this derived class”. And a supertype is not necessarily a subclass: templates offer the benefit of the doubt when it comes to static interfaces.
This mismatch leads, in my experience, to interfaces that are ill-specified at best and buggy at worst—so it’s nice to see those issues addressed.