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
