Does D have too many features?

[H. S. Teoh]

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