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

[Moritz Maxeiner via Digitalmars-d]

On Friday, 23 June 2017 at 21:14:47 UTC, MysticZach wrote:
> On Friday, 23 June 2017 at 20:49:35 UTC, Moritz Maxeiner wrote:
>> Normal usage of the new syntax? If asserts later on get a 
>> (possibly breaking) syntax overhaul that will affect (and 
>> forward breakage to) the contract syntax, as well, if it uses 
>> the same compiler infrastructure.
>
>>> My naive assumption is that any improvement in the in/out 
>>> grammar would also apply to asserts, and vice versa.
>>
>> Why should it? Contracts are not asserts or vice versa.
>
> I 95% disagree. As far as I can tell, they are _very_ similar. 
> The only difference I can see is that when you violate an `in` 
> contract, the exit message should point to the caller instead 
> of the callee as the source of the problem. Beyond that, they 
> seem like little more than glorified `assert`s.

This is (unfortunately) not a matter of opinion (within the 
context of DbC), see Meyer's original publication [1], who 
effectively birthed and established the DbC paradim.
Contracts within the DbC paradigm *are* abstractions that do not 
necessitate any particular implementation. Most native languages 
simply (sensibly) choose to use asserts for that.

>
>> I'm not sure what you're getting at here. With the proposal 
>> Timon implemented we have the following:
>> - the newer, decoupled contract syntax that separates contract 
>> specification and implementation from each other; Timon's 
>> implementation uses asserts as the internal contract 
>> implementation AFAIK
>
> Not exactly. It actually _couples_ `in` expressions with assert 
> expressions. In essence it just lowers
>

It would only couple the contracts with asserts if the DIP also 
specifies that asserts *must* be used for the lowering (which I 
would be against btw).
Otherwise, it couples contracts with the request of "you take 
care of the implementation for me", which Timon's dmd 
implementation just happens to be use asserts for as the default 
(which is fine).

[1] Meyer, Bertrand: Design by Contract, Technical Report 
TR-EI-12/CO, Interactive Software Engineering Inc., 1986