Looks interesting! Haven't quite absorbed it yet, though :-} Wrote a simple implementation of a switch (trying to follow the style of what's already in client.jl), and then use the corresponding config value to determine the definition of assert and @assert. However … my straightforward approach would require the code in client.jl to be executed before that of error.jl, which it isn't. Should/could I somehow trigger a redefinition once the code in client.jl has been run?
I'm working on a kind of a solution now, but it seems a bit iffy. A summary: - I've defined use_assertions and useassertions() – similar to other flags in client.jl – but placed it in base.jl, so it's available when we get to the assertion definition. I've done this rather than place the assertion definitions after client.jl, because assertions are used elsewhere, of course. (Though they may be getting the wrong definitions, now – at least initially). - I've split out assertions into assert.jl. This is then loaded just after error.jl to keep the parser/compiler happy, but it is then reloaded after client.jl, when useassertions() has its correct value. Now, I'm guessing this can't work. When @assert is used before client.jl, the first (possibly wrong) definition will be used, and the code will be constructed based on that. That can't be undone when @assert is redefined, I guess. So … what to do? Move the client code earlier? Sneak in a lone option check just for this, early on? Avoid assertions for error checking in the earlier code (if we're talking about using it more for testing purposes anyway), so assertions can be imported only once, after client.jl? I guess some kind of juggling along these lines (perhaps a combination) would work. Though there *are* currently (as far as I can see) twenty files that (*i*) are included before client.jl, and (*ii*) use assertions (89 uses). Not sure how many of these the client code depend on, though? Another option: We could have an internal assert that is always used – a renaming of the current assert(s). Then the publicly available one (called assert) would either be a no-op or call the internal one. Then the internal one could be used in the library code. This would mean we couldn't turn off the assertions used in the library, though (or in the code defined before the client runs). Suggestions/thoughts?
