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_at_[hidden]> 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_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
>