4 ms·
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 l
by radq 3y ago
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
- cerved 3y agowhen would you want to do that?
- deleted 3y ago[deleted]
- wruza 3y agoWhen there’s a group of resources with a non-trivial disposal order but there’s no explicit manager object, for example.
- deleted 3y ago[deleted]
- pavlov 3y agoConsidering this limitation, I wonder if the syntax could have been something else than assignment. Like maybe: using getResource() as res;
- kybernetikos 3y agoI agree. If it's assignment then it should work the same as assignment (from the users perspective), otherwise it should have a different syntax.
- pavlov 3y agoAlso 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.
- lillecarl 3y agoYou assign it to a variable that is then disposed of once it's out of scope?
- saiojd 3y agoThat's strange, what's the motivation behind not allowing destructuring? Seems very prudish.
- masklinn 3y agoIt'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.
- wruza 3y agoNot 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.
- saiojd 3y agoTo me it seems like disposing of the object being destructured is the natural solution. But I can see where others will disagree.
- kuschkufan 3y agoThere is literally an example for using destructuring in the linked article. So it is supported.
- ojintoad 3y agoCan 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.
- masklinn 3y agoThe 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-management/issues/78#issuecomment-1135152072 https://github.com/tc39/proposal-explicit-resource-managemen...
- ojintoad 3y agoThanks! 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.
- pwdisswordfishc 3y agoIt’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-UsingDeclaration https://tc39.es/proposal-explicit-resource-management/#prod-...
- bakkoting 3y ago> 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.