I think a "defer" or "on scope exit" statement is just about ideal, gets you the same benefits but much more simply.
What constructor? And why would a Drop implementation be invoked to move something? You've moved it, there's nothing left to drop.
> Did you use the copy-and-swap idiom properly?
I don't believe I'm familiar with this idiom? From some quick googling this seems to be related to panic safety and ensuring that you don't leave things in an invalid state if a panic happens. It doesn't seem to be RAII-specific, and would also apply to a defer mechanism.
> Did you define all the "rule of five" methods?
Rule of five? You mean that your Clone implementation must properly handle resources in accordance with your Drop implementation, right? I'm not sure where the other three come in?
But I suspect any system with constructors / destructors leads to a lot of the same implicit behaviors, unintended complications, and leaky abstractions, and I generally favor explicit Initialize() and Cleanup() functions that you call manually, even in languages that support the implicit/magic stuff.
* Well, it kind of does, in so far there is a Ctor enum variant in the compiler implementation to represent the name of a type in the value namespace, but it is not overridable by end users and has no logic.
The only thing that RAII requires is the concept of ownership, and a cleanup function that the compiler knows about. The one implicit thing here is the automatic insertion of calls to the cleanup function.
defer does not get you the same benefits as a destructor because you can easily forget to write a defer, while destructors are always called.