<br><br><div class="gmail_quote">On Mon, Jun 24, 2013 at 11:46 PM, monarch_dodra <span dir="ltr"><<a href="mailto:monarchdodra@gmail.com" target="_blank">monarchdodra@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Monday, 24 June 2013 at 22:27:19 UTC, Brad Anderson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sunday, 23 June 2013 at 01:34:53 UTC, Andrei Alexandrescu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 6/22/13 2:58 PM, monarch_dodra wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
long story short: we don't have rfind. C++ does.<br>
</blockquote>
<br>
We do, just that it's for random-access ranges. C++ offers it for bidirectional ranges too. We could of course support it if bidirectional ranges were required to have something like r1.before(r2) that, assuming r2 is reachable from r1, returns the portion in r1 that's before r2.<br>

<br>
Andrei<br>
</blockquote>
<br>
How efficiently could before() be implemented?<br>
</blockquote>
<br></div></div>
In terms of efficiency, it would really depend on the range that implements it, but I'd say "o(1)": cheap. The problems are (imo):<br>
*defining the exact semantics that go with it.<br>
*defining the traits that go with it.<br>
<br>
One big hurdle (I think), is that there is no way to provide a default implementation, even for RA ranges with slicing. And that's very bad.<br>
<br>
I'm going to get bashed for this, but I think the concept of "iterable" range would be a much simpler concept: Far be for me to want iterators as the norm (puke), but being able to temporarily view a range (if possible), as two end points, before re-creating the range from said points, has some very simple, and easy to understand, yet efficient, semantics.<br>

<br>
It's really the only way to provide slicing for ranges that aren't RA...<br>
<br>
Eg:<br>
Range r;<br>
Range r10 = Range(r.begin, advance(r.begin, 10));<br>
</blockquote></div><br><div>That seems possible in some cases, but not all.</div><div><br></div><div>the primitives for iterators should be roughly:</div><div><div>void iterator.popFront() (or ++)</div></div><div><div>bool iterator.equals(Iterator other);</div>
</div><div>auto iterator.front();</div><div><br></div><div>The tricky part is to define </div><div>bool iterator.equals(Iterator other);</div><div><br></div><div>there are cases where this is possible:</div><div>* range defined over an array</div>
<div>* range over elements assumed to be unique (interesting case)</div><div><br></div><div>but I don't see how that would work in general. </div><div>thoughts?</div><div><br></div>