"the last change" for ranges

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> MLT wrote:
> > One needs something like a lazy semi-infinite range, that only calls
> > a certain function when it reaches an unexplored part.
> That's a great abstraction, but we can't afford to impose that to
> everybody. There must be an abstraction for a one-pass go through an
> arbitrarily long stream.
> Anyhow, I decided to change ranges as follows:
> a) Input:
> bool empty();
> ref T popNext();
> b) Output:
> void putNext(T);
> c) Forward:
> bool empty();
> ref T front();
> void popFront();
> The function ref T popNext() is a nonmember that accepts any forward
> range and uses front() and popFront(). Of course, a forward range is
> welcome to implement popFront as a member if it so wishes. The function
> putNext() overwrites front() and then calls popFront.
> d) Bidirectional:
> bool empty();
> ref T front();
> void popFront();
> ref T back();
> void popBack();
> popNext, putNext apply as for forward ranges.
> e) Random
> bool empty();
> ref T front();
> void popFront();
> ref T back();
> void popBack();
> ref T opIndex(uint n);
> void opIndexAssign(T, uint n);
> popNext, putNext apply as for forward ranges. We need to fix the
> opIndexAssign mess.
> Andrei

Please, please, please PLEASE, PRETTY PLEASE FOR THE LOVE OF GOD ALMIGHTY tell me
you're not serious!!!  Isn't changing the interface such that forward ranges are
no longer effectively a subtype of input ranges a bit drastic?  Or do you have
some magic up your sleeve that, given any forward range, will automatically call
popFront, and then front, when popNext is called, using extension function hacks
or something?

The whole beauty of ranges is that they provide one standard interface to program
to if all you need is a lowest common denominator level of functionality.
Frankly, if you destroy this, I think that just enforcing forward vs. input ranges
purely by convention would be the lesser of two evils.