The order of the range returned is the same as the one received.
Not true. It should default to the genuine bidirectional range's
direction.
If it was reversed before calling rfind we could: let the user
reverse the result again or add the possibility to query the
range to know it it's already been reversed (compared to original
ordering):
@property bool reversed() {}
In fact, this is to be known anyways if the range has to keep
internal data to know in which direction it has to move. Meaning,
reverse should be implemented like that:
VOID reverse() {
_reversed = true;
}
instead of
ReversedBidirectionalRange reverse() {
return blablabla...
}
There truly are multiple ways to implement a solution to this
problem. We could also have merge decide the direction of the
range based on the "end" range (since we are moving towards this
one).
