[jolux]

Scope is a necessary part of it too though. There’s always going to be one owning scope for an object in Rust (unless you’re using Rc) and that scope is responsible for calling the destructor. You can change which scope is responsible by moving it, but scope is still important. Without scope being an implicit part of resource management, you have a feature like try/finally or with in Python.

[klyrs]

You're still trying to make this about rust without bothering to learn what the C++ users here are talking about. I'm not sure what to tell you.

[jolux]

Rust got the concept from C++ and it’s not a C++-specific concept, despite having originated there. You seem to have some fundamental disagreement with what I’m saying that you’ve yet to identify. What does RAII look like without scope, if it’s not about scope? How would RAII work in a dynamically scoped language?

[klyrs]

Specifically, RAII plays really nicely with move semantics -- you can move objects between parent/child scopes, and sometimes that happens transparently (which may be an abomination, or may be heavenly, depending on your worldview). By moving objects (which can be forbidden explicitly or implicitly), you pass their associated resources around, leaving an empty husk to "clean up" when execution hits the end of a scope, which often compiles down to nothing. You need to be mindful of scopes, of course, but RAII isn't about scopes -- it's about being certain that your object is fully capable of satisfying its contracts the moment you've left the constructor.