You are assuming the thing can drop itself. When that is fine, sure, do RAII. But not all cases can be done that way.
For example, the Rust allocators working group has been contorting itself about deallocation. The right thing to do is to not store a pointer to a (de)allocator in e.g. every Box<T, A>, but just pass the (de)allocator when it comes time to deallocate a box. But Rust is completely incapable of expressing this and so we will get some crazy epicycle thing instead, or no good support for custom allocators with non-flat data structures.
Even if RAII is the 90% solution I think it is still good to layer the feautres in this way:
1. Linear types. Fundamental building block for that some types one cannot just forget the values.
2. Defer, sugar for scope-based running some code that will eliminate a linear variable. avoiding an error.
3. RAII, a way to fill provide a default defer command if none was manually provided. Default is "type driven" --- we associate a default defer command with the linear type that would be dropping.
From a Rust Perspective, we would want to distinguish Clone (an arbitrary convention for cloning) from Copy (and indication we can in fact copy for free. Saying types that need a destructor and types that don't are both affine is like adding some .clone() sugar and erasing the Copy--Clone distinction --- It is erasing a lot of essential nuance/complexity and I don't think a good idea.
For example, the Rust allocators working group has been contorting itself about deallocation. The right thing to do is to not store a pointer to a (de)allocator in e.g. every Box<T, A>, but just pass the (de)allocator when it comes time to deallocate a box. But Rust is completely incapable of expressing this and so we will get some crazy epicycle thing instead, or no good support for custom allocators with non-flat data structures.
Even if RAII is the 90% solution I think it is still good to layer the feautres in this way:
1. Linear types. Fundamental building block for that some types one cannot just forget the values.
2. Defer, sugar for scope-based running some code that will eliminate a linear variable. avoiding an error.
3. RAII, a way to fill provide a default defer command if none was manually provided. Default is "type driven" --- we associate a default defer command with the linear type that would be dropping.
From a Rust Perspective, we would want to distinguish Clone (an arbitrary convention for cloning) from Copy (and indication we can in fact copy for free. Saying types that need a destructor and types that don't are both affine is like adding some .clone() sugar and erasing the Copy--Clone distinction --- It is erasing a lot of essential nuance/complexity and I don't think a good idea.