protocol for using InputRanges

[Joseph Rushton Wakeling]

On 24/03/14 14:20, Dicebot wrote:
> I think there is one design mistake with current InputRange rules that makes
> usage so inconsistent. We have `empty` but don't have any distinct `not yet
> started` state. If calling `popFront` at least once was required before
> accessing `front`, I can't imagine the case where having any non-trivial code in
> `front` would have been necessary.

I floated some ideas along those lines, for a "first" method that would be 
automatically called immediately before the first call to front, popFront, etc., 
whatever came first.

The trouble is that it's so vague _when_ it should be called.  Example from 
std.random: RandomSample not only has a .front which needs a check as to whether 
the first value has actually been selected, it also has an .index method which 
corresponds to the index of the chosen element of the range being sampled from.

Now, how is a "first" method supposed to know which methods it should precede? 
Any method?  Specified ones?  In any case, even if we could get it to work, it'd 
be a convenience rather than a solution, and would still in effect result in a 
non-const .front.

OTOH a requirement that .popFront() be called at least once before .front is 
accessed won't wash either.  At least in the case of randomSample, the code 
required to generate the _first_ sample point is different from what is required 
to .popFront().