== Quote from bearophile (bearophileh...@lycos.com)'s article > The gentle and a-lot-working David Simcha has converted one of my bug reports into an enhancement request: > http://d.puremagic.com/issues/show_bug.cgi?id=4264 > Currently (SVN) only array() is able to digest iterables that define opApply only, but I think a few more spread support will be very good. > In the thread of that 4264 there are plenty of comments and views of the situation. Opinions welcome, both here and there. > Bye, > bearophile
I've started looking into the performance aspects of supporting opApply in std.algorithm and std.range where possible. I created quick and dirty Map, Filter and Until opApply-based iterables for D1. I then instantiated them with int[] arrays and some trivial (as in, compile to a single instruction) predicates, compiled them on LDC with full optimizations and started reading some disassemblies. It seems even LDC is too stupid to fully inline cases where Map is stacked with Filter. Things seem to get partially inlined in the most arbitrary ways, even though Map gets fully inlined when used alone. Even stranger, the delegate calls get converted to direct function calls, even though they don't get inlined. I wonder if this is a weakness of compiler inlining heuristics in general, though. When you stack a whole bunch of trivial function calls together, such these function calls would compile down to a handful of instructions if every single one of them was inlined, is this just an ugly corner case in the imperfect heuristics compilers use to inline functions? If so, now I understand why old-school programmers don't trust compilers.