Hacker News Reader

Comment by radq | Hacker News Reader

I have some reservations about the specification - it looks like there are a lot of caveats to how it can be used. For example, it's allowed in for and for-of loops, but not in for-in loops. Also looks like destructuring will not be allowed.

    using res = getResource(); 
    const { x, y } = res; // ok
    
    using { x, y } = getResource(); // error

View on HN

Considering this limitation, I wonder if the syntax could have been something else than assignment. Like maybe:

  using getResource() as res;

I agree. If it's assignment then it should work the same as assignment (from the users perspective), otherwise it should have a different syntax.

Also seems like there would be use cases where you don't even want to assign the result, you just want the destructor to run at the end of the scope. Something like:

  using someMutex.lock();

With the assignment syntax it's not obvious to me whether that's allowed.

You assign it to a variable that is then disposed of once it's out of scope?

There is literally an example for using destructuring in the linked article. So it is supported.

Can you clarify where it indicates it's supported i.e. which specific example? I re read and didn't see it myself, seems others are missing it.

To be fair I don't see it not being supported either by the examples.

The last example:

    {
      await using { connection } = getConnection();
      // Do stuff with connection
    } // Automatically closed!

edit: according to the ES proposal issues, this might be something that doesn't actually exist, on purpose (it's rather ambiguous as to what will be disposed of): https://github.com/tc39/proposal-explicit-resource-managemen...

Thanks! Yes that example is subtly different.

I did also click through to the proposal but didn't see that issue. It does seem like it's still unclear what's intentional or not.

It’s intentional. The grammar production in the proposal is parametrized as ~Pattern (a parameter introduced in the proposal), which means it does not allow destructuring.

https://tc39.es/proposal-explicit-resource-management/#prod-...

> not in for-in loops

What would that even mean? The binding in a `for-in` can only ever hold a string, which can't be disposable. With a `for` or `for-of` the binding can hold an object, which is something you could dispose of.

That's strange, what's the motivation behind not allowing destructuring? Seems very prudish.

It's ambiguous. Are you disposing of the object being destructured or the destructuring results? How do you make the distinction?

Much easier to not do it.

Not sure if this would produce more issues, but they could ignore c# and use something like:

  const using x = getX()
  const {using prop1, prop2} = using getX()
  void using getX()
  // x, prop1 and 2 anonymous Xs to dispose

Instead of giving `using` the power / the burden of variable creation. This also solves `using mutex.lock()` mentioned elsewhere itt.

To me it seems like disposing of the object being destructured is the natural solution. But I can see where others will disagree.

when would you want to do that?

When there’s a group of resources with a non-trivial disposal order but there’s no explicit manager object, for example.

Reply on news.ycombinator.com