-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Full Tuple
and NamedTuple
covariance
#10786
Comments
To be precise, there are at least 5 parts to implementing full
Above all, the compiler should never instantiate all subtypes of a At the time of writing this I got the first 3 parts working. |
Bathroom thought: #10519 works because subtyping never compares generic arguments recursively, but they could manifest in fully covariant |
This RFC is essentially the opposite of #10036.
A
Tuple
instance can be upcast to a largerTuple
, but not downcast to a smaller one:Likewise, runtime type checks also fail:
This ultimately comes from the fact that type filtering of
Tuple
instances is non-commutative, i.e. #2404 (comment).I suggest that we make these examples work, because they are compatible with
Tuple
's built-in covariance rules. The same goes forNamedTuple
instances up to equivalence. One consequence is the family ofTuple(T)
instances have exactly the same subtyping relationships as the family ofT
, so the following example should also compile:Another consequence is two
Tuple
instances may have a common subtype even if neither is a subtype of the other:The text was updated successfully, but these errors were encountered: