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

           Summary: Allow dup in nothrow functions
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: druntime
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2011-03-04 15:09:52 PST ---
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.

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

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


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #1 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-03-04 15:27:01 PST ---
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.

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

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



--- Comment #2 from bearophile_hugs@eml.cc 2011-03-04 16:11:05 PST ---
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).

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

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



--- Comment #3 from bearophile_hugs@eml.cc 2011-03-07 16:21:27 PST ---
See also:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=25400

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

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


monarchdodra@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra@gmail.com
           See Also|                            |http://d.puremagic.com/issu
                   |                            |es/show_bug.cgi?id=9468


--- Comment #4 from monarchdodra@gmail.com 2013-02-07 02:10:00 PST ---
(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)

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

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



--- Comment #5 from monarchdodra@gmail.com 2013-02-07 03:05:13 PST ---
(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.

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

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


Denis Shelomovskij <verylonglogin.reg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verylonglogin.reg@gmail.com
           Platform|x86                         |All
         OS/Version|Windows                     |All


--- Comment #6 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-10-02 15:34:27 MSD ---
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.

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