--- Comment #6 from 2011-03-03 16:15:35 PST ---
(In reply to comment #5)
> We could define some algorithms to work with opApply, but that would blow up
> the size of std.algorithm

I agree that std.algorithm already contains many functions (as in future
std.container if it doesn't split). But I don't think this can justify keeping
walkLength() semantic as an amputee. A possible solution is then to keep
walkLength() inside std.range, despite it working with opApply() too.

One of the purposes of a good standard library is to reduce the useful
functions I have to write and maintain. I will need to keep a walkLength-like
function to perform this complete semantics.

> and we'd hit

walkLength() returns an integral value that represents the walking length of
the iterable, regardless the way the iterable is implemented. This doesn't make
the function harder to understand (but a struct/class is free to have more than
one opApply(), that yield a different number of items. walkLength() has to walk
the single-item-yield opApply()).

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to