Search Terms
tsserver, server, infer, argument help
Suggestion
Get a better argument description when accessing the argument help of an inferred argument list.
When accessing the argument information for the following code (Playground), both vscode and the playground only show fun2(...args: [number, string]): string:
type Parameters<T> = T extends (...args: infer U) => any ? U : never;
declare function fun1(x: number, y: string): number;
declare function fun2(...args: Parameters<typeof fun1>): string;
fun2(/* get parameter help here */);
fun2(10, "text");
/* ^ hover here */
It'd be a lot more intuitive, if the help would resemble the actual parameters.
When hovering over fun2 in the playground, it even shows the more readable information fun2(x: number, y: string): number, so this might be an easy improvement.
Use Cases
Even though the current display is perfectly valid, it makes it hard to understand what the parameters were meant for, so the only use case for this would be readability/UX.
Related Issues
Not exactly a duplicate of #26132 (which seems fixed in 3.1.0-dev.20180818), but also not a totally different one. If you consider this feature request a duplicate, feel free to close it.
Checklist
My suggestion meets these guidelines:
Search Terms
tsserver, server, infer, argument help
Suggestion
Get a better argument description when accessing the argument help of an inferred argument list.
When accessing the argument information for the following code (Playground), both vscode and the playground only show
fun2(...args: [number, string]): string:It'd be a lot more intuitive, if the help would resemble the actual parameters.
When hovering over
fun2in the playground, it even shows the more readable informationfun2(x: number, y: string): number, so this might be an easy improvement.Use Cases
Even though the current display is perfectly valid, it makes it hard to understand what the parameters were meant for, so the only use case for this would be readability/UX.
Related Issues
Not exactly a duplicate of #26132 (which seems fixed in 3.1.0-dev.20180818), but also not a totally different one. If you consider this feature request a duplicate, feel free to close it.
Checklist
My suggestion meets these guidelines: