> 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.
Though an interesting case study, I’m not sure the example here is relevant. One should expect non-static constinit to generate code more similar to constexpr than static constinit. Constexpr similarly doesn’t have an error either (and realistically that may be a bigger concern).
 
> 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.
Yes, that is the case currently since that is the ONLY use of constinit, but constinit never implied static and this proposal will add additional use to constinit outside of avoiding SIOF. It is thus up to the user to catch omitted static, as is the case for other attributes (which you illustrated in your example).
 
From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Sent: Friday, January 26, 2024 1:51 PM
To: std-proposals_at_[hidden]
Cc: Franklin <yang.franklin9_at_[hidden]>
Subject: Re: [std-proposals] Expanding constinit
 
On Fri, Jan 26, 2024 at 2:01 PM Franklin via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote:
> 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