For now, assert() function is described as debug function and internally is eval() with checks. Continuing the inlining theme (looks like I think a lot about inlining, don’t I) I’d like to have assert which can:
- Pre-compile the expression inside, i.e. most of the times I don’t really need to recompile the expression, just substitute variables.
- Can be quickly turned into no-op if I don’t want it – meaning, just function receiving true/false is not enough, since I can’t no-op it quickly.
- Of course, can be told what to do if assertion fails, just like the old one.
This can allow people to generate quite efficient pre/post-condition code easily, and turn it on and off on request. I.e. I see my app misbehaving, I turn on asserts, I run it, some assert breaks and I get the full trace of what happened even not touching a debugger once. Not that debugger is something bad – but debugger can’t efficiently checks pre/post-conditions either.
Which brings me to another idea of connecting debugger to these asserts – but debugger should be able to connect to errors (IIRC, some debuggers can now – it’s very easy to do from debugger’s point of view anyway) so if failed assert produces an error that should be enough.