TC39 General
2022-05-12
plaintext logs
prev next
source on github
00:00
<Justin Ridgewell>
Eg, for a proxied promise, you want to wait to adopt the thenable into your native promise
00:00
<Justin Ridgewell>
It seems the goal isn't determine whether a promise is safe, it's to safely cast it to a native promise
00:01
<Justin Ridgewell>
Why not just add that instead?
00:03
<Kris Kowal>
I do believe Promise.resolveSkepitcally(landmine) would be equally satisfying for the hardened JavaScript trade-offs.
00:03
<Mathieu Hofman>
"is safe promise" is a user land thing
00:04
<Justin Ridgewell>
Promise.safeResolve = (input) => {
  if (input.[[PromiseState]]) {
    // guaranteed to not be a proxy, so no GetOwnDesc traps
    const constructor = GetOwnPropertyDescriptor(input, 'constrcutor);
    const then = GetOwnPropertyDescriptor(input, 'then');
    if (constructor?.value === %Promise% && then?.value === %Promise.p.then%) {
      return input;
    }
  }
  return Promise.resolve().then(() => input);
};
00:05
<Justin Ridgewell>
Now, given that Promise.resolve already isn't safe and there's some need for Promise.safeResolve, can we make the then call sync?
00:05
<Mathieu Hofman>
But yes, a "safeResolve" would work as well
00:06
<Justin Ridgewell>
The Promise.safeResolve would protect you from the sync then, and we could make regular code using Promise.resolve/then-return-value/Promise-constructor-executor-resolve/direct-return-async-fn faster
00:08
<Mathieu Hofman>
I do consider my inquiry orthogonal to the "call then sync" question. I am not concerned regarding safety on that since we established it's already unsafe. My concern on that is what was raised on github, that at this point people do expect a thenable to be called in a new tick.
00:09
<Mathieu Hofman>
I'm ok with fast-tracking native promises, but I'm skeptical about calling random then synchronously
00:11
<Justin Ridgewell>

that at this point people do expect a thenable to be called in a new tick

I'm hopeful that there are very few programs that need this

00:12
<Justin Ridgewell>
Or that there's some other way to fix those programs
00:13
<Justin Ridgewell>
Eg, your async_hooks example is looking for then being used to adopt state, but that could be an async_hook itself.
00:14
<Mathieu Hofman>
Yes and I would very much prefer it to be a first class hook
00:16
<Mathieu Hofman>
I'm just not sure trying to reduce the ticks of non-native-promise thenables is worth the risk of breakage