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
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
