TC39 Delegates
2026-06-01
plaintext logs
prev next
source on github
19:06
<bakkot>
ljharb: x = new Promise(()=>{}); Promise.try(() => x) === x // false was this discussed? seems like it would be nice if it were true, like if you'd done a try-catch with a Promise.resolve() in the non-throwy case, to avoid the extra allocation/microtask
19:07
<ljharb>
it wasn't discussed afaik, and i'd be fine with tightening that if possible
19:07
<ljharb>
since Promise.resolve offers that semantic it's kind of silly not to use it anywhere else we can
19:08
<bakkot>
yeah
19:08
<bakkot>
would clean up some code I'm writing, at least
19:08
<bakkot>
I bet we could get away with changing that still, it's relatively new
19:10
<bakkot>

the MDN description of the problem statement certainly makes it sound like it ought to work that way:

You may have an API that takes a callback. The callback may be synchronous or asynchronous. You want to handle everything uniformly by wrapping the result in a promise. The most straightforward way might be Promise.resolve(func()). The problem is that if func() synchronously throws an error, this error would not be caught and turned into a rejected promise.

(but then goes on to give the actual semantics)

19:31
<bakkot>
I guess if we got https://github.com/tc39/proposal-faster-promise-adoption I might not care; I don't actually care about identity per se, just that I don't have to wait an extra tick in the happy path