Comment #0 by bearophile_hugs — 2011-03-04T15:09:52Z
In DMD 2.052 it's allowed to create a new dynamic array inside nothrow functions, this compiles and works:
nothrow void foo(int[] a) {
auto b = new int[a.length];
b[] = a[];
}
void main() {}
But this almost equivalent code isn't accepted:
nothrow void foo(int[] a) {
a.dup;
}
void main() {}
DMD 2.052 shows:
test.d(2): Error: _adDupT is not nothrow
test.d(1): Error: function test.foo 'foo' is nothrow yet may throw
I suggest to let it accept the dup inside nothrow functions too.
Comment #1 by issues.dlang — 2011-03-04T15:27:01Z
Actually, I think that it depends. For primitives and classes, dup should definitely be allowed. However, for structs, they'd need a postblit which was nothrow (if they had one), and they'd all of their member variables to either be classes or primitives or be structs which... recursion. So, you can't just blindly make the duping of arrays nothrow, but yes, it should generally be legal to dup arrays in nothrow functions. It's just a bit more complicated when dealing with structs.
Comment #2 by bearophile_hugs — 2011-03-04T16:11:05Z
I see, thank you for your comment. Then dup has to be conditionally nothrow, and we go back to issue 5125. (There is no need for dup to be a template, the conditional nothrow may work on normal functions too, I think).
Comment #3 by bearophile_hugs — 2011-03-07T16:21:27Z
(In reply to comment #1)
> Actually, I think that it depends. For primitives and classes, dup should
> definitely be allowed. However, for structs, they'd need a postblit which was
> nothrow (if they had one), and they'd all of their member variables to either
> be classes or primitives or be structs which... recursion. So, you can't just
> blindly make the duping of arrays nothrow, but yes, it should generally be
> legal to dup arrays in nothrow functions. It's just a bit more complicated when
> dealing with structs.
Just want to point out http://d.puremagic.com/issues/show_bug.cgi?id=9468 : dup does not call postblit.
So at this point, *that* issue needs to be fixed before dup can even try to conditionally be nothrow (or @safe)
Comment #5 by monarchdodra — 2013-02-07T03:05:13Z
(In reply to comment #4)
> (In reply to comment #1)
> > Actually, I think that it depends. For primitives and classes, dup should
> > definitely be allowed. However, for structs, they'd need a postblit which was
> > nothrow (if they had one), and they'd all of their member variables to either
> > be classes or primitives or be structs which... recursion. So, you can't just
> > blindly make the duping of arrays nothrow, but yes, it should generally be
> > legal to dup arrays in nothrow functions. It's just a bit more complicated when
> > dealing with structs.
>
> Just want to point out http://d.puremagic.com/issues/show_bug.cgi?id=9468 : dup
> does not call postblit.
>
> So at this point, *that* issue needs to be fixed before dup can even try to
> conditionally be nothrow (or @safe)
Wait, never mind, ignore me.
Comment #6 by verylonglogin.reg — 2013-10-02T04:34:27Z
Inability to `dup`/`idup` in `nothrow` functions is very frustrating. I'd say this is the most [one of few] PITA of `nothrow` issues for now.
Comment #7 by bugzilla — 2014-05-09T05:24:17Z
This is working in 2.066 head.
Comment #8 by github-bugzilla — 2015-01-01T13:08:08Z