[dmd-internals] changeset 455

[Brad Roberts]

On Mon, 3 May 2010, Steve Schveighoffer wrote:

> ----- Original Message ----
> > From: Walter Bright <walter at digitalmars.com>
> >
> > I'm reluctant to transform 
> > all asserts because:
> > 
> > 1. this means all asserts, whether meant for unit 
> > testing or not, have to have return code, negatively affecting optimization all 
> > the time
> > 
> > 2. many asserts are not meant at all to be unit tests, and 
> > there's no reason to think otherwise when they are outside the unittest 
> > block
> 
> We're forgetting 2 things here:
> 
> 1. unit tests run independently of any user input, they are completely defined by the unit test code itself.
> 
> 2. Nobody, and I mean nobody, should ever compile unittest code for production.  In fact, I'd say you probably have not understood the meaning of unit tests if your main function looks anything unlike:
> 
> void main() {}
> 
> Therefore, you shouldn't be concerned with the optimization quality of unittest code during asserts.
> 
> What if we solve this with a completely global solution -- when compiling with unit tests enabled, all asserts do a unittest style assert (decided at link), when compiling without unittests, asserts function as they do now.  Can this be done?
> 
> -Steve

Careful.. don't conflate building unittests into production code with 
building production code with asserts enabled or disabled.

I run LOTS of important code with asserts enabled in production.  I'm 
willing, in fact eager, to risk a production system exiting rather than it 
continuing to run past an assertable state.  I will say that there's a set 
of asserts that I do disable in production systems, those that are really 
expensive to execute -- most of mine are dead trivial.  Admitedly, I'm not 
talking about D here, but rather C++.  But the philosophy doesn't differ 
based on language choice.

I fully agree that with D that it's unlikely that I'd leave unit tests 
turned on in production builds -- but if the tests are fast enough to 
leave in, no real harm either.  Keep in mind, they don't affect anything 
beyond the cost of app startup, or shouldn't.

Later,
Brad