-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Analysis of multiple-use generic type parameters on DefinitelyTyped #19596
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
Comments
/cc @ahejlsberg @mhegazy |
I'm strictly against that. To the contrary, I've filed #16107 to fix function inference. Notice, that when the inferencer is strict, it's easy to make it more loose by providing a type annotation. However, when it's loose from the get-go, virtually every generic reference needs a fix. The latter also makes many safety and type-level programming patterns no longer possible. Another ramification of this suggestion is that any two types should become equitable. declare operator ===<T>(left: T, right: T): boolean;
"hello" === 7; // now an error, should be OK with the proposed logic
// with T = string | number |
I'd be okay with it as long as it's something statically differentiable from normal generic parameters, it's something I can still specify explicitly if needed, and of course, if the type inference algorithm was improved substantially (so the type names are much less common). I'd rather not run into confusion over whether |
This will have the effect of having to put type guards in a lot of places, places where I wouldn't have needed it in pure JS, b/c I "know" the types myself. Either that or resort to casts.. I use TypeScript to check that my code is sane and sound and give me errors if not.. not to accept whatever I'm writing and tell me what the result would be. And I expect TypeScript to report the error where it is most likely happening.
I would expect TypeScript to report an error here and not even having to run the test. |
I think a challenge with getting acceptance for this is that many users interpret generics in TypeScript in very different ways. I'd say there are roughly three different ways generics are interpreted in TypeScript:
Those that use generics in style 1 and 2 should be fine with this, those that use generics in style 3 are probably against - it might break assumptions in their programs. For instance, in the Looking at the examples selected from DefinitelyTyped, I think a significant number fall into category 3. If you were to interpret those functions in a parametric way, most would be useless constant functions, so there must be some hidden constraints associated with the signatures. I'd be concerned that changing the inference mechanism by default might allow people to call those functions in ways that violate the hidden constraints. As suggested it would probably please more people if it was a separate mechanism, disabled by default. The default behavior would guarantee that inference would always ensure that two values of generic type |
@RyanCavanaugh What was this closed in response to? Just curious because the issue isn't showing me any leads here. |
Background: We're considering synthesizing union types during generic type inference, same as we do for functions:
This would likely need to be paired with some sort of syntax for making this not happen in cases like
What follows is a sorting of all the cases I could find on DefinitelyTyped where a type parameter was declared and used in more than one position
T
and Lower-priorityT
In these cases, two or more uses appear, but there is only one
T
at any given "level" of inference. These functions would be mostly unchanged under a hypothetical union type inference world.Promises...
Just putting this in its own bucket because 😠
Equal-weight
T
These use the same type parameter in at least two positions of equal weight in the inference process
The text was updated successfully, but these errors were encountered: