On 10/23/14 2:40 PM, 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.

This is kind of an absurd statement when you have clearly marked a line as being for debugging only. If only there were some automated tool that could detect this when you are compiling for release and flag it as an issue?

-Steve

On 10/23/14 3:31 PM, Walter Bright wrote:
> 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 your own 1-person projects, or just with 2+ reviewers for every commit?

In my experience, source control does not stop me from committing debug code by accident.

Seriously, the idea of "just avoid committing mistakes" or "just use x version control system" is not a very palatable answer.

-Steve

On Friday, 24 October 2014 at 12:45:21 UTC, Steven Schveighoffer wrote:
> On 10/23/14 3:31 PM, Walter Bright wrote:
>> 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 your own 1-person projects, or just with 2+ reviewers for every commit?
>
> In my experience, source control does not stop me from committing debug code by accident.
>
> Seriously, the idea of "just avoid committing mistakes" or "just use x version control system" is not a very palatable answer.

I usually use `git add -p` to review my changes before I commit them. But this doesn't prevent anything from slipping through by accident from time to time.

Maybe a hook could reject lines that contain `debug\s*=`? Or are you thinking about a manual review of every commit before each release?

On 10/24/14 9:08 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Friday, 24 October 2014 at 12:45:21 UTC, Steven Schveighoffer wrote:
>> On 10/23/14 3:31 PM, Walter Bright wrote:
>>> 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 your own 1-person projects, or just with 2+ reviewers for every
>> commit?
>>
>> In my experience, source control does not stop me from committing
>> debug code by accident.
>>
>> Seriously, the idea of "just avoid committing mistakes" or "just use x
>> version control system" is not a very palatable answer.
>
> I usually use `git add -p` to review my changes before I commit them.
> But this doesn't prevent anything from slipping through by accident from
> time to time.
>
> Maybe a hook could reject lines that contain `debug\s*=`? Or are you
> thinking about a manual review of every commit before each release?

My proposal is to have the compiler reject such code unless one of the debugging switches is present on the command line. If you aren't debugging, don't compile code that is marked as "only compile during debugging." I don't think it's that complex or controversial.

-Steve

On Friday, 24 October 2014 at 13:15:45 UTC, Steven Schveighoffer wrote:
> My proposal is to have the compiler reject such code unless one of the debugging switches is present on the command line. If you aren't debugging, don't compile code that is marked as "only compile during debugging." I don't think it's that complex or controversial.
>
> -Steve

IMHO it should at least emit a warning. I understand how it can be useful from Walter's previous example but the enabling switch belongs on the command line, not in code.

I use this pattern somewhar often:

version(unittest)
{
    debug = ExtraCostlySanityChecks;
}

On 10/26/14 3:15 AM, Dicebot wrote:
> I use this pattern somewhar often:
>
> version(unittest)
> {
>      debug = ExtraCostlySanityChecks;
> }

My proposal covers this, it would still be fine:

http://forum.dlang.org/post/m2avtc$15e3$1@digitalmars.com

-Steve