[Bug libstdc++/99417] [C++17] std::variant assignment fails to compile

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED
            Version|unknown                     |11.0
   Target Milestone|---                         |12.3

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I don't think this was a bug, at least not when you reported this. It was the
required behaviour prior to https://wg21.link/lwg3585

In the C++17 and C++20 standards variant<C>::operator=(const Original&) is
specified as:

(13.1) — If *this holds a Tj, assigns std::forward<T>(t) to the value contained
in *this.

(13.2) — Otherwise, if is_nothrow_constructible_v<Tj, T> ||
!is_nothrow_move_constructible_v<Tj> is true, equivalent to
emplace<j>(std::forward<T>(t)).

(13.3) — Otherwise, equivalent to operator=(variant(std::forward<T>(t))).


The second bullet is why the 'noexcept' on the move ctor matters, and it means
that we use the third bullet, but that won't compile because variant<C> is not
move assignable, because C is not move assignable.

So libc++ and MSVC were non-conforming in accepting this.

LWG 3585 changed the third bullet so that move assignment isn't needed. That
was implemented for libstdc++ by r13-5661-g1395415fdc2d60 and
r12-9450-ga5a03ea09ddf09.