[dparoski]

Hmm, IMHO it feels like you're bending the definition of "lifetime" a bit in a manner that already presumes RC-based automatic memory management, and once one accepts that assumption then naturally one concludes that the lifetime ends when refcounting says it ends. To me, the lifetime of a heap allocated thing effectively ends when it is no longer reachable via any existing variables (though perhaps this definition is biased towards a tracing-GC view of the world).

I agree with your points about "finally". It can definitely be a bit clunky, and this is why some languages have introduced scoped cleanup constructs such as C#'s "using" statement, Python's "with" statement, and D's "scope" statement. I guess what I was getting at with my original comment is that I feel scoped cleanup constructs are a better way to go vs. relying on heap allocated things being reclaimed at a certain time, given that the lifetime of a heap allocated thing can depend on non-local state outside of the current function/method.

[wvenable]

I completely agree with your definition. All that RAII needs is that the destructor be called the instant that the object is no longer reachable. With reference counting, that is the case (the object is freed when the refcount reaches zero). But with many other forms of GC (including tracing) that isn't the case -- a process eventually cleans up unreachable objects and the order of that cleanup is indeterminate.

Even scoped cleanup constructs are problematic. I often forget to use them when needed in C# and it's often hard to tell if an object needs it. Furthermore, implementators of IDiposable in C# have to write a lot of boilerplate code[1] to do disposable correctly and cascade disposing to every contained object (again determining if it's necessary). It's also not change friendly -- a class might not need to be disposed today but if changed later all the existing instantiating code won't have guards.

I'm not sure why you think the the lifetime of heap allocated objects under RAII is an issue -- they'll just clean themselves up when they're not needed. It's much less worry and code. What issue do you think exists?

As for Scoped cleanup constructs, they are just hack for languages that can't do RAII -- they have no other benefit.

[1] http://msdn.microsoft.com/en-us/library/b1yfkh5e%28v=vs.110%...