On Sunday, 23 March 2014 at 09:26:53 UTC, w0rp wrote:
I understand it like this.
* empty - Are there no more values?
* front - Get me the current value.
* popFront - Advance to the next value.
That is correct.
In terms of how I implement an InputRange in general, I
typically end up with this.
* empty - Advance and cache "current value," return true if we
ran out of values.
* front - enforce(!empty), which in turn caches the current
value, which we then return.
* popFront - enforce(!empty), clear the cached value so we can
later advance.
So .front gives you the same thing again and again until you
call popFront, you could indeed call .front before .empty, but
you may get an exception. This obviously isn't how I implement
all InputRanges, as there are better ways to write other
ranges, such as ranges which operate on sets of integers or
wrap arrays. This is just my last resort general case
InputRange implementation.
.front assignment obviously replaces the cached value.
That is not consistent with the first part of your reply and is
incorrect imho. Calling empty() twice should not destroy
anything, even according to your understanding. Neither should
front(). User should be able to call them as many times as he
wishes getting same value every time. Only popFront() mutate the
range.
