C++ Logo


Advanced search

[std-proposals] Specify how `std::nullopt_t` is constructed

From: Brian Bi <bbi5291_at_[hidden]>
Date: Thu, 14 Dec 2023 20:03:36 -0500
Under the current specification of `std::nullopt_t`, it is unspecified
whether certain attempts to construct `std::optional<T>` from nested braced
lists are well-formed, for example:

#include <optional>
struct S1 {
    S1() = default;
struct S2 {
    S2(S1) {}
std::optional<S2> os{{{}}};

With libstdc++, this actually selects the `std::nullopt_t` overload of the
`std::optional<S2>` constructor, which is then ill-formed because the
constructor of `std::nullopt_t` is explicit.

This problem could be solved if we required the constructor to be something
like this:

class nullopt_t {
    struct token {};
    constexpr nullopt_t(std::same_as<token> auto);

The above constructor template is guaranteed not to accept any argument
that is a *braced-init-list* because deduction will fail.

Do folks think this would be a reasonable proposal? Would it require any
ABI break? (I've never understood which standard library changes require
ABI breaks. It seems like adding and removing non-virtual member functions
is something that has been done before, so maybe this would be ok?)

*Brian Bi*

Received on 2023-12-15 01:03:49