Ron Buckton

> Another quick clarification, I assume the following is also true... Yes. `using` lifetime is scoped to the block. If you wish it to live long enough to be reachable...

I generally wouldn't recommend deleting a method since that changes the object's shape (which can affect runtime performance). It also wouldn't prevent something like: ```js { using a = ...;...

In most cases a disposable has at least one field that holds the actual resource to be disposed. You can almost always just use that field as the disposal indicator...

I am not convinced we should consider implementing full Python-like context managers. If we are not borrowing that complexity, then the only purpose that adding `Symbol.create` would serve is to...

This is part of the reason why I'm not in favor of calling it `Symbol.create`. If you were going to do work asynchronously to create the resource, you do it...

> > @mhofman > > I think @rbuckton 's argument is that the create can always return an AsyncDisposable. In the case of a create failing, it can technically initiate...

The appropriate place to discuss this is probably https://github.com/tc39/proposal-cancellation, though that proposal hasn't seen much activity since WHATWG has been adamant that there shouldn't be two native cancellation mechanisms and...

I'd suggest reading over the cancellation proposal and taking a look at https://www.npmjs.com/package/@esfx/canceltoken, which is based on an early implementation of the proposed API. I'd appreciate any feedback.

> I can definitely see how `#set` is important for the utility of auto-accessors. But some things feel a bit like a surprising mismatch to me, e.g., > > *...

Here are a few caveats to consider, off the top of my head: - Some transformations depend on various emit helpers at runtime, even for `--target ES2015`, such as for...