Ah, right. Yeah, I did look for those in the Julia code, but couldn't find them. I see now that they're in repl.c, where they affect jl_compileropts.
Well, there are two ways of dealing with that part of the issue: 1. Modify repl.c (which I'd need to do anyway, to give the proper help messages, etc.) and do some kind of mojo there. 2. Use a global variable/function (like is_interactive/isinteractive()) that simply modifies assertion behavior – not definition. This, of course, would add another condition to the assert function, but it shouldn't be a problem for @assert, anyway, if the if-statement is moved inside it. As long as useasserts() has the proper value when the assert macro is executed, it would still generate no code. Now, assuming I'll want to keep most of this code high-level, and set the value of this variable in client.jl rather than in repl.c, we still have the issue of order of execution, I guess. Here's a proposal to deal with that part: We follow D, which has put some thought into assertions and testing, etc. (They have built-in support for unit test clauses, and design-by-contract clauses with pre- and post-conditions for functions, for example.) They have two names, like I hinted at before. They have assert for checking program correctness. This is primarily for testing purposes, and although shipping with assertions can be a good idea, it should probably be optional. Then they have enforce, which is for error checking <http://ddili.org/ders/d.en/assert.html> (e.g., for user-supplied values, etc.). It is not possible to turn off enforce – it's basically just an if statement linked to a throw statement. (They also have static asserts, but I guess we don't need a separate mechanism for that.) So: How about renaming the current asserts to enforce, and then adding if-statements using the command-line flag to assert? The performance hit would then only be in the version that is designed to be turned off if performance is crucial, and would have zero cost in the macro version (after compilation).
