This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++20 status.

3024. variant's copies must be deleted instead of disabled via SFINAE

Section: 22.6.3.2 [variant.ctor] Status: C++20 Submitter: Casey Carter Opened: 2017-10-10 Last modified: 2021-02-25

Priority: Not Prioritized

View other active issues in [variant.ctor].

View all other issues in [variant.ctor].

View all issues with C++20 status.

Discussion:

The specification of variant's copy constructor and copy assignment operator require that those functions do not participate in overload resolution unless certain conditions are satisfied. There is no mechanism in C++ that makes it possible to prevent a copy constructor or copy assignment operator from participating in overload resolution. These functions should instead be specified to be defined as deleted unless the requisite conditions hold, as we did for the copy constructor and copy assignment operator of optional in LWG 2756(i).

[ 2017-10-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

Proposed resolution:

This wording is relative to N4687.

  1. Change 22.6.3.2 [variant.ctor] as indicated:

    variant(const variant& w);

    -6- Effects: If w holds a value, initializes the variant to hold the same alternative as w and direct-initializes the contained value with get<j>(w), where j is w.index(). Otherwise, initializes the variant to not hold a value.

    -7- Throws: Any exception thrown by direct-initializing any Ti for all i.

    -8- Remarks: This function shall not participate in overload resolutionconstructor shall be defined as deleted unless is_copy_constructible_v<Ti> is true for all i.

  2. Change 22.6.3.4 [variant.assign] as indicated:

    variant& operator=(const variant& rhs);

    […]

    -4- Postconditions: index() == rhs.index().

    -5- Remarks: This function shall not participate in overload resolutionoperator shall be defined as deleted unless is_copy_constructible_v<Ti> && is_copy_assignable_v<Ti> is true for all i.