protocol for using InputRanges

[w0rp]

On Friday, 28 March 2014 at 23:14:56 UTC, Tobias Müller wrote:
> On Thursday, 27 March 2014 at 20:49:16 UTC, Walter Bright wrote:
>> On 3/27/2014 12:21 PM, Rainer Schuetze wrote:
>>> This loop is intuitive. Not being allowed to call empty or 
>>> front multiple times
>>> or not at all is unintuitive. They should not be named as if 
>>> they are properties
>>> then.
>>
>> I can concede that. But I can't concede being able to call 
>> front without first calling empty, or calling popFront without 
>> calling empty and front, or requiring 'pump priming' in the 
>> constructor.
>
> Disclaimer: I'm a C++ programmer just lurking here, I've never
> actually used D.
>
> I find it very counter-intuitive that 'empty' is required before
> front or popFront.
> Since 'pump priming' in the constructor isn't wanted either, i'd
> suggest the following protocol:
>
> while (popFront())
> {
>     front;
> }
>
> popFront is then required to return !empty.
> 'empty' as a separate property getter can stay but is not
> required for the protocol.
>
> This way, it's clear that the work to fetch the next element is
> always done in popFront.
>
> Generally I find dependecies between functions problematic that
> require a specific call sequence. If they can be removed, they
> should.
>
> With my proposed solution, there's still one minor dependency,
> namely that front is not valid before the first popFront. This
> could be solved by again combining the two, as proposed by
> someone else in this thread.
>
> Tobi

Well, it might seem kind of weird at first that an InputRange has 
these concepts in three distinct methods, but they really are 
three separate operations. After I have spent enough time working 
with Java Iterators, I have found it much nicer to be able to get 
the current value or see if I'm at the end or not without having 
to worry about caching the current value myself. Also as I've 
said before it gives you some opportunity to make trying to fetch 
something out of an empty range less error prone, because you 
don't have to check for a null value, etc.