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