Comment #0 by default_357-line — 2018-03-06T09:56:07Z
Consider:
assert(true.repeat.all != false);
We may expect this to hang indefinitely. We will certainly not expect it to fail immediately!
What happens is this.
true.repeat is an infinite range. all searches for a place at which its condition becomes false. For this, it employs find. Find uses "empty" to signal success, ie. it returns an empty range if the element was not found. However, in this case find *cannot* return an empty range because the Repeat range type can never be empty. It compiles anyways. This then leads to .empty concluding, correctly, that find may never return an empty range, and immediately, without evaluating its input range, returning false.
Either all must not be implemented on top of find, or find must be adjusted to signal failure in some other way, possibly using a VariantN.
Comment #1 by default_357-line — 2018-03-06T11:09:09Z
The actual problem seems to be that expression.empty actually presumes that expression terminates. So when .all checks for find.empty, it fails to account for the case that find does not terminate, in which situation the behavior is logically undefined.
Comment #2 by default_357-line — 2018-03-06T12:23:43Z
No, this is the actual problem!
struct Struct
{
enum Enum = 5;
}
bool fooEvaluated;
Struct foo() { fooEvaluated = true; return Struct(); }
assert(foo().Enum == 5);
assert(fooEvaluated == true);
Should this last assert pass? Right now it doesn't, because foo() is never evaluated because Enum is enum. This means that in any and all, the find() never runs.
Comment #3 by ag0aep6g — 2018-03-06T12:35:08Z
That makes it a codegen bug. foo isn't pure so it must be executed for the side effects. The compiler cannot skip the execution just because the result isn't really used.
Comment #4 by ag0aep6g — 2018-03-09T21:18:22Z
The codegen bug has its own dedicated issue: issue 12486.
I'm changing this to a Phobos bug. Maybe `true.repeat.all` can be made to behave as expected by working around the compiler bug.
I'm not sure how feasible that is, though. Likely, other Phobos functions are affected as well. Ideally, the compiler bug would get fixed soon and then this can be closed as a duplicate. (Wishful thinking for sure.)
Comment #5 by ag0aep6g — 2018-04-08T19:57:35Z
(In reply to ag0aep6g from comment #4)
> The codegen bug has its own dedicated issue: issue 12486.
[...]
> Ideally, the compiler bug would get fixed soon and
> then this can be closed as a duplicate.
Issue 12486 has been fixed. `assert(true.repeat.all != false);` is now an infinite loop as expected. Closing as duplicate.
*** This issue has been marked as a duplicate of issue 12486 ***