Pre-conditions at compile-time with static arguments

[KennyTM~]

On Apr 26, 11 03:44, bearophile wrote:
> Given that pre-conditions are meant to run fast and to be (nearly) pure, this is my idea: when you call a function with all arguments known at compile time (as at the r3 variable) the compiler runs just the pre-condition of that function at compile-time (and not its body and post-condition).
>
> The advantage is some bugs are caught at compile-time, and the compiler is kept simple (I'd like contracts to be verified statically in more situations, but this requires a more complex compiler). The disadvantage is longer compilation times, and troubles caused by pre-conditions that can't really run at compile-time (like a precondion that uses a compiler intrinsic). A way to solve this last problem is to not raise an error if a pre-condition can't run at compile-time, and just ignore it, and let it later run normally at run-time.
>
> The variable r2 is a situation where not all arguments of foo() are known at compile-time, so here the foo pre-condition is not run.
>
>
> (Note: the variable r2 is a situation where one argument of foo is known at run-time, and in this case the pre-condition contains a part (assert(x>=0&&x<text.length)) that's able to use this information to catch a bug. This is a possible improvement of the idea is to perform this partial test. This looks less easy to implement, so it's not important).
>
> Bye,
> bearophile

I feel this isn't right. The input or the precondition is very often not 
compile-time evaluable, thus it just won't run. An example grabbed from 
my code near by:

         foreach (key; keys)        // <-- keys is usually not known at 
compile time
             assert(key !in _map);  // <-- 'in' is not CTFE-able (yet).

Also, if the precondition were complaining, and you change some bit of 
the code and find it can be compiled -- that won't mean anything, as it 
is likely the change just make the precondition non-CTFE-able. The 
benefit doesn't worth the cost.

(And this is yet another kind of 0% false-positive-rate, non-zero 
false-negative-rate feature. I bet you'll get a "false sense of 
security" response. Personally I'd rather have the compiler to catch 50% 
of compile-time detectable errors than leaving 100% of them to run time.)

I also don't believe this still keeps the compiler simple, as now there 
are 2 kinds of CTFE error the compiler needs to distinguish: assert 
errors and non-assert errors. I don't know much about the compiler 
intrinsic, and actually the D front-end is already very complicated :), 
so this doesn't matter.