Suggested Change to Contract Syntax

[Jacob Carlborg via Digitalmars-d]

On 2016-03-10 23:57, Jonathan M Davis wrote:

> 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.

Another advantage of the contracts would be if the caller would be 
responsible for running the contracts. That is currently not the case. 
Then a library could be shipped with contracts and it's up to the user 
of the library to decide if the contracts should be executed or not.

I don't want to start a discussion which approach is right and which is 
wrong.

-- 
/Jacob Carlborg