This is super informative, thanks! Probably worth it to turn this comment into a post of its own.

The error handling question for RAII is a very good point! This is honestly where I’m pretty glad with Python’s exception story (is there a bad error? Just blow up! And there’s a good-enough error handling story that you can wrap up your top level to alert nicely). As the code writer, you have no excuse to, at least, just throw an exception if there’s an issue that the user really needs to handle.

I’ll quibble with 2 though. I don’t think RAII and arenas conflict too much? So many libraries are actually handlers to managed memory elsewhere, so you don’t have to release memory the instant you destruct your object if you don’t want to. Classically, reference counted references could just decrement a number by 1! I think there’s a a lot of case-by-case analysis here but I feel like common patterns don’t conflict with RAII that much?

EDIT: sorry, I guess your point was more about decoupling entirely. I know there are libs that parametrize by allocator, but maybe you meant something even a bit more general

It may not be a big issue for closing files

from open(2):

A careful programmer will check the return value of close(), since it is quite possible that errors on a previous write(2) operation are reported only on the final close() that releases the open file description. Failing to check the return value when closing a file may lead to silent loss of data. This can especially be observed with NFS and with disk quota.

so it’s actually quite important to handle errors from close!

The reason for this is that (AFAIK) write is just a request to do an actual write at some later time. This lets Linux coalesce writes/reschedule them without making your code block. As I understand it this is important for performance (and OSs have a long history of lying to applications about when data is written). A path-based API without close would make it difficult to add these kinds of optimizations.

1. Note that in the context of comparison with defer, it doesn’t improve the defaults that much. The common pattern of defer file.close() doesn’t handle errors either. You’d need to manually set up a bit of shared mutable state to replace the outer return value in the defer callback before the outer function returns. OTOH you could throw from a destructor by default.

2. I disagree about “bend over backwards”, because destructors are called automatically, so you have no extra code to refactor. It’s even less work than finding and changing all relevant defers that were releasing resources piecemeal. When resources are owned by a pool, its use looks like your fourth point, and the pool can release them in bulk.

3/4 are general API/architecture concerns about resource management, which may be valid, but not really specific to RAII vs defer, which from perspective of these issues are just an implementation detail.

Using a descriptor is essentially an optimization to avoid path resolution.

I believe it also the point at which permissions are validated.

Entire categories of usage of that API amount to open/write/close and could trivially be replaced by a bulk-write API

Not quite sure I understand what you mean… Something like Ruby IO.write()? https://ruby-doc.org/core-3.1.2/IO.html#method-c-write

What other models are you talking about? Off the top of my head, linear types are more powerful; with-macros (cf common lisp) are orthogonal; and unconstrained resource management strategies are also more powerful.

That’s interesting, but it wouldn’t work in Go because of garbage collection. You could have a magic finalizer helper, but you wouldn’t be able to guarantee it runs at the end of a scope. For a language with explicit lifetimes though, it’s a great idea.

Don’t these still require you to opt-in to the correct behavior? You can just forget to use those constructs too.

This is not “right by default” though. I’ve reviewed (and requested changes to) plenty of Ruby code that uses file = File.open(path) because the choice of using the block API is opt-in. If Ruby was “right by default” no one would have spent cycles on the issue at all.

RAII style is similar too, just without an additional nesting/indentation, unlike python or ruby.

What happens if I store that file variable in a global variable? Can I still try and read/write to it, resulting in runtime errors? It’s certainly more right than an explicit open/close pair.

The problem with finaliser-based cleanup is that it relies on GC being run promptly. You can’t use it for things like lock release because it will run an unbounded amount of time in the future. It’s dangerous to use it for file descriptor cleanup because you can rapidly accept a lot of connections and then drop the last reference to the file descriptor object but if the GC doesn’t catch up fast enough then you don’t close the file descriptors and the will hit OS-defined limits (in the worst case, consume a lot of kernel resources in the best case). The Java documentation explicitly tells you not to use finalisers for file descriptor cleanup except as a last resort (i.e. if you’ve accidentally forgotten to close an open descriptor) for precisely this reason.

What would happen if you have a GC’d container of refcounted objects, like say an ArrayList<File>? When the ArrayList becomes unreachable, it won’t decrement the refcount on the Files right away, so the Files wouldn’t be released deterministically.

Maybe the compiler should specialize ArrayList<File> so that the whole thing is refcounted?

Early Rust was going to be this way, IIRC.

Go’s and Zig’s defer are rather different beasts Go runs defered statements at the end of the function, Zig at the end of scope. ant to lock a mutex insife a loop? Can’t use Go defer for that..

This distinction doesn’t really matter in a language with first-class lambdas. If you want to unlock a mutex at the end of a loop iteration with Go, create and call a lambda in the loop that uses defer internally.

destructors can’t take arguments or return values

