*TL;DR; Assert is no slower than exception throwing& the problem is people expect it to be a `nop` if optimisation is turned on. and a `nop` is much faster than an assert*(*I haven't actually tested this),
Its not that assert is slow. it is that traditionally (and we are talking going back to a very long time), `assert` statements are removed by the optimizer. (Eg. It is one of the only things done by `cpython -o`) Because `asserts` are error messages targeted at the developer. In theory they will never be triggered at run time, in "shipped" code. This is different from Exceptions. Exceptions may be thrown (and not caught) in shipped code. Its bad, but sometimes unavoidable, and it is better that the exception is thrown (and not caught) than to allow the program to run in an unknown state (potentially leading to data corruption, or infinate looping or all kinds of problems). vs if the exception was instead an assert, then in the shipped version they are not their and so the program runs in unknown state. Currently running `julia --optimise` does not actually remove them. This is generally considered a bad thing. It break the expectation that they will be gone in the optimised version. This is very bad, if you have an `assert` in a key inner loop. However, some people are writing code, that is using asserts to check that a function is being used correctly. Because they are lazy (aren't we all? I know I do this). If this code is ship in optimized form (without asserts), then the users of there code (if it is a library) are going to be be able to get into unintended states -- by accident. Now what people should do, is as in your example check conditions and throw meaning full exceptions. Your way works, as does using an if statement (i'ld use an if statement, but that is just me). But as a hack for those of us who are lazy, a @check macro was proposed, which would not be removed by the optimizer.
