www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A Small Enhancement Idea

reply "Jack Stouffer" <jack jackstouffer.com> writes:
I wanted some second opinions on an idea I had for D before I 
made a bugzilla issue.

Currently in D, to have a statement run only in debug mode, you 
can mark it with the debug keyword. But, there is currently no 
way to mark a statement so that it only runs in release. So what 
I propose is a release statement like so:

debug {
     // only runs when -debug is given
}

release {
     // only runs when -release is given
}

Or, if adding a new keyword to the language is a no go, it could 
be done like so:

debug {
     // only runs when -debug is given
} else {
     // only runs when -release is given
}

I have run into a need for this twice in one day, both having to 
do with unit tests in phobos. For the first one, I needed a way 
to make sure that a function is  nogc in release. For the other, 
the function I was tested had different outputs for release and 
debug if the input was an empty range, and I had no way to test 
both cases.

I can think of several other use cases off the top of my head. 
One, If you have a GUI application that checks for a serial 
number on startup, there's no reason to do that check in a debug 
build. Or, if your making a game, there's no reason to do the 
opening logo crawl before the menu if your using debug mode.

A rebuttal to this might be to just use version and pass 
something in during compilation. The problem that I have is this 
is not a solution for the phobos code that I am working on. Also, 
I think the first example above is very clear code and follows 
the debug statement's precedent.
Sep 02 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Sep 02, 2015 at 04:28:10PM +0000, Jack Stouffer via Digitalmars-d wrote:
 I wanted some second opinions on an idea I had for D before I made a
 bugzilla issue.
 
 Currently in D, to have a statement run only in debug mode, you can mark it
 with the debug keyword. But, there is currently no way to mark a statement
 so that it only runs in release. So what I propose is a release statement
 like so:
 
 debug {
     // only runs when -debug is given
 }
 
 release {
     // only runs when -release is given
 }
debug { ... } version(release) { ... } T -- Don't throw out the baby with the bathwater. Use your hands...
Sep 02 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/02/2015 06:32 PM, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Sep 02, 2015 at 04:28:10PM +0000, Jack Stouffer via Digitalmars-d
wrote:
 I wanted some second opinions on an idea I had for D before I made a
 bugzilla issue.

 Currently in D, to have a statement run only in debug mode, you can mark it
 with the debug keyword. But, there is currently no way to mark a statement
 so that it only runs in release. So what I propose is a release statement
 like so:

 debug {
      // only runs when -debug is given
 }

 release {
      // only runs when -release is given
 }
debug { ... } version(release) { ... } T
Tested with DMD 2.068.0. This does not work.
Sep 03 2015
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Wednesday, 2 September 2015 at 16:28:12 UTC, Jack Stouffer 
wrote:
 I wanted some second opinions on an idea I had for D before I 
 made a bugzilla issue.

 Currently in D, to have a statement run only in debug mode, you 
 can mark it with the debug keyword. But, there is currently no 
 way to mark a statement so that it only runs in release. So 
 what I propose is a release statement like so:
-release and -debug are decorrelated. Your program can have both switch or none of them.
Sep 02 2015
next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Wednesday, 2 September 2015 at 16:40:04 UTC, ponce wrote:
 On Wednesday, 2 September 2015 at 16:28:12 UTC, Jack Stouffer 
 wrote:
 I wanted some second opinions on an idea I had for D before I 
 made a bugzilla issue.

 Currently in D, to have a statement run only in debug mode, 
 you can mark it with the debug keyword. But, there is 
 currently no way to mark a statement so that it only runs in 
 release. So what I propose is a release statement like so:
-release and -debug are decorrelated. Your program can have both switch or none of them.
And here is the answer to your next question: so what does -release do exactly? http://p0nce.github.io/d-idioms/#So-what-does--release-do,-exactly?
Sep 02 2015
prev sibling parent reply "Jack Stouffer" <jack jackstouffer.com> writes:
On Wednesday, 2 September 2015 at 16:40:04 UTC, ponce wrote:
 On Wednesday, 2 September 2015 at 16:28:12 UTC, Jack Stouffer 
 wrote:
 I wanted some second opinions on an idea I had for D before I 
 made a bugzilla issue.

 Currently in D, to have a statement run only in debug mode, 
 you can mark it with the debug keyword. But, there is 
 currently no way to mark a statement so that it only runs in 
 release. So what I propose is a release statement like so:
