You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The typing spec states that, when A and B are potentially overloaded methods
If a callable B is overloaded with two or more signatures, it is assignable to callable A if at least one of the overloaded signatures in B is assignable to A
If a callable A is overloaded with two or more signatures, callable B is assignable to A if B is assignable to all of the signatures in A
However, this definition seems to be too strict. Consider the following example:
These two protocols specify the exact same runtime behavior. Yet, following the rules of the spec, IntScalarOurs is assignable to IntScalarTheirs, but IntScalarTheirs is not assignable to IntScalarOurs.
Case 1: A=IntScalarOurs, B=IntScalarTheirs.
If a callable B is overloaded with two or more signatures, it is assignable to callable A if at least one of the overloaded signatures in B is assignable to A
Is (self, int) -> Self assignable to (self, int | Self) -> Self? No, because int is not a supertype of int | Self (contravariance)
Is (self, Self) -> Self assignable to (self, int | Self) -> Self? No, because Self is not a supertype of int | Self (contravariance)
Thus, IntScalarTheirs is not assignable to IntScalarOurs.
Case 2: A=IntScalarTheirs, B=IntScalarOurs.
If a callable A is overloaded with two or more signatures, callable B is assignable to A if B is assignable to all of the signatures in A
Is (self, int | Self) -> Self assignable to (self, int) -> Self? Yes.
Is (self, int | Self) -> Self assignable to (self, Self) -> Self? Yes.
Thus, IntScalarOurs is assignable to IntScalarTheirs.
From a pure set-theoretic POV, it seems that subtyping functions should follow a very simply rule based on the domain.
$f <: g$ if and only if $\text{dom}(f) ⊇ \text{dom}(g)$ and $f(x) <: g(x)$ for all $x∈\text{dom}(g)$
What is currently specced appears to be a lemma for a sufficient condition, but not a necessary one.
Individual type-checkers can of course use such lemmas if the general case is too difficult to check/implement (and communicate that to their users), but shouldn't the spec be biased towards the theoretically principled point of view, when applicable?
Uh oh!
There was an error while loading. Please reload this page.
The typing spec states that, when
A
andB
are potentially overloaded methodsHowever, this definition seems to be too strict. Consider the following example:
These two protocols specify the exact same runtime behavior. Yet, following the rules of the spec,
IntScalarOurs
is assignable toIntScalarTheirs
, butIntScalarTheirs
is not assignable toIntScalarOurs
.Case 1:
A=IntScalarOurs
,B=IntScalarTheirs
.(self, int) -> Self
assignable to(self, int | Self) -> Self
? No, becauseint
is not a supertype ofint | Self
(contravariance)(self, Self) -> Self
assignable to(self, int | Self) -> Self
? No, becauseSelf
is not a supertype ofint | Self
(contravariance)Thus,
IntScalarTheirs
is not assignable toIntScalarOurs
.Case 2:
A=IntScalarTheirs
,B=IntScalarOurs
.(self, int | Self) -> Self
assignable to(self, int) -> Self
? Yes.(self, int | Self) -> Self
assignable to(self, Self) -> Self
? Yes.Thus,
IntScalarOurs
is assignable toIntScalarTheirs
.From a pure set-theoretic POV, it seems that subtyping functions should follow a very simply rule based on the domain.
What is currently specced appears to be a lemma for a sufficient condition, but not a necessary one.
Individual type-checkers can of course use such lemmas if the general case is too difficult to check/implement (and communicate that to their users), but shouldn't the spec be biased towards the theoretically principled point of view, when applicable?
Related Discussions
#1782
The text was updated successfully, but these errors were encountered: