Good Contract programming idiom?

[Norbert Nemec]

bearophile wrote:
> But generally public functions must test arguments in release mode too, so I (and lot of other people) don't like to use asserts in this situation. It's better to use an always present test followed by a throw (so such test is not in the precondition).

For this statement, you should make a distinction between libraries and 
applications.

Indeed, contracts are part of the interface, so a released library 
should still allow to check for them.

Breach of a contract, however, is always a bug. In a correct program, 
user interaction should never break either contracts or assertions. If 
you trust your code enough to drop the assertions, you can just as well 
drop the contracts.

The correct way to handled contracts for libraries would actually be to 
store them as part of the library interface information. A release-mode 
library would then contain neither assertions nor contracts, but leave 
it to the compiler to add contract-checks for calls to the library, when 
compiling an application in devel-mode.