proposal-explicit-resource-management VS proposal-class-method-parameter-decorators

The standard doesn't have anything to do with TypeScript, not sure where you got that from? https://github.com/tc39/proposal-explicit-resource-managemen...

The explicit resource management proposal tries to make it a bit easier for us, by allowing the resource to declare how it should be managed, rather than expecting us to clean everything up when we use the resource. We get a new keyword using to define a variable (rather than const or let), which tells the runtime to clean up the resource at the end of the function.

Enter the explicit resource management proposal, which describes — among many other things — a new using operator that was introduced in TypeScript 5.2 and is making its way into JavaScript. From the top of the README file, here’s what this proposal aims to do:

In addition to this, is the new (stage 3 even!)explicit resource management proposal[0], supported by TypeScript version >= 5.2[1]

Though I agree that async context is better fit for this generally, the RMP should be good for telemetry around objects that have defined lifetime semantics, which is a step in the right direction you can use today

[0]: https://github.com/tc39/proposal-explicit-resource-managemen...

[1]: https://www.totaltypescript.com/typescript-5-2-new-keyword-u...

It's too early for that, https://github.com/tc39/proposal-explicit-resource-management

[3]: https://github.com/tc39/proposal-explicit-resource-managemen...

I'm not _entirely_ sure which RAII you mean, but if you mean something like C#'s `using` or Java's `try-with-resources` or Python's `with`, then https://github.com/tc39/proposal-explicit-resource-managemen... and https://github.com/tc39/proposal-async-explicit-resource-man... are in stage 3 (of 4 stages) in ECMAScript's language proposal lifecycle and will be coming to a JS engine near you behind a flag soon-ish.

Indeed, decorators will bring significant changes to how we write applications today. Perhaps not immediately, as the current specification primarily focuses on classes, but with all the additions and ongoing work JavaScript code in many applications will soon look different. We are now closer than ever to the moment when we can finally see those ones that are real decorators in the specification. It is an exciting development that promises to enhance the expressiveness and functionality of JavaScript applications.

> I wonder if they will put forth a new proposal for dependency injection next, at this rate.

Yes, there is a new-ish proposal [1] which is motivated in large part by DI.

(Full disclosure: I'm on the committee and don't really like DI or this proposal. But we'll see how it goes.)

[1] https://github.com/tc39/proposal-class-method-parameter-deco...

Class Method Parameter Decorators: Decorators for ECMAScript class method and constructor parameters