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