C++标准未正式引入128/256位整数的阻碍因素是什么？

开发者对大位宽整数的需求确实普遍存在，目前行业内常用的替代方案包括Boost库相关组件、GCC/Clang等编译器提供的__int128扩展，或是标准库的std::bitset<>，但前两者不属于标准，后者无法支持完整的整数算术运算，始终不够方便。C++标准委员会没有快速推进该特性，主要有以下几方面顾虑：

• 不符合C++零开销抽象的核心设计准则
  目前只有x86-64、ARM64等少数主流架构提供原生128位整数的硬件支持，大量嵌入式、老旧x86、小众架构完全没有对应的硬件指令。如果标准强制要求支持128/256位整数，这些平台只能通过软件模拟实现，运算效率会比原生整数低几个数量级，直接违背了C++“不为不需要的特性付出额外开销”的设计原则。
• 现有实现的ABI和功能差异过大，统一成本极高
  目前主流编译器已经实现的__int128等扩展，在不同平台、不同编译器下的ABI规则（比如参数传递方式、返回值处理）、支持的运算边界、输入输出配套实现都存在明显差异，甚至MSVC直到最近的版本才初步支持128位整数扩展。如果标准要统一该特性的规范，需要协调所有主流编译器厂商、平台方调整现有实现，稍有不慎就会破坏大量已经使用扩展特性的存量代码，落地阻力非常大。
• 特性边界尚未形成行业共识
  关于大位宽整数的标准定义，行业内还存在很多没有定论的争议：是仅新增128位有/无符号整数，还是同步支持256位甚至更宽的整数？要不要配套专门的字面量后缀、标准库算术函数、输入输出重载？和现有基础整数类型的隐式转换规则如何设计？这些细节如果没有经过充分论证就贸然纳入标准，反而会给开发者带来更多的兼容性和使用陷阱。
• 优先级相对更低
  目前已有的非标准方案已经能覆盖绝大多数场景下的大位宽整数需求，相比之下，模块、协程、范围库完善、执行器这些更影响广大开发者体验的特性优先级更高，委员会有限的人力会优先投入到这些领域，大位宽整数的标准化进度自然会被延后。

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