Hi Tony,

Thanks for your answer.

I agree that this is indeed the reason why it was required to not be DefaultConstructible in the first place. However, after the final resolution of CWG Core Issue 1518 (P0398R0) the DefaultConstructible requirement is, afaict, not needed, and the idiomatic requirement would rather appear to be that of the final resolution of LWG Core Issue 2510 (which was updated based on CWG 1518), which updated several other library tag types to be have an explicit user-declared default constructor.

In other words, would not the following synopsis suffice for nullopt_t?

struct nullopt_t { explicit nullopt_t() = default; };

As I noted out in my previous message there are some compiler variance regarding whether such an implementation would indeed yield an unambiguous call for "opt = {};" (see the demo [7]), but I believe this also stems from the somewhat confusing rounds around CWG 1518/1630 (/LWG 2510), and I've highlighted that GCC may have rejects-valid bug here.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835

Cheers,

David

On Wed, May 12, 2021 at 12:36 AM Tony V E <tvaneerd@gmail.com> wrote:

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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion

--
Be seeing you,
Tony