Add note about the checker's type relations #5
Conversation
| y = x; // Error: Type 'number' is not assignable to type 'string'. | ||
| ``` | ||
|
|
||
| When computing the type of an array literal from the types of its elements, we use a different relation: **strict subtyping**. To compute the type of an array literal, we need to compare the type of each array element to one another, removing the types that are a subtype of another element type. To do this comparison between array element types, we use the strict subtyping relation, as seen in the following example: |
There was a problem hiding this comment.
It's not just about arrays - it's about subtype reduction. I think we do that during inference too.
|
|
||
| When doing overload resolution, we try to match the argument type (`any`) to the parameter type of each overload signature using the subtype relation. Because `any` is not a subtype of `string` or `number`, we pick the last signature. If we used the assignability relation, we'd go match an `any` argument with the parameter type `string` on the first `myFunc` signature, and it would match, because `any` is assignable to `string`. | ||
|
|
||
| > **_Note:_** something that can be confusing is how `any` has a different behavior depending on the relation being used to compare it, and how it differs from `unknown`. Basically, `any` is special because it is assignable to every type, but `any` is not a subtype of every type. And every type is assignable to `any`, and every type is a subtype of `any`. So `any` has this special behavior during assignability where it is assignable to **any**thing. |
There was a problem hiding this comment.
If you style it like
> **Note**: something that can be confusing...it'll render like
Note: something that can be confusing...
| Another usage of identity is in inference. When inferring from one type into another, we get rid of the parts of both types that are identical. For example, when inferring from one union to another union, e.g. from `boolean | string | number` to `T | string | number`, we get rid of the identical types on both sides (`string` and `number`) to end up inferring from `boolean` into `T`. | ||
| Yet another example is when checking assignability of two instantiations of the same invariant generic type: two instantiations are still related if their type arguments is identical. | ||
|
|
||
| > **_Implementation note:_** Most of the times, identity is used for object types, and we try to make it quick to check that by interning that information. |
There was a problem hiding this comment.
I don't know if identity is special in this regard. We do a fast equality check and cache object types for every type relationship.
|
I don't know if you want to bother with this, but the archived spec tried to highlight some of the specific differences among the type relationships. |
|
|
||
| We use those relations for different things in the checker, and in general we have all those different relations because sometimes we wanna be more strict, and sometimes we don't. | ||
|
|
||
| We use **assignability** to check if an argument can be passed to a function, or if an expression can be assigned to a variable: |
There was a problem hiding this comment.
This is true - but we use assignability for almost everything. Even for overriding types.
interface Base<T> {
value: { prop?: T };
}
interface Derived<T> extends Base<T> {
value: {};
}
There was a problem hiding this comment.
I think this is fine as-is. Consider some of the feedback I brought up, and make the examples more explicitly examples. Use the words "for example" or "for instance" to signal that subtype reduction is not specific to coming up with a best type for arrays, but it is useful
Also, I think you might want to at least briefly mention things like type narrowing where we use a combination of the relationships, and what happens when we don't use certain type relationships. You might be familiar with some examples of this based on recent design meetings, where narrowing introduces a mutual subtype, which is undesirable when joining types from multiple control-flow antecedents, and it's better to leverage strict subtypes when possible.
No description provided.