I've actually reduced the problem to the defaulted copy assignment operator itself: gcc: https://godbolt.org/z/83Gjdb clang: https://godbolt.org/z/z35x4K
The controlling clause would seem to be https://eel.is/c++draft/class.copy.assign#7.4. In particular, because overload resolution cannot find this->_m.operator=(rhs._m), the operator should be defined as deleted (which seems to be the behaviour of gcc, https://godbolt.org/z/bs5aPY). On Thu, 5 Nov 2020 at 11:08, connor horman <chorma...@gmail.com> wrote: > > > On Thu, Nov 5, 2020 at 11:06 connor horman <chorma...@gmail.com> wrote: > >> Looking at https://eel.is/c++draft/optional.optional and >> optional.assign, it shouldn't be ill-formed to have a non >> copy-constructible type, the copy constructor of optional should be defined >> as deleted. >> [optional.optional.general] clause 3 "T shall be a type other than cv >> in_place_t or cv nullopt_t that meets the Cpp17Destructible requirements" >> [optional.assign] clause 7 "This operator is defined as deleted unless >> is_copy_constructible_v<T> is true and is_copy_assignable_v<T> is true" >> >> I presume it's the same or similar in both C++17 and C++20 (published) >> (with Cpp17Destructible being just Destructible in C++17). >> >> >> On Thu, Nov 5, 2020 at 10:07 Pavel Černohorský via cfe-users < >> cfe-users@lists.llvm.org> wrote: >> >>> On 05. 11. 20 15:47, Marshall Clow via cfe-users wrote: >>> >>> I tried this code on compiler explorer. >>> It compiles w/o error with clang + libc++ >>> It fails to compile with clang and libstdc++ >>> >>> The error message given is: >>> >>> In file included from <source>:1: >>> /opt/compiler-explorer/gcc-10.2.0/lib/gcc/x86_64-linux-gnu/10.2.0/../../../../include/c++/10.2.0/optional:158:7: >>> error: the parameter for this explicitly-defaulted copy assignment operator >>> is const, but a member or base requires it to be non-const >>> operator=(const _Optional_payload_base&) = default; >>> ^ >>> /opt/compiler-explorer/gcc-10.2.0/lib/gcc/x86_64-linux-gnu/10.2.0/../../../../include/c++/10.2.0/optional:357:7: >>> note: in instantiation of template class 'std::_Optional_payload_base<S>' >>> requested here >>> : _Optional_payload_base<_Tp> >>> ^ >>> /opt/compiler-explorer/gcc-10.2.0/lib/gcc/x86_64-linux-gnu/10.2.0/../../../../include/c++/10.2.0/optional:631:30: >>> note: in instantiation of template class 'std::_Optional_payload<S, true, >>> false, false>' requested here >>> _Optional_payload<_Tp> _M_payload; >>> ^ >>> /opt/compiler-explorer/gcc-10.2.0/lib/gcc/x86_64-linux-gnu/10.2.0/../../../../include/c++/10.2.0/optional:660:15: >>> note: in instantiation of template class 'std::_Optional_base<S, true, >>> true>' requested here >>> : private _Optional_base<_Tp>, >>> ^ >>> <source>:10:20: note: in instantiation of template class >>> 'std::optional<S>' requested here >>> std::optional<S> a; >>> ^ >>> 1 error generated. >>> >>> I got exactly the same error, but the question is why. Shouldn't both >>> g++ and clang++ behave the same way even on the libstdc++ (which is the >>> default library clang uses on a lot of distros)? Is this gcc being too >>> permissive to some bug in libstdc++ or is it a clang bug? Should I file a >>> bug report to clang? >>> _______________________________________________ >>> cfe-users mailing list >>> cfe-users@lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users >>> >>
_______________________________________________ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users