All,

How about expanding constinit in another direction! It doesn't have to be
constinit, it could be consteval or a better word for it. I show what I am
wanting.

C99

some_function_call( static constexpr struct some_type );

C++??

explicit constant initialization

some_function_call( static constexpr "Hello World"s, static constexpr
std::vector<std::string>{ static constexpr "Hello"s, static constexpr
"World"s } );
// OR
some_function_call( static constexpr "Hello World"s, static constexpr
std::vector<std::string>{ "Hello"s, "World"s } );
// OR
some_function_call( constinit "Hello World"s, constinit
std::vector<std::string>{ "Hello"s, "World"s } );

Here constinit would mean static, const, constexpr, consteval.

implicit constant initialization

some_function_call( const std::string&, const std::vector<std::string>& );

some_function_call( "Hello World"s, std::vector<std::string>{ "Hello"s,
"World"s } );

...

This is similar tohttps://
www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1045r1.html just without
the overloading and with different purpose in mind.

WHY?

1) to realize the original purpose of constexpr, ROMability, but instead of
it being specified as a maybe, now it is definite or the next best thing
const and static
2) anonymous constants
3) the simplicity reasons/examples in p1045r1
4) Mainly for safety reasons, static consts are safe from dangling and
concurrency errors
Why should assembly be safer and simpler than C++ when it comes to inline
constants that can't dangle?
Why should C99 be explicit safer and pre C99 implicitly safer than C++ due
to is custom structured literals having a lifetime like a variable instead
of the C++ temporary lifetime to the statement?
Why should the 1st C++, CFront, C with classes be more safe than any of the
standardization of C++ when it comes to constants?
Why should C++ be the only programming in the world or at least widely used
and popular language that has dangling constants, needlessly?
5) Performance reasons because no matter how great moving is, lvalue
referencing a global constant is faster than doing a dynamic memory
allocation. I am speaking of you std::string and std::vector.

constant dangling
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2724r1.html

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
>
> 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.
>
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>