On Mon, Apr 28, 2025 at 10:55 PM None <a1343922569_at_[hidden]> wrote:

> 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
>
[snip more about syntax]

But it doesn't seem like you "understand the technical challenges I pointed
out"! The issue isn't with the *syntax*. I actually like your first-choice
*syntax*. The problem is:

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! [...]
>
> One might say that the feature that is *possible* is not *useful*, while
> the feature that is *useful* is not *possible*.
>

Look at your own example again:

uint64_t myLog(uint64_t a, uint64_t b) {
    if consteval (b) {
        if (isPowerOfTwo(b)) {
            // Optimized implementation for b being compile-time known and
a power of 2
            return ...;
        }
    }
    // Generic implementation
}

The "if consteval (b)" line serves no purpose there. You could just as well
have written:

uint64_t myLog(uint64_t a, uint64_t b) {
    if (isPowerOfTwo(b)) {
        // Optimized implementation for b being compile-time known and a
power of 2
        return ...;
    }
    // Generic implementation
}

Your "Optimized implementation" may have depended on b's value being a
power of two, but it couldn't possibly have depended on b's value being
compile-time known, since in fact you (as the programmer) do *not* know b's
value, and the compiler has no mechanism to reveal it to you.
This example is also suboptimal because the runtime test for "isPowerOfTwo"
can be done in about 2 machine instructions, so it's not as if we win big
by skipping that test at runtime.
Maybe you can come up with a different (more motivating) example; but I
doubt it.

–Arthur

>