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?
