I'd be in favor of having both assert and enforce. -- John
On Jul 25, 2014, at 7:08 AM, Magnus Lie Hetland <[email protected]> wrote: > 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: > Modify repl.c (which I'd need to do anyway, to give the proper help messages, > etc.) and do some kind of mojo there. > 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 (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).
