The last changes to range

[Philippe Sigaud]

On Sat, May 29, 2010 at 18:45, Andrei Alexandrescu <
SeeWebsiteForEmail at erdani.org> wrote:

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

Does that mean that you changed some other parts recently?


> 1. First, I want to define this:
>
> // inside range type SomeRange
> @property SomeRange save();
>

vote++
That should make it clear you need a forward range for an algorithm.



> 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.
>

I think many ranges and algorithm that you put in std have a constraint on
InputRange that should be changed to ForwardRange. Most (all?) of the lazy
ones should probably ask for a ForwardRange. Don't forget to update that
part.


> 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.
>

Will that be associated with a constraint template? And why methods instead
of free functions?



> 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.
>
> And if front does not return by ref? Do you then define the fronts to be
different or compare the values?

About returning by ref, did you try to use 'auto ref'? I think I tried the
day the feature appeared, without success, IIRC. Many ranges in Phobos
return by ref and won't compose with other ranges because of that.

Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20100529/b0f73294/attachment.html>