On 10/22/14 4:15 PM, Walter Bright wrote:
On 10/22/2014 1:04 PM, Jonathan M Davis wrote:
Yeah, being able to just enable the debug blocks from within the code
like
that seems questionable to me and has nothing to do with debug blocks
disabling pure functions. It just makes for a nastier side effect when
debug
blocks are enabled within the code rather than via the command-line.

Lots of people (like me, though I'm often told I'm a unique snowflake
and nobody programs like me) debug code by editting the source code to
enable/disable debug code rather than messing with the makefile.

This is a good point. Enabling debug on a specific feature/module in a complex build system is not easy. For someone simply typing dmd *.d, this is trivial, but not if you have to go edit a makefile, or try to figure out how to pass arguments to it (I need to look that up every time).


Take a look at about any source file in dmd, for example, with the
commented out printf's, and template.c, with the file scope #define LOG 0.

D needs to support this style of debugging, and the 'debug' conditional
with how it is set is just the ticket. The feature works as designed and
intended.

I think there is a problem though. What if you leave your debug in by accident? Now your pure code isn't so pure, and you have no idea.

As we all know from "const-by-convention" C++, if there is an easy way to "get around" something that the compiler makes difficult, people will exploit it. I would hate to see someone using this "feature" to simply make something impure pure so they can get it to compile.

I propose a compromise. By default, the compiler emits warnings when debug=x is executed, AS LONG AS it's not inside a debug block already enabled by a command line debug directive. However, if the compiler has any of the following switches, then then warnings are suppressed:

-unittest
-g
-gc
-debug

The theory being, you are testing the code with these switches, not releasing it. This way, you can add your debug=x enablers when doing make debug or make unittest, but once you go to make release, you get the warning.

Optionally, we could have a dedicated switch to suppress these warnings.

Does this sound reasonable?

-Steve

Reply via email to