www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5700] New: Allow dup in nothrow functions

reply d-bugmail puremagic.com writes:
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



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: -------
Mar 04 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5700


Jonathan M Davis <jmdavisProg gmx.com> changed:

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



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: -------
Mar 04 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5700




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: -------
Mar 04 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5700




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: -------
Mar 07 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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





 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: -------
Feb 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5700








 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: -------
Feb 07 2013
prev sibling parent d-bugmail puremagic.com writes:
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



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: -------
Oct 02 2013