> This is not possible because stack allocation is done at runtime
As is constant static and thread local initialization, done at program and threat start, respectively. constinit only specifies that the value they are initialized with is a compile time constant, which is also fine with automatic storage duration
My only concern with the idea is that it makes an "omitted `static`" typo harder to catch.
int f(int i) {
QUALIFIERS int a[] = {1,2,3,4,5,6,7,8,9,10};
return a[i];
}
If -DQUALIFIERS= then both Clang and GCC generate inefficient code.
If -DQUALIFIERS=const then both Clang and GCC generate inefficient code.
If -DQUALIFIERS=constexpr then both Clang and GCC generate inefficient code.
If -DQUALIFIERS=constinit then both Clang and GCC reject with an error diagnostic.
If -DQUALIFIERS=static then both Clang and GCC generate good code.
If -DQUALIFIERS=static const then both Clang and GCC generate good code.
If -DQUALIFIERS=static constexpr then both Clang and GCC generate good code.
If -DQUALIFIERS=static constinit then both Clang and GCC generate good code.
Now, it seems that the first three lines should all be considered missed-optimization bugs in both Clang and GCC.
And the fourth line is inconsistent with the first three; that's basically your argument, as I understand it, that inconsistency is bad (and you're right).
But it's arguably convenient that line #4 is rejected, given that the person writing line #3 certainly meant line #7 and the person writing #4 probably meant #8 (since if they didn't mean #8 then arguably they meant #1). If you're not trying to avoid the Static Initialization Order Fiasco, then you don't need `constinit`; so, any `constinit` variable that isn't subject to static initialization probably indicates a bug.
I don't think my concern is terribly big; but it's the kind of thing that a proposal should engage with and provide some reasonable argument that "the ability to detect an omitted `static` here isn't something we ought to value."
HTH,
Arthur