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