[Issue 9139] New: `destroy` is dangerous and inconsistent

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Dec 10 11:40:29 PST 2012


http://d.puremagic.com/issues/show_bug.cgi?id=9139

           Summary: `destroy` is dangerous and inconsistent
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: wrong-code
          Severity: critical
          Priority: P2
         Component: druntime
        AssignedTo: nobody at puremagic.com
        ReportedBy: verylonglogin.reg at gmail.com


--- Comment #0 from Denis Shelomovskij <verylonglogin.reg at gmail.com> 2012-12-10 22:40:28 MSK ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list