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

--- Comment #10 from Basile B. <b2.temp@gmx.com> ---
(In reply to Rainer Schuetze from comment #9)
> > Sorry, did you miss my previous answer ? Use the code from the first message. The regression is obvious.
> 
> I noticed and it is consistent with what I tried to say before: the reduced test case

Damn, the reduced test case is wrong. Don't comment it

> fails because it checks "test()" for length 6, but then tries to
> access "test()"[$-7].
> 
> I think the problem actually existed before (as in my variation), but is now also visible in array comparisons a bit earlier.

Okay let's fix the test case:

```
int test()
{
    if (test.stringof.length > 6 &&
        test.stringof[$-7..$] == "1234567") {}
    return 0;
}

enum a = test();
```

this compiles with 2.077.1, not with 2.078-beta.1.
the "&&" RHS is clearly here to prevent the bound error and the LHS should only
be evaluated once the RHS evaluates to "true". Unless the semantic for && is
different in CTFE mode, which i don't believe to be desirable, there's a
problem

The regression is that (a && b) behaves like ((a) & (b)) for some reason.

--

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

--- Comment #11 from Rainer Schuetze <r.sagitario@gmx.de> ---
Short circuiting is only performed for "static if", which also works for your test case.

The string comparison used to be converted to a runtime call, so it could not be evaluated further (but with soe special support in CTFE). It is now a template that can be const folded and reports the error.

--

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

--- Comment #12 from Basile B. <b2.temp@gmx.com> ---
Before closing, would it be possible to gag the error if the LHS evaluates to false ?

--

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

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #13 from Martin Nowak <code@dawg.eu> ---
(In reply to Basile B. from comment #12)
> Before closing, would it be possible to gag the error if the LHS evaluates to false ?

We ultimately dismissed short-circuit semantics outside of static if.

https://issues.dlang.org/show_bug.cgi?id=9073 https://github.com/dlang/dmd/pull/2559 https://github.com/dlang/dmd/pull/1325

--

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

--- Comment #14 from Rainer Schuetze <r.sagitario@gmx.de> ---
The problem here is not the short-circuiting of semantic analysis, but the const-folding now done on the second operand of "&&" that predicts a runtime error if the code is actually executed.

Maybe it's ok to consider const-folding part of the semantic analysis (and the code in the bug report never should have compiled). Otherwise we could try to detect dead code and mute const-folding errors in it. But that's a can of worms that's probably better left closed.

Or is it part of the language definition that you must not compile code "arr[-1]"?

--

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

--- Comment #15 from Walter Bright <bugzilla@digitalmars.com> ---
Tracing this through the compiler, the trouble is more subtle.

  int test()
  {
    if (test.stringof.length > 6 &&
        test.stringof[$-7..$] == "1234567") {}
    return 0;
  }
  enum a = test();

1. The enum declaration says evaluate test() at compile time.
2. test() has not had semantic run on it yet, so the CTFE runs semantic on it
before attempting to execute it.
3. semantic sees the == with arrays on both sides. So it attempts to
instantiate the object.__equals() template with the left and right operands of
the ==.
4. As part of argument matching to the template, the operands get constant
folded.
5. The error is generated by the constant folding.

object.__equals() was added fairly recently, hence the regression.

I don't see any obvious way out of this.

However, there is a simple workaround, as constant folding does not do any flow analysis:

  int test()
  {
    auto i = test.stringof.length;
    if (test.stringof.length > 6 &&
        test.stringof[i-7..i] == "1234567") {}
    return 0;
  }

  enum a = test();

Here, the value of `i` is not propagated to the constant folder. The optimizer will do that, but later. CTFE will do it, too, but CTFE respects short circuits.

Note also that the following version:

  int test()
  {
    if (test.stringof.length > 6 &&
        test.stringof[$-7..$]) {}
    return 0;
  }

  enum a = test();

does not issue an error. That's because no template matching is attempted.

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|CTFE                        |rejects-valid

--- Comment #16 from Walter Bright <bugzilla@digitalmars.com> ---
BTW, here's where the constant folding is done:

------------ dtemplate.d(1586)----------------
// Optimize argument to allow CT-known length matching
farg = farg.optimize(WANTvalue, (fparam.storageClass & (STC.ref_ | STC.out_))
!= 0);
//printf("farg = %s %s\n", farg.type.toChars(), farg.toChars());
--------------------------------------------------

https://github.com/dlang/dmd/blob/master/src/dmd/dtemplate.d#L1587

I'm not giving up yet, maybe I'll think of something :-) or maybe one of you guys will.

In any case, it's not a CTFE issue. I'll remark it as rejects-valid for the time being.

--

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

--- Comment #17 from Walter Bright <bugzilla@digitalmars.com> ---
I had an idea:

https://github.com/dlang/dmd/pull/8259

--

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

Basile B. <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |turkeyman@gmail.com

--- Comment #18 from Basile B. <b2.temp@gmx.com> ---
*** Issue 18878 has been marked as a duplicate of this issue. ***

--

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

Basile B. <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--