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 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.

This proposal also serves to improve consistency, since there is really no reason to exclude automatic storage from constinit, and there are benefits to including it (even if minor).

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]cpp.org> on behalf of Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, January 26, 2024 7:09:40 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jason McKesson <jmckesson_at_[hidden]>
Subject: Re: [std-proposals] Expanding constinit

On Fri, Jan 26, 2024 at 7:39 AM Jan Schultke via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> > Upon loading the executable, the representation of the object is also mapped into the process address space, so really no initialization happens at run time ...
>
> So ... loading the executable and mapping the object representation of
> the object happens at compile-time, not at run-time? This is obviously
> false.
>
> I get that it's cheap, and on modern architectures, doesn't require
> any work to be done individually per object, but let's not get
> sidetracked by implementation details. As described in
> https://eel.is/c++draft/basic.start.static, all static initialization
> strongly happens before dynamic initialization. However, it doesn't
> happen "at compile-time". This would imply that the lifetime of the
> object has begun before you have turned on your PC, let alone run the
> program.
>
> > A variable declared constexpr specifies to create a compile-time constant which can be used in other constant expressions.
>
> No. It specifies that (https://eel.is/c++draft/dcl.constexpr#6)
> > the full-expression of the initialization shall be a constant expression

That's not *all* it does. Most uses of `constexpr` variables also
themselves become constant expressions. Forcing its initialization to
be a constant expression is just a thing you have to do to achieve
that effect.

> In practice, this makes it feasible for implementations to evaluate
> the initializer prior to program startup; however, this is not
> required and wouldn't be implementable when writing a C++ interpreter.
>
> > constinit has a different intention. It explicitly requires that initialization happens during compile time ...
>
> While there is no such thing as "compile-time" in the standard, I
> absolutely agree that the original intent of constinit doesn't make
> much sense when applied to automatic storage duration variables. Their
> lifetime begins when the function gets executed, so they cannot be
> constant-initialized. However, I think it's reasonable to slightly
> misuse the constinit keyword to equally imply that "the
> full-expression of the initialization shall be a constant expression",
> however, without also implying const.

Why should we want to?

>
> I think my motivating example isn't too far-fetched and this feature
> would be implementable, so it's quite reasonable to make a proposal.

Your motivating example is not particularly motiving. I don't see why
it's so important that the call to `compute_size` must be a constant
expression, yet you must also be able to modify the object. Equally
important, if `compute_size` is a `consteval` function, you can just
as easily do:

```
constexpr auto buffer_size = compute_size(...);
config c{ .buffer_size = buffer_size, .host_name = get_host_name_from_os()};
start_service(c);
```

It seems to me that what you really want is a way to be able to invoke
a `consteval` function and use the results to do something that is not
explicitly `constexpr`.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals