(ref.doc)oosc-7-9

7.1 p 112 (keywords: assertion, documentation, programming by
contract)
For the time being, however, the emphasis will be on the
application of assertions as a conceptual tool for increasing
the correctness and robustness of sotware. Assertions will be
studied as a technique for constructing correct systems and
documenting why they are correct.

7.3.2 p 116 (keywords: assertion, checking, programming by contract)
If the client's part of the contract is not fulfilled, that is to say
if the call does not satisfy the precondition, then the class is not
bound by the post-condition.
[...] you do not need to test for them [the preconditions]...

Complexity is probably the single most important enemy of software
quality.

The distribution of redundant checks [...] destroys the conceptual
simplicity of the system.

The recommended approach is to systematically use preconditions, and
then allow module authors to assume, when writing the body of a
routine, that the correponding precondition is satisfied.

9.5.2 The meaning of short, p 205
[...] a principle of software engineering: avoid documentation.