On Sat, May 29, 2010 at 15:54, Andrei Alexandrescu <[email protected]>wrote:
> Typo: "Attenpting" (at least two places) > > I think popBack for bidirectional ranges is broken. Consider I have a range > of 1000 elements and I take 5 of them. Then popBack would have to back off > 996 elements. That is not what your code is doing, and it would not satisfy > the complexity requirements of popBack. > > Please keep the popBack code only for random-access ranges. > > > Thanks, > > Andrei > > Yes, I think that's why in the bug report I posted something that defined back/popBack only for bidir ranges even though it was an 'overspecification'. AKAIK, there is no clean way to define them otherwise. Steve: > Arguably, Take should never support back and popBack. > If you have a random access range, why wouldn't you just do r[0..3]? Because your range may not have opSlice defined. And is such a slice always lazy? The difficulty in std.range/algo is to keep them lazy as much as possible. Eager versions of these functions are easy to do (and could well be part of std.array or std.algo.eager) I *think* at some time I had a version of take that changed if the range has slicing and returned just r[0..n]. But I dropped it not long afterwards, maybe because it caused too much headache with the changing type (R or Take!R), even hiding it in a template. Anyway, the idea was just to extend map/filter/take and such as much as cleanly possible (see bugs #3871 and #3872), to have them play nice when composed. map particularly cries out to have opIndex/back/popBack/opSlice defined when possible. It a workhorse, used in many range transformation. Philippe
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
