That sounds pretty much like putting your application authors under
tutelage (great word - just found it in the dictionary... :-) )
Writing a library that other can use, you should always assume that they
are mature and responsible beings. The contracts explicitly tell the
application author their responsibilities. Checking the contracts
provides a safety net for the application author. If the author decides
to deactivate this safety net, you should allow them to do so.
Ultimately, the language provides everything that would allow a compiler
to offer fine-tuned switching of checks. It should be straightforward to
implement an option to activate only checks of public contracts between
libraries, but this decision should be up to the application programmer
who is responsible that the whole package works as it should.
After all: The whole D language is built on the concept of providing
professional tools for responsible programmers. If someone decides to
shoot himself in the foot, at least give him a quality gun that allows
him to aim properly!
Lionello Lunesu wrote:
You make a good point, but there's one problem I have with this.
I'm looking at this as a library writer. I can write in-contracts with
assertions, but I would not feel comfortable with only assertions, since
I know they will not get compiled in a release build of the library.
So in a release build I don't want anything weird to happen when wrong
arguments are passed to my library function. This can only be prevented
by throwing run-time exceptions, right?
