Suggested Change to Contract Syntax

[Jonathan M Davis via Digitalmars-d]

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