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