--- Comment #7 from Andrei Alexandrescu <> 2011-03-03 
16:29:17 PST ---
(In reply to comment #6)
> (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.

Instead you may want to use the range interface and benefit of walkLength and

> > 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()).

Definitely increases complexity because it requires the usual type
discrimination and an extra version. But let's say that's manageable. The worse
problem is that it creates a precedent - then why not do the same for other
algorithms (including find itself of which you complain already)? Please abide
to your own standards.

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

Reply via email to