为何std::optional未采用哨兵值表示空可选值？

你已经明确该方案因ABI破坏无实施可能，这里针对“最初为何未选择此方案”补充除实现复杂度外的核心原因：

• 标准库类型内存布局未标准化：C++标准从未规定std::string、std::vector等类型的具体内存结构。不同编译器甚至同一编译器的不同版本，对这类容器的实现都可能差异巨大——比如有的std::string用小字符串优化（SSO）时会把数据存在内部缓冲区，有的则始终用堆指针。这意味着不存在跨平台、跨实现的通用“无效魔术位模式”，强行指定会剥夺标准库实现的灵活性，甚至导致现有代码崩溃。
• 泛型一致性要求：std::optional的设计目标是为所有类型提供统一的接口与行为。如果只为部分有空闲位的类型采用魔术位方案，其他类型用布尔标记，会导致optional的内存大小、行为逻辑出现分裂——比如有的optional大小等于sizeof(T)，有的则是sizeof(T)+sizeof(bool)，用户使用时需额外区分，违背了泛型编程的一致性原则。
• 安全性与向后兼容性风险：即使某类当前存在“空闲”位表示，后续标准库或编译器版本可能为优化性能、新增特性而利用这些位。这会导致依赖魔术位的optional突然失效，引发难以调试的内存错误。这种依赖未标准化细节的方案，会给代码长期维护埋下隐患。
• C++对象模型约束：C对象模型要求对象必须处于有效状态（未初始化存储除外）。用魔术位标记空optional，相当于在存储中放置了一个“无效的T对象”，这违反了对象有效性规则——比如用户误调用optional.value()时会访问无效对象，触发未定义行为，而C的设计哲学更倾向于避免这类隐式风险。

对比Rust的方案：Rust的类型系统与内存模型对布局控制更严格，且多数标准库类型的内部结构是标准化的，因此能安全使用魔术位方案。但C++更注重兼容性、实现灵活性与向后兼容，这让魔术位方案从设计阶段就不具备可行性。

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