On Sunday, 23 March 2014 at 09:34:28 UTC, Szymon Gatner wrote:
On Sunday, 23 March 2014 at 00:50:34 UTC, Walter Bright wrote:
1. If you know the range is not empty, is it allowed to call
r.front without calling r.empty first?
IMO: yes. Logic of empty() sould be const and not have side
effects.
If this is true, extra logic will need to be added to r.front
in many cases.
2. Can r.front be called n times in a row? I.e. is calling
front() destructive?
If true, this means that r.front will have to cache a copy in
many cases.
Yes, all true. Not sure if there is something like that in
Phobos but if for example you had RandomValueRange, ever call
to front() should return the same random number until
popFront() is called at which point internal front variable is
being recalculated and cached.
Since only popFront() is non-const, it is there where all the
magic/mutation should happen.
In my code I also have CachingRange which calls front() on
underlying range the first time and then stores result
internally. I use it for ranges which generate front() on the
fly and I knot it is expensive. I could cache that calculation
directly in that underlying range but CachingRange is reusable.
I tend to think about pair of C++ iterators, which are
generalization of pointers. So for C pointers 'first' and 'last':
*first -> front()
first != last -> empty()
++first -> popFont()
And I stick to semantics.
