"the last change" for ranges

[Steven Schveighoffer]

On Wed, 20 May 2009 13:35:14 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Jason House wrote:
>> I feel like there are too many differences between input and forward
>> ranges for such a minor difference. Many range functions are written
>> assuming no side effects on the caller. This can restrict the use of
>> helper functions. It may be best to make their usage different...
>
> So how do you think we should go about it? Also don't forget that any  
> ranges should be seamlessly and efficiently treated as input ranges.
>
> Andrei

struct Input(R) // enforce that R is a forward range for type T, not  
versed well enough in D2 to know how to do this yet
{
   R _range; // make this R * if you want Input(R) to be a reference type
   alias _range this;
   auto popNext() { auto result = _range.front; _range.popFront(); return  
result; }
   // and so-on, can leave out truly duplicate functions like empty as the  
alias this will take care of that.
}

// convenience method
Input!(R) asInput(R)(R r)
{
   return Input!(R)(r); // or Input!(R)(new R(r)); if reference type is the  
right answer
}

No extra code required in any forward range, just wrap it.  Input still  
retains the forward range functions as an underlying base if you need BOTH  
input and forward range functionality (not sure why).

-Steve