-
Notifications
You must be signed in to change notification settings - Fork 12.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
Inference bug #3038
Comments
Simplifying this somewhat: function keyOf<T>(value: { key: T; }): T {
return undefined;
}
interface Data {
key: number;
}
var data: Data[] = [];
function toKeysNonGeneric(values: Data[], toKey: (value: Data) => string): Data {
return undefined;
}
toKeysNonGeneric(data, keyOf); Paging @JsonFreeman |
This actually behaves according to spec. We instantiate the generic |
I understand that inference can be really hard. What I don't understand is why instead of displaying an error message saying it that inference cannot be done, you decided to go a simpler way that somehow compiles making code unsound and leading to nasty bugs. Are there any plans to fix it? |
I think we are conflating some concepts here. The inference itself succeeds, as it should. In your example, number is the result of the inference. However, the assignability check succeeds unsoundly. As @ahejlsberg explained, the original reason for this unsoundness is indeed that historically, checking this in a sound way led to an infinite recursion. But we have a new way of dealing with infinite recursion that would be resilient to this sound way of checking signatures. So in theory, we could check this in a way that would fail, using contextual signature instantiation. |
@JsonFreeman, so now that you say you have that new way round that infinite recursion problem, do you think we should reopen this issue or the other related one that got closed too #3055? not sure what it means when you guys close valid issue reports |
In the past, when we had this behavior, we found that many people were confused by it, and it disallowed lots of code that seemed reasonable even though the code was technically not sound. Also, generic signatures that are part of generic types do lead to this deep recursion, and even though we have a way of limiting the depth of the recursion, it would still deepen the assignability checks drastically and make assignability checks take much longer. So while there are no longer technical limitations in the way, fixing this would seem to hamper most users' experiences more than it would benefit them. |
Is there a reason (besides budget) for not having an option to instruct the compiler to do thorough checks? |
I'd say this falls into the category of checks explored by #274. @RyanCavanaugh, is that issue a good meter for the popularity of a "stricter" mode? |
@Aleksey-Bykov Feel free to add a comment in that issue with a small description or link to this issue as far as an additional check. |
gentlemen, how come the following work? export function keyOf<a>(value: { key: a; }): a {
return value.key;
}
export interface Data {
key: number;
value: Date;
}
var data: Data[] = [];
export function toKeys<a>(values: a[], toKey: (value: a) => string): string[] {
return undefined;
}
// BEFORE: toKeys(data, keyOf);
// AFTER:
toKeys(data, x => keyOf(x)); // <-- fails as expected |
will there be an infinite recursion still if TS replaces point free notation |
This happens for the same reason discussed above. The I agree this is not intuitive. Again, I think this qualifies as a good feature for stricter type checking, though arguably it should be part of the basic type check mode as well. |
@JsonFreeman I vote with two hands for the stricter type checking mode. As far as I know, non strict type checking in TypeScript was one of the reason why Facebook/Flow was created. |
Fixed in #30215. |
Reproduced at playground: http://www.typescriptlang.org/Playground#src=export%20function%20keyOf%3Ca%3E(value%3A%20%7B%20key%3A%20a%3B%20%7D)%3A%20a%20%7B%0A%09return%20value.key%3B%0A%7D%0Aexport%20interface%20Data%20%7B%0A%09key%3A%20number%3B%0A%09value%3A%20Date%3B%0A%7D%0A%0Avar%20data%3A%20Data%5B%5D%20%3D%20%5B%5D%3B%0A%0Aexport%20function%20toKeys%3Ca%3E(values%3A%20a%5B%5D%2C%20toKey%3A%20(value%3A%20a)%20%3D%3E%20string)%3A%20string%5B%5D%20%7B%0A%09return%20undefined%3B%0A%7D%0A%0AtoKeys(data%2C%20keyOf)%3B%20%2F%2F%20%3C--%20expected%20compile%20error%2C%20since%20keyOf%20should%20have%20inferred%20a%20as%20%60number%60%20rather%20than%20%60string%60%0A
The text was updated successfully, but these errors were encountered: