foreach thoughts

[monarch_dodra]

On Tuesday, 14 January 2014 at 19:05:22 UTC, Peter Alexander 
wrote:
> 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.

Actually, you could give an opApply for infinite ranges too. 
foreach loops can have breaks, and opApply knows how to handle 
them.