On Sun, Apr 29, 2012 at 03:06:53AM +0200, bearophile wrote:
> Jonathan M Davis:
>
> >* foreach_reverse is essentially redudant at this point (not to
> >mention
> >confusing if combined with delegates), since we have retro.
>
> retro() can't replace foreach_reverse until the front-end
> demonstrability produces asm code equally efficient.
> Loops _must_ be fully efficient, they are a basic language
> construct, this is very important. Even foreach() is sometimes not
> equally efficient as a for() in some cases...
[...]
IMO, the compiler needs to _aggressively_ inline opApply() delegates,
unless it's impossible (e.g. opApply is recursive), or perhaps exceeds
some reasonable size limit for loop inlining). It's rather disheartening
to design a great abstract type for manipulating collections, only to
have opApply always incur the overhead of allocating and invoking a
delegate _every loop iteration_, even when opApply is as simple as:
int opApply(int delegate(ref T arg) dg) {
someSetupCode();
for (i=0; i<n; i++) {
dg(element[i]);
}
someCleanupCode();
}
As far as I'm concerned, the compiler *should* just inline the whole
thing (both opApply and the delegate body) when you write foreach(c;
container) {...}. There's no reason for such a trivial loop to incur a
call to a delegate every iteration.
Powerful abstractions such as opApply need to be optimized to the max,
so that D's generic programming capabilities can be a strong selling
point.
T
--
Nearly all men can stand adversity, but if you want to test a man's character,
give him power. -- Abraham Lincoln
