Closed glyn closed 1 year ago
Not sure I like the concept of "subtype by coercion". One can be used in place of the other as it can be coerced, but that is not usually what we'd call a subtype.
That's a different point really. Table 13 already includes at least one subtype by coercion, so this issue adds another subtype by coercion.
@cabo How would you like to proceed with "subtype by coercion"? If we want to explore alternatives, I think it deserves a separate, non-editorial issue.
From the spec, just below Table 14:
OptionalNode
is a subtype ofOptionalValue
via coercion since theOptionalNode
instanceNode(n)
can be coerced to theOptionalValue
instanceValue(v)
, wherev
is the value of the noden
.
I disagree with the idea that coercion implies subtypes.
If I have integer and floating point numeric types, I can cast from one to the other, but that doesn't mean that either is a subtype of the other.
C# provides "implicit" casts where the compiler can infer a type cast from context. For example,
float f1 = 1.5;
int i1 = (int) f1; // C# requires that I explicitly cast this because of data loss
int i2 = 42;
float f2 = i; // This is an implicit cast. int isn't a subtype, but it is compatible.
I think this is closer to what we're dealing with here. We're looking at compatibility and conversion between types, not polymorphism (as "subtype" implies).
OptionalNode
is a subtype by coercion ofOptionalValue
, but Table 13 does not include this subtype relationship.