Ron Buckton

@waldemarhorwat: Can you clarify as to whether I have accurately described your concerns as presented at the last plenary session? Would you find the NLT inconsistency introduced by (1) a...

Would option 2 not be satisfactory? It maintains NLT consistency for all Extractor cases, though is mildly inconsistent with a normal function call. Though there is obvious overlap conceptually, extractors...

This fixes the cover grammar to match the _ExtractorAssignmentPattern_ grammar so that `F(, x) = y` parses as intended.

@waldemarhorwat does this sufficiently cover your concern about Elision missing from the cover grammar from #23? I've opted for option 2 in https://github.com/tc39/proposal-extractors/issues/23#issuecomment-2135970793 for the time being, and can revise...

FYI, unless anyone has comments on this PR, I plan to merge it later this evening.

In an earlier draft of the proposal, `DisposableStack.prototype.dispose` was actually a getter that returned a bound function invoked `this[Symbol.dispose]`. If we were to make a change, it would likely be...

In the meantime, a potential workaround that matches the current spec behavior would be to do the following: ```js class NotifyingStack extends DisposableStack { dispose() { const wasDisposed = this.disposed;...

Also, is there a reason you are not just using `.defer()` in this case? ```js class NotifyingStack extends DisposableStack { constructor(notify) { this.defer(notify); } } ```

Ideally this can be pursued as a needs-consensus PR and not a follow-on to avoid making potentially breaking changes after implementations have shipped. I will bring this to the July/August...

> I totally agree that, in isolation, `using r = new Resource()` is cleaner. `defer` does start to feel repetitive and more error-prone. But that verbosity is not pointless, it...