Contract checking (Re: enforce()?)

[Sean Kelly]

Norbert Nemec Wrote:

> On 28/06/10 12:59, bearophile wrote:
> > Norbert Nemec:
> >> [...] to place code for input contract checking in the *calling* code. [...]
> >> Output contract checks, on the other hand should be compiled inside the
> >> returning routine.
> >
> > Is this a positive thing to do? Can this be done? (D must support separate compilation, but in many situations this is not done/necessary, so maybe in such situations it can be done). Is Eiffel doing it? if it's a good thing and it's doable then what kind of changes does it require to the compiler?
> 
> These are good and pragmatic questions that you ask.
> 
> The whole issue only arises when doing separate compilation of a library 
> and an application. (I use the term "application" for any code that uses 
> the library.)
> 
> In an idea world (beware, I am switching of "pragmatic thinking mode" 
> for a moment), I would describe the situation would as follows:
> 
> Either part can be compiled in "debug" mode or in "release" mode. Debug 
> mode in the library means that you want to debug the library code 
> itself. Release mode in the library means that you trust the library 
> code to be correct and switch off all internal checks.

I see the choice of "release" for disabling contracts as a huge mistake in nomenclature.  For libraries, I would ship a checked and unchecked build (with -release disabled and enabled), but none with -debug or -unittest set.  Those are for internal testing and the user shouldn't care to turn on debug code in a library simply because he's debugging his own app.

The idea of compiling the "in" contract into the application code is an interesting one, but I suspect it could be tricky.  Consider an unchecked build of the library, a checked build of the app, and now taking the address of a library function.  Worse, what if a library routine returns the address of another library routine?  Now the application has a reference to an unchecked version of the function, even if the involved technical hurdles are surmounted (multiple entry points or the like).

This seems like a nice idea but it seems too complicated.  I'd rather just ship checked and unchecked builds of a library and leave it at that.