Contracts vs debug

F i L witte2008 at gmail.com
Sat Feb 4 11:00:39 PST 2012


Timon Gehr wrote:
> First of all, you don't really need the debug statements, 
> assertions are stripped from -release'd code anyway.
>
> The assertions in the function body are not part of the 
> function interface. (eventually, contracts can be on function 
> declarations lacking a function body) Conceptually, with an 
> assert in the function body, the bug would be inside the 
> function: If it is not assumed in the in-contract it cannot be 
> asserted that bar is != 0. Some code could just go ahead and 
> call foo(0). If the assertion is in the in-contract, foo(0) is 
> invalid. And in the in-contract, this is supposed to be visible 
> for everyone.
>
> For a pragmatic reason, because contracts are supposed to be 
> inherited (but due to a bug, in-contracts are not currently 
> inherited without adding an in{assert(false);} contract to the 
> overriding function, this bug does not break LSP though, it is 
> just a little annoying)
>
> Contracts can also be used for modular static model 
> checking/static error detection.
>
> You may want to have a look at the Eiffel and Spec# systems.

All that makes sense. I forgot about Inheritance. Thank you for 
the explanation.


More information about the Digitalmars-d-learn mailing list