Yes and no. I think the poster does make an interesting point.

If the parent class is instantiable - which is a code smell already but also very common and even encouraged by some OO evangelizing[1], as is the case for the "colored point" example - then he's right, the derived class which adds fields does admit more values than the parent class does (excluding child values).

[1] encouraged by the commonly heard advice: "if you don't like exactly what the class does, then derive from it and supply your own customizations". Ie. this is the use of inheritance for ad-hoc customization, as opposed to a design-first approach which would have the parent be abstract (which has its own problems of course such as requiring great foresight).

Range and capability are separate concepts. That’s what I’m getting at—conflating them is problematic, not least because it’s trying to statically specify dynamic behaviour.

Here’s a simple example. A 2D vector (x:ℝ × y:ℝ) is a subtype of a 3D vector (x:ℝ × y:ℝ × z:ℝ). The range of the 3D vector includes that of the 2D one, but there is no sane way to make one a subclass of the other, due to differences in behaviour—magnitude, for instance.

> Here’s a simple example. A 2D vector (x:ℝ × y:ℝ) is a subtype of a 3D vector (x:ℝ × y:ℝ × z:ℝ).

Again, I think that's backwards. Every 3D vector is also a 2D vector if you ignore its z coordinate, so 3D vectors are a subtype of 2D vectors (assuming some type system that has subtyping between tuples of fewer fields).

You could implement this by having 3D vector subclass 2D, but as you note that's fraught with peril. But that's because substitutability requires meaningful semantic behavior and not just matching signatures. Just because two objects can both "foo" doesn't mean they are substitutable in a pragmatic sense. They have to do the appropriate thing when you foo them.