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
