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

[d-bugmail at puremagic.com]

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



--- Comment #12 from Steven Schveighoffer <schveiguy at yahoo.com> 2011-03-04 08:13:08 PST ---
I agree that we don't want to cater to all styles, at the expense of added
complexity.  I think actually, using isIterable, does not increase complexity
immensely for walkLength.  It covers the same ground as isInputRange, but with
the added bonus of allowing any foreachable structure.

One thing to note is, you cannot convert opApply (or similar) constructs into
ranges.  This means that any function/construct in std.algorithm or std.range
that yields a range cannot be used on a generic isIterable type.  For example,
map yields a range, so it cannot accept opApply type arguments.

In addition, any function which operates on multiple aggregates could not take
opApply-based args because you can't iterate them in parallel easily.  This
eliminates quite a few functions.

However, any functions that operate on the *whole* set of values from a range
should be easily tweaked to also accept isIterable.

For example, reduce, some forms of count, isSorted, etc. should be possible on
any foreachable construct.

I think we may find that a) the number of functions which can also accept
isIterable types is pretty small and b) adding the ability to support
opApply-based aggregates is not complex.

It definitely needs more analysis before judging whether it makes sense.  I
agree that if you do walkLength, you should do all the functions that make
sense.

BTW, I just noticed that count(r) is identical to walkLength(r).  Any reason
for the duplication?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------