bug in foreach continue

Adam D. Ruppe via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri Mar 17 07:23:41 PDT 2017


On Friday, 17 March 2017 at 13:10:23 UTC, Jonathan M Davis wrote:
> it looks like break and continue _are_ used at compile time, 
> since it prints

They are working exactly the same way as any other loop. The fact 
that it is unrolled and the dead code removed from the binary is 
an implementation detail that doesn't change the semantics of the 
loop, just like any other loop unroll optimization.

`continue` is more like `goto` than it is like `static if`, even 
when looping over AliasSeq.

> whereas if the break were just compiled in to be run at 
> runtime, you never would have seen any of the strings past 
> "hello" in the outer loop get printed.

No, they did a normal break at runtime. But they are breaking the 
INNER loop, so the outer loop continues. The generated code 
simply removed the dead portions since the optimizer realized 
there was no point carrying it around.

You are totally overthinking this, loops still work the same way 
regardless of what they are iterating over.

The only special thing about an AliasSeq thing is that the 
current value is available at compile time, so it is legal to use 
in more places (then the compiler implementation generates the 
code differently to make it happen, but that's the same idea as 
passing -funroll-loops or -O3 and getting different code, they 
don't change how break works.)

> Remember that this is basically doing loop unrolling, which is 
> not necessarily the same thing as you would expect from a 
> "static foreach." It's not like we're building a string mixin 
> here.

Yes.


More information about the Digitalmars-d-learn mailing list