assert() vs. enforce(), invariant() vs. ... ?

[Ramon]

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