As a note, I'm one of those that have used the main function in addition to unittests. I use it in the unittest build mode of my JSON serialization library, using the unittests to ensure I didn't break anything, and then using the main to run a performance test that my changes actually did make it faster.
On 4/30/14, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Wed, Apr 30, 2014 at 08:43:31AM -0700, Andrei Alexandrescu via > Digitalmars-d wrote: > [...] >> Last but not least, virtually nobody I know runs unittests and then >> main. This is quickly becoming an idiom: >> >> version(unittest) void main() {} >> else void main() >> { >> ... >> } >> >> I think it's time to change that. We could do it the >> non-backward-compatible way by redefining -unittest to instruct the >> compiler to not run main. Or we could define another flag such as >> -unittest-only and then deprecate the existing one. > [...] > > Actually, I still run unittests before main. :) When I want to *not* run > unittests, I just recompile with -release (and no -unittest). > > The nice thing about unittests running before main is that during the > code-compile-test cycle I can have the unittests run *and* manually test > the program afterwards -- usually in this case I only run the program > once before modifying the code and recompiling, so it would be needless > work to have to compile the program twice (once for unittests, once for > main). > > An alternative, perhaps nicer, idea is to have a *runtime* switch to run > unittests, recognized by druntime, perhaps something like: > > ./program --pragma-druntime-run-unittests > > Or something similarly unlikely to clash with real options accepted by > the program. > > > T > > -- > Genius may have its limitations, but stupidity is not thus handicapped. -- > Elbert Hubbard >