对 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从 cv-ref 限定引用构造到类型Type。 这超级方便。

除此之外，最后一个构造函数也有帮助，因为它是一种使用列表初始化来初始化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>为 false

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

第二个只是将基础类型的构造函数的显式性"转发"到optional类型

但第三个限制很好

奇

• 此构造函数不参与重载解析，除非std::is_constructible_v<T, U&&>为 true
。

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

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

说谎的特质是不好的。

基本词汇类型的说谎特征是加分的。

基本词汇类型的谎言特征也很容易干扰过载分辨率，这是双重的。

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

Answer 2

我一发布问题就得到了答案(它作为编辑包含在我问题的最后一部分)

该库希望为用户提供一种方便的方法，以便能够在 SFINAE 情况下通过该构造函数构造可选，而不会在以后导致硬错误。 如果未包含该约束，则库可能会认为可以从任何其他类型构造可选，但后来发现它会导致硬错误。

例如，以下示例说明了一个类似的问题 (https://wandbox.org/permlink/XGgWgJcNJ99BBycu)

#include <iostream>
#include <string>
#include <vector>
#include <tuple>
using std::cout;
using std::endl;
class Something {
public:
Something() = default;
template <typename U>
Something(U&& u) : vec(std::forward<U>(u)) {}
private:
std::vector<int> vec;
};
template <typename U, typename = std::void_t<>>
class SomethingConstructibleFrom 
: public std::false_type {};
template <typename U>
class SomethingConstructibleFrom<
U, 
std::void_t<decltype(Something{std::declval<U>()})>> 
: public std::true_type {};
int main() {
if constexpr (SomethingConstructibleFrom<std::string>::value) {
// this must be constructible because the above returned true
// but SURPRISE!
auto something = Something{std::string{"qwerty"}};
std::ignore = something; 
}
}