Readd AsyncContext.Snapshot.wrap() helper

[jridgewell]

Based on some feedback, it's useful to have a dedicated helper when only a single function needs to be wrapped. Having to create a Snapshot and return a new (...args) => snapshot.run(fn, ...args) is a little too cumbersome.

This should be very helpful while library support is still being implemented in the ecosystem. This allows consumers of unsupported libraries to quickly wrap callbacks they pass to the library.

[andreubotella]

While looking at the test262 tests for Function.prototype.bind, I noticed that GetFunctionRealm is special-cased for bound function exotic objects. This patch would need to either modify that AO similarly, or add a [[Realm]] internal slot to AsyncContext wrapped function exotic objects.

[jridgewell]

Done.

[shicks]

This is a little nitpicky, but would it be possible to put this directly onto AsyncContext? I imagine the most common usage will look something like

callback = AsyncContext?.Snapshot?.wrap(callback) ?? callback;

with the second ?. being defensive around some other non-conformant AsyncContext existing. We could do away with the extra optional chaining entirely if this were defined up a level.

[littledan]

Why would someone want to be defensive against a non-conformant AsyncContext implementation? I would imagine this more like,

callback = typeof AsyncContext === "object" ? AsyncContext.Snapshot.wrap(callback) : callback

[jridgewell]

I'm OK with either position, but I definitely don't think a second ?. should be encouraged. I also kinda imagine using a utility function that would isolate this from most consumer code:

const wrap = (cb) => AsyncContext?.Snapshot.wrap(cb) ?? cb;


class Foo {
  test() {
    const cb = wrap(() => …);
  }
}

[shicks]

I don't feel strongly.

[legendecas]

AsyncContext.wrap would be ambiguous since a function can also be wrapped with AsyncContext.Variable.prototype.run. I would find AsyncContext.Snapshot.wrap be more explicit that a function is wrapped with a snapshot.

[jridgewell]

AsyncContext.wrap would be ambiguous since a function can also be wrapped with AsyncContext.Variable.prototype.run

Re: #25

I would find AsyncContext.Snapshot.wrap be more explicit that a function is wrapped with a snapshot.

Let's keep as is then.

[legendecas]

ecmarkup v18.2.0 is released but there are several unrelated errors to this PR if upgraded. Fixing in #72