[phobos] auto ref

[Andrei Alexandrescu]

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