2c:null 2d:["$","title",null,{"children":"using for JavaScript - The Good, the Bad and the Ugly | rix | Observable"}] 32:T4c7,There are [quite a few motivations for the proposal](https://github.com/tc39/proposal-explicit-resource-management#motivations). But to name a few important ones: (1) Resource disposal or cleanup has no standard interface. Libraries and APIs use all sorts of mechanisms and names like `close`, `destroy`, `finalize`, `unsubscribe`, `removeEventListener`, `delete`, `free`, and so on. (2) Resource may leak if `try ... finally` is not properly used. ```ts const reader = stream.getReader(); ... reader.releaseLock(); // Oops, should have been in a try/finally ``` (3) Even with `try ... finally`, disposing multiple resources often require properly grouping `try` scopes, or one dispose can throw and leak the other resources. ```ts const a = ...; const b = ...; try { ... } finally { a.close(); // Oops, issue if `b.close()` depends on `a`. b.close(); // Oops, `b` never reached if `a.close()` throws. } ``` (4) Even if you grouped `try ... finally` correctly, you still need to be careful about the variable lifetime living longer than the actual resource's lifetime. ```ts const handle = ...; try { ... // ok to use `handle` } finally { handle.close(); } // not ok to use `handle`, but still in scope ```33:T5c5,## `using` Syntax With a standard resource disposal interface defined, the `using` syntax is proposed to be the ambitious solution to all the other issues. Basically, if you write `using` in some block scope: ```ts { // lines before using x using x = resource(); // lines after using x using y = resource(); // lines after using y } ``` It behaves about the same as the following except some differences in error handling which I will get to later. ```ts { // lines before using x const x = resource(); try { // lines after using x const y = resource(); try { // lines after using y } finally { y[Symbol.dispose](); } } finally { x[Symbol.dispose](); } } ``` Try to notice that every line that can access variable `x` were put inside a `try` block, and `x` is disposed after that with a `finally` block. It ensures that a thrown error after `using x` will trigger the disposal, which solves issue (2). Try again and notice that each `using` creates a separate `try ... finally` scope, ensuring that even `y[Symbol.dispose]()` throws, we still continue to execute `x[Symbol.dispose]()`. This solves issue (3). Finally (pun intended), because all lines after `x` (those within `x`'s variable lifetime) in the block are before `x`'s disposal, it ensures that no code can use `x` by the same variable name after its resource was disposed. This solves issue (4). 34:T8d2,## `SuppressedError` Let's investigate how many times the code above can throw: ```ts { // lines before using x const x = resource(); try { // lines after using x const y = resource(); try { // lines after using y // <- throw error1 } finally { y[Symbol.dispose](); // <- throw error2 } } finally { x[Symbol.dispose](); // <- throw error3 } } ``` As we can see it can throw 3 times before it reaches the end of the block. If we keep it as is, the caller of the scope can only inspect the outmost throw, or the 3rd throw in this case. To allow inspection on any inner throws, a `SuppressedError` type is introduced, and a special error handling mechanism is defined for the `using` syntax. Basically, for multiple `using` definitions in the same block scope, instead of overwriting inner throws, an outer throw will be merge with the inner throw into a `SuppressedError`, propagating both errors together. It behaves like this: ```ts { let $$error = undefined; let $$hasError = false; function $$setError(error) { $$error = $$hasError ? new SuppressedError(error, $$error) : error; $$hasError = true; } // lines before using x const x = resource(); try { // lines after using x const y = resource(); try { // lines after using y // <- throw error1 } catch(error) { $$setError(error); // <- $$error = error1 } finally { try { y[Symbol.dispose](); // <- throw error2 } catch(error) { $$setError(error); // <- $$error = new SuppressedError(error2, error1) } } } catch(error) { $$setError(error); } finally { try { x[Symbol.dispose](); // <- throw error3 } catch(error) { $$setError(error); // <- $$error = new SuppressedError(error3, new SuppressedError(error2, error1)) } } if ($$hasError) { throw $$error; } } ``` So in our case the block can throw `new SuppressedError(error3, new SuppressedError(error2, error1))` containing all thrown errors.35:Tba8,## Now `{}` block can affect control flow (The Bad) It's important to note that each code block would collect and suppress all thrown errors in its body and during disposal of resources bound to the same `{}` block scope, and finally rethrow the compound error. This behavior is an implication of adopting RAII, but it can lead to some subtle and confusing implications. For example, observe the following two programs: ```ts { using x = { [Symbol.dispose]() {} }; using y = { [Symbol.dispose]() { throw new Error(); } }; console.log("done"); } { using x = { [Symbol.dispose]() {} }; { using y = { [Symbol.dispose]() { throw new Error(); } }; } console.log("done"); } ``` Both programs would throw error, but the first program would print the log while the second won't. The execution of the two programs behave like the followings (simplified for illustration purposes). ```ts { const x = { [Symbol.dispose]() {} }; try { const y = { [Symbol.dispose]() { throw new Error(); } }; try { console.log("done"); // <- reached here } finally { y[Symbol.dispose](); // <- then throws here } } finally { x[Symbol.dispose](); } } { const x = { [Symbol.dispose]() {} }; try { const y = { [Symbol.dispose]() { throw new Error(); } }; try { } finally { y[Symbol.dispose](); // <- throws here } console.log("done"); // <- but never reaches here } finally { x[Symbol.dispose](); } } ``` This behavior may be surprising to many people as we are used to the fact that a `{}` block should not affect the control flow, but with `using`, `{}` can change your program's control flow. Because of this, every time you want to nest part of your code into a `{}` block you need to be very careful whether you included a `using` statement in it, and you need to reason about if the change can affect control flow in unexpected ways. In addition, sometimes we need to explicitly define new `{}` blocks for `using`. A typical use case is for transaction rollback. ```ts // roll back transaction if either action fails async function transfer(account1, account2) { await using tx = transactionManager.startTransaction(account1, account2); { await using resource = someResource(); // dispose may throw await account1.debit(amount); await account2.credit(amount); } // mark transaction success if we reach this point tx.succeeded = true; } // await transaction commit or rollback ``` Without the inner `{}` scope to separate the `tx` transaction and the inner logic, we might end up with throwing in the inner resource disposal, but still reached to the point where we set `tx.succeeded = true` and ended up committing the transaction without rollback. This control flow implication of `using` is very confusing, and can easily be overlooked in code review.36:T7ed,## No way to enforce `using` (The Ugly) You can still leak `Disposable` resources if you forget to `using` it, maybe by a typo of `const` instead of `using`. A leak like this would be silent, and it can even disappear from heap dump after GC. A resource management mechanism should provide a safer mechanism to prevent people from forgetting to dispose it. There's a [very long discussion between me, Ron and others](https://github.com/tc39/proposal-explicit-resource-management/issues/159) exploring different approaches to solve this. If we have to keep the proposal in a backward compatible state, then the best solution so far was [suggested by @Jamesernator](https://github.com/tc39/proposal-explicit-resource-management/issues/159#issuecomment-1613170795) and I explained it [in more details here](https://github.com/tc39/proposal-explicit-resource-management/issues/159#issuecomment-1620895118). If we get what he proposed, we can author resources in a safer manner: ```ts function createHandle(): Creator> { return { [Symbol.create]() { const { write, close } = nativeWriter(); return { write, [Symbol.dispose]: close }; } }; } { using { write } = createHandle(); write('data'); } ``` As the return value of `createHandle()` will not be usable if not being consumed with a `using` statement. However, this is still a discussion happening [in a follow-on thread](https://github.com/tc39/proposal-explicit-resource-management/issues/195), and Ron is mixing the discussion with adding a full Python-like context manager feature, which I think is more than what we need. In any case, currently there's no way to author a function returning a `Disposable` type, while enforcing your function callers to correctly dispose it without forgetting `using`. When working as a team, we want to define some programming contract that's both easy to follow, and hard to make mistakes. I don't think the `Disposable` + `using` contract meets our expectations in terms of safety.37:T462,## Is `using` really necessary? All the issues from the motivations can have different solutions without introducing a new language syntax. One way we can do this is using `DisposableStack`, which is actually already part of the proposal. `DisposableStack` is designed to be a utility to move resources from one `{}` block scope to another, or to compose multiple resources. Interestingly, I find it already simple enough to solve all the issues from the motivations without `using`: ```ts const stack = new DisposableStack(); try { // lines before using x const x = stack.use(resource()); // lines after using x const y = stack.use(resource()); // lines after using y } finally { stack.dispose(); } ``` It solves both issues (2), (3), (4) with merely the cost of creating a `stack` and adding a `try ... finally` block. And even better, it doesn't have the problem of `{}` block changing the control flow. If `using` is introducing merely a syntactic sugar over this solution, and also causing problems in control flow analysis, I don't think it's a good feature to be added to the language. 38:[] 30:{"id":"9e65f7705677a186","slug":"using-for-javascript","title":"using for JavaScript - The Good, the Bad and the Ugly","thumbnail":"3b4c71cfa9fae86663dae8c7a40f6d6df3331c043b1955cd2199e9c53f5f69e9","access_level":"public","create_time":"$D2023-07-22T05:13:31.853Z","update_time":"$D2023-07-22T17:50:52.820Z","view_time":null,"first_public_time":"$D2023-07-22T05:13:31.853Z","has_unpublished_edits":null,"fork":false,"stars":0,"starred":false,"owner":{"type":"team","id":"72e51317eb10aec3","login":"rix","name":"rix","avatar_url":"https://avatars-next.observableusercontent.com/20058f5572c00c2807c8c0a31d6dc913ee57ddabc4e75869a4666632e88b7fa3","tier":"starter_2024","bio":""},"version":141,"publish_version":null,"role":null,"authored":false,"authors":[{"type":"individual","id":"ddedbb681d4376e1","login":"rix","name":"rix","avatar_url":"https://avatars-next.observableusercontent.com/20058f5572c00c2807c8c0a31d6dc913ee57ddabc4e75869a4666632e88b7fa3","tier":null,"bio":""}],"members":[{"type":"individual","id":"ddedbb681d4376e1","login":"rix","name":"rix","avatar_url":"https://avatars-next.observableusercontent.com/20058f5572c00c2807c8c0a31d6dc913ee57ddabc4e75869a4666632e88b7fa3","tier":null,"role":"editor"}],"comments":[],"custom_thumbnail":false,"trashed":false,"lapsed":null,"subscribed":null,"forks":0,"collection":null,"type":"notebook","body":{"titling":"auto","title":"using for JavaScript - The Good, the Bad and the Ugly","cells":[{"id":0,"value":"# `using` for JavaScript - The Good, the Bad and the Ugly","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"","database":"$undefined"},{"id":5,"value":"Recently the new `using` syntax added in TypeScript 5.2 generated a lot of heat. Matt Pocock wrote an [article](https://www.totaltypescript.com/typescript-5-2-new-keyword-using) and made [some](https://youtu.be/VqdVaix3Zvw) [videos](https://www.youtube.com/watch?v=8HoOxOd86M4&t=693s) about it. The syntax is based on the [Explicit Resource Management](https://github.com/tc39/proposal-explicit-resource-management) JavaScript language proposal presented by Ron Buckton from Microsoft. The proposal advanced to Stage 3 in March 2023, which means it's recommended for runtime engines and language tools to implement it and expects feedback from the community. Once it advanced to Stage 4, it will officially become part of the JavaScript language specification.","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"","database":"$undefined"},{"id":11,"value":"I learned about this proposal in early June of 2023 when I was doing some research on resource lifetime management mechanisms for JavaScript. [@Bergi](https://stackoverflow.com/users/1048572/bergi) on StackOverflow referred this proposal to me. Since then, I have spent quite some time for the last few weeks learning more about the proposal, discussing problems and issues about the design with Ron Buckton and other people. This post is mostly my view on the proposal, with some explanation of the design decisions I learned from Ron and others, and why I wouldn't recommend my colleagues to adopt the `using` syntax at this stage.","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"","database":"$undefined"},{"id":20,"value":"## Motivations","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"","database":"$undefined"},{"id":25,"value":"$32","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"","database":"$undefined"},{"id":36,"value":"## `Disposable` and `AsyncDisposable` (The Good)\n\nThe proposal to solve the first issue is to introduce two standard interfaces:\n\n```ts\ninterface Disposable {\n [Symbol.dispose](): void;\n}\ninterface AsyncDisposable {\n [Symbol.asyncDispose](): Promise;\n}\n```\n\nBy using unique Symbols, these new methods can be added to any object values returned by any existing APIs and library functions without breaking compatibility, making it very easy to adopt.\n\nNow, instead of calling some arbitrarily named dispose methods, you can instead call `obj[Symbol.dispose]()` or `await obj[Symbol.asyncDispose]()` as a standard way to dispose resources.\n\nThis design is reasonable, and probably the only practical approach to solve the issue if maintaining compatibility is a hard requirement.\n","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"","database":"$undefined"},{"id":43,"value":"$33","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"","database":"$undefined"},{"id":57,"value":"$34","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"","database":"$undefined"},{"id":84,"value":"$35","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"","database":"$undefined"},{"id":100,"value":"$36","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"","database":"$undefined"},{"id":120,"value":"$37","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"","database":"$undefined"},{"id":128,"value":"## Summary\n\nI feel like the `using` syntax is still half-baked, and can cause more problems than it solves. I wished I was told about this proposal before Stage 3 so I could better engage in the design process. But now, I guess the best we can do is to have more eyes on the proposal and make sure we fix as much issues as possible.","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","tool":"$undefined","providerMetadata":"$undefined","attachments":"$undefined","output":"","database":"$undefined"}],"files":"$W38","stdlib":"1"}} 31:"$30:body"