-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
Breaking changes associated with Union Types #868
Comments
Added "Recommendations" to each section |
For the homogeneity constraint in type argument inference (the example with the Giraffe and Elephant), I do not see why we have to give an error if there is a constraint. Intuitively, if Giraffe and Elephant are candidates, we want to pick Animal if we have a feasible way to do so. All we would have to do is get the best common type for T, see that it fails, and then fall back to the constraint. We already do this if we successfully compute a BCT incompatible with the constraint, so why not on failure too? I looked into the Promises break, and it was never really working anyway. The old behavior was that the first call to |
For the first: the reason to give an error is more one about user expectations than what is technically possible. What are the type relationships that signature is trying to represent? To me it reads that the function expects 2 arguments of the same type which are both subtypes of Animal. So even if both are arguments are subtypes of Animal but of different types then an error is expected. If an Elephant and Giraffe were intended to work then the function would take a T and U both constrained by Animal. And yeah I looked at all the promises examples closely and essentially all of them were previously |
I am personally in favor of being gentler when there is a constraint. I think we can do so without losing correctness. That said, the philosophy you explained makes sense. |
This issue tracks the set of breaking changes that result from the change to union types #824 to implement the suggestion #805. The issues here will be formalized further once an official spec update is done, until then it will mostly serve as an easy reference for the type of coding patterns that have broken for various reasons.
Multiple Best Common Type Candidates
Given multiple viable candidates from a Best Common Type computation we now choose an item (depending on the compiler's implementation) rather than the first item.
This can happen in a variety of circumstances. A shared set of required properties and a disjoint set of other properties (optional or otherwise), empty types, compatible signature types (including generic and non-generic signatures when type parameters are stamped out with
any
).Recommendation
Provide a type annotation if you need a specific type to be chosen
Generic Type Inference
Using different types for multiple arguments of type T is now an error, even with constraints involved:
With constraints:
See #824 (comment) for explanation.
Recommendations
Specify an explicit type parameter if the mismatch was intentional:
or rewrite the function definition to specify that mismatches are OK:
Generic Rest Parameters
You cannot use hetergeneous argument types anymore:
Likewise for
new Array(...)
Recommendations
Declare a back-compat signature if the 1.0 behavior was desired:
Overload Resolution with Type Argument Inference
Recommendations
Manually specify a type parameter
Promises
This used to not have an error:
The text was updated successfully, but these errors were encountered: