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
