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.

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.

On Wednesday, 22 October 2014 at 20:15:57 UTC, 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.
>
> 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 can understand that, but it does seem a bit risky in this case. The suggestion of creating a warning for it seems like a good one, since it allows you to debug like that but needles you to not leave it that way.

- Jonathan M Davis

On 10/22/2014 1:28 PM, Jonathan M Davis wrote:
> I can understand that, but it does seem a bit risky in this case. The suggestion
> of creating a warning for it seems like a good one, since it allows you to debug
> like that but needles you to not leave it that way.

I don't want deliberately written debug code to produce needling warnings. The Boy Who Cried Wolf comes to mind. The feature provides for a valid use case, one that is pretty hard to do any other way.

Such warnings should go into a separate linting tool.

On Wednesday, October 22, 2014 14:10:02 Walter Bright via Digitalmars-d wrote:
> On 10/22/2014 1:28 PM, Jonathan M Davis wrote:
> > I can understand that, but it does seem a bit risky in this case. The
> > suggestion of creating a warning for it seems like a good one, since it
> > allows you to debug like that but needles you to not leave it that way.
>
> I don't want deliberately written debug code to produce needling warnings.
> The Boy Who Cried Wolf comes to mind. The feature provides for a valid use
> case, one that is pretty hard to do any other way.
>
> Such warnings should go into a separate linting tool.

That's actually one of the few cases where I would have said that actually having a warning made sense as opposed to making it an error or leaving it to a lint tool. Since no one should be leaving warnings in their code, it seems to me that having a warning for something that's temporarily okay to do but not okay to leave in your code is just about the only valid use case for warnings (particularly if deprecation-related stuff is separate like it is in D). So, I'd definitely be in favor of having a warning in this case, but I don't care enough to fight for it either, particularly since I almost never use debug blocks (though their ability to bypass pure will probably make it so that I use them at least periodically).

- Jonathan M Davis

On Wednesday, 22 October 2014 at 21:10:06 UTC, Walter Bright wrote:
> I don't want deliberately written debug code to produce needling warnings.

You should have an overriding option on the command line to turn off all debugging. Having debug statements in release code is a no-go.

> The Boy Who Cried Wolf comes to mind. The feature provides for a valid use case, one that is pretty hard to do any other way.
>
> Such warnings should go into a separate linting tool.

I think warnings built into the compiler is a good feature for catching common mistakes. I use it often and find it much more attractive than lint, which I would only use if stuck on a bug.

It is also GREAT for NEW USERS to have a "-pedantic", "-Wall" and even an "-idiomatic" option built into the compiler.

Arguments against two binaries:

- Newbies will never user lint and they NEED heavy-duty warnings.

- There is zero advantage to having two binaries for the end user.

- Having two binaries means that IDEs will only bother to support the compiler.

- It is slower. Having two binaries means that you have to make two passes, first lint then compiler.

- A linting tool cannot keep pace with the compiler. If devs report a feature as a bug, it is candidate for builtin warning.

- Not providing helpful warning options makes the compiler look unfinished and of low quality. Without developers will blame the compiler devs for lost time, not themselves.


Arguments for two binaries:

- It is easier for the implementor.

- Too early to add warnings to dmd since the language will change a lot.

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

"Steven Schveighoffer"  wrote in message news:m2avtc$15e3$1@digitalmars.com...

> 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).

Exactly.

> 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.

What if you leave any other form of debug code enabled by accident?  The answer is to use version control, and make a quick pass over changes before you commit. 

On 10/23/2014 11:40 AM, Daniel Murphy wrote:
> "Steven Schveighoffer"  wrote in message news:m2avtc$15e3$1@digitalmars.com...
>> 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.
>
> What if you leave any other form of debug code enabled by accident?  The answer
> is to use version control, and make a quick pass over changes before you commit.

Version control has been successful at eliminating such mistakes in my experience with github.

On 10/23/2014 12:31 PM, Walter Bright via Digitalmars-d wrote:
> Version control has been successful at eliminating such mistakes in my
> experience with github.

Not eliminating, but with many eyes watching the flow of changes, at least relatively easy to catch.

On 2014-10-23 20:40, Daniel Murphy wrote:

> What if you leave any other form of debug code enabled by accident?  The
> answer is to use version control, and make a quick pass over changes
> before you commit.

Perhaps something for a lint tool as well.

-- 
/Jacob Carlborg