On Tue, 12 Dec 2023 at 21:17, Greg Falcon via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> I looked around but didn't find any DRs addressing this issue.
>
> P1143R2 allows `constinit` on declarations, not just definitions, because `constinit` in a header declaration guarantees no initialization order fiasco on that variable. Meanwhile, the stronger `constexpr` on a variable definition provides lifetime protection during shutdown as well, since such a variable must be trivially destructible.
>
> The combination of the above suggests the following pattern:
>
> ```
> // foo.hpp
> extern constinit const int kFoo;
>
> // foo.cpp
> constexpr int kFoo = 1;
> ```
>
> However, by the text of P1143R2 and the spec, this is not allowed; a variable declared `constinit` anywhere must use `constinit` at the definition.
>
> Implementations have diverged on how to handle this. MSVC treats the above as an error, clang emits a warning, and gcc silently accepts it. (https://godbolt.org/z/je834M6hM)
>
> The `constexpr` requirements imply `constinit` (since they are strictly stronger), but the core language does not allow this substitution in a definition. Nor can an author write `constexpr constinit kFoo = 1;` in the .cpp file to get the best of both worlds, as this is explicitly forbidden as well.
>
> If folks here think this topic is ripe for consideration, I will happily file a core language issue.

This should be a paper targeted for EWG, not a Core Issue. The
requirement to have constinit at the definition seems deliberate,
so this isn't a spec bug. For others following, this is [dcl.constinit]/1:

"If the specifier is applied to any declaration of a variable, it
shall be applied to the initializing declaration."

Other than that, yes please, looks plausible.