Thank you, Arthur, for your valuable feedback. I understand the technical challenges you pointed out, and indeed my original syntax if consteval(b) could have some problems, suggesting that the "named variable" b might be usable as a constexpr within the branch value of the expression, which would introduce complex semantic issues.
I think we can first consider the template version "if (std::is_constexpr_arg<N>())" (just like the "form 3" in my previous code) or "if (std::is_constant_evaluated(N))", which represents the conditional judgment of "whether the (N-1)th argument is constexpr or not", and is just similar to the "std::is_constant_evaluated()" (which can be regarded as the parameterless version of "std::is_constant_evaluated(N)") in C++20, or the "__builtin_constant_p(expr)" in GCC (though it is "compiler-dependent"). The biggest difference between the "__builtin_constant_p(expr)" and the "std::is_constant_evaluated(N)" is that the latter replaces the "variable name" with the "parameter index". In my opinion, this form is "technically feasible" and the "natural extension" of the "std::is_constant_evaluated()".

The "if consteval(xxx)" can be considered as "syntactic sugar" of the "if (std::is_constexpr_arg<N>())" or "if (std::is_constant_evaluated(N))", just like the relationship between the "if consteval" in C++23 and the "if std::is_constant_evaluated()" in C++20. If we implement the template version, then we can consider the "syntactic sugar" version "if consteval(xxx)", which is the most natural syntax extension to the existing standard specification. The "if consteval(para_name)" looks nice, but its problem has been mentioned before, which means that we must introduce a new syntactic explanation of the named variable "para_name" in this special context. The "if consteval(index)" is easier to implement, but looks a bit odd.

I offer these thoughts for your consideration.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Arthur O'Dwyer via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, April 28, 2025 10:22 PM
To: marcinjaczewski86_at_[hidden]m <marcinjaczewski86_at_[hidden]>
Cc: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>; std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Idea and proposal: Concise mechanism for detecting specific constexpr arguments within functions

On Mon, Apr 28, 2025 at 9:56 AM Marcin Jaczewski <marcinjaczewski86_at_[hidden]<mailto:marcinjaczewski86_at_[hidden]>> wrote:
pon., 28 kwi 2025 o 15:48 Arthur O'Dwyer via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> napisał(a):
>
> Now, the big problem with this is that just knowing that `b`'s value is known to the compiler at compile-time — a boolean yes/no answer — doesn't give the programmer access to what numeric value the compiler thinks it has!
> So we still can't write, e.g.,
> uint64_t myLog(uint64_t a, uint64_t b)
> {
> if consteval (b) {
> std::array<int, b> subresults; // ERROR, the expression `b` did not magically become a constant expression in here... unless you propose that it should, which is a whole new can of worms
> // Optimized implementation with b known
> return ...;
> }
> // Generic implementation
> }

Even more:
```
if consteval (b) {
    return std::array<int, b>{};
}
```
How do we even handle this? Function would effectively change its type
based on values you pass to it.

Right, that's a good example of the whole new can of worms that would result from making my example not-an-"ERROR".

One might say that the feature that is possible is not useful, while the feature that is useful is not possible.

–Arthur