-
Notifications
You must be signed in to change notification settings - Fork 127
Description
The task here is to resolve the following TODO and add support for is_gradual_equivalent_to
for an overloaded callable. Note that this relation is supported when both types are non-overloaded callable i.e., a callable type with one signature.
Notes
Currently, the equivalence relation between two, possible overloaded, callable types is implemented based on the definition of equivalence in the typing spec and delegates it to the subtyping check:
We also define an equivalence relation on fully static types: the types
A
andB
are equivalent (or “the same type”) if and only ifA
is a subtype ofB
andB
is a subtype ofA
.
Implementation of equivalence check between two callable type:
I had a discussion with Carl internally and we think that the gradual equivalence check could potentially be implemented using a similar approach instead of implementing it from scratch as it might be complicated to implement the check from scratch.
The way this could work is by using some kind of "strategy" parameter that the CallableType::is_subtype_of
accepts which would have two variants to indicate that the subtype check between two parameter type is being done to check either (1) gradual equivalence between two callable types or (2) subtyping between two callable types.
In terms of implementation, this could look like:
- Update
CallableType::is_gradual_equivalent_to
to delegate it tois_subtype_of
when either of both types are overloaded - Update
CallableType::is_subtype_of
to accept an enum parameter with two variants - Pass this parameter to
Signature::is_subtype_of
- The inner close in
Signature::is_subtype_of
that checks the relation between two types will take either of the two approach:- If the main check is
is_subtype_of
, the logic that exists currently will remain as is - If the main check is
is_gradual_equivalent_to
, if both types are fully static then call intoType::is_subtype_of
otherwise useType::is_gradual_equivalent_to
- If the main check is
Both (1) and (2) above would be represented using a two variant enum parameter that I talked about earlier.