contracts are intended to document hoare logic. i.e. pre, post, invariant.
They can be compile time if the compiler can verify them statically (where they become a noop), runtime otherwise, or disabled entirely if you can't prove them statically but don't want the overhead cost.
Realistically contracts will gradually evolve towards static/compile time asserts as tooling improves.
And like the blog post states, contracts are explicitly not input validation. They are there to encode what you expect and what you don't internally in your code rather than just documenting those pre/post/invariant conditions in comments.
> They can be compile time if the compiler can verify them statically (where they become a noop)
This only happens during constant evaluation. For example, the following could be determined statically, but compiles w/o error on gcc
int add_nums(int x, int y)
pre(x >= 0)
pre(y >= 0)
{ return x + y;
}int result_rt = add_nums(-1,-1); // no compile error
> Contracts are explicitly not input validation. They are there to encode what you expect
The line between what's "input validation" and what's "What you expect" is very muddy. Input validation is a statement of "this is input I expect".
Is it input validation to say a string must be at least some length characters? What if that string is a password? What if it's an MD5 sum?
It SHOULDN'T be used for input validation but it will be. And almost certainly the person that does use it for input validation will argue that they were just laying out expectations.