http://d.puremagic.com/issues/show_bug.cgi?id=5691
--- Comment #6 from bearophile_h...@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: -------