http://d.puremagic.com/issues/show_bug.cgi?id=4492

           Summary: Version of take() which takes from the back of a range
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: jmdavisProg@gmail.com


--- Comment #0 from Jonathan M Davis <jmdavisProg@gmail.com> 2010-07-21 16:41:01 PDT ---
Most of the functions that we have in phobos at this point seem to deal with the front of a range rather than the back. Naturally, for a lot of stuff, that's exactly what you want, and there _are_ ranges which don't have a back, but for some functions, it would be nice to have a corresponding function which acts on the back of a range. The one which immediately comes to mind is take(). There's no way to take the back n elements of a range.

There are ways to get more or less the same thing - you can copy the range and then pop off elements from the front - but there are situations where taking from the back of a range would be useful. So, I suggest that std.range have a function named takeBack() - or something similar - which does the same thing as take() except that it takes from the back of the range rather than the front.

Now, there may be reasons which I haven't thought of why this wouldn't work very well (unlike take(), it obviously wouldn't work with infinite ranges), but I would think that it would be useful enough to at least look into adding it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4492


David Simcha <dsimcha@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsimcha@yahoo.com


--- Comment #1 from David Simcha <dsimcha@yahoo.com> 2010-07-21 17:31:20 PDT ---
What's wrong with just using take(retro(myRange), someNumber)?  This is only a
tiny bit more typing than takeBack and IIUC does exactly what you want.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4492



--- Comment #2 from Jonathan M Davis <jmdavisProg@gmail.com> 2010-07-21 17:39:34 PDT ---
You get the elements in the wrong order. Now, you could do

retro(take(retro(myRange), someNumber))

but that seems awfully inefficient, not to mention far more verbose than

takeBack(myRange, someNumber)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4492



--- Comment #3 from David Simcha <dsimcha@yahoo.com> 2010-07-21 19:16:35 PDT ---
Two points:

1.  Retro is not inefficient.  For random access, there's the overhead of
translating the index to length - index, but this is negligible in most cases
(though I wouldn't use it in super performance critical numerics code).  In the
case of front(), popFront(), etc., all it does is forward front() to back(),
popFront() to popBack() and vice-versa.  These are virtually guaranteed to be
inlined by the compiler, resulting in truly zero overhead for non-random
access.

2.  Sorry for the misunderstanding on what you expected takeBack to do. However, now IIUC takeBack would be unimplementable on non-random access ranges, unless the range had a length **and** you performed an O(n) seek.  If you can only access the front and back element of a range at any given time, you can't get the Nth element from the back.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4492



--- Comment #4 from Jonathan M Davis <jmdavisProg@gmail.com> 2010-07-21 19:57:42 PDT ---
Hmm. Well, it certainly _looks_ inefficient, but if it's not, all the better. It would still be a bit ugly to have to code it that way though.

As for takeBack() being unimplementable... Couldn't popBack() be used to
construct a new range? Or does that not work? I haven't look at the source for
take(), but I would have half expected it to do something similar with
popFront(). What it is it about the back which would make it so much less
tractable than the front for non-random access ranges?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4492


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com


--- Comment #5 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-07-22 07:50:51 PDT ---
(In reply to comment #2)
> You get the elements in the wrong order. Now, you could do
> 
> retro(take(retro(myRange), someNumber))

That won't work, retro needs a bidirectional range, and take is not a bidirectional range.

Like David said, your takeBack will only work on random access ranges, an O(n) cost for constructing a range is unacceptable.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4492



--- Comment #6 from Jonathan M Davis <jmdavisProg@gmail.com> 2010-07-22 10:33:10 PDT ---
Well, if it doesn't work, it doesn't work. It at least looks like it should work, but I haven't gone into the guts of exactly what would be required for it to work. And with pretty much the only ranges I've used thus far coming from arrays or std.algorithm or std.range functions which have processed arrays, I'm not particularly familiar with the restrictions of a given function and the range types that it'll take (though presumably that will change as we get more containers), so obviously I need to study up on those more. takeBack() would be nice, but if it can't reasonably be done, then them's the breaks.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4492



--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-07-22 10:46:24 PDT ---
You might misunderstand what I was talking about.

I meant that specific example of a workaround won't work, not that you couldn't implement takeBack.

As far as I know, the only restriction would be that the input would need to be a random access range, so you could get the $-Nth element in O(1) time.

I'd probably call it something different however, like takeTail (or just tail), since back implies you only want the back element, or are starting with the back element.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4492



--- Comment #8 from Jonathan M Davis <jmdavisProg@gmail.com> 2010-07-22 10:55:26 PDT ---
Ah okay. I did misunderstand what you meant.

takeTail() probably would be a better name.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4492


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com


--- Comment #9 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-07-22 15:07:02 PDT ---
It looks like we're already in good shape to meet such a need. If popping elements from the tail is needed, take(retro(range), n) should do. If getting the last n elements from a range in the same order is needed, range[range.length - n .. range.length] should do. I'll keep this open for a bit more if something new shows up.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------