But constructors can. If you implement a Defer class to use RAII, it takes a lambda in the constructor and calls it in the destructor.

hidden code all defer code is visible in the scope

I’m not sure I buy that argument, given that the code in defer is almost always calling another function. The code inside the constructor for the object whose cleanup you are defering is also not visible in the calling function.

The first point is minor, and not really changing the overall picture of leaking by default.

Destruction with arguments is sometimes useful indeed, but there are workarounds. Sometimes you can take arguments when constructing the object. In the worst case you can require an explicit function call to drop with arguments (just like defer does), but still use the default drop to either catch bugs (log or panic when the right drop has been forgotten) or provide a sensible default, e.g. delete a temporary file if temp_file.keep() hasn’t been called.

Automatic drop code is indeed implicit and can’t be grepped for, but you have to consider the trade-off: a forgotten defer is also invisible and can’t be grepped for either. This is the change in default: by default there may be drop code you may not be aware of, instead of by default there may be a leak you may not be aware of.

destructors can’t take arguments or return values. While most destructions only release acquired resources, passing an argument to a deferred call can be very useful in many cases.

Yes, more than useful:

• Zero-cost abstraction in terms of state: A deferred call doesn’t artificially require objects to contain all state needed by their destructors. State is generally bad, especially references, and especially long lived objects that secretly know about each other.
• Dependencies are better when they are explicit: If one function needs to run before another, letting it show (in terms of what arguments they require) is a good thing: It makes wrong code look wrong (yes, destruction order is a common problem in C++) and prevents it from compiling if you have lifetimes like Rust.
• Expressiveness: In the harsh reality we live in, destructors can fail.

I think the right solution is explicit destructors: Instead of the compiler inserting invisible destructor calls, the compiler fails if you don’t. This would be a natural extension to an explicit language like C – it would only add safety. Not only that: It fits well with defer too – syntactic sugar doesn’t matter, because it just solves the «wrong default» problem. But more than anything, I think it would shine in a language with lifetimes, like Rust, where long lived references are precisely what you don’t want to mess with.

You could run an anonymous function within a loop in Go, just to get the per-loop defer. Returning a value in a defer is also possible.

func main() (retval int) {
    for {
        func() {
            // do stuff per loop
            defer func() {
                // per loop cleanup
            }()
        }()
    }
    defer func() {
        retval = 42
    }()
    return
}

For me, the point of the article was that if it’s opt-in, it’s “wrong by default”. Leaving that aside, I feel like it’s a bad idea generally to have different “modes” for programming languages. If I’m looking at some piece of code, I have to remember what mode it works in to know if it’s correct; I have to be much more careful in copying chunks of code around, as well (sure, “shouldn’t do that”, but it happens).

That particular example is not a problem with RAII though, it is specific to API of shared_ptr and C++ flexible evaluation order.

This should be fixed in C++17, at least partially. TL;DR – see the “The Changes” section.

https://www.cppstories.com/2021/evaluation-order-cpp17/

As that article points out, this is solved in C++11 with std::make_shared: any raw construction of std::shared_ptr is code smell. This kind of footgun is not really intrinsic to RAII, but to the way that C++ reports errors from constructors: the only mechanism is via an exception, which means that anything constructing an object as an argument needs to be excitingly exception safe. The usual fix for this is to have factory methods that validate that an object can be constructed from the arguments and return an option type.

The more subtle footgun with RAII is that it requires the result to be bound to a variable that is not necessarily used. In C++, you can write something like:

{
  std::lock_guard(mutex);
  // Some stuff that expects the lock to be held
} // Expect the lock to be released here.

Only, because you didn’t write the first line as std::lock_guard g{mutex} you’ve locked and unlocked the mutex in the same statement and now the lock isn’t held. I think the [[nodiscard]] attribute on the constructor can force a warning here but I’ve seen this bug in real-world code a couple of times.

The root cause here is that RAII isn’t a language feature, it’s a design pattern. The problem with a defer statement is that it separates the initialisation and cleanup steps. A language that had RAII as a language feature would want something that allowed a function to return an object that is not destroyed until the end of the parent scope even if it is not bound to a variable.

It would be intetto have a language with “explicit RAII”. You can define a destructor, but instead of calling it for you the compiler just complains if you forget to call it. This way it would be visible in your code (likely with a defer statement) but hard to forget.

when calling C libraries

When interfacing with a C library in C++ or Rust one of the first things I tend to do is make small wrappers for resources that implement RAII for them. I find they pays off very quickly in terms of productivity and correctness. Even if I don’t wrap much else this is very useful.

Exceptions, maybe?

To be honest how would you like to handle that situation in your program? Terminate it completely? Retry closing? What if you can’t close the file at all? This is one of those scenarios where error handling isn’t obvious.

On the other hand I want language that use RAII but has support for linear types, where you are forced by the type system to close it manually, otherwise it will fail to compile.