TC39 Async Context on 2022-11-20

17:45	<littledan>	That's already feasible in the proposed design, just not convenient. I don’t think it is, because you can’t really reliably get ahold of something with no context variables defined, if the engine may define some of them (as proposed by Yoav in his talk)
17:46	<littledan>	I expect the most obvious thing it will be used for is passing along request state in a server. That's what I'm using `AsyncLocalStorage` for (though in that case, its a Discord bot). I think priority of different threads of control is also likely to be a very immediate and important application
19:39	<rbuckton>	I'm not opposed to any storage of a cancellation token in an async context. Its fine to do so in an application, its just that its a bad practice for library authors to depend on it if there's a chance an intermediate/middleware might need to use the API with its own level of control. For example, if `fetch` were to have a transparent cancellation mechanism, it would be bad if it didn't also introduce a way to easily suppress an implicit cancellation flow. You wouldn't want `setTimeout` to have implicit cancellation because its just used too often for too many things to have a user try to cancel one timer and accidentally cancel every timer that may have been created in the same flow.