Dad, self-employed, problem solver at heart, async all the way. Formerly a principal software engineer at Nuance Communications. Occasionally I tweet, blog and answer my own StackOverflow questions.
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().
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
Dad, self-employed, problem solver at heart, async all the way. Formerly a principal software engineer at Nuance Communications. Occasionally I tweet, blog and answer my own StackOverflow questions.
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:
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 ifawait
was aware of it, to save a few implicit allocations otherwise incurred by awaiting viaobj.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))
, whenthen
isn't enough and I need a promise - e.g., for use withPromise.race()
.It'd also help to if I need the promise itself
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 usePromise.resolve(thenable)
rather than spreading args with yournew 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:
It never occurred to me I could use a
thenable
withPromise.resolve
andPromise.race
etc. Today I've learnt something new, thanks to you! It really does work:I could recommend this read on V8.dev: Faster async functions and promises.