libcxx中的可选std :: nullopt_t实现

Question

Clang implements std::nullopt_t this way:

struct nullopt_t
{
    explicit constexpr nullopt_t(int) noexcept {}
};

constexpr nullopt_t nullopt{0}; 

Why not simply:

struct nullopt_t{};

constexpr nullopt_t nullopt{};

?

Answer 1

According to cppreference :

std::nullopt_t must be a LiteralType and cannot have a default constructor. It must have a constexpr constructor that takes some implementation-defined literal type.

... so if Clang implemented nullopt_t as you suggested, it wouldn't meet the requirements. Now, if you are wondering why those requirements exist (a different question), the answer is:

nullopt_t is not DefaultConstructible to support both op = {}; and op = nullopt; as the syntax for disengaging an optional object.

Answer 2

As mentioned on std::nullopt_t :

Notes

nullopt_t is not DefaultConstructible to support both op = {}; and op = nullopt; as the syntax for disengaging an optional object.

Now test this with your implementation:

struct nullopt_t { };
template <typename T>
struct optional {
  optional &operator=(nullopt_t);
  optional &operator=(const optional &);
  optional &operator=(optional &&);
  template <typename U>
  optional &operator=(U &&);
};
int main() {
  optional<int> oi;
  oi = {};
}

This fails, because the call to operator= is ambiguous. It could be an attempt to call operator=(nullopt_t) , or it could be an attempt to call operator=(optional &&) , and there is no language rule to resolve this ambiguity.

Therefore, unless there's a change to the language rules, or oi = {}; no longer needs to be valid, either nullopt_t or optional needs to not be default-constructible, and nullopt_t is the logical choice for that.

Answer 3

Others have explained why struct nullopt_t {}; is insufficient. But there are at least two alternative solutions that are still simpler than the ones currently ensconced in libc++ and libstdc++.

(Here's some test code: http://melpon.org/wandbox/permlink/HnFXRjLyqi4s4ikv )

Here are the alternatives, in increasing order of paranoia:

Option 1 (nobody as far as I know)

struct nullopt_t { constexpr explicit nullopt_t() {} };
constexpr nullopt_t nullopt{};

Option 2 (libc++ <experimental/optional>)

struct nullopt_t { constexpr explicit nullopt_t(int) {} };
constexpr nullopt_t nullopt{0};

Option 3 (libstdc++ <experimental/optional>)

struct nullopt_t {
    enum class secret { tag };
    explicit constexpr nullopt_t(secret) { }
};
constexpr nullopt_t nullopt{nullopt_t::secret::tag};

Option 4 (libc++ <optional>)

struct nullopt_t {
    struct secret_tag { explicit secret_tag() = default; };
    constexpr explicit nullopt_t(secret_tag, secret_tag) noexcept {}
};
constexpr nullopt_t nullopt{nullopt_t::secret_tag{}, nullopt_t::secret_tag{}};

Any one of these alternatives (even Option 1, as far as I know) would suffice to make the assignment o = {} unambiguous. I don't know why both libc++ and libstdc++ go beyond that solution — and notice that libc++ goes so far as to create a two-argument constructor!

If anyone knows the reason for libc++'s increased paranoia, I'd love to hear it; please create an answer and/or leave a comment below.