Does D have too many features?

Timon Gehr timon.gehr at gmx.ch
Mon Apr 30 11:49:38 PDT 2012


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
>



More information about the Digitalmars-d mailing list