[phobos] The last changes to range

[Andrei Alexandrescu]

I plan to make two more (hopefully the last two) changes to the range 
abstraction this morning.

1. First, I want to define this:

// inside range type SomeRange
@property SomeRange save();

That simply returns a copy of the range. Most implementations look like 
this:

// inside range type SomeRange
@property SomeRange save() { return this; }

If SomeRange is a class or interface, you'd write:

// inside range type SomeRange
@property SomeRange save() { return this->clone(); }

The idea is that save() provides a guaranteed means to take a snapshot 
in a range's state. The notable absents are input ranges - they are 
unable to define save(), and therefore some algorithms won't apply to them.

2. swapFront, swapBack, and swapAt methods

// inside range type SomeRange
void swapFront(ref ElementType!SomeRange obj);
void swapBack(ref ElementType!SomeRange obj);
void swapAt(size_t i, ref ElementType!SomeRange obj);

All functions are optional and are needed if and only if front(), 
back(), and opIndex() return rvalues. The idea is to provide a cheap 
means to move elements in and out of ranges without creating extra 
copies. There's more detail about this of increased subtlety, please ask.

Of course, swapBack() only makes sense if back() exists and swapAt() 
only makes sense if opIndex exists.

3. sameFront()

The gnarly bringToFront() algorithm needs the primitive:

// inside range type SomeRange
bool sameFront(SomeRange another);

I think it's necessary for future algorithms as well. It's an optional 
primitive. In particular, if front() returns by reference it's easy to 
infer that two ranges have the same front by comparing the addresses of 
their front()s.

I'll post this to the newsgroup too.


Andrei