https://issues.dlang.org/show_bug.cgi?id=12920

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #1 from hsteoh@quickfur.ath.cx ---
Still happens on git HEAD.

--

https://issues.dlang.org/show_bug.cgi?id=12920

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical

--

https://issues.dlang.org/show_bug.cgi?id=12920

safety0ff.bugz <safety0ff.bugz@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |safety0ff.bugz@gmail.com
         Resolution|---                         |DUPLICATE

--- Comment #2 from safety0ff.bugz <safety0ff.bugz@gmail.com> ---


*** This issue has been marked as a duplicate of issue 7392 ***

--

https://issues.dlang.org/show_bug.cgi?id=12920

--- Comment #3 from Marc Schütz <schuetzm@gmx.net> ---
Is it really a duplicate? The code in the other bug is clearly invalid, but this one should work IMO.

--

https://issues.dlang.org/show_bug.cgi?id=12920

Martin Krejcirik <mk@krej.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mk@krej.cz
           Hardware|x86_64                      |All
                 OS|Linux                       |All

--- Comment #4 from Martin Krejcirik <mk@krej.cz> ---
(In reply to Marc Schütz from comment #3)
> Is it really a duplicate? The code in the other bug is clearly invalid, but this one should work IMO.

In this example 'v' is a runtime variable and as such it cannot be a case variable.

If a,b,c were enums, it would compile.

But I don't understand why uint a,b,c gives error message Error: variable v cannot be read at compile time

but int a,b,c does not. So maybe it's a different bug.

--

https://issues.dlang.org/show_bug.cgi?id=12920

--- Comment #5 from Marc Schütz <schuetzm@gmx.net> ---
(In reply to Martin Krejcirik from comment #4)
> In this example 'v' is a runtime variable and as such it cannot be a case variable.

No, the foreach iterates over `values`, which is a tuple. It should therefore get unrolled, and `v` should become a constant.

--

https://issues.dlang.org/show_bug.cgi?id=12920

--- Comment #6 from Martin Krejcirik <mk@krej.cz> ---
(In reply to Marc Schütz from comment #5)
> No, the foreach iterates over `values`, which is a tuple. It should therefore get unrolled, and `v` should become a constant.

It cannot become a constant if a,b,c are not constants. It could still work if foreach is unrolled at compile-time, but that would be an enhancement request, I think.

--

https://issues.dlang.org/show_bug.cgi?id=12920

--- Comment #7 from Marc Schütz <schuetzm@gmx.net> ---
(In reply to Martin Krejcirik from comment #6)
> (In reply to Marc Schütz from comment #5)
> > No, the foreach iterates over `values`, which is a tuple. It should therefore get unrolled, and `v` should become a constant.
> 
> It cannot become a constant if a,b,c are not constants. It could still work if foreach is unrolled at compile-time, but that would be an enhancement request, I think.

foreach over a tuple _is_ unrolled, that's already implemented behaviour. But you're right that `values` could indeed refer to global or even local vars, didn't think of that.

--