protocol for using InputRanges

Szymon Gatner noemail at gmail.com
Sun Mar 23 02:38:42 PDT 2014


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.



More information about the Digitalmars-d mailing list