The rfind challenge

[Phil Lavoie]

On Tuesday, 15 January 2013 at 18:19:48 UTC, H. S. Teoh wrote:
> On Tue, Jan 15, 2013 at 06:03:06PM +0100, Phil Lavoie wrote:
> [...]
>> An addition to this solution could be another new primitive:
>> reverse:
>> 
>> Pseudo:
>>   original = range.save
>>   reversed = range.reverse //Permanently invert start an end. I
>> think this is feasible for all bidirectional ranges. Still a
>> bidirectional range.
> [...]
>
> I like this very much, actually. I think .reverse is much more 
> useful
> than .back and .popBack. I mean, how many algorithms actually 
> use .back
> and .popBack? Probably less than a handful, if any. Most 
> algorithms use
> .front and popFront().
>
> Viewed in that light, what then is a bidirectional range, if 
> not a range
> where you can swap the direction of iteration? That is, we can 
> redefine
> a bidirectional range to be one that implements .reverse, with 
> the
> property that R.reverse.reverse == R. Get rid of .back and 
> .popBack,
> which hardly anybody uses anyway. It simplifies the range API
> significantly, and makes rfind implementable in terms of 
> primitives.
>
>
> T

+1

I was about to suggest a solution based on Reversible ranges 
instead of bidirectional ranges, but I have yet to polish it.