https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121594
friedkeenan at protonmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |friedkeenan at protonmail dot
com
--- Comment #2 from friedkeenan at protonmail dot com ---
I have a similar case that doesn't compile and at least looks similar:
```
#include <array>
int main() {
template for (constexpr auto I : std::array{1, 2, 3}) {
/* ... */
}
}
```
Godbolt link: https://godbolt.org/z/ajvvGeeTW
This gives an error saying:
```
<source>:6:5: note: '<temporary>' was not declared 'constexpr'
<source>:4:34: error: the value of '<temporary>' is not usable in a constant
expression
4 | template for (constexpr auto I : std::array{1, 2, 3}) {
| ^
```
A similar workaround as given here, of first defining the array as static
constexpr and then using that in the template for, does compile:
```
#include <array>
int main() {
static constexpr auto range = std::array{1, 2, 3};
template for (constexpr auto I : range) {
/* ... */
}
}
```
However, if one drops off the static from the declaration, then it again does
not compile:
```
#include <array>
int main() {
constexpr auto range = std::array{1, 2, 3};
template for (constexpr auto I : range) {
/* ... */
}
}
```
Godbolt link: https://godbolt.org/z/r53e1zxPx
This case gives the following error:
```
<source>:6:38: error: 'range' is not a constant expression
6 | template for (constexpr auto I : range) {
| ^~~~~
<source>:6:38: note: reference to 'range' is not a constant expression
<source>:4:20: note: address of non-static constexpr variable 'range' may
differ on each invocation of the enclosing function; add 'static' to give it a
constant address
4 | constexpr auto range = std::array{1, 2, 3};
| ^~~~~
| static
```
So it would perhaps appear that the non-constant address in the non-static and
temporary cases is what's causing the issue here. The experimental branch of
Clang which supports P2996 compiles all these cases.
The error message for the tuple case is different so I'm not completely sure
it's the same core issue, but I figure maybe the tuple code is divergent enough
to cause a different error message while still being caused by the same thing.
