On 04/30/2012 04:47 AM, H. S. Teoh wrote:
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
Use a scope delegate in the opApply signature to avoid the allocation.
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
