Ask HN: What should have been the term for RAII?

”For dust thou art, and unto dust thou shall return”

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.

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.

Are there languages that do SBRM but not RAII?

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.

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

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.

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

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.

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

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.

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

The standard library necessarily has broad coverage of many use cases. That's why not every constructor of lock_guard acquires the lock. It's a completely legitimate use case that your thread happens to have a lock and wishes to use the end of lifetime of a lock_guard to release it. It's the same reason that you can construct a unique_ptr from an object that was allocated with new instead of with make_unique. Also, it's perfectly analogous to Go's `defer mu.Unlock()`.

DRR, destructor resource release. At least that's the relevant part to me...

Constructor Acquires, Destructor Releases.

Unfortunate acronym, you're going to get a bunch of lisp docs...

You are right, I do program in LISP and love the C[AD]+R idea.

I even had my own proposal 5 years ago for improving that!

> That's right, but I would go one step further and have F(irst) and R(est), with obvious composition as follows: (using kruhft's examples from another thread)

    > (ff  x) == (caar  x) == (car (car x))

    > (rrf x) == (cddar x) == (cdr (cdr (car x)))

> I would argue that it's worth sacrificing the 'f' and 'r' symbols for such a common construct.

> …

> Yes, I realize I'm 55 years late to the party.

https://news.ycombinator.com/item?id=13259344

Now we only need to implement both changes at the same time! :-P

It's also pretty pointless; it's just repeating the job description of the constructors and destructor of any object that manages a resource.

Who is that for? Dummies who get it backwards? Oh, look, you're releasing in your destructor and acquiring in the destructor. Did you forger your CADR?

Can we use some wilderness phrases like “Pack It In, Pack It Out” or “Leave No Trace”?

cppreference defines it as:

> Resource Acquisition Is Initialization or RAII, is a C++ programming technique[1][2] which binds the life cycle of a resource that must be acquired before use (allocated heap memory, thread of execution, open socket, open file, locked mutex, disk space, database connection—anything that exists in limited supply) to the lifetime of an object.

I’d crib the name from Rust, this is ownership, where the object owns the resource.

Something with scopes? "Scoped resources" ?