Date: Fri, 26 Jan 2024 16:32:12 -0500
On Fri, Jan 26, 2024 at 2:01 PM Franklin via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> There seems to have been a lot of discussion (way more than I can reply to!), so here are my responses to some of the discussion points. Please note the quotes are paraphrased.
>
> > 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
>
> > This dilutes the meaning of constinit
> Constinit, compared with constexpr and consteval, is considerably less common and only fulfills a niche purpose (globals are often considered bad practice). The changes do not modify behavior of constinit, only the conditions in which it can be used.
>
> > You can store the result of a constant expression in a separate constexpr variable and use that instead
> As can you for static variables. Since the assignment is to a constexpr value, it is also guaranteed to have constant initialization. The only drawback is that this does not prevent against typos to a non-constexpr variable for initialization.
The key justification for `constinit` was avoiding the "Static
Initialization Order Fiasco". By ensuring that a static variable
(whose initializing expressions can use other previously declared
static variables) is initialized with a constant expression, you can
guarantee that its initializing expression cannot be broken by
initialization order issues.
Using `constinit` with local variables doesn't help at all in this regard.
> The other main feature of this proposal is of course to guarantee that an expensive constructor is not invoked at runtime, which serves the same purpose as the original constinit and `override` in preventing unintentional mistakes.
`constinit` and `override` are about preventing breakage, preventing
scenarios that cause your code to behave incorrectly. An "expensive
constructor" being invoked at runtime is not broken code; it's just
*slower* code. If the constructor was `constexpr`, and the parameters
were also constant expressions, it isn't a "mistake" if the compiler
generates runtime code for it. That's a quality of implementation
matter.
<std-proposals_at_[hidden]> wrote:
>
> There seems to have been a lot of discussion (way more than I can reply to!), so here are my responses to some of the discussion points. Please note the quotes are paraphrased.
>
> > 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
>
> > This dilutes the meaning of constinit
> Constinit, compared with constexpr and consteval, is considerably less common and only fulfills a niche purpose (globals are often considered bad practice). The changes do not modify behavior of constinit, only the conditions in which it can be used.
>
> > You can store the result of a constant expression in a separate constexpr variable and use that instead
> As can you for static variables. Since the assignment is to a constexpr value, it is also guaranteed to have constant initialization. The only drawback is that this does not prevent against typos to a non-constexpr variable for initialization.
The key justification for `constinit` was avoiding the "Static
Initialization Order Fiasco". By ensuring that a static variable
(whose initializing expressions can use other previously declared
static variables) is initialized with a constant expression, you can
guarantee that its initializing expression cannot be broken by
initialization order issues.
Using `constinit` with local variables doesn't help at all in this regard.
> The other main feature of this proposal is of course to guarantee that an expensive constructor is not invoked at runtime, which serves the same purpose as the original constinit and `override` in preventing unintentional mistakes.
`constinit` and `override` are about preventing breakage, preventing
scenarios that cause your code to behave incorrectly. An "expensive
constructor" being invoked at runtime is not broken code; it's just
*slower* code. If the constructor was `constexpr`, and the parameters
were also constant expressions, it isn't a "mistake" if the compiler
generates runtime code for it. That's a quality of implementation
matter.
Received on 2024-01-26 21:32:32