Why assert is in the language?

[Jonathan M Davis]

Tomek Sowiński wrote:

> There's a better way:
> 
> void assert_(string file = __FILE__, uint line = __LINE__)(bool pred, lazy
> string msg = null) {
>      version(unittest)
>          if (!pred)
>              throw new AssertError(msg, file, line);
> }
> 
> If unittesting is off, it is inlined and all calls vanish.
> 
> Someone mentioned the assert(0) special case. That could be implemented
> like:
> 
> void fail() {
>      asm {
>           // HLT instruction...
>      }
> }
> 
> Following benefits spring to mind:
>   - It's clear that fail is something different than assert. Unlike assert
> vs. assert(0).
>   - The compiler can be made aware of fail() to recognize and refuse to
> compile dead code.
>   - Documentation can be added with no additional effort; newbies can read
> it straight from a tooltip provided by the IDE.
>   - Curious users are free to introspect the implementation.
> 
> So I ask again -- what benefits on top of that list can having assert in
> the language give?
> 
> 
> Tomek

1. The compiler itself uses assert. Given that it uses assert, even if 
assert isn't a keyword, you won't be able to use it for anything else. 
Either it's going to be a keyword or it's going to be like Object and be 
something defined that's always defined, so you can't use the name for 
anything else. At that point, it might as well be a keyword - on top of 
which making it a keyword makes it so that IDEs are likely to highlight it 
accordingly, and it will be more obvious in the code.

2. It's almost certainly more efficient as a keyword. As a keyword, there 
likely aren't any function calls going on beyond what's being asserted. If 
it were an actual function, given that it's used primarily in debug mode, it 
almost certainly wouldn't be inlined, and it would slow down the code that 
much more.

3. Making assert a keyword makes it easier for the compiler to treat it 
specially. It knows about assert and what to do with it without having to 
examine every function to see whether it's assert and therefore have to 
treat it differently. The closest to anything, that I'm aware of, which is 
treated specially in that manner is Object, and unlike examining each 
function to see whether it should treat it specially, it will be quite 
straightforward with Object because it only has to deal with it specially 
when dealing with class declarations, and since it _always_ inserts the 
Object stuff in that case, it's a no-brainer. Having to look at each 
function to see whether it's on the list of functions to treat specially 
would have to slow compilation down. Not to mention, Walter's trying to keep 
D such that it's fairly easy to compile so that tools (including the 
compiler) will have a much easier time handling it and are less likely to be 
buggy. If it starts having to treat functions in a special way, then that's 
just going to have to complicate things.

4. Given that Walter is definitely pushing design by contracts and unit 
tests - both of which need assertions - it makes perfect sense to include 
assertions in the language itself.

5. I see _0_ downsides to assert being in the language itself. Sure, there 
may be ways to make assert better, but that doesn't require it to be done in 
library code. We might as well put it in the language itself and give the 
compiler the chance to deal with it specially.

- Jonathan M Davis