Promise construct signature allows resolving without a value

[Arnavion]

The current construct signature for Promise in es6.d.ts is this:

new <T>(executor: (resolve: (value?: T | PromiseLike<T>) => void, reject: (reason?: any) => void) => void): Promise<T>;

I would like all of these to definitely compile:

new Promise(resolve => resolve()); // (1)
new Promise<void>(resolve => resolve(null)); // (2)
new Promise<number>(resolve => resolve(5)); // (3)

... these to maybe compile:

new Promise<void>(resolve => resolve()); // (4)
new Promise(resolve => resolve(5)); // (5), and also inferred as Promise<number>

... and this to not compile:

new Promise<number>(resolve => resolve()); // (6)

Currently all of these compile, including (6), although (5) is inferred as Promise<{}>

Changing value to required makes (6) not compile, but also breaks (1) and (4). By then adding one more overload:

new (executor: (resolve: () => void, reject: (reason?: any) => void) => void): Promise<void>;
new <T>(executor: (resolve: (value: T | PromiseLike<T>) => void, reject: (reason?: any) => void) => void): Promise<T>;

(1) to (3) will continue compiling, and (4) to (6) will stop compiling. Since (5) was not being inferred correctly anyway, I think it's okay that it won't compile. Losing (4) is perhaps the bigger problem, since it will break existing code that uses it.

---

PromiseConstructor.resolve already does this - it has one overload with no type parameter and no parameter that returns Promise<void>, and one with a type parameter and a required parameter that returns Promise<T>. I seem to remember Promise's construct signature also did used to do the same at one point (maybe back when it was in lib.d.ts?) which is why I was surprised to discover that it doesn't now.

[mhegazy]

Ron Buckton (@rbuckton) can you take a look.

[rbuckton]

This would not be maintainable if we plan to migrate Promise to an ambient class declaration.

[Arnavion]

In that case you can do just the first change (make value required) with the corresponding consequences. new Promise<void>(resolve => resolve()) would need to be new Promise<void>(resolve => resolve(null)). If you're going to make it a class then (1) will be broken anyway.

As it stands new Promise<number>(resolve => resolve()) compiles which is not good, and is also inconsistent with Promise.resolve()

[poelstra]

We've ran into this multiple times too (not just with Promises, but other generic classes as well).

I've been thinking whether it might make sense for the compiler to allow any 'trailing void parameters' to be ommitted (or maybe only when they were defined as a generic type) by marking them as optional automatically.

Example:

function foo<T>(a: number, b: T): void {}

foo<number>(42, 3); // foo(a: number, b: number)
foo<void>(42); // foo(a: number, b?: void)
foo<number>(42); // error, because b is not made optional

Arnav Singh (@Arnavion) I agree that making it required instead of accidentally allowing it to be forgotten for non-void makes sense. Note that it would not be resolve(null), but resolve(undefined) (or resolve(void 0)), though.

[Arnavion]

(null is also assignable to the void type so I wrote it for convenience, but sure.)

[danquirk]

I think we're going to just dupe this against #4260 since there's a proposed solution there but we should keep all the cases here in mind when discussing it further. If you think there's something unique here that isn't captured in that discussion we can reopen this.

[Arnavion]

Dan Quirk (@danquirk) Sure, but after you did #4260, you'd still need to make the value parameter here required to prevent (6) from compiling.

[Arnavion]

(To be clear, I'm saying this isn't a duplicate.)

[Ivanca]

Arnav Singh (@Arnavion) Dan Quirk (@danquirk) One year later and case 6 is still allowed to compile, meaning:

new Promise<number>(resolve => resolve()); // (6)

When it clearly should not.

[rbuckton]

It is perfectly legal to write:

let x: number; 
print(x); // undefined

function f(): number {
 return;
}
print(f()); // undefined

Except, of course, under strictNullChecks.