DIP 1009 (Add Expression-Based Contract Syntax) Accepted

[Zach Tollen]

On Wednesday, 11 April 2018 at 16:16:33 UTC, Jonathan M Davis 
wrote:
> If we actually end up with a language improvement that makes it 
> so that contracts are compiled in based on the caller instead 
> of the callee, then I'll start using contracts. Until then, I'm 
> not generally going to bother.

My first proposal suggested allowing the contracts at the top of 
the function body. If you mixed that idea with what H.S. Teoh 
later proposed, the result would have looked like:

int fun(int a) {
    in(a >= 0);
    out(r; r > 0);
    ...
}

It's not much different from if you did:

int fun(int a) {
    assert(a >= 0);
    typeof(return) result;
    scope(success) assert(result > 0);
    ...use `result`...
}

For anyone who wants even more convenience in how to write 
contracts this idea would still possible to add, although it's 
probably not that important.

But that idea received criticism on principle, that contracts are 
part of the signature and not the body. I didn't much care about 
the criticism myself, because I just wanted the contracts to be 
as ergonomic as possible so that people would use them. They 
seemed like a feature of D whose syntax was not up to the same 
standards as the rest of D, whose syntax otherwise is a major 
selling point.

However, eventually I was convinced that the accepted proposal is 
better precisely because of the possibility of a future 
implementation where the caller checks rather than the callee. In 
this case the contracts *must* be in the signature, because the 
body could be missing altogether. So basically, I agree with H.S. 
Teoh. A future DIP which allows caller-side checking will be all 
about the implementation, rather than about the syntax, and may 
or may not face opposition precisely for that reason, I don't 
know. From the user's point of view it amounts to nothing more 
than being able to use contracts in more places, i.e. in 
precompiled code, and with better error messages that fault the 
caller instead of the callee. I don't feel technically qualified 
to write that DIP, but I'm glad that the current DIP is designed 
with that one in mind.