www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Pre-conditions at compile-time with static arguments

I was distracted and with a unfocused mind, sorry for the late reply.


 We thought about this approach and deliberately did not do it.

Thank you for your answer. Sometimes it doesn't harm to think again a bit about a topic.
 It is not predictable at compile time whether a function can be executed
 at compile time or not (the halting problem). Therefore, you'll wind up
 with cases that silently fail at compile time, and so are put off until
 runtime. The user cannot tell (without looking at assembly dumps) if it
 happened at compile time or not.
 Instead, we opted for a design that either must run at compile time, or
 must run at run time. Not one that decides one way or the other in an
 arbitrary, silent, and ever-changing manner.

In this discussion I was talking about running just the pre-conditions, and not the whole function, and not its post-condition. This is different because: - Pre-conditions are usually small or smaller than function bodies; - Pre-conditions are usually meant to be fast (and not slower than the function body), so they are probably not too much heavy to run. pre-conditions, unlike debug{} code are meant to run often; - Pre-conditions are often pure (mine). If the "feature" I am talking about gets introduced, D programmers will be encouraged to write more pure preconditions (this probably explains why most other Contract-based systems I've seen don't use free code in contracts as D does, but use a specific expression language. This forces them to be pure and simpler, more fit for analysis!). Even if a function is not marked as "pure", what matters in this discussion is to its pre-condition to be CTFE-pure. The problem you list is of course important for the normally run CT functions, and I agree with the decision. But it's much less important for my idea, because I've seen that finding bug in code is essentially never a deterministic process, it's very probabilistic. People find only some bugs (people today find new bugs even in 10+ years old very-high-quality C code used by everyone (Zlib)), lint tools (including the static analysis flag of Clang I've shown recently) find only some other bugs, and different lints find different bugs. One important factor for those tools is to reduce false positives as much as possible (even if this increases false negatives a little), and this idea of mine produced zero false alarms (if the pre-conditions are written correctly). This feature is useful because when in your code you have struct literals like: Foo f1 = Foo(10, -20); The compiler is able at compile-time to tell you that line of code is wrong because -20 is not acceptable :-) This is useful in many situations. This feature works only if the arguments are known at compile-time, this is a strong limitation, but I think it's better to have it anyway. Even if this feature sometimes gets disabled by turning a CTFE-pure function pre-condition into not CTFE-pure code as you say, the programmer doesn't need to care a lot about this, because even if this change doesn't allow to catch a bug in the code, other bugs too are not found by the compiler. All static analysis tools do the same, they sometimes find a bug, but if you change the code in a way they don't fully understand, they don't find the bug any more. This is why I think your argument doesn't hold. The feature I have proposed is not a language feature, it's a compiler feature (the only change is in user code, that's encouraged to create CTFE-pure pre-conditions). This means that even if DMD doesn't want this idea, future D compilers will be free to adopt it. And from the direction of the tide (as Clang adds better and better analysis for C and C++ code) I think this will be seen as a cheap but useful compiler feature to add (a "low-hanging fruit" because the only needed compiler change I see needed is to not stop the compilation if a pre-condition of a function with statically known arguments turns out to be not runnable). Bye, bearophile
Apr 26 2011