Bug 9139 – `destroy` is dangerous and inconsistent

In our root `object` module we have a function "to reclaim non-memory resources without compromising memory safety" (yes, its a correct definition as it is what Andrei said and what it really do). The problem is that it works not only for classes but also for all other types and behaves differently for each type. As an example of the current situation danger consider the following code (an `std.algorithm.move` implementation): --- void move(T)(ref T source, ref T target) in { assert(&source == &target || !pointsTo(source, source)); } body { if (&source == &target) return; static if (hasElaborateDestructor!T) destroy(target); static if (hasElaborateAssign!T || !isAssignable!T) memcpy(cast(void*) &target, cast(const void*) &source, T.sizeof); else target = source; static if (hasElaborateCopyConstructor!T || hasElaborateDestructor!T) ... // set `source` to its `init` state here } --- This code compiles fine. And it looks fine not only for D newbies but also for rather skilled programmers. It also behaves fine in some cases. But it will do unpredictable things in other cases.

A proposal how to fix this: 1. Create a function that equals to "out of scope" action as proposed in Issue 9137. 2. Remove any "out of scope" behavior from `destroy`. 3. Note in `destroy` documentation that it doesn't do any "out of scope like" actions and one have to use other function for such manual lifetime implementation.

(In reply to Denis Shelomovskii from comment #0) > It also behaves fine in some cases. But it > will do unpredictable things in other cases. This bug report is close to useless due to vague language like that. As it was filed close to 5 years ago, and Object.destroy has received updates since then, I am going to close this, but please reopen if you think this is still an issue and can present concrete examples of problematic code.