A preview of this PR can be found at https://tc39.es/proposal-explicit-resource-management/pr/216.

Hm. I would lightly prefer to always await for sync-dispose, and only skip awaits (when possible) in the case of await using x = null specifically. Having things happening in the same turn when using await using seems surprising. Nothing happens for the null case so eliding that await is fine.

I can be convinced to only skip for null, it's still an improvement over the current approach.

As I mentioned on the issue, skipping new turn altogether in exceptional cases is not acceptable. The rule that should be respected is that if there is an await evaluated in the block, expressions following the block must execute in a future turn.

As I mentioned on the issue, skipping new turn altogether in exceptional cases is not acceptable. The rule that should be respected is that if there is an await evaluated in the block, expressions following the block must execute in a future turn.

It should be clarified that must execute is too strong here. If all disposals throw synchronously and the surrounding block is contained within a try-catch block, the catch clause and statements that follow will still execute in the same turn, which is consistent with await elsewhere:

try {
  const fail = () => { throw "sync throw" };
  
  HAPPENS_BEFORE
  
  await fail();
} 
catch {
  HAPPENS_AFTER
}

Even with the await, both HAPPENS_BEFORE and HAPPENS_AFTER will happen in the same turn.

Skipping the new turn in exceptional cases is directly in line with existing ECMASCript. await must operate on a normal completion, a synchronous throw completion always bypasses the await.

Also, the current specification text skips new turns for synchronous exceptions, as do await and for await:

If that were not the case, HAPPENS LATER would be logged before HAPPENS AFTER as it is scheduled before the await.

This does, however, ensure that an await happens if we transition from a collapsed set of async-from-sync operations that succeeded to a synchronous operation such as a using resource disposal, or a sync exception from any other disposal in the scope.

If all disposals throw synchronously and the surrounding block is contained within a try-catch block, the catch clause and statements that follow will still execute in the same turn, which is consistent with await elsewhere:

I don't believe this is equivalent. In the await using case the right hand side of the await evaluated.

To be more clear, if execution proceeded past the await, I believe in both cases the author should be able to assume an interleaving point happens.

In the await using case, what is awaited isn't the RHS of the assignment, it's the subscription to the dispose that occurs at the end of the block (i.e., you are awaiting the effects of the using). If there is no other await in the block, when the dispose call is evaluated you are still in the same turn as the block itself. If the dispose throws synchronously, you have not actually reached the point in execution where the await occurs.

The closest example of this is for await, which also has this behavior:

In this example, the synchronous throw in next results in execution continuing synchronously out of the loop to the catch clause, thus HAPPENS_BEFORE and HAPPENS_AFTER occur in the same turn. Yes, there is an interleaving point before this, but even that can result in synchronous execution, though the body of the loop isn't evaluated:

So this is completely in line with the behavior of both await and for await as it exists in the language today. The only time there is an actual call to Await is if the RHS does not throw synchronously. I believe we must maintain that invariant.

That said, the most likely implementation of a normal @@asyncDispose will be with an async function which will not throw synchronously. The issues lies with how @@dispose is handled in await using as we do not wrap it in a PromiseCapability, we merely Await(*undefined*) if it succeeds. We could do the same thing we do for %AsyncFromSyncIteratorPrototype%.next and wrap it in a PromiseCapability so that sync exceptions turn into rejections, though that would mean we can only collapse Await for null/undefined, which I would be fine with.

Even with that though, a hand-written @@asyncDispose can still throw synchronously just like a hand-written AsyncIterator.next (or AsyncIterator.return) can in a for..await. It's a rare corner case, but I would rather not break with for..await on this.

As an alternative to this PR, I've posted #218 to add a PromiseCapability to the @@dispose wrapper and #219 to only perform deterministic collapse on null/undefined resources.

Closing this in favor of #218/#219.