std::Optional 的转发引用构造函数的约束

std::optional截至目前，有 8 个构造函数，如下所示（也在这里http://en.cppreference.com/w/cpp/utility/可选/可选 http://en.cppreference.com/w/cpp/utility/optional/optional)

/* (1) */ constexpr optional() noexcept;
/* (1) */ constexpr optional( std::nullopt_t ) noexcept;

/* (2) */ constexpr optional( const optional& other );

/* (3) */ constexpr optional( optional&& other ) noexcept(/* see below */);

template < class U >
/* (4) */ /* EXPLICIT */ optional( const optional<U>& other );

template < class U >
/* (5) */ /* EXPLICIT */ optional( optional<U>&& other );

template< class... Args > 
/* (6) */ constexpr explicit optional( std::in_place_t, Args&&... args );

template< class U, class... Args >
/* (7) */ constexpr explicit optional( std::in_place_t,
                                       std::initializer_list<U> ilist, 
                                       Args&&... args );

template < class U = value_type >
/* (8) */ /* EXPLICIT */ constexpr optional( U&& value );

我喜欢最后一个构造函数。它有助于std::optional由 cv-ref 限定的类型引用构造Type。这超级方便。

除此之外，最后一个构造函数也有帮助，因为它是使用列表初始化来初始化std::optional实例，无需使用std::in_place。发生这种情况的原因是，当将大括号括起来的参数列表传递给构造函数时，将使用默认类型，因为函数模板无法从{}（至少这是我对情况的理解，并且是我最近才学会的一个巧妙的技巧）（另请注意，这只能用于调用基础类型的非显式构造函数，根据此处的规则http://en.cppreference.com/w/cpp/language/list_initialization http://en.cppreference.com/w/cpp/language/list_initialization)

auto optional = std::optional<std::vector<int>>{{1, 2, 3, 4}};

我能理解的最后一个构造函数有两个约束

• std::decay_t<U>两者都不是std::in_place_t nor std::optional<T>
• 这个构造函数是显式的当且仅当std::is_convertible_v<U&&, T>是假的

第一个很容易理解，它有助于防止构造函数 (2)、(3)、(4)、(5)、(6) 和 (7) 出现歧义。如果类型是std::in_place它可能与（6）和（7）冲突。如果该类型是一个实例化std::optional那么它可能与(2)、(3)、(4)和(5)相冲突。

第二个只是将基础类型的构造函数的显式性“转发”给optional type

但第三个限制很奇怪

• 该构造函数不参与重载决策，除非std::is_constructible_v<T, U&&> is true

为什么需要这个？ (8) 永远不会与空构造函数冲突，因为它至少需要一个参数。只剩下一个原因了——它可能与std::nullopt_t当通过时std::nullopt，但这不会发生，因为nullopt无论 cv-ref 合格版本是什么，版本始终是更好的匹配std::nullopt_t已通过（如下所示）

void func(int) {
    cout << __PRETTY_FUNCTION__ << endl;
}

template <typename U>
void func(U&&) {
    cout << __PRETTY_FUNCTION__ << endl;
}

int main() {
    auto i = int{1};
    func(1);
    func(i);
    func(std::move(i));
    func(std::as_const(i));
    func(std::move(std::as_const(i)));
}

最后的限制背后的原因是什么？

为什么不像往常一样让构造函数出错呢？是否需要这来帮助检测该类型是否可以通过 SFINAE 传递的参数来构造，而不会在以后导致硬错误？

说谎的特质是不好的。

对于基本词汇类型来说，说谎的特征是非常糟糕的。

基本词汇类型的谎言特征也很容易干扰重载决策，这是双重不利的。

void f(std::optional<int>);
void f(std::optional<const char*>);
f({""}); // ambiguous without the constraint