Proposal to deprecate "retro.source"

[monarch_dodra]

On Thursday, 8 November 2012 at 18:20:31 UTC, Jonathan M Davis 
wrote:
> On Thursday, November 08, 2012 10:56:38 monarch_dodra wrote:
>> On Thursday, 8 November 2012 at 09:18:54 UTC, Jonathan M Davis
>> 
>> wrote:
>> > In the case of retro, I think that it would good to have 
>> > source
>> > exposed for
>> > std.container's use. It's easy for std.container to 
>> > understand
>> > what retro's
>> > supposed to do, and use it accordingly, and I think that it
>> > would be silly for
>> > it have to call retro on the retroed range to do that. I do
>> > agree however that
>> > in general, it doesn't make sense to access source.
>> 
>> Yes, accessing the original range is useful, but AFAIK, 
>> container
>> doesn't use retro in any way. It does it with take (which also
>> has a source field). For take, there is no way to extract the
>> source other than with a specialized function.
>
> std.container doesn't use retro right now, but it really should 
> (though that
> would require externalizing retro's return type). For instance, 
> what would you
> do if you had to remove the last five elemets from a DList? You 
> can't simply
> take the last 5 and pass that to remove with something like 
> take(retro(list[],
> 5)) or retro(take(retro(list[], 5))), because the resulting 
> type is
> unrecognized by remove. You're forced to do something like
>
> list.remove(popFrontN(list[], walkLength(list[]) - 5));
>
> which is highly inefficient.

It's funny you bring this up, because I've been wrapping my head 
around this very problem for the last week. The root of the 
problem is that Bidirectional ranges (as *convenient* as they 
are) just don't have as much functionality as iterators or 
cursors. If you've used DList more than 5 minutes, you know what 
I'm talking about.

The "retro" trick you mention could indeed be a convenient 
mechanic. (Keep in mind that take is forward range, so can't be 
retro'ed though).

I'm just afraid of what it would really mean to interface with a 
retro'ed range: What exactly does that range represent for the 
original container?

What we'd *really* need (IMO) is a takeBack!Range, that would 
only implement back/popBack. No, the resulting range wouldn't 
*actually* be a range (since it wouldn't have a front), but it 
would still be incredibly useful even if *just* to interface with 
containers, eg:

list.remove(list[].takeBack(5)); //Fine, that's not a "real" 
range, but I know how to interface with that.

I'll toy around with this in my CDList implementation.

----
PS: The problem you bring up is common to all bidirRanges, and 
not just containers: As a general  rule, there is no way to 
extract a subrange from the end of a bidirrange...

> [SNIP]*The rest*[/SNIP]
>
> - Jonathan M Davis

Read and acknowledged.