isInfinite isInadequate

[monarch_dodra]

On Wednesday, 17 October 2012 at 12:18:32 UTC, Peter Alexander 
wrote:
> So, std.range.isInfinite checks if r.empty is a compile time 
> boolean equal to false. This works most of the time, but not 
> always. Some ranges are infinite, but cannot be determined to 
> be so at compile time (or even run time!)
>
> cycle([1, 2, 3]).until(4);    // infinite, but not isInfinite
> cycle(new int[0]);            // not infinite, but isInfinite
> collatzSequence(n).until(1);  // infiniteness an open problem!
>
> In short, isInfinite does not -- and cannot -- work as a way of 
> telling if a range is finite or infinite in general.
>
> On resolution is to take isInfinite at face value: it only 
> tells you if a range is statically determined to be infinite. 
> If isInfinite is false, it could still be infinite.
>
> This leaves us with the tricky cases like cycle(new int[0]). 
> There's three resolutions to this (as far as I can tell):
>
> 1. Change cycle to not be an infinite range.
> 2. Make cycle assert when the source range is empty.
> 3. Ignore this issue.
>
> Option 1 is sound, but kind of sucks, because generally cycle 
> is infinite.
>
> Option 2 is sound, but I don't like the idea of asserting on 
> logically valid input just because the problem is too hard.
>
> Option 3 is not sound, but may be practical. Perhaps these 
> edge-case, fake, infinite sequences are not worth worrying 
> about -- just let it slide and make other people worry about 
> the consequences.
>
> This Phobos pull request is relevant: 
> https://github.com/D-Programming-Language/phobos/pull/871
>
> Thoughts?

> cycle(new int[0]);            // not infinite, but isInfinite
> 2. Make cycle assert when the source range is empty.

Technically, while cycle does not assert, it will fail on the 
first call to front, either because of a divide by 0 (RA: 
index%length), or because of a call to an empty front.

We should add an assert. IMO.

--------
TBH, I do not see either as being a problem:

Technically, cycle([]) *is* isInfinite, but the program will 
assert because of a run-time error due to the user's logic. 
Nobody said that just because a range is infinite, that it can't 
ever fail...

Ranges that go on forever, but are not *isInfinite*. My stance on 
this point is that it is not a *big* problem either. I see it 
more as a runtime "infinite loop", rather than an compile time 
"infinite range". It's like a for loop where the run-time end 
condition will always be true.

That said, if the user *does* know the range will be infinite, I 
wouldn't be against having an "assumeInfinite" template function, 
that can take any range, and transform into an (assumed) compile 
time infinite range.