| |
| Posted by monarchdodra@gmail.com | PermalinkReply |
|
monarchdodra@gmail.com
| 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@puremagic.com
ReportedBy: monarchdodra@gmail.com
--- Comment #0 from monarchdodra@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: -------
|