<br><div class="gmail_quote">On Sat, May 29, 2010 at 18:45, Andrei Alexandrescu <span dir="ltr">&lt;<a href="mailto:SeeWebsiteForEmail@erdani.org">SeeWebsiteForEmail@erdani.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I plan to make two more (hopefully the last two) changes to the range abstraction this morning.<br></blockquote><div><br>Does that mean that you changed some other parts recently? <br></div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

1. First, I want to define this:<br>
<br>
// inside range type SomeRange<br>
@property SomeRange save();<br></blockquote><div><br>vote++<br>That should make it clear you need a forward range for an algorithm.<br><br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


The idea is that save() provides a guaranteed means to take a snapshot in a range&#39;s state. The notable absents are input ranges - they are unable to define save(), and therefore some algorithms won&#39;t apply to them.<br>
</blockquote><div><br>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&#39;t forget to update that part.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
2. swapFront, swapBack, and swapAt methods<br>
<br>
// inside range type SomeRange<br>
void swapFront(ref ElementType!SomeRange obj);<br>
void swapBack(ref ElementType!SomeRange obj);<br>
void swapAt(size_t i, ref ElementType!SomeRange obj);<br>
<br>
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&#39;s more detail about this of increased subtlety, please ask.<br>
</blockquote><div><br>Will that be associated with a constraint template? And why methods instead of free functions?<br> <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


<br>
3. sameFront()<br>
<br>
The gnarly bringToFront() algorithm needs the primitive:<br>
<br>
// inside range type SomeRange<br>
bool sameFront(SomeRange another);<br>
<br>
I think it&#39;s necessary for future algorithms as well. It&#39;s an optional primitive. In particular, if front() returns by reference it&#39;s easy to infer that two ranges have the same front by comparing the addresses of their front()s.<br>

<br></blockquote><div>And if front does not return by ref? Do you then define the fronts to be different or compare the values?<br><br>About returning by ref, did you try to use &#39;auto ref&#39;? I think I tried the day the feature appeared, without success, IIRC. Many ranges in Phobos return by ref and won&#39;t compose with other ranges because of that.<br>
<br>Philippe<br></div></div>