Type inference with JSDoc, @template and curried functions

[RedGlow]

Issue Type: Bug

(I'm not completely sure this is the right place to report this bug, so point me to the correct place in case)

Let's take this JavaScript code:

/**
 * @template T
 * @param {T} a 
 * @returns {(b: T) => T}
 */
const curriedFunction = a => b => b;

const text1 = "hello";
const text2 = "Mattia";

const text3 = curriedFunction(text1)(text2);

The types that VSCode infers are:

const curriedFunction: <T>(a: T) => (b: T) => T
const text1: "hello"
const text2: "Mattia"
const text3: T

All types are correct expect for text3. In fact, if I look at the type instantiation for the curriedFunction call, I get this:

const curriedFunction: <string>(a: string) => (b: T) => T

Now, it seems to me that the first T instantiation is correctly bound to string, but then the return value doesn't get its T bound to the same template variable. Am I missing something, or this is the type that I should get?

const curriedFunction: <string>(a: string) => (b: string) => string

VS Code version: Code 1.41.1 (26076a4de974ead31f97692a0d32f90d735645c0, 2019-12-18T14:58:56.166Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (4 x 2904)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: enabled rasterization: enabled skia_renderer: disabled_off surface_control: disabled_off surface_synchronization: enabled_on video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	31.83GB (17.31GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (5)

Extension	Author (truncated)	Version
npm-intellisense	chr	1.3.0
gitlens	eam	10.2.0
vscode-npm-script	eg2	0.3.10
prettier-vscode	esb	3.18.0
vscode-import-cost	wix	2.12.0

[DanielRosenwasser]

Looks like T isn't getting instantiated properly!

[IllusionMH]

TBH @templates are not part of JSDoc by itself and proposed code is not valid in Closure Compiler (at least online version in Advanced mode will show an error).

To achieve proper checks in your case you'll need 2 generic types which AFAIK not possible with @templates syntax.
Even with T instantiated for nested function it still behaves strange in JS

If you rely on TS checks only (because it's not valid CC code) you can utilize separate .d.ts file.

helpers.d.ts

type Nested<T> = (b: T) => T;

export type Curried = <T>(a: T) => Nested<T>;

index.js

/** @type {import('./helpers').Curried} */
const curriedFunction = a => b => b;

const text1 = "hello";
const text2 = "Mattia";

const text3 = curriedFunction(text1)(text2);

const correctError = curriedFunction(text1)(123);

---

I'm really curious if it's possible to achieve with JSDoc only and/or with one generic function, but in our case we had to use .d.ts for similar tasks.

[sandersn]

This has been a bug for a long time. Moving to 3.9.