Yes, but why people don't bother using them? It can't just be an aversion to verbosity, since people do write unit tests - many of which could have been contracts instead. And it seems like there's increased interest in preventing bugs through more rigorous static code analysis these days (Rust etc), so why doesn't it come up in that context?
IMO the key insight of contract programming is that contracts belong to the interface; that's exactly why asserts in the main body don't cut it. It needs to be where it's versioned as part of the interface, where the tools treat it as such etc.
OTOH contract inheritance in OOP is really something specific to OOP; but contracts are quite useful even without objects in the picture (e.g. in Ada this is probably more common than not).
It applies the Liskov substitution principle to it. So preconditions can only be widened in subclasses, and postconditions can only be narrowed.
In simple terms, it means that when you override a method, the override's precondition is automatically OR'ed with that of the superclass, and your postcondition is AND'ed. And ditto for interface inheritance.
Thanks, that makes sense. IIRC, I read about this either in Bertrand Meyer's book Object-oriented Software Contruction, or in the Eiffel language's docs, some years back, though I may not have known about it as an application of the Liskov substitution principle at the time, or even later, although I did read about the Liskov principle later :)
And I may not have grokked the Liskov principle when I read it, either, but thanks to your reply, I now have a glimmering of what it means, and will look it up again :)
I do really like them. In certain situations they are actually useful to the optimizer too, saves some branches on array length alignment for example.