With all the challenges presented, wouldn’t it make more sense to make it possible to explicitly mark parameters as constexpr/consteval and allow overloads on constexpr/consteval parameters?

We could do overloads like this:
uint64_t myLog(uint64_t a, uint64_t b);
uint64_t myLog(consteval uint64_t a, uint64_t b);
uint64_t myLog(uint64_t a, consteval uint64_t b);
uint64_t myLog(consteval uint64_t a, consteval uint64_t b);

This would be a lot to write. We could allow the variant:
uint64_t myLog(constexpr uint64_t a, constexpr uint64_t b);
with the meaning that ‘constexpr’ can be both compile time and runtime evaluated. We could the synthesize the proper functions (with and without ‘consteval’ as above). In that case it would make sense that we could ask for parameters if they are consteval.

> On Apr 29, 2025, at 6:33 AM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Monday, 28 April 2025 20:34:57 Pacific Daylight Time None via Std-Proposals
> wrote:
>> #include <iostream>
>> #include <cstdint>
>>
>> uint64_t myLog(uint64_t a, uint64_t b) {
>> if consteval (b) { // first judge whether b is constexpr
>> if (isPowerOfTwo(b)) { // then judge whether b is power of two
>> // Optimized implementation for b being compile-time known and a
>> power of 2 return ...;
>> }
>> }
>> // Generic implementation
>> }
>
> If you want this to go further, please study GCC's __builtin_constant_p()
> intrinsic, which is exactly what this is. Research where it's used and useful
> for, as well as where it doesn't work and its weaknesses.
>
> The Linux kernel uses it a lot. But it uses a lot of it in macros, which may
> be the weakness.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals