honestly kinda like scala's _

At least wikipedia article also use ID as the abbr for identifier or identity ( https://en.wikipedia.org/wiki/Identifier )

at any rate i feel very strongly against "Id" but "identifier" or "code" seem fine to me

What are you talking about?

I think we should also keep the practice of starting every paragraph with the acronym, even if it's a continuation of the current speaker. To make it super clear that it is a continuation and not a missing acronym.

check the page history, someone changed ID to Id yesterday. 🫥

Yeah I am pretty baffled, what does vandalizing Wikipedia have to do with what we are discussing?

I think our unanimity model is getting a little frustrating here because folks feel like threats of blocks are being used in a way that makes other delegates feel like their point will be ignored (which would violate the original goal of our consensus-seeking in the first place). This equality/inclusion/process question is a bigger issue than the actual contents of the arguments (since anything will work technically).

I would support the change to a consensus model that doesn't require 100% agreement. I don't like that one veto stops something.

re: async contexts, I am assuming that the behavior is, whenever a function is scheduled to be run on a subsequent microtask tick or turn of the event loop, the host is required to snapshot the current async context bits and then restore them before running the function?

i'm kind of confused by justin's example saying the propagation point is at the await pause

I will ask the question about event listener dispatch I guess

Ashley Claymore: the event listener question is less "how is this implemented" and more "what is the thing you want here" - I'm trying to get at the mental model, not the implementation

that becomes a lot easier if/once AsyncWrap is standardized

sync function calls should just inherit the current context, leading to the same behavior? (pls clarify)

Yeah, that's the point of an alternative option captureAsyncContext of addEventListener

the event should be dispatched with the context you bound/wrapped, whether that happens synchronously or async

the event should be dispatched with the context you bound/wrapped, whether that happens synchronously or async

the fact that not all callbacks will necessarily automatically inherit the context in which the callback was added (depending on the API which adds the callback) is a little bit awkward, since the whole point of this is that you want to define a context which is available when your callback runs even though your callback is getting registered to run by code you don't control

thinking about this even more, I am tempted to say that automatic wrapping happens only when you can't do it yourself, i.e. only for syntactic yield and await (and friends, like using await, of course) - in every other case (including manual calls to .then) you can just wrap the continuation yourself, and not have to worry about whether the scheduler you're using happens to do wrapping for you

I mostly agree, with the exception of .then. The biggest problem with context passing and Promises is that you would need to potentially wrap every .then callback in the event one of them throws. This is far more arduous than wrapping the single entrypoint of an event handler.

i haven't been following, but it seems pretty important to preserve the sugar-ness of await over promises.

It will also be difficult to explain why await x; doSomethingWithContext() would work, but x.then(() => doSomethingWithContext()) wouldn't. Especially when many editors have refactorings for that, which now become potentially unsafe operations.

Can someone link to the YouTube playlist?

the other side of this, it will be difficult to explain why x.then(doSomethingWithContext) would work, but setTimeout(doSomethingWithContext) would not. so that implies setTimeout needs to automatically wrap as well. and then now you have the same problem but with s/setTimeout/setEventListener/, and so on

This becomes one more thing to consider when wrapping code in an AsyncContext, especially if that code calls into a third-party package that might use .then.

so making the rule "you always need to wrap callbacks" is much simpler

i.e., we should not make some APIs do wrapping of callbacks automatically.

(And also if you force me to take away the fast path for await promise because I have to patch .then, I will riot)

Assuming there's implicit wrapping in syntactic awaits

I have to preserve across any promise usage, because anything else will break an important API for us

I have to preserve across any promise usage, because anything else will break an important API for us

You need to wrap your handlers before you hand them to other people

If you automatically associate context for .then, you are saving users a significant amount of complexity and boilerplate. If you are calling into questionable code, the presence of automatic context copying doesn't prevent you from manually wrapping the callback yourself.

I can't wrap it per requests, because the global value would change per request

I think transferAndFixLength is better than transferToFixedLength

"calling into questionable code" meaning calling into... any code?

Devs cannot escape our context on our platform, so any future point in which they would trigger an event listener would already have restored the request context

shu: please try to give a little more time between a name change and a stage 3 advancement next time; we may have been able to come up with a better name if we had more time

littledan: because it didn't matter enough

So in order for us to guarantee they cannot escape our context, the promise.then() must preserve context

yes, and also every other possible way of scheduling a callback

Michael, this is exactly what we introduced the "note dissent that's non-blocking" part for

so I'm wondering what's not going to work about that

Why are promise instances relevant?

"Promises are sugar for callbacks" is at least as important as "await is sugar for Promises"

ljharb: I'd like to try to have a call to resolve the Id issue, are you available during the break today?

absolutely, thanks

As the library implementor, I should not have to care about whether or not I am flowing an AsyncContext. That is, as I understand it, literally the entire point of this feature.

which means that "some subset of things will preserve the context transparently" is not good enough

Please join the fun AsyncContext discussion at #tc39-async-context:matrix.org !

littledan: MatrixError: [403] You are not invited to this room. (https://matrix-client.matrix.org/_matrix/client/r0/join/%23tc39-async-context%3Amatrix.org) 🥺

I think we need to transfer it to the TC39 space first, then open up registrations to any space members

built-ins like Promise and syntax like await must preserve this

by "viable" do you mean something like "convenient"?

No, I mean an AsyncContext that doesn't support .then would not be useful for my purposes and I don't know that I would be willing to support Stage 2 without it. Limiting it only to await makes it barely usable and results in a terrible DX for the most common case outside of await itself.

that is: the thing you mean is "without this it will be too inconvenient to be practical", not "without this it will lack some guarantee I rely on", right?

(like I said, I'm ok with "all" or "none", just not "some")

I am a lot more OK with making people who are explicitly using AsyncContexts think about them than making everyone else think about them.

If we can't mandate "all", we can't do the "cannot escape context" thing Justin said is a requirement

This just isn't the way they are used; the AsyncContext flows through a whole environment automatically and this is the entire point.

And if it's not a requirement that the context flows automatically, then library authors now have to think about async contexts all the time.

littledan: no, the unexported binding

I assumed the binding would be decorated either way, and "export decorators" would be decorators that applied specifically to exports in some way

is anyone actually advocating for the distinct semantics? Or is this just about syntax placement?

rbuckton: what about export default class {}?

With option 1 (decorators only before export), would export default @dec class A {} be a valid export of a class expression?

With option 1 (decorators only before export), would export default @dec class A {} be a valid export of a class expression?

and what about export default @noopDecorator class {}?

This is very much a declaration. This is clear in the decorator spec.

with or without decorators, export class {} has no user-observable local binding

ryzokuken: can we do a heat check for both options?

We will need very clear wording for a temp check.

yes, that is the point I'm trying to make

that will not be true of this syntax

i must be dumb because all these arguments still cut both ways to me

Is it expanded? It's performing an await on that line before the block on the next line begins execution

hypothetically if the syntax was using await (bindingExpr) { }, that seems perfectly clear

I think the body of the loop counts as "right here"

so async do { Promise.resolve({}) } has no interleaving point? it produces a promise?

i meant "would it address the specific 'await means here' concern" (and also it is definitely not a real proposal for many reasons)

We could potentially use await using x = ... instead. I opted against it because of the cover grammar necessary to try to keep LR1, but it's an option.

yeah, maybe. Adding more cover grammars seems good to avoid.

IIRC, bakkot 's position is that the syntax complexity shouldn't matter as long as we achieve the right syntax. bakkot, is that correct?

do people in the decorator-before-export camp think that decorators should also come before the return when you're returning a class? as in

@dec
return class {}

i think we probably should not have allowed this case at all, in either order. declare your thing explicitly and then export/return/etc it

lol that is a previously unmentioned fourth option, i guess

if i'm not around tomorrow during the discussion can someone mention just not allowing this at all