*I find the "static constexpr" syntax in expressions confusing. If youwant
to go into this direction on a per-expression basis, how about a"consteval
operator"?> some_function_call(x, consteval(y));*

Same track: I am asking for a consteval specifier like C
> some_function_call(x, consteval y);
// or some_function_call(x, constinit y)
// or some_function_call(x, rom y)
// or some_function_call(x, ROM y)
// or some_function_call(x, constant y)
// or some_function_call(x, read_only y)
I don't care what the word is as long as it is const and static throughout.
... and const init and consteval

This should also be legal.

rom int{4};
rom int{2};
some_function_call(x , rom {x, y} , rom {y, x} )











*In this example, x would not be evaluated as a constant expression,but y
would be. This would be a very powerful tool because it would dotwo things
for you:> int x = consteval(y);This is effectively "constinit int x = y".>
requires { consteval(y); }This tests whether y can be evaluated as a
constant expression.*

What I am asking for not only asserts that it is constant through and
through but also makes it static storage duration.
That's where the safety comes in.

If you categorize all instances as being const and consteval.
const(false), consteval(false) == purely runtime
const(false), consteval(true) == mutables initialized with a *rom template*
const(true), consteval(false) == immutables
*const(true), consteval(true) == pure compile time constants*

That's 37.5% of the scenarios.

If one realize that inputs by default should be passed by const& unless
they can be copied than it is only an issue of whether it was constant
initialized or not;

50% of those scenarios

These percentages drop to ~0% as code bases become more runtime and
increase towards ~100% in constexpr test and example code.
The latter of which is where we get beat up in the media. Do we have to
make it so easy for the language zealots?

...

Also there are sound reasons why this should be the implicit behavior for
constexpr capable temporaries passed to const &.
How does a programmer know that an instance of constant dangling even needs
to be fixed if it is left up to compilers?
Are we really asking all C++ programmers to have to look at assembly to
know whether or not it needs to be fixed.
That is the current state of affairs.
The only argument I received against this so far was about teachability and
that doesn't stand up because the current state of affairs is unteachable
due to the current indeterminate behavior.






On Fri, Jan 26, 2024 at 8:41 AM Jan Schultke <janschultke_at_[hidden]>
wrote:

> I find the "static constexpr" syntax in expressions confusing. If you
> want to go into this direction on a per-expression basis, how about a
> "consteval operator"?
>
> > some_function_call(x, consteval(y));
>
> In this example, x would not be evaluated as a constant expression,
> but y would be. This would be a very powerful tool because it would do
> two things for you:
>
> > int x = consteval(y);
>
> This is effectively "constinit int x = y".
>
> > requires { consteval(y); }
>
> This tests whether y can be evaluated as a constant expression.
>