`try` alongside `using`

[arthurfiorette]

We also need to figure ways to combine with https://github.com/tc39/proposal-explicit-resource-management.

Originally posted by @arthurfiorette in #68

[arthurfiorette]

using result = try resource()
await using result = try asyncResource()

Seems to be the general approach.

---

using does not work with destructured objects, which might just be the same with our proposal.

using { a, b } = resource() // breaks
using [ok, error, value] = try resource() // should also break?

Although [ok, error, value] is not destructuring the value but instead the Result class. [ok, error, value] can also be rewritten as { ok, error, value } which is the same thing as the first example.

using {ok, error, value} = try resource() // if using { a, b } = resource(), this should break as well

---

About its usage, I'm not sure... This is my early draft idea:

class Result {
  constructor(ok, error, value) {
    this.ok = ok
    this.error = error
    this.value = value

    if(value?.[Symbol.dispose]) {
       this[Symbol.dispose] = function () { value[Symbol.dispose]() }
    }

    // the same for asyncDispose
  }
}

---

I'm also fine with not allowing this idea at all.

[ljharb]

It would make more sense if Result was just always disposable, and added both error and value to a DisposableStack for the purpose of disposing it (and an AsyncDisposableStack, so that it can also be async-disposable)

[blended-bram]

One challenge will be that the destructured pattern needs to keep reference to the destructured object prior to performing the destructuring protocol. One might write:

using [ok, error, resource] = try setup();
using [ok, error, asyncResource] = try await setup();

And expose resource to be disposed synchronously and asyncResource to be disposed asynchronously.

Given that the Result class is used for the proposal, it could implement the dispose / async dispose methods and forward the calls to resource. Or return a bound function to resource's dispose.

class Result {
  [Symbol.dispose]() {
    if (!this.value) return;
    if (!(Symbol.dispose in this.value)) return;
    const dispose = this.value[Symbol.dispose];
    return dispose.bind(this.value);
  }
}

The forwarding in combination with the destructuring approach requires the dispose protocol to act on the result of the try-expression before the destructuring takes place:

{
  using [ok, error, resource] = try setup();
} // calls Result[Symbol.dispose]() -> forwards (safely) to resource[Symbol.dispose]()

// is the same as:
{
  using result = try setup(); // aquire dispose binding
  const [ok, error, resource] = result; // destructure
} // calls result[Symbol.dispose]();

Most straightforward is to permit using to be a destructured assignment, where a reference to the object-to-be-destructured is held.

[blended-bram]

using result = try resource()
await using result = try asyncResource()

For the async case, I think it is going to be confusing whether you have await on the try or not. There is a difference with try-expression for an async call and I would expect await using result = try await asyncResource; for consistency. Otherwise it implies that try ${expr} implicitly awaits promise values.

[Arlen22]

I was just looking through the spec, And I noticed a couple things.

It seems that await using indicates that the cleanup function might be async, but it has no bearing on the assignment expression. In other words, the using syntax doesn't touch the value until it crosses the equal sign.

I didn't look at it in detail but from the parsing syntax at least and from what you all are saying, it sounds like the using directive happens before destructuring occurs.

The spec checks for the presence of a callable dispose function, so I believe we would need to use a get accessor to directly get the dispose functions from the value object.

We do need to take the this variable into account. I'm assuming the dispose methods expect it to be the resource.

It might actually be easier for the using directive to check whether the resource is our Result class, but that's probably a stage 3 decision.