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.
