On Thu, 5 Nov 2020 at 09:29, Marshall Clow via cfe-users <
cfe-users@lists.llvm.org> wrote:
> On Nov 5, 2020, at 6:34 AM, Pavel Černohorský via cfe-users <
> cfe-users@lists.llvm.org> wrote:
> >
> > Hello,
> >
> > I would like to ask what is wrong with the following code:
> > ```
> >
> > #include <optional>
> >
> > struct S
> > {
> > S& operator=(S&) { return *this; };
> > };
> >
> > void thisWillNotCompileInClang()
> > {
> > std::optional<S> a;
> > }
> >
> > ```
> >
> > Compilation command is `g++ or clang++ -std=c++17 -c source.cpp`. It
> compiles without problems with g++ 9.3.0, but not with clang++ 10.0.0 (both
> from current stable Ubuntu 20). This code is simplification of code using
> widely adopted rapidjson library which uses assignment operator with
> non-const parameter a lot. Earlier versions of clang did not complain
> (tried with 7.0.1 on currently stable Debian Buster).
>
> A note from the libstdc++ maintainer:
>
> > I think there was a core change in C++20 to make the =default do the
> right thing (which is delete it, I think).
> > Clang does compile it with -std=c++20 just not -std=c++17.
>
Right, this was made valid by P0641R2, which was voted into C++20 but was
not moved as a defect report resolution against prior standards. So I think
g++ is being more permissive than the standard requires (though as far as I
can see, it would be a conforming extension to accept these cases
retroactively), and libstdc++ seems to be relying on that lenience
(probably unintentionally).
> — Marshall
>
>
> _______________________________________________
> 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
