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.