Bug 13185 – Detect precondition violations at compile time when possible

In many cases, the compiler can easily detect that a function call cannot possibly pass the precondition. int divide(int x, int y) in { assert(y != 0); } body { return x / y; } void main() { func(3); divide(9, 0); } In these cases we can produce an error at compile time.

(In reply to yebblies from comment #0) > In many cases, the compiler can easily detect that a function call cannot > possibly pass the precondition. > > int divide(int x, int y) > in > { > assert(y != 0); > } > body > { > return x / y; > } > > void main() > { > func(3); > divide(9, 0); > } > > In these cases we can produce an error at compile time. In my opinion it's much better to offer the programmer an explicit way to tell the compiler that a compile-time testing (where/if possible) is desired, using an "enum precondition": int divide(in int x, in int y) enum in { // Enum pre-condition. assert(y != 0); in { // Regular pre-condition. assert(y != 0); } body { return x / y; } void main() { divide(9, 0); }

(In reply to bearophile_hugs from comment #1) > > In my opinion it's much better to offer the programmer an explicit way to > tell the compiler that a compile-time testing (where/if possible) is > desired, using an "enum precondition": > I think they have different purposes. This is simply extra best-effort checking to catch invalid calls at compile-time. It does not allow you to implement custom static checking.

Pull to check simple integer comparisons in preconditions containing a single assert. https://github.com/yebblies/dmd/compare/start13185

(In reply to yebblies from comment #2) > I think they have different purposes. This is simply extra best-effort > checking to catch invalid calls at compile-time. It does not allow you to > implement custom static checking. I value your work and efforts, but why add an ultra-special case that generates an error, instead of a little more general solution?

(In reply to bearophile_hugs from comment #4) > > I value your work and efforts, but why add an ultra-special case that > generates an error, instead of a little more general solution? To start with, because your enhancement is a language enhancement while this is a diagnostic enhancement. There's nothing little about adding a language feature. I disagree that this is an ultra-special case. My pull request only implements a couple of cases, but I intend to expand the checking significantly if it's accepted.

As discussed here and in the PR review, the suggestion is not well-defined. It re-implements an ever-growing subset of CTFE/constant folding, which has to be specified for speculative contexts or pushed to the backend. Since yebblies is no longer active as a D contributor, I'm going to close this, but anyone is welcome to champion a new, more defined proposal/implementation.