[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Dec 28 10:11:48 UTC 2017


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

--- Comment #10 from Basile B. <b2.temp at 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.

--


More information about the Digitalmars-d-bugs mailing list