https://issues.dlang.org/show_bug.cgi?id=13185

bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc

--- Comment #1 from bearophile_hugs@eml.cc ---
(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);
}

--

https://issues.dlang.org/show_bug.cgi?id=13185

--- Comment #2 from yebblies <yebblies@gmail.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=13185

yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #3 from yebblies <yebblies@gmail.com> ---
Pull to check simple integer comparisons in preconditions containing a single assert.

https://github.com/yebblies/dmd/compare/start13185

--

https://issues.dlang.org/show_bug.cgi?id=13185

--- Comment #4 from bearophile_hugs@eml.cc ---
(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?

--

https://issues.dlang.org/show_bug.cgi?id=13185

--- Comment #5 from yebblies <yebblies@gmail.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=13185

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #6 from Walter Bright <bugzilla@digitalmars.com> ---
https://github.com/dlang/dmd/pull/3799

--

https://issues.dlang.org/show_bug.cgi?id=13185

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

https://issues.dlang.org/show_bug.cgi?id=13185

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dkorpel@live.nl
         Resolution|---                         |WONTFIX

--- Comment #7 from Dennis <dkorpel@live.nl> ---
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.

--