Tim: The startup option making @assert a no-op was what I had in mind, yes. 
Either specifically for this, or it could be linked to testing/debugging in 
general, perhaps? I saw a mention of a @debug macro somewhere on this list, 
which I assume doesn't exist either? Maybe both could be turned on by 
default, but one could have a --no-debug switch or something (similar to 
the common -DNDEBUG in C/C++, which is also used to nix assertions)? (I 
guess the assert function should have the same fate as the @assert macro, 
for consistency? Its arguments would still be evaluated, I guess – the 
compiler won't optimize away those?)

John: Hm, yes. I don't know – @assert for error handling might not be a bad 
idea in general? (Sort of minimal DbC support? Although that's also a form 
of testing, I guess.) Perhaps one could have levels of assertions, sort of 
like levels of logging? Not to over-design anything or make a huge API out 
of this, but … one could have two levels, perhaps, where @assert is left as 
it is (for backward compatibility), and another macro/function pair is 
added – say, @expect – which is intended to be used for testing/debugging, 
and which is turned off by the --no-debug switch? Hey, one might even have 
slightly more configurability, and let the user configure what @expect 
should do – at least a choice betwen error and warn? (Then silencing it 
would be the third option. One could even link this stuff to logging, but I 
guess there's no single standardized logging package yet.) Perhaps 
configuring this globally is ugly. And perhaps I'm overdoing this 
completely xD

But, yeah, if we just go for an added switch that lets you turn off asserts 
(and none of the other stuff, except maybe @debug), what would the 
situation be in the transition period? (No one would force you to run with 
the assertions turned off, after all.)

I don't know. This isn't frightfully important to me, but if adding a 
switch/startup option isn't too involved (haven't looked at that part of 
the source yet), I could have a whack at it (with some input on what 
functionality is actually desired, here :-).

Reply via email to