foreach thoughts

Peter Alexander peter.alexander.au at gmail.com
Tue Jan 14 11:05:20 PST 2014


On Tuesday, 14 January 2014 at 18:38:27 UTC, David Nadlinger 
wrote:
> On Tuesday, 14 January 2014 at 16:31:00 UTC, Dicebot wrote:
>> So it does inline but end result is still less optimal 
>> assembly-wise.
>
> The problem, by the way, seems to be that the program actually 
> contains two loops that LLVM cannot merge: One in the filter() 
> constructor (skipping the initial run of even elements), and 
> the actual foreach loop in main().
>
> David

I wonder if there is some way the language could help with that 
in the common case. For example, provide an opApply for all 
non-infinite ranges that can be used with foreach instead of 
front/empty/popFront. I imagine opApply is much easier to inline 
and optimise than trying to piece range operations and state back 
together to see the underlying loop.


More information about the Digitalmars-d mailing list