I think nullopt is the way it is so that

optional<int> opt;
opt = {}; // HERE

the assignment isn't ambiguous.

*IIRC*





On Tue, May 11, 2021 at 11:36 AM David Friberg via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> Hi all,
>
> The current (C++17, C++20) spec of nullopt_t [1] requires that nullopt_t
> shall not have a default constructor ([...] or an initializer-list
> constructor, and shall not be an aggregate).
>
> P0032R3 [2] (Homogeneous interface for variant, any and optional), one of
> the papers which was part of introducing optional, had a discussion around
> the nullopt_t type, tag types in general, and the DefaultConstructible
> requirement. Particularly, from section 'Not assignable from {}':
>
> > To re-enforce this design, there is an pending issue 2510-Tag types
> should not be DefaultConstructible Core issue 2510.
>
> At the time of P0032R3, the resolution of of LWG issue 2510 [3] was indeed
> for all tag types to not be DefaultConstructible, but this resolution was
> later superseded as part of the resolution of CWG issue 1518 [4], which in
> turn reverted parts of the resolution of CWG issue 1630 [5] (which "went
> too far in allowing use of explicit constructors for default
> initialization"). The final resolution for CWG 1518 (P0398R0 [6]) lead to
> the requirement for aggregate classes to not have any explicit
> [user-declared] constructors, and LWG 2510 was resolved accordingly by
> making all tag types have explicit user-declared (constexpr) default
> constructors.
>
> However, the spec of nullopt_t never changed after these events or as part
> of updating other tag types, and it is still explicitly required to not be
> DefaultConstructible (nor have a initialization-list constructor) and to
> not be an aggregate, whereas the implementation of it is otherwise
> unspecified.
>
> Is this an oversight, and should the requirements for the nullopt_t type
> instead be provided via a synopsis such as for the other tag types, with a
> user-provided explicit (explicitly-defaulted) default constructor?
>
> Note that we still see some compiler variance on the topic of CWG
> 1518/1630 [7].
>
> References:
> [1] [optional.nullopt]/2,
> https://timsong-cpp.github.io/cppwp/n4659/optional.nullopt#2
> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0032r3.pdf
> [3] http://cplusplus.github.io/LWG/lwg-defects.html#2510
> [4] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1518
> [5] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1630
> [6] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0398r0.html
> [7] https://godbolt.org/z/Tf96s4Krf
>
> Cheers,
> David
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>

-- 
Be seeing you,
Tony