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@lists.isocpp.org> on behalf of Arthur O'Dwyer via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Monday, April 28, 2025 10:22 PM
To: marcinjaczewski86@gmail.com <marcinjaczewski86@gmail.com>
Cc: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>; std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
Subject: Re: [std-proposals] Idea and proposal: Concise mechanism for detecting specific constexpr arguments within functions
pon., 28 kwi 2025 o 15:48 Arthur O'Dwyer via Std-Proposals <std-proposals@lists.isocpp.org> 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