www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10854] New: debug should also bypass safety and nothrow

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10854

           Summary: debug should also bypass safety and nothrow
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: monarchdodra gmail.com


--- Comment #0 from monarchdodra gmail.com 2013-08-19 08:42:51 PDT ---
debug instructions/blocks were allowed to nicely bypass function purity. This
allows inserting impure calls for testing reasons inside pure functions.

This should be expanded for  safe and nothrow. Its really a natural evolution
IMO.

There is nothing more annoying than inserting a test "writeln()" in a function,
only to be refused because said function is  safe or nothrow.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 19 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10854


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc


--- Comment #1 from bearophile_hugs eml.cc 2013-08-19 09:21:47 PDT ---
(In reply to comment #0)

 debug instructions/blocks were allowed to nicely bypass function purity. This
 allows inserting impure calls for testing reasons inside pure functions.
 
 This should be expanded for  safe and nothrow. Its really a natural evolution
 IMO.
If in module A you call a nothrow function F from module B, and you pre-compile module A with aggressive optimizations that rely on F never throwing, and then you run the module B in debug mode and now the function F throws, what does it happens? If F is also tagged with 'pure' and when you debug B you call something not pure, like printf(), inside the debug{}, the optimizations of the compilation of the module A could cause some of those calls to printf() to never happen. But if the code inside debug{} is well behaved this doesn't cause significant problems. Peraphs with nothrow the situation is worse.
 There is nothing more annoying than inserting a test "writeln()" in a function,
 only to be refused because said function is  safe or nothrow.
For that I try to use printf(), that is nothrow. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 19 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10854



--- Comment #2 from monarchdodra gmail.com 2013-08-19 10:40:40 PDT ---
(In reply to comment #1)
 (In reply to comment #0)
 
 debug instructions/blocks were allowed to nicely bypass function purity. This
 allows inserting impure calls for testing reasons inside pure functions.
 
 This should be expanded for  safe and nothrow. Its really a natural evolution
 IMO.
If in module A you call a nothrow function F from module B, and you pre-compile module A with aggressive optimizations that rely on F never throwing, and then you run the module B in debug mode and now the function F throws, what does it happens?
If the *context* of the debug instruction is nothrow, then the debug could be automatically expanded to try {BODY} catch (Exception e){assert(0, format"Exception %s was thrown from a debug clause in a nothrow context");} Or something with "scope(failure)", to avoid scoping the debug instruction/
 If F is also tagged with 'pure' and when you debug B you call something not
 pure, like printf(), inside the debug{}, the optimizations of the compilation
 of the module A could cause some of those calls to printf() to never happen.
But that is what we already have. Also, I don't think the new pure definitions mean a pure function can be outright optimized out. But I'm unsure.
 But if the code inside debug{} is well behaved this doesn't cause significant
 problems. Peraphs with nothrow the situation is worse.
 
 
 There is nothing more annoying than inserting a test "writeln()" in a function,
 only to be refused because said function is  safe or nothrow.
For that I try to use printf(), that is nothrow.
That is indeed a workaround, but much less powerful than a writef. It is also a workaround to something (IMO) you shouldn't have to. But thanks for the tip. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 19 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10854



--- Comment #3 from bearophile_hugs eml.cc 2013-08-19 13:05:40 PDT ---
(In reply to comment #2)

 Also, I don't think the new pure definitions
 mean a pure function can be outright optimized out. But I'm unsure.
The DMD compiler completely optimizes out strongly pure functions in some situations. And I expect better optimizers to remove some more calls. Observe: import std.stdio; int sqr(in int x) pure nothrow { debug printf("sqr\n"); return x ^^ 2; } int twoSqr(in int x) pure nothrow { return sqr(x) + sqr(x); } void main() { writeln(twoSqr(3)); } ...>dmd -debug -run test.d sqr sqr 18 ...>dmd -O -release -debug -run test.d sqr 18 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 19 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10854


monarchdodra gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


--- Comment #4 from monarchdodra gmail.com 2013-08-20 08:48:31 PDT ---
*** This issue has been marked as a duplicate of issue 8464 ***

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