TC39 Async Context on 2023-03-13

11:04	<Andreu Botella>	Aren't the snapshot requirements on `HostMakeJobCallback` and `HostCallJobCallback` a bit too loose?
11:05	<Andreu Botella>	we don't want hosts to populate `[[AsyncContextSnapshot]]` with any snapshot whatsoever
11:42	<Andreu Botella>	I opened https://github.com/tc39/proposal-async-context/pull/31 to tighten those requirements
11:52	<littledan>	I opened https://github.com/tc39/proposal-async-context/pull/31 to tighten those requirements This PR LGTM but I think we should really refactor the PR to make abstract operations for run and get. Then, this PR would say, the AsyncContext must be created by run
11:52	<littledan>	(This implies a tighter host limitation, otherwise hosts could do anything run does)
11:52	<littledan>	I would also mention JS-implemented scheduling and, delete the last bullet point (access limitation) as I think a lot of people will be skeptical of it and it will throw off the discussion
11:52	<littledan>	Sorry I didn’t review Andreu’s PR earlier. Let’s avoid the term “asynchronous callstack” as it is confusing and misleading (doesn’t make it clear that run has to be explicit). Instead, we are talking about the asynchronous flow of control.
11:58	<littledan>	Also would be good if the spec had a sort of introduction that linked to the readme
11:58	<littledan>	Maybe it should begin with the definition of the AsyncContext class and then go into how it works
11:58	<littledan>	(Again, apologies for the delayed review )
12:14	<Andreu Botella>	Huh, it looks like `Atomics.waitAsync`'s `HostResolveInAgent` leaves everything to the host, rather than using `HostMakeJobCallback` and `HostCallJobCallback`
12:15	<Andreu Botella>	should it be up to the host whether the callback gets wrapped there?
12:17	<littledan>	Let’s leave any proposed refactorings there for later (since we will learn what html wants as this proposal evolves, and no need to duplicate the debate)
12:18	<Andreu Botella>	sure
12:18	<littledan>	We can just note that this state of the spec might mean that TC39 might not hold us to a very meaningful layering
12:18	<Andreu Botella>	I just have been learning a bit about low-level concurrency and was trying to make sense of the atomics and memory model parts of the spec, and I noticed this slightly intersected with AsyncContext
12:19	<littledan>	Hopefully the layering can be expressed more by the structure of the spec and less by requirements
12:19	<littledan>	Requirements end up being really unclear
12:25	<littledan>	It is great that you noticed this connection btw, even if it is not actionable right now
14:10	<Andreu Botella>	the way the spec is written right now, `AsyncContext.wrap` doesn't check if the argument is a function, but it does check if it's a constructor
14:11	<Andreu Botella>	in order to figure out whether to make the wrapped function a constructor or not
14:11	<Andreu Botella>	do we want this behavior?
14:12	<Andreu Botella>	also, `AsyncContextWrappedFunctionCreate` is defined to take a function object as its first argument, which isn't the case since `AsyncContext.wrap` doesn't check that
14:13	<littledan>	I guess we should eagerly check for callability, as this is what .bind does
14:13	<littledan>	btw if Function.prototype.bind doesn't work for class declarations (just old-style classes), does that mean its [[Construct]] behavior is thought of as "legacy"? In this case, should we not bother replicating it?
15:55	<rbuckton>	How does `Function.prototype.bind` not work? You can `new` the result, but you can't subclass it without fixing `.prototype` first: `class C {} let C1 = C.bind(null); new C1() instanceof C; // true class D extends C1 {} // TypeError: Class extends value does not have a valid prototype property C1.prototype; // undefined C1.prototype = C.prototype; class D1 extends C1 {} // ok`
18:48	<littledan>	oh well Function.prototype.bind throws on things which are not callable. I forgot about how classes are callable and they just throw.
19:01	<ljharb>	it's so baffling to me that the call/construct slots were basically made useless with things like that
19:08	<littledan>	yes, it makes me feel like it was a mistake to have a [[Construct]] hook in the first place
19:19	<ljharb>	i mean it'd be super useful to have both slots actually mean what they're called, but short of that having two is silly
19:51	<rbuckton>	I'd love for a "call constructor" to be valid in the language. It'll be possible to write a user-space `@Callable` decorator, I think, but you would have to replace the constructor with a regular `function` to do so. A native `@Callable` that does the same thing could just replace the `[[Construct]]` slot.
19:54	<rbuckton>	What's weird to me is that `class` has a `[[Call]]` that throws, but `() => {}` doesn't have a `[[Construct]]` at all (even one that throws).