DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Mark via Digitalmars-d]

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