是否存在限制因素阻止std::optional::value_or()实现条件性noexcept？

这个三元表达式包含两个分支：

• 当optional包含值时：返回**this，也就是对T进行拷贝构造（左值重载）或移动构造（右值重载）。如果T的拷贝/移动构造函数可能抛出异常，这个分支就会抛出。
• 当optional为空时：将参数v转换为T，也就是调用T的转换构造函数（或通过隐式转换构造T）。如果这个转换操作可能抛出异常，这个分支就会抛出。

要让value_or()成为noexcept，必须保证两个分支的操作都不会抛出异常，这是一个严格的条件。

2. 条件性noexcept的可行条件 #

如果要为value_or()添加条件性noexcept标注，左值重载的声明应该类似这样：

template <class U>
constexpr T value_or(U&& v) const& noexcept(
    std::is_nothrow_copy_constructible_v<T> &&
    std::is_nothrow_constructible_v<T, U&&>
);

右值重载则需要把is_nothrow_copy_constructible_v<T>替换为is_nothrow_move_constructible_v<T>。

但标准中并没有这样定义，主要原因可能包括：

• 收益与复杂度的权衡：条件性noexcept的标注会增加函数声明的复杂度，而value_or()的异常场景相对明确，用户可以通过T和U的构造函数属性自行判断是否会抛出，委员会可能认为添加这个标注的收益不大。
• C++17对条件性noexcept的保守使用：在C++17引入std::optional时，条件性noexcept的应用还没有像后续标准那么广泛，对这类工具函数的异常标注相对保守。

3. 总结 #

不存在技术上的硬性障碍阻止value_or()成为条件性noexcept，但它的异常安全性依赖于两个独立操作的noexcept属性，这使得它无法无条件地标记为noexcept。而标准中未添加条件性noexcept标注，更多是基于设计权衡的选择。

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