Right, and those destructors get called at the of the variable's scope.
Is there a reason why it's not well-founded to consider scopes to be regions?
Is there a reason why it's not well-founded to consider scopes to be regions?
You're running into a colloquial vs formal distinction, I think. Yes, a scope is a "region" in the sort of general sense, but in PLT, "region based memory management" is jargon: https://www.cs.umd.edu/projects/cyclone/papers/cyclone-regio...
If you check 2.1 of that paper, you'll see it's something sort of like "arenas with optional GC if you want to reclaim memory", which is quite different than what Rust does by default.
What would be the appropriate description for Rust's memory model? Automatic scoped memory management with opt-in reference counting?
Memory management is the correct term. Rust the language does not do any memory management: memory management is a feature of the standard library. I would say that the Rust standard library (the `alloc` crate specifically) provides types that safely encapsulate allocation and deallocation of memory.
This is enabled by automatic destructor calls on stack-allocated variables when they go out of scope. (However, note that destructors need not deallocate memory).
Again, this part works exactly the same in C++. In C++ when a type's constructor acquires some resource, and its destructor releases that resource (in this case the resource being memory) it is referred to as "Resource Acquisition Is Initialization" or RAII.
And to certain extent, C++ has influenced Turbo Pascal/Delphi as well with similar approach.
"Garbage collection" implies dynamic lifetime determination.
Rust's ownership system is static lifetime determination.
For those instances where dynamic lifetime determination is necessary, Rust provides types like Rc (which can be considered a very rudimentary garbage collector).
It does not. It refers to automatic memory reclamation.
Generally, memory reclamation policies (whether automatic or manual) are closely tied to lifetimes—a sound program does not attempt to reuse objects which are still alive—but that is incidental in this context. In rust, programs generate garbage, do not explicitly clean it up or free it, and it is reused for new allocations; that is garbage collection.
Reference counting, far from rudimentary, is a highly effective means of garbage collection which works quite well for certain types of programming languages and programs. (Notable examples include switch/objc, nim, and apl.) It has fallen out of favour in recent times because popular languages in industry and academia encourage execution patterns that perform much better with tracing garbage collectors, but that is not in itself a mark against reference counters.