C++23中[[assume]]属性在常量表达式中失效的行为探究

C++23引入的[[assume(conditional-expression)]]属性规定：若conditional-expression求值结果不为true，则程序行为是未定义的。

举个简单例子：

int div(int x, int y) {
    [[assume(y == 1)]];
    return x / y;
}

这段代码编译后，编译器可利用“y不为1时行为未定义”的信息做优化，比如GCC会生成等价于假设y始终为1的汇编：

div(int, int):
        mov     eax, edi
        ret

注意，这类优化并非强制要求，编译器完全可以忽略所有[[assume]]假设。

常量表达式场景的核心疑问 #

C++标准要求编译器诊断常量表达式中的所有未定义行为，但这在[[assume]]的场景下是否合理？看下面的示例：

constexpr bool extremely_complicated(int x) {
    bool result;
    // 一万行复杂计算逻辑...
    return result;
}

constexpr int div(int x, int y) {
    // 当编译器无法证明extremely_complicated(x)返回true时，是否应触发编译错误？
    // 这里extremely_complicated(x)不会被求值，编译器需要在不求值的前提下证明结果为true
    [[assume(extremely_complicated(x))]];
    return x / y;
}

constexpr int quotient = div(4, 2);

这里的矛盾点在于：编译器不可能解决停机问题，也就无法对任意复杂的条件表达式完成“是否恒为true”的证明。那如果编译器无法证明假设的正确性，是否属于标准层面的问题？

目前C++标准文档的[dcl.attr.assume]章节并未明确提及[[assume]]与常量表达式的具体交互逻辑。

注：extremely_complicated(x)本身并非常量表达式，但它出现在[[assume]]中时，若其结果为false，会导致div(4,2)在常量求值过程中产生未定义行为——而常量表达式中的未定义行为通常要求编译器诊断。

内容的提问来源于stack exchange，提问作者Jan Schultke