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.)
Comment #1 by maxim — 2013-02-07T02:37:12Z
I have assetion failure on windows 2.061 on the sixth line. Which environment do you use?
Comment #2 by monarchdodra — 2013-02-07T03:04:54Z
(In reply to comment #1)
> I have assetion failure on windows 2.061 on the sixth line. Which environment
> do you use?
Herp derp. I'm an idiot. Looks like I was running dmd, and not my usual rdmd, which could explain why it was "running" so good.