On Tuesday, 27 June 2017 at 23:17:15 UTC, Moritz Maxeiner wrote:
Considering that code is read a lot more than written those two
are *critically* important.
What more do you expect? It could eventually be optimized to
inject the in contract check at the caller's side (before
entering the function), but the point of contracts is that they
*aren't* violated. If they are, well, your program[1] is broken
and needs to die.
[1] abstract: computational task; implementation barring safe
thread/fiber killing: process
Sure, but it would be even better if it hadn't compiled in the
first place. For instance, the "pure" attribute is a sort of
contract, and if a function designated "pure" modifies global
state then my code *does not compile*. Furthermore, if a pure
function foo() contains a call to a function bar() not designated
"pure", then it doesn't compile either, even though bar() may in
fact be pure. So the compiler's behavior is "I can't guarentee
that this function is pure, therefore I refuse to compile". In
other words, I get useful error-checking from the compiler at the
cost of having to "help" him a bit from time to time (like
designating bar() as pure in this example).
The above behavior is unreasonable for validating a completely
general contract - the compiler won't be able to guarentee much
without excessive effort on the part of the programmer, supplying
it with informative preconditions and postconditions.
Nevertheless, as attributes like pure, const, safe and nogc
demonstrate, the compiler can be of great help in writing correct
code. Detecting violations of these function attributes in
run-time is trivial but far less useful.
So basically, I'd like the ability to implement fairly simple
contracts (with a similar level of sophistication to the above
examples) that the compiler can check for me. I don't know, maybe
this is easier to implement using UDAs...
