Mathieu Hofman

Arguably the following is still a sloppy mode footgun: ```js const r = #{ x: 1 }; const s = Symbol(); r[s] = 'foo'; ``` So while having `[[Set]]` disallow...

I guess my main issue is a conceptual one. If my package uses jsvu internally, it feels weird for it to rely on external files. One impact of that is...

This is not equivalent to the test proposed in #2910, right? This test seem to use the realm of the `then` function of the thenable to create the `onResolve` /...

So one thing I still don't understand is why isn't the realm of `Promise.prototype.then` or of `Promise.resolve` used to create the callback? In which cases is it unavailable such that...

Thanks for the links, still going through them. From a quick read, this sound like an HTML specific decision to not process enqueued promise jobs under some circumstances, which ends...

Right, dynamic scoping is a security issue, and I don't see how the current approach satisfies that invariant. I wrote the following test: https://gist.github.com/mhofman/df7047ee89942038cbc4629c41b8c7e0 First, implementations seem inconsistent, so I...

> They're both using a realm that isn't the currently-invoked function's `blue` is the realm of the invoked function, hence why it's acceptable. > I'd be calling the thenable's `.then`...

From a conceptual point of view, I think JSC is closer to being correct, as it's the creator of the adopting promise which creates the callback function in its own...

My opinion derives from what a userland library implementing `Promise` would likely do if the only operation available was "EnqueueJob". The library in the adopting realm (`yellow`) would likely just...

The current thinking to avoid the purity conundrum is to have trusted code replace the `Proxy` constructor with a version that stamps proxy instances it creates (adds them to a...