# RAII

RAII — Resource Acquisition Is Initialization — is the discipline of tying a resource's lifetime to an object's lifetime. The constructor acquires the resource (memory, file descriptor, lock, socket); the destructor releases it. As long as the object is destroyed deterministically, the resource is released deterministically. No `try`/`finally`. No paired-call discipline at every call site.

The name is misleading enough that even Stroustrup later called it a poor choice — what matters is the destructor running, not the constructor doing acquisition. "Scoped resource management" describes it more honestly. But the acronym stuck.

## The shape

A type wraps a resource. Its constructor acquires; its destructor releases; copy and move semantics make ownership explicit at the type level. Anyone holding the object holds the resource; when the object dies, the resource is freed. C++ destructors fire on scope exit, on exception unwinding, on container element removal, and on smart-pointer reset — uniformly, without programmer attention.

The standard library's `unique_ptr`, `shared_ptr`, `lock_guard`, `fstream`, `vector`, and `string` are all RAII types. So is every Rust type with a `Drop` impl — Rust took RAII as a baseline and made it the only memory-management story.

## Why it works

The argument [[stroustrup-memory-leaks]] makes is operational, not aesthetic: a human can track a few dozen objects, not tens of thousands of allocations. RAII collapses the bookkeeping. Once a resource has an owner, the question of *who frees it* becomes the question of *who owns it*, and ownership is visible at the type signature. Pointer-arithmetic code answers neither question; RAII code answers both by construction.

This generalizes beyond memory. File handles, mutex locks, database transactions, GPU resources, and reference counts all share the acquire/release pattern. RAII is the encoding of that pattern in the type system.

## What it requires from the language

RAII needs deterministic destruction — destructors that fire at known points (scope exit, container removal, smart-pointer reset), not "eventually, when GC notices." Languages with non-deterministic finalizers (Java, Python, Go) cannot do RAII directly; they fall back to `try`-with-resources, `with` blocks, or `defer`, all of which require the programmer to remember to opt in.

Garbage-collected languages can manage memory without RAII because memory is fungible — slightly delayed reclamation is fine. They cannot manage *non-fungible* resources (file handles, locks, network sockets) the same way, which is why Java grew `try`-with-resources and Python grew context managers. RAII is the C++/Rust answer to the same problem, applied uniformly.

## Connections

- [[stroustrup-memory-leaks]] — the canonical short statement of RAII as memory-leak prevention
- [[simplified-model-of-fil-c]] — Fil-C bolts memory safety onto C/C++ via GC because the discipline of RAII isn't enforceable in legacy code
- [[pointer-provenance]] — pointers carry allocation identity; RAII puts that identity inside an owning type
- [[no-silver-bullet]] — RAII is one of the rare attacks on accidental complexity that produced an order-of-magnitude reduction in a specific bug class