Can't recreate a range?

[Steven Schveighoffer]

On 4/30/20 2:03 PM, Casey wrote:
> Interesting.  I'll take this into account.  I was putting the work into 
> front because I didn't want to do the work until it was requested.  
> Putting the work in popFront makes more sense in some ways, but the fact 
> you have to call it before getting any records seems like it would break 
> normal range algorithms.  (Please correct me if I'm wrong)  I'm 
> wondering if putting the work into it's own method and calling it one 
> from the constructor and from popFront the rest of the way.

You don't necessarily have to do it in a separate function, because 
until you return it from your factory method (the only way you can 
create such a thing), it technically doesn't need to be "sane".

So what I mean is at the bottom of your function you have:

auto readStream(Range)(auto ref Range r) if (isInputRange!(Unqual!Range))
{
    ... // define your struct

    auto result = StreamRange(r);
    if(!r.empty) result.popFront(); // prime range
    return result;
}

There is a valid argument to be made about not doing any work until 
requested. You could do this inside front, but in that case, I would say 
you have an additional boolean that checks if it has ever been run, and 
run popFront once (setting that bool to false). But I don't necessarily 
like that, because that puts an extra burden on front. front is supposed 
to be non-mutating, called as much as you need (ideally it should be 
inout). Practically, you can make it do work, but really the bulk of the 
work should be done in popFront.

Note that you will have to check for priming in popFront as well, 
because if you did for instance:

auto r = readStream(...);
r.popFront(); // skip first element?

This would not do what is expected. In fact, thinking about it some 
more, you should be able to call popFront as many times as you want and 
have it skip that many elements without calling front once. Your range 
will not do that.

-Steve