A problem with D contracts

[Jonathan M Davis]

On Saturday 31 July 2010 18:33:09 bearophile wrote:
> D contract programming lacks the 'old', but there is another different
> problem.
> 
> Allowing only asserts (and calls to only pure/readonly functions) in
> precoditions, postconditions and invariants opens the door for future
> software that perform automatic compile-time verification of contracts.
> 
> Putting all kind of D code inside contracts will make them very hard to
> statically verify.

D strives to be practical and useful rather than perfect - not to mention what's 
best here depends on your goals. IIRC TDPL, specifically mentions that contracts 
allow for I/O for debugging purposes. Requiring contracts to be pure would 
destroy that ability, and there plenty of situations where that would be a big 
problem.

Also, while automatic compile-item verification of contracts might be cool, 
you're talking about a future extension that would likely be used by a small 
percentage of the D user base while I'm willing to be that the ability to put 
print statements and the like in contracts would be used by a far greater 
percentage.

So, while I can see why purity for contracts could be useful, what we have does 
the job, and enforcing purity has serious downsides. Personally, I think that 
what we have works quite well, and it's way better than the situation in any 
other language that I've used.

- Jonathan M Davis