-release and -debug are decorrelated. Your program can have both switch or none of them.
I know. That doesn't somehow invalidate this idea.
Sep 02 2015
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Wednesday, 2 September 2015 at 17:03:18 UTC, Jack Stouffer 
wrote:
 On Wednesday, 2 September 2015 at 16:40:04 UTC, ponce wrote:
 On Wednesday, 2 September 2015 at 16:28:12 UTC, Jack Stouffer 
 wrote:
 I wanted some second opinions on an idea I had for D before I 
 made a bugzilla issue.

 Currently in D, to have a statement run only in debug mode, 
 you can mark it with the debug keyword. But, there is 
 currently no way to mark a statement so that it only runs in 
 release. So what I propose is a release statement like so:
-release and -debug are decorrelated. Your program can have both switch or none of them.
I know. That doesn't somehow invalidate this idea.
H. S. Teoh's answer does.
Sep 02 2015
parent reply "jmh530" <john.michael.hall gmail.com> writes:
On Wednesday, 2 September 2015 at 17:14:27 UTC, Gary Willoughby 
wrote:
 On Wednesday, 2 September 2015 at 17:03:18 UTC, Jack Stouffer 
 wrote:
 On Wednesday, 2 September 2015 at 16:40:04 UTC, ponce wrote:
 On Wednesday, 2 September 2015 at 16:28:12 UTC, Jack Stouffer 
 wrote:
 I wanted some second opinions on an idea I had for D before 
 I made a bugzilla issue.

 Currently in D, to have a statement run only in debug mode, 
 you can mark it with the debug keyword. But, there is 
 currently no way to mark a statement so that it only runs in 
 release. So what I propose is a release statement like so:
-release and -debug are decorrelated. Your program can have both switch or none of them.
I know. That doesn't somehow invalidate this idea.
H. S. Teoh's answer does.
I wasn't familiar with version(release). Would you need to compile with -version=release then?
Sep 02 2015
parent reply "Jack Stouffer" <jack jackstouffer.com> writes:
On Wednesday, 2 September 2015 at 19:15:08 UTC, jmh530 wrote:
 I wasn't familiar with version(release). Would you need to 
 compile with -version=release then?
No, it seems to work with just the -release flag. The Python programmer in me hates the inconsistency between these two, but it's fine.
Sep 02 2015
next sibling parent "Xinok" <xinok live.com> writes:
On Wednesday, 2 September 2015 at 19:34:53 UTC, Jack Stouffer 
wrote:
 On Wednesday, 2 September 2015 at 19:15:08 UTC, jmh530 wrote:
 I wasn't familiar with version(release). Would you need to 
 compile with -version=release then?
No, it seems to work with just the -release flag. The Python programmer in me hates the inconsistency between these two, but it's fine.
I think it's for the better. The trouble with including keywords in the language is that it encourages their use. For example, there was once a suggestion to add a "namespace" keyword to the D language simply for the sake of linking with C++. There was a huge backlash because of the reason I stated before. I think the same philosophy applies here; we shouldn't add a "release" keyword because it would encourage it's use. But why not encourage it? Because debug builds are for testing and, well, debugging your code. However, if there is "release-only" segments of code, then these are excluded from debug builds and so don't receive the same extensive testing and error checking as all other code. On the other hand, there are those corner cases when you actually need this which are adequately covered by the "version(release)" statement. In summary, from a software engineering perspective, this is a bad idea in general and should be avoided wherever possible.
Sep 02 2015
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 2 September 2015 at 19:34:53 UTC, Jack Stouffer 
wrote:
 On Wednesday, 2 September 2015 at 19:15:08 UTC, jmh530 wrote:
 I wasn't familiar with version(release). Would you need to 
 compile with -version=release then?
