[Issue 5691] walkLength() compatible with opApply()

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Mar 3 16:18:30 PST 2011


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



--- Comment #6 from bearophile_hugs at eml.cc 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
> http://d.puremagic.com/issues/show_bug.cgi?id=3923.

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: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list