Discussion on: Would it make sense to have "Symbol.promise" as standard JavaScript Symbol?

[Andrew Nosenko]

I actually wasn't aware of the binding proposal, thanks for pointing it out! It'd be great if it makes to the final stage soon.
I still think Symbol.promise would make sense if await was aware of it, to save a few implicit allocations otherwise incurred by awaiting via obj.then. Also, having a direct access to the object's default promise might save me from doing something like this: new Promise((...a) => obj.then(...a)), when then isn't enough and I need a promise - e.g., for use with Promise.race().

It'd also help to if I need the promise itself

[Ash]

I don't know enough about the mechanics and overhead of await to comment on that.

In the Promise.race case, it seems to handle primitives and thenables directly, so there may not be any need to wrap as a 'real promise'.

Reading up on Promise.resolve - is there a reason you can't use Promise.resolve(thenable) rather than spreading args with your new Promise idiom?

I find the Promise part of the EcmaScript spec really hard to read, so refer to the comments against Promise.resolve on MDN:

If the value is a thenable (i.e. has a then method), the returned promise will "follow" that thenable, adopting its eventual state; otherwise, the returned promise will be fulfilled with the value

[Andrew Nosenko]

It never occurred to me I could use a thenable with Promise.resolve and Promise.race etc. Today I've learnt something new, thanks to you! It really does work:

export {}

class Thenable {
  #promise;

  constructor(ms) {
    this.#promise = new Promise(r => setTimeout(r, ms)); 
  }

  then(...a) { return this.#promise.then(...a); }
}

await Promise.resolve(new Thenable(2000));

await Promise.race([new Thenable(2000)]);

I don't know enough about the mechanics and overhead of await to comment on that.

I could recommend this read on V8.dev: Faster async functions and promises.