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

[H. S. Teoh via Digitalmars-d]

On Wed, Jun 21, 2017 at 07:18:18PM +0000, MysticZach via Digitalmars-d wrote:
> [...] Or are all contracts basically just fancy sugar for asserts at
> the beginning and end of a function body?
[...]

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.


T

-- 
Political correctness: socially-sanctioned hypocrisy.