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
