A problem with D contracts

[Marianne Gagnon]

Agreed, and if static verification is ever implemented (like there isn't already enough to do on D ;) I can very well imagine adding contract blocks with the "pure" keyword (or is it an annotation now?)

> 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