Consevutive calls to r.front

Mike Parker via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sun Jun 7 21:51:18 PDT 2015


On 6/8/2015 12:43 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Monday, June 08, 2015 00:42:07 Mike Parker via Digitalmars-d-learn wrote:
>> When implementing a custom range, is it correct to say that
>> consecutive calls to r.front with no intervening calls to
>> popFront should return the same value? Seems like I read
>> something along those lines before, but I can't find it anywhere.
>
> Yes. I was actually talking with Walter about this at dconf. Two consecutive
> calls to front must return equivalent values (but not necessarily exactly
> the same object - e.g. map!((a) => to!string(a))(range) is going to return
> equal strings, but they won't be the exact same string). It would be a
> fundamental violation of the range concept for multiple calls to front
> to return values that were not equal if popFront were not called in between.
>
> Also, a range cannot depend on empty or front being called in order to
> iterate correctly. It _can_ choose to do work in those functions instead of
> just popFront (e.g. map does), but it has to work to just have popFront
> called without calling empty or front (e.g. if you know that the range has
> more than 10 elements, you should be free to call popFront 10 times without
> checking empty or accessing front).
>
> - Jonathan M Davis
>
Thanks, Jonathan. That's what I was looking for.


More information about the Digitalmars-d-learn mailing list