On Thu, Jun 22, 2017 at 06:17:54AM +0000, MysticZach via Digitalmars-d wrote: > 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. [...] > But on the other side, binary-only libraries published in release mode > are actually rare in D, right?
Rare or not, if we want D to grow, we cannot ignore proprietary usage, which would most likely involve binary-only libraries. Precluding this (or at the very least discouraging it) just because of a design flaw in D's implementation of DbC would be a grave strategic error on our part. T -- Debian GNU/Linux: Cray on your desktop.
