Ron Buckton

It looks like there may be a case in the algorithm that still introduces an extraneous Await in the case of: ```js { await using x = null; using y...

`AsyncDisposableStack.prototype.use` has the same effects as `await using x = y` where `y` is a sync disposable. The `await` that is implied by `await using` (and thus by `use` in...

@mhofman this does beg the question, is it imperative that there is an `Await` for every individual resource added via `await using`, even if it exposes an `@@dispose` method, or...

Note that prior to amending the specification text to mandate an implicit `await`, in the above case no `await` would have occurred at all for the above case, so the...

I was looking into this not too long ago. The approach I had considered was to add a slot to `DisposeCapability` indicating whether there were any `await using` declarations in...

I will have a PR up shortly for the deterministic collapse of Await, though I do have a question for @mhofman and @erights: Given the following code: ```js { await...

I've changed my position here slightly to err on the side of consistency in both directions. Collapse of `Await` can only occur between synchronous resources in an `await using`. For...

> I think this particular one is a problem. There is a syntactic `await` which can result in no new turn. From a static analysis pov, this is not acceptable....

Also, the current proposal text operates in this way, as it aligns with `Await` handling elsewhere: ```js (async function () { try { await using x = { [Symbol.dispose]() {...

If your intent is to explicitly give ownership of a resource to another function, one option is to emulate `DisposableStack.prototype.move()`, in which you create a copy of the object and...