[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