C++中符合constexpr要求的函数为何需要显式标注constexpr？

这个设计是C++标准委员会权衡过语义契约、编译效率、向后兼容性之后的选择，核心原因有这几个：

• 明确的接口契约承诺
  constexpr从来不是给编译器用的隐式优化提示，而是给函数调用方的公开承诺：你标了这个关键字，就等于保证后续版本的这个函数都会满足编译期执行的要求，调用方可以放心把它用在模板参数、数组长度这类需要编译期常量的场景。如果由编译器自动推断是否支持constexpr，开发者哪天改函数实现不小心破坏了编译期执行的条件，所有依赖这个能力的上游代码都会直接编译失败，而且事先没有任何契约提醒，会直接导致大规模的兼容性事故。
• 控制编译开销
  如果要求编译器自动检测所有符合条件的函数为隐式constexpr，编译器需要对每一个函数都做constexpr合规性检查，还要同时生成编译期可执行的常量计算版本、以及运行期版本两份代码，对于动辄几十万上百万文件的大型C++项目来说，会导致编译速度指数级变慢，完全没有必要。显式标注相当于开发者主动告诉编译器“只有我标了的函数才需要做constexpr处理”，大幅降低编译侧的无用开销。
• 保证向后兼容性
  C从C11才引入constexpr特性，此前已经有几十年的存量代码。很多旧代码里的函数刚好符合constexpr的所有要求，但原始开发者根本没有让它在编译期执行的设计意图。如果默认开启自动推断，会导致很多旧代码的行为出现不可预期的变化，甚至引出原本不存在的编译错误，破坏C++一直强调的向后兼容原则。
• 避免语义歧义
  部分边界场景下，函数的执行时机（编译期/运行期）会影响程序的最终行为，比如函数内部依赖了某些编译期和运行期值不一样的环境变量、宏定义。显式标注constexpr能让开发者完全掌控哪些函数允许编译期执行，避免编译器自动选择执行时机带来的意料之外的bug。

补充：constexpr的设计逻辑和inline非常相似：二者最初都带有优化提示的属性，但最终的核心作用变成了语法层面的契约标记，而非编译器可以自动推断的优化选项。

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