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

[d-bugmail at puremagic.com]

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



--- Comment #7 from Andrei Alexandrescu <andrei at metalanguage.com> 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
others.

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


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