Let me share some thoughts and inner warnings, here.
I notice a certain (constructive and pragmatic) tendency here to
say "Ha, that can be done" using templates, mixins, whatever.
I personally feel that to be somewhat dangerous and short term.
It's about concepts. Concepts and a smart and consistent
implementation is almost always preferable over a "can be done"
hack.
DbC is a concept and a powerful one - and the D creators have
wisely decided to implement it in D. Unfortunately they seem to
not have done it consistently (as some question and threads
indicate).
There *should* be a clear answer/rule/statement to "which one to
use? enforce? invariants? asserts?". And there *should* be a way
to let the programmer decide about his use of DbC (as opposed to
"release cuts all DbC").
I propose to end the "release cuts out DbC" approach and to
instead introduce sth. like "@DbC-on" and '@DbC-off'. This, hand
in hand with D's smart version mechanism offers much more without
losing anything.
The current way would be
version(release)
@DbC-off;
and being the default D would work as it did before. But we could
decide ourselves and we could have DbC available at runtime if we
please so. Using @DbC-on and @DbC-off we could even have good
granularity.
assert shouldn't be mixed up with DbC (as it often is right now).
In fact, I think, assert could/should have two major roles.
Ignoring DbC assert has a well established purpose and that's
what it has and does in D, too.
In relation/context to DbC there is no competition. DbC cares
about three scenarios, namely, method entry, method exit and
class level ("as long as you are not in a method X is guaranteed
to be ..."). assert is no competion but a complement as I see it,
in that it offers checks/guarantees for certain single situations
that are just not DbC jobs (example: make sure inside a method
something doesn't go amok).
Thanks for considering
A+ -R
