-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Contextual typing interferes with type argument inference #33738
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
Here's a simpler repro that gives some clues as to what is going on: type I<K extends string> = { p: string } & Record<K, number>;
type Thusly<Data, K extends string> =
ThisType<Data & I<K>> & {
data?: (this: I<K>) => void,
watch?: { [s: string]: (val: any) => void }
}
declare function test<K extends string = never>(options?: Thusly<unknown, K>): void;
declare function test(options?: never): void
test({
data () {},
watch: {
m (value: boolean) {
var x: never
var x = this.p
}
}
}) In the error case, Also, the error only reproduces if some type (I haven't figured out which one yet) is not a subtype of The error is entirely down to the result of inference; using So I think this can be broken down into two problems:
For (2), I think the current behaviour is correct, actually. That means a smaller repro for (1) is this: type I<K extends string> = { p: string } & Record<K, number>;
type Thusly<Data, K extends string> =
ThisType<Data & I<K>> & {
data?: (this: I<K>) => void,
watch?: { [s: string]: (val: any) => void }
}
declare function test<K extends string = never>(options?: Thusly<unknown, K>): K;
declare function test(options?: never): void;
var bad: "p"
var bad = test({
data () {},
watch: {
m (value: boolean) {}
}
})
var good: never
var good = test({
data () {},
watch: {
m () {}
}
}) Right now I guess that this repro needs
(2) might actually be something to do with assignability, and (3) might be something to do with intersections in |
Briefly, I can get rid of type I<K extends string> = { p: string } & Record<K, number>;
type Thusly<Data, K extends string> = {
data: (x: Data & I<K>) => void,
watch: { [s: string]: (val: any) => void }
}
declare function test<K extends string = never>(options?: Thusly<unknown, K>): K;
declare function test(options?: never): void;
var bad: "p"
var bad = test({
data (x) {},
watch: {
m (value: boolean) {}
}
})
var good: never
var good = test({
data (x) {},
watch: {
m () {}
}
}) So there doesn't appear to be this-type inference here; just contextual typing interfering with type inference. |
Works on 2.3 - 3.5 — although after sleeping on it, I think that the inference from I'll bisect 3.5 – 3.6 to see which PR broke things. |
The break happens at #32558. However, I believe the I'm going to put this in the backlog since I think it's low priority. @ahejlsberg you might be interested in this, especially if I've mis-diagnosed the role of contextual typing. |
It's |
TypeScript Version: 3.6.3, 3.7.0-beta
Search Terms: inference, wrong, type parameter
Code
Expected behavior:
this.test
intestWatch
is of typestring
.Actual behavior:
this.test
intestWatch
is of typeany
.Looks like
Instance
keys are used asPropNames
and they override actual instance type.Note that if I do either following things, it behaves as expected:
value
´s type annotation.this
type ofDataDef
callback.test
function.Playground Link:
http://www.typescriptlang.org/play/#code/JYOwLgpgTgZghgYwgAgJIgM5jiJyDeAUMspFgFzJZSgDmhAvoYWAJ4AOKAInNlxDAA8PbABpkABSgB7dhgB8yALzIRcZAB9kACm1gAFsAyUAShDgATaSAA2rQVNkLkAMjSZsuCAEplitd7MEAAe7NJQYKQcKAAqhhgx0RYAwtIAtmEgEOAA8uxgwNYYAOrABgCCUFBwrI5ywrxw4nUAcnBpEBjIIZAgFl3UdIpKxMjSAEYAVhAIkS6jqRnW2WB5BUUNfAKbTchmCOEWDjLsbR0Y4jis8vLNJ2edANoAuorzJHFGiZyC6Fg4eDcalce3MVls9n2h2OsgeF2QVxu8gA3Mw2JxVAI4ABXGxgNSCABqwxIE2ms00Oj08UohN8SkUZJmYG8qPR3CxuLAdS6KihUCOgxAtEuIGuqJCYQiyFAkFgiBQi0yKzWhUwO2UmPgXIJf08SFukhOGH4ME1PNNoDKauEnLxPJuBFG7GNAH5KBaBKiSBZGu7VI1vcgAO68BD6f38wVgGjC8TFMP6AASOAsNmggkRKMYQVC4Ui7OQlWqtWNlpA1usghiJO0AGsIKxpGaYt4XhK89LC56YFb1iBqyTizUe32bTXUYRJfmohiE2Bwym+umoIPNdoAG5wGyUGLiaQ2CyE7e7+mKDfSYAWScWGY2OBQFAwbG4fukTpgHZ3WHtTrdYK9P0VAxnQmpZBu0DyNosj9hg-qfAkSRKssuT5GqJRlPow6lk4X5Gj+5zyN4lAXleqK3gg96Psgz6vmq75YNBaFFP64HQMRyCkRYaIftoRA+o0Oi+PxJDII+YDYlAIBOqJokwNI0iUDG2IQKMJBMOpoijKGC76JQIkkGQYDzuGOhbjYKmUOMCnpjgwlqaJBhGAAdEZyAAPTuQiYoORpyBMAwgTMEAA
Related Issues:
This is quite similar issue with #33164 but different as it can reproduce on v3.6.3 which the issue is already fixed.
The text was updated successfully, but these errors were encountered: