On Thursday, 30 April 2020 at 16:21:05 UTC, Steven Schveighoffer
wrote:
I would say part of the issue is that you are doing all your
work in front and not popFront.
What happens is that Appender is a pointer-to-implementation
struct, and the compiler will allocate the first one shared
amongst all initial StreamRange instances.
On your first call to front, it's going to utilize that shared
one. Then on the call to popFront, it will reset it to another
one.
For the second unittest, in your first call to front, it
notices that it's already been filled, so it doesn't do any
work (and returns the existing buffer).
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.
another problem, your empty condition is based on the input,
which violates range expectations. indeed, on the first call to
front, the range all of a sudden becomes empty.
I was about to argue the point, but after thinking about the use
of popFront to execute the work, that would work.
3. You don't need a further Range parameter for the nested
struct, it can use the template parameter from the containing
function.
4. Make it a static struct, or else it will retain a pointer to
the function stack frame needlessly.
I'll definitely try that out. Regarding 3, I think that was in
the example code I used, so I just went with it.