No, it seems to work with just the -release flag. The Python programmer in me hates the inconsistency between these two, but it's fine.
It's because -debug has _nothing_ to do with "debug mode." It simply has to do with debugging. And that makes sense and is perfectly fine except that it causes confusion when you start considering -release and "release mode" - especially when folks have a tendency to call the opposite of "release mode" "debug mode." So, arguably -debug and version(debug) should have been something else in order to reduce confusion, but I honestly don't know what name to use instead, since it _is_ specifically for debugging. - Jonathan M Davis
Sep 04 2015
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/02/2015 06:28 PM, Jack Stouffer wrote:
 I wanted some second opinions on an idea I had for D before I made a
 bugzilla issue.

 Currently in D, to have a statement run only in debug mode, you can mark
 it with the debug keyword. But, there is currently no way to mark a
 statement so that it only runs in release. So what I propose is a
 release statement like so:

 debug {
      // only runs when -debug is given
 }

 release {
      // only runs when -release is given
 }

 Or, if adding a new keyword to the language is a no go, it could be done
 like so:

 debug {
      // only runs when -debug is given
 } else {
      // only runs when -release is given
 }

 I have run into a need for this twice in one day, both having to do with
 unit tests in phobos. For the first one, I needed a way to make sure
 that a function is  nogc in release. For the other, the function I was
 tested had different outputs for release and debug if the input was an
 empty range, and I had no way to test both cases.
Its behaviour literally depended on the -release flag? How?
 I can think of several other use cases off the top of my head. One, If
 you have a GUI application that checks for a serial number on startup,
 there's no reason to do that check in a debug build. Or, if your making
 a game, there's no reason to do the opening logo crawl before the menu
 if your using debug mode.

 A rebuttal to this might be to just use version and pass something in
 during compilation. The problem that I have is this is not a solution
 for the phobos code that I am working on.
version(assert){}else{ // only runs when -release is given }
Sep 03 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 2 September 2015 at 16:28:12 UTC, Jack Stouffer 
wrote:
 I wanted some second opinions on an idea I had for D before I 
 made a bugzilla issue.

 Currently in D, to have a statement run only in debug mode, you 
 can mark it with the debug keyword. But, there is currently no 
 way to mark a statement so that it only runs in release. So 
 what I propose is a release statement like so:

 debug {
     // only runs when -debug is given
 }

 release {
     // only runs when -release is given
 }

 Or, if adding a new keyword to the language is a no go, it 
 could be done like so:

 debug {
     // only runs when -debug is given
 } else {
     // only runs when -release is given
 }

 I have run into a need for this twice in one day, both having 
 to do with unit tests in phobos. For the first one, I needed a 
 way to make sure that a function is  nogc in release. For the 
 other, the function I was tested had different outputs for 
 release and debug if the input was an empty range, and I had no 
 way to test both cases.

 I can think of several other use cases off the top of my head. 
 One, If you have a GUI application that checks for a serial 
 number on startup, there's no reason to do that check in a 
 debug build. Or, if your making a game, there's no reason to do 
 the opening logo crawl before the menu if your using debug mode.

 A rebuttal to this might be to just use version and pass 
 something in during compilation. The problem that I have is 
 this is not a solution for the phobos code that I am working 
 on. Also, I think the first example above is very clear code 
 and follows the debug statement's precedent.
In general, it's a really _bad_ idea to only do something in release mode. It makes it much harder to debug it when something goes wrong, and it means that what you're doing in non-release mode doesn't necessarily correspond to what happens in release mode. Normally, the only code differences between release mode and non-release mode relate to extra correctness checking - like with assertions - which get stripped out in release mode for efficiency. And many folks think that even _that_ is a bad idea. So, I'd suggest that you reconsider even trying to do this, and doing something like having a range act differently between release and non-release modes seems like a disaster waiting to happen. At most, having assertions that get stripped out in release mode makes sense. The behavior and semantics of the code doesn't really change in that case. It's just a question of what happens when you screw up and fail the assertion (i.e. whether it's triggered and kills your program or whether it was compiled out and your program heads into undefined, buggy territory). So, maybe you've actually found a case where it makes sense to do something in release mode but not in non-release mode, but I seriously question that it's a good idea. - Jonathan M Davis
Sep 04 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/04/2015 04:53 PM, Jonathan M Davis wrote:
 Normally, the only code differences between release mode and non-release
 mode relate to extra correctness checking - like with assertions - which
 get stripped out in release mode for efficiency.
Failing assertions have been redefined to be undefined behaviour in -release. That's not the same as stripping them out.
Sep 04 2015