dsimcha wrote:
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?

Consider:

struct R
{
    bool empty();
    ref int front();
    void popFront();
}

ref int popNext(ref R fwdRange)
{
    auto result = & fwdRange.front();
    fwdRange.popFront;
    return *result;
}

void main()
{
    R r;
    int x = r.popNext;
}

This should work, I just noticed with surprise it doesn't. It's a bug, specifically bug 3015:

http://d.puremagic.com/issues/show_bug.cgi?id=3015

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.

You and I see eye to eye.


Andrei

Reply via email to