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:
Cheers,
David