7 ms·

It's neat, but if I understand it correctly, if you forget to write the "using" keyword the code will still work just fine but the dispose will never be called,

• rixtox 3y ago
  There's a conversation I had with Ron Buckton, the proposal champion, mainly on this specific issue. [1] Short answer: Yes, Disposable can leak if you forget "using" it. And it will leak if the Disposable is not guarded by advanced GC mechanisms like the FinalizationRegistry. Unlike C# where it's relatively easier to utilize its GC to dispose undisposed resources [2], properly utilizing FinalizationRegistry to do the same thing in JavaScript is not that simple. In response to our conversation, Ron is proposing adding the use of FinalizationRegistry as a best practice note [3], but only for native handles. It's mainly meant for JS engine developers. Most JS developers wrapping anything inside a Disposable would not go through the complexity of integrating with FinalizationRegistry, thus cannot gain the same level of memory-safety, and will leak if not "using" it. IMO this design will cause a lot of problems, misuses and abuses. But making JS to look more like C# is on Microsoft's agenda so they are probably not going to change anything. [1]: https://github.com/tc39/proposal-explicit-resource-management/issues/159 https://github.com/tc39/proposal-explicit-resource-managemen... [2]: https://stackoverflow.com/a/538238/1481095 https://stackoverflow.com/a/538238/1481095 [3]: https://github.com/tc39/proposal-explicit-resource-management/pull/168 https://github.com/tc39/proposal-explicit-resource-managemen...
• Nathanba 3y ago
  well maybe you want to explicitly free it later...
  • deleted 3y ago
    [deleted]
• maxloh 3y ago
  JavaScript is a garbage collected language, so no memory leak is possible.
  • mcluck 3y ago
    Garbage collection doesn't prevent memory leaks. Nothing stops you from filling up a Map and never emptying it
    • maxloh 3y ago
      Memory allocated for the map is supposed to be freed when the variable goes out of scope.
      • tgv 3y ago
        Nope. It's freed when there's nothing referencing it any longer, at the next garbage collect. Here are common pitfalls: https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/ https://auth0.com/blog/four-types-of-leaks-in-your-javascrip...
    • tom_ 3y ago
      It's not a leak if the memory is still referenced! A garbage-collected system can never leak memory.
      • bigyikes 3y ago
        You’re being pedantic. “Memory leak” is colloquially used when you have data in memory which accumulates and isn’t actively being used by the system.
        • deleted 3y ago
          [deleted]
      • jmull 3y ago
        The problem with that definition of "memory leak" is that it's not useful to programmers. A more useful definition is memory that remains allocated unintentionally.
• paulirwin 3y ago
  No, but static code analysis could do a good job at catching this (at least it does in C#).
• wvenable 3y ago
  In C#, the garbage collector will eventually call the destructor that will dispose the object. It just won't happen deterministically with the code. I assume there would be similar logic for JavaScript but I haven't looked at the specification. It is not always a mistake to miss the using keyword -- if you're taking ownership of the object, then you will dispose of it manually (potentially in your own dispose method).
  • recursive 3y ago
    I'm not aware of a way to control the GC behavior of an object in JS. The memory will be freed, and that's all. If something else needed to be done, I don't think there's a way to do it. Happy to be proven wrong though.
    • Drakim 3y ago
      You can kinda use a WeakMap to later detect if an object has been dereferenced, and thus run some sorta cleanup routine.
      • recursive 3y ago
        How? WeakMap (and WeakSet, more directly) can detect if an object has been collected only if you have a reference to pass to it. If you have reference to the object in a variable or data structure, it won't have been eligible for collection in the first place.
        • bakkoting 3y ago
          You can't use a WeakMap or a WeakSet, but you can use a WeakRef or a FinalizationRegistry.
          • recursive 3y ago
            I did not know about these things. Looks cool!
    • deleted 3y ago
• WorldMaker 3y ago
  That situation already exists today, but is inconsistent: some things need .close() and others .dispose() and yet others .destroy() and then there's things like .end() and .reset() and .disconnect() and .revoke() and .unsubscribe(). All of those and more already exist in JS code today (just off the top of my head) with notes in library READMEs or other documentation to call them or possibly face resource leaks. The `using` keyword suggests a common name for these sorts of functions, [Symbol.dispose](), and provides lovely syntax sugar for try/catch/finally to make sure such things get called even in failure cases, and even provides suggested built-in objects DisposableStack and AsyncDisposableStack to help in managing multiple ones and transitioning older APIs like the many names I've seen, mentioned here. Even better, right now lint tools have to individually case rules specific to each library given the variety of names, but lint tools can make a nice global rule for all objects implementing [Symbol.dispose]() (just as they can warn when a Promise is left unawaited).
• mmis1000 3y ago
  Eslint will probably have a rule about it. As `call a function return promise without using the result` have a relevant rule today. Probably it will block the pattern that `call a function that returns disposable object without using using keyword`...etc.