[Issue 9468] New: dup does not postblit

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Feb 7 02:03:26 PST 2013


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

           Summary: dup does not postblit
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: critical
          Priority: P2
         Component: DMD
        AssignedTo: nobody at puremagic.com
        ReportedBy: monarchdodra at gmail.com


--- Comment #0 from monarchdodra at gmail.com 2013-02-07 02:03:20 PST ---
All the title. This seems like an obvious bug, but was not able to find a
similar entry, so I'm filing it:

//----
struct S
{
    int i;
    this(this)
    {
        assert(0);
    }
    void opAssign(S)
    {
        assert(0);
    }
}

void a() @safe
{
    S[] s = [S(1), S(2)];
    s = s.dup;
}
//----

Runs fine. It shouldn't even compile (@safe can't call postblit). If you were
to try to put a struct with "deep copy" semantics in an array and dup that
array, things will not end well.

Marking as critical because, well, calling postblit when copying something
seems like the *minimal* amount of work that needs to be done.

See also:
http://d.puremagic.com/issues/show_bug.cgi?id=8409 : Proposal: implement
arr.dup in library
This would be an easy fix, since a library implementation *should* have compile
time access to postblit.

And:
http://d.puremagic.com/issues/show_bug.cgi?id=5700 :
http://d.puremagic.com/issues/show_bug.cgi?id=5700 : Allow dup in nothrow
functions
This one mentions that being nothrow depends on whether or not the postblit is
nothrow, but apparently, it doesn't even get called. Note that dup is marked as
safe though (which, in this case, it shouldn't be.)

-- 
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