Most of D users would rather call that "static contracts". I dont know why the author choose to call that "unit test".

Why is it odd? The compiler does all sorts of other checks based on things like static assert or type information.

It's odd because you lose control over that aspect of compilation. It slows down the development loop because every time you do a build you have to wait for a bunch of unit tests that you don't care about yet.

Every time you do exploratory work you now have to comment out all the tests that this work breaks because otherwise it won't compile anymore.

That would be even more annoying than Go's stupidly pedantic compiler.

> It slows down the development loop because every time you do a build you have to wait for a bunch of unit tests that you don't care about yet.

Can't that be an optional thing decided by some compiler flag? I think I remember doing something like that in D.

That's how one would normally do it, and that's what I would expect to see: Build for development, and the compiler only errors out if things are so bad that it's unable emit a binary (for everything else, it emits warnings). Build for release, and it errors out unless EVERYTHING is done right.

Unfortunately, ever since golang decided on an autocratic and backwards "there are no warnings, only errors" policy, others have started to sip from the same kool aid jar.