Repository navigation
Unable to create a function wrapper #54569
Description
Bug Report
🔎 Search Terms
2556, tuple, union
🕗 Version & Regression Information
n/a
⏯ Playground Link
Playground link with relevant code
💻 Code
class Test {
one(s: string): void {s}
two(n: number): boolean {return n > 100}
ten(k: CryptoKey, w: Window): Document {k; return w.document}
}
const test = new Test()
export function run<Name extends keyof Test, Args extends Parameters<Test[Name]>>(name: Name, ...args: Args): void {
const fn = test[name]
fn(...args)
}
run('one', '')
run('two', 123)
run('ten', null, window)🙁 Actual behavior
TypeScript shows an error about the spread argument.
I've seen a bunch of similar issues, however I left unsatisfied with them. My specific concerns are these:
- Okay, so how do I create a wrapper function that preserves the static analysis?
- apply doesn't work as well, with a different error.
- Despite the error, TS seems to actually understand me and check the arguments of the wrapped functions, in particular:
- I can't call
run('five') - I can't call
run('one') - I can't call
run('one', 123) - I can't call
run('ten', null, window)as demonstrated in the last line
- TS doesn't provide any facilities to ignore this particular error that I know is irrelevant to me.
I'm left with no options, and I think this deserves an issue.
🙂 Expected behavior
TypeScript doesn't show an error.
Activity
fatcerberus commentedon Jun 8, 2023
Okay so the problem here is that
Name extends keyof Testcan be a union of keys - in which casenameandargscan be mismatched1, so TS is warning you that the call is unsafe for that reason.You really need #27808 to deal with this properly. Short of that, you’ll just have to ts-ignore the error.
Footnotes
Put more generally, it is not safe to call a union of function types with a union of their parameter types. ↩
stronny commentedon Jun 8, 2023
Nevertheless it does typecheck the calls correctly, so everything works exactly as I expect it to, except the error message.
fatcerberus commentedon Jun 8, 2023
Yes, but this call also typechecks:
…which therefore makes the inner call to
fnunsafe. Hence the error message.jcalz commentedon Jun 8, 2023
I'd say #47109 is the current way to express this sort of thing:
Playground link to code
Could you elaborate? On the face of it it looks false: TS provides type assertions, the
anytype, and the//@ts-ignoredirective, each of which could be used to prevent your code from complaining. I'm not recommending you use any of those, but I'm wondering why they don't count as "facilities to ignore" your error.stronny commentedon Jun 8, 2023
I'm afraid I don't understand what is unsafe here. It correctly points out that you can't run one with a number.
I am once again finding myself at the bottom of the confidence curve. Hats off, this seems to check out.
Which one of these can tell TS to ignore this particular error and nothing else, again?
@ts-ignoreignores the whole line, so other errors can slip in. I run strict, so anyanyis an error in itself. I tried to assert the type of...args, but came back empty-handed too.fatcerberus commentedon Jun 8, 2023
It does not: See Playground
Joe Calzaretta (@jcalz) Worth noting that your solution suffers from the exact same unsoundness as shown here, despite removing the error in the implementation. This pattern really does beg for
oneofconstraints.stronny commentedon Jun 8, 2023
I see the problem now. Strange how
run('one', 123)gives an error, butrun('one' as keyof Test, 123)doesn't, despite the same type being declared in the function argument. My TS knowledge is not enough to reason about what's going on at this point.As it's my own code, this solution still seems perfectly safe for my particular use case.
fatcerberus commentedon Jun 8, 2023
In the first case,
nameis typed as"one"; in the second case it's typed askeyof Test. That's the difference.By giving a union of keys for
Name, you get a union of function types forTest[Name]. Then, becauseParametersis distributive, it resolves to a union of those functions' parameter types. TS doesn't understand that these unions are all supposed to correlated (there's a separate issue about that, fwiw). By passing a string literal directly, it infers a string literal type forNameinstead of justkeyof Test, TS then knows exactly which functionTest[Name]refers to, and you get your nice type checking on the call.stronny commentedon Jun 8, 2023
That actually makes sense. Thank you.
I suppose I should go ahead and close the issue now.
jcalz commentedon Jun 8, 2023
Yeah, see #48730