On Thursday, 10 March 2016 at 22:39:54 UTC, Adam D. Ruppe wrote:
Contracts are most interesting in the case of inheritance and keeping variables between them isn't going to be easy.
IMHO, at this point, inheritance is the only reason they're worth having in the language. Without inheritance, in contracts could just as easily be assertions at the top of the function, and while out contracts are certainly easier as they are now rather than having to put a contract at each return statement or use a scope(exit) statement to do the out contracts, you can still do out contracts that way, and honestly, I don't think that out contracts are worth much anyway, since in almost all cases, unit tests do that job already, and it's usually much easier to write test that specific input gives specific output than it is to have a general test at the end of the function.
But while in most cases, in and out contracts are trivially done in the function itself, inheritance is a whole other kettle of fish, and having them built into the language solves that problem whereas doing it yourself is actually fairly hard and error-prone. So, for that reason, and that reason alone, I think that having them built into the language is a good thing.
There has been some discussion of getting the compiler to catch some stuff based on in contracts, in which case, in contracts would be worth a bit more, but as it stands, I pretty much never use out contracts (because I think that they're useless), and if inheritance isn't involved (which it usually isn't), then I don't even bother with an in contract and just put the assertions in the body and avoid the extra syntax. If/Once we get more features in the compiler which take advantage of contracts, then I'll likely change my tune on that one, but for now, IMHO, they're really only of value in classes.
- Jonathan M Davis
