Consider making the value argument of promises optional.

[jespertheend]

I frequently pass in the promise callback argument into other functions that don't intend on providing any arguments in the callback function. For example:

async function doSomething() {
  // do something...
  await new Promise(r => setTimeout(r, 1000));
  // do something else...
}

admittedly this is a bit of a bad example, because setTimeout actually does provide an argument in its callback.
But consider the following:

function fireCallback(cb: () => void) {
    cb();
}

await new Promise(r => fireCallback(r));
//                                 ^^^------Argument of type '(value: unknown) => void'
//                                 is not assignable to parameter of type '() => void'.

^{playground link}

Passing in r in fireCallback gives an error because the promise expects r to be called with a value, even though this is perfectly valid in JavaScript. The promise will simply resolve with undefined.

One way to work around this is by simply doing new Promise<void>(r => fireCallback(r)), but this isn't possible when working with JavaScript in strict mode. So the workaround ends up looking more like this:

/** @type {Promise<void>} */
const promise = new Promise(r => fireCb(r));
await promise;

^{playground link}

which is really verbose and tedious to write.

The PromiseConstructor is currently defined as

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

making value: optional like so:

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

solves this issue, but I'm not sure if it might break anything else.

[MartinJohns]

making value: optional like so:

T does not include undefined, and you call resolve without an argument, then you get an invalid value.

[yume-chan]

1. Promise is part of JavaScript, not DOM, so this is not the right issue tracker.
2. the first argument of resolve is actually deliberately changed to be non-optional in TypeScript 4.1 (https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/#resolves-parameters-are-no-longer-optional-in-promises) to prevent people from forgetting the argument.
3. I think the type inference should be improved, when you write new Promise(r => setTimeout(r), 1000), the T in Promise should be whatever setTimeout will pass to it (or void if no argument given), if no better type can be inferred.

[jespertheend]

Promise is part of JavaScript, not DOM, so this is not the right issue tracker.

Ah sorry about that, is the TypeScript repository the correct place for this?

[orta]

It is, yes, but given the switch is pretty recent and release notes worthy (with some good arguments for why) I don't think the request is going to get too far.

[jespertheend]

Yeah me neither, I'll mostly aim for point 3 in #1333 (comment)
My main issue is that

/** @type {Promise<void>} */
const promise = new Promise(r => fireCb(r));
await promise;

is tedious to type.

[jespertheend]

I've submitted microsoft/TypeScript#49390