[phobos] phobos commit, revision 1566

[Philippe Sigaud]

On Sat, May 29, 2010 at 15:54, Andrei Alexandrescu <andrei at erdani.com>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100529/a9fd2087/attachment.html>