I noticed when I was fixing std.range this morning that a lot of opportunities to use auto ref aren't taken advantage of.  Is there any reason for this that still applies?  If not, should all of std.range be converted to auto ref so we can finally send all the bugs related to rvalue vs. lvalue returns that have plagued std.range to the ash heap of history?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100623/e7afbea8/attachment.html>

Yes, we should convert all of those ugly mixin strings to auto ref. The matter is a bit more complicated; allow me to share some recent findings I made.

There are several kinds of ranges:

1. Unsealed:

struct UnsealedRange(T)
{
     @property bool empty();
     @property ref T front();
     void popFront();
}

Such ranges simply expose the address of their elements.

2. Sealed without assignment:

struct SealedNonAssigningRange(T)
{
     @property bool empty();
     @property T front();
     T moveFront();
     void popFront();
}

Such ranges offer non-ref access to front() but must also offer moveFront() to extract the front destructively. Without moveFront(), ranges over expensive-to-copy types make it impossible to implement many algorithms efficiently.

3. Sealed with assignment

struct SealedNonAssigningRange(T)
{
     @property bool empty();
     @property T front();
     T moveFront();
     @property void front(T);
     void popFront();
}

The ideas generalize to forward, bidirectional, and random-access ranges.

In an ideal world it should be very easy for a higher-order range (i.e. one built on top of another range) to detect all of these circumstances and generate code accordingly. Ideas are welcome. Perhaps some clever mixins could help. At any rate, it looks to me like auto ref will be an important part of the solution, but not all of it.


Andrei

On 06/23/2010 10:17 AM, David Simcha wrote:
> I noticed when I was fixing std.range this morning that a lot of opportunities to use auto ref aren't taken advantage of.  Is there any reason for this that still applies?  If not, should all of std.range be converted to auto ref so we can finally send all the bugs related to rvalue vs. lvalue returns that have plagued std.range to the ash heap of history?
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos