c++ - 对 std::optional 的转发引用构造函数的约束

Question

std::optional截至目前有 8 个构造函数，列在下面(也在此处 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由类型为 Type 的 cv-ref 限定引用构建. super 方便。

除此之外，最后一个构造函数也有帮助，因为它是使用列表初始化来初始化 std::optional 的便捷方式。例如，无需使用 std::in_place .发生这种情况是因为当将花括号括起来的参数列表传递给构造函数时，将使用默认类型，因为函数模板无法从 {} 中推导出类型。 (至少这是我对情况的理解，是我最近才学会的一个巧妙技巧)(另请注意，根据此处的规则，这只能用于调用基础类型的非显式构造函数 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也不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类型

但是第三个限制很奇怪

• 此构造函数不参与重载决议，除非std::is_constructible_v<T, U&&>是真的

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

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 传递的参数构造，而不会在以后导致硬错误？

Answer 1

说谎的特质是不好的。

基本词汇类型的谎言特征是不好的。

基本词汇类型的谎言特征也很容易干扰重载解析，这是 doubleplusungood。

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