http://d.puremagic.com/issues/show_bug.cgi?id=10854
--- Comment #2 from [email protected] 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: -------
