C++23放宽constexpr限制后，能否将constexpr设为默认？

一、C++23后constexpr函数的剩余限制 #

你提到的是核心限制，但还有一些场景化的细节限制需要注意：

• 不能是协程
• 构造函数/析构函数所属的类不能包含虚基类
• constexpr函数模板或类模板的constexpr成员函数，至少存在一个合法特化满足上述要求
• 额外的次要限制：
  • 函数内部不能定义thread_local存储期的变量
  • 当尝试编译期求值时，执行路径不能包含asm语句、未捕获的异常（虽然函数可以包含try/catch块）
  • 不能是concept（这更多是语法层面的限制，而非函数本身的行为限制）

二、放宽限制后constexpr函数的实用价值 #

即使C++23大幅弱化了constexpr的限制，它的核心价值依然清晰且不可替代：

1. 按需编译期计算：虽然不再要求函数对所有参数都能编译期求值，但当传入常量表达式时，编译器仍会自动触发编译期计算，彻底消除运行时开销。比如编译期计算哈希值、生成常量数据结构，或是验证配置参数的合法性。
2. 统一代码逻辑：用同一个函数覆盖编译期和运行时场景，无需维护两套逻辑。例如一个字符串处理函数，既可以在编译期解析常量字符串生成枚举，也能在运行时处理用户输入的动态字符串，减少代码冗余。
3. 强化编译期检查：配合static_assert、consteval等特性，constexpr函数可以在编译阶段完成参数验证、逻辑正确性检查，提前发现错误，避免运行时崩溃或异常。
4. 适配constexpr标准库：C++20及之后的标准库提供了大量constexpr容器（如std::array的完整constexpr操作）、算法和工具类，constexpr函数可以直接利用这些特性，在编译期构建复杂的业务逻辑。
5. 简化元编程：相比传统依赖模板特化、SFINAE的元编程，constexpr函数支持常规的循环、分支等流程控制，用更直观的代码实现元编程逻辑，大幅降低元编程的学习和维护成本。

三、能否将constexpr设为默认？ #

目前来看，直接将constexpr设为函数默认属性并不现实，主要有以下原因：

1. 二进制兼容性问题：现有非constexpr函数与constexpr函数的ABI可能存在差异（例如编译器的inline策略、符号生成规则），强行默认会破坏既有代码的二进制兼容，导致旧版本库与新版本代码无法正常链接。
2. 语义冲突风险：constexpr函数的特殊语义是“支持编译期求值”，但很多函数本身设计为仅运行时执行（比如涉及IO操作、动态内存分配的函数）。如果默认设为constexpr，编译器可能会尝试对这些函数进行编译期求值，引发编译错误，反而增加开发负担。
3. 编译性能损耗：编译器需要对constexpr函数进行额外的检查和求值尝试，即使大部分场景下不会触发编译期计算。若所有函数默认都是constexpr，会显著增加编译器的工作负载，拖慢整体编译速度。
4. 代码可读性下降：constexpr是一个显式的语义标记，能让开发者快速识别哪些函数支持编译期计算。如果默认开启，代码的意图会变得模糊，不利于团队协作和后续维护。

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