[jolux]

I’m a Rust programmer but I would call it scope-based or scope-bound resource management, a popular alternative term in the C++ community.

[klyrs]

> I would call it scope-based or scope-bound resource management

RAII isn't about scope, it's about lifetimes that can persist beyond the instantiating scope. More like object-bound resource management.

[xedrac]

Many RAII objects really are tied to a simple scope - such as std::lock_guard. So it's not just about persisting beyond the initial scope. I don't recall the word "lifetime" being used in the C++ world before Rust came along. The word "scope" was often used in the same way we talk about lifetimes now. And if you think of the space between an object's constructor and its destructor as a scope, then anything that it owns is tied to its own scope. In this way, calling it "scope-based" is rather intuitive. The only wrinkles would be objects that are tied to multiple scopes (reference counted), and objects that change scopes (move semantics), but even then it's not hard to reason about. Regardless, the term RAII is widely understood, so I'm not sure it needs a new name.

[kazinator]

> I don't recall the word "lifetime" being used in the C++ world before Rust came along.

"Lifetime" is a normative term in ISO C. In the 1999 standard, it is given as: "The lifetime of an object is the portion of program execution during which storage is guaranteed to be reserved for it. An object exists, has a constant address, and retains its last-stored value throughout its lifetime." (6.4.2 Storage Durations of Objects)

"Lifetime" appears three times in the Index of the 1988 edition of Compilers: Principles, Techniques and Tools by Aho, Sethi and Ullman (a.k.a. the Red Dragon Book).

Lifetime, of a temporary 480

Lifetime, of an activation 391, 410

Lifetime, of an attribute 320-322, 324-329

[xedrac]

It appears I was simply not exposed to the terminology then. But thanks for the information.

[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.

[jeffbee]

RAII isn't just about automatic ("scope-based") variables. RAII refers to the way the language ties together the construction and allocation of the object.

[jolux]

Are there languages that do SBRM but not RAII?

[light_hue_1]

Plenty of languages don't have RAII have SBRM. Scope based resource management predates the idea of constructors by decades. It's common in Lisp and Scheme. Haskel doesn't have RAII, but scope-based resource management is critical.

``` (call-with-output-file some-file (lambda (out) (write 'hello out))) ```

[mhh__]

D has constructs:

    scope(exit) foo(); // Call foo at the end of the scope
    scope(success) foo(); //Call foo if all goes well
    scope(failure) foo(); //Call foo if the wings fall off the plane.

[remram]

Python's with keyword maybe?

You can do

    with lock:
       # lock is held
    # lock released
    with lock:
       # lock is held again

Also Go's defer keyword, which is bound to the current function (defer until function returns).

[jolux]

Right, but those are opt-in features. In Python you can lock something and not release it by mistake. In Rust this pattern is enforced, the destructor will always release it at the end of the enclosing scope unless there is a panic or infinite loop. I think this is a substantive difference.

[tazjin]

It's not enforced in Rust, but it's automatic unless you actively prevent it from happening. So you could say it's an opt-out feature.

std::mem::forget is considered safe, as explained in its docs: https://doc.rust-lang.org/std/mem/fn.forget.html

[jolux]

Fair enough, yeah.

[codeflo]

Rust doesn’t have initializers in the C++ sense. And I mean, even in C++ many classes like shared_ptr or even lock_guard have constructors that don’t acquire the resources yet. When the resource is acquired is an API design concern; the important part is where it’s released.

[jolux]

This sounds like an argument that C++ isn't RAII.

[somedudetbh]

C++ _isn't_ RAII. RAII is a design pattern you can apply, leveraging C++ language features, in C++ in certain cases to avoid a certain class of bugs.

[jolux]

Well sure but I would assume the pattern would be consistently implied in the standard library, no?

[Matthias247]

Yes. Eg if you look at Java try-with-resources there is an exact scope during which resources live and can be used. At the end of the scope the .close() method will be called.

For C++ and Rust there might not be a well defined scope since objects can be „moved“. Eg a method constructing an object can return it to the caller without the destructor being called.

[jolux]

It's well-defined, it's just more flexible than Java. The difference is that returning a value moves it, and resources are owned by the creating scope by default. Java doesn't have the same concept of ownership, or rather, you can't move values in Java.