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

[MysticZach via Digitalmars-d]

On Wednesday, 21 June 2017 at 19:34:53 UTC, H. S. Teoh wrote:
> This is a sticky point about D's current DbC implementation 
> that myself and several others feel is a design flaw. In 
> particular, that in-contracts are executed as part of the 
> *callee*, when the intent of DbC is really that it is the 
> obligation of the *caller* to fulfill its stipulations, and 
> therefore the contract verification should happen at *caller* 
> site rather than at the beginning of the callee.
>
> This particular implementation detail causes problems with 
> binary-only libraries: most library vendors would prefer to 
> ship the library compiled with -release rather than not, but in 
> -release, the asserts in any in-contracts would be elided, 
> making them essentially non-existent by the user uses the 
> library.  So you either have to dispense with DbC altogether, 
> or be forced to ship two versions of your library, one with 
> contracts compiled in and one without, in order for your users 
> to benefit from DbC *and* not have to suffer performance 
> penalties in their own release builds.
>
> Had in-contracts been implemented on the caller's side instead, 
> this would no longer be a problem: the contracts will still be 
> part of the library API, so the user can benefit from them when 
> not compiling with -release, but now the library itself can be 
> shipped only with the binaries compiled with -release for best 
> performance.
>
> This is probably something outside the scope of this DIP, 
> however.

It's related. A design flaw in D's DbC means that contracts on 
the whole are less important. Which means, unfortunately, that 
improving them is less important. Which could affect the final 
decision. But on the other side, binary-only libraries published 
in release mode are actually rare in D, right?