[ 2020-06-08 Nina Dinka Ranns comments ]

The revised wording provided by LWG 2833 should resolve this issue as well.

[ 2019-07 Issue Prioritization ]

Priority to 2 after discussion on the reflector.

This wording is relative to N4810.

1. Modify [variant.ctor] as indicated:

   constexpr variant() noexcept(see below);
   

   -2- Effects: […]

   -3- Ensures: […]

   -4- Throws: […]

   -5- Remarks: This function shall be usable in a context that requires constant evaluation if the alternative type T₀ can be value-initialized in a context that requires constant evaluationconstexpr if and only if the value-initialization of the alternative type T₀ would satisfy the requirements for a constexpr function. […]

[ 2017-06-17, Tim Song comments ]

This issue is related to LWG 2833.

In [variant.ctor] p5, we say:

Remarks: This function shall be constexpr if and only if the value-initialization of the alternative type T₀ would satisfy the requirements for a constexpr function. […]

First of all, I find it confusing that we say "This function shall be constexpr if […]", when the declaration of the function clearly has the constexpr keyword on it unconditionally. Instead, I would use the wording "This function shall be usable in a constexpr context if […]".

Secondly, I think we shouldn't be using if-and-only-if since it restricts whether implementations can be constexpr-friendly as an extension. Instead, it seems better to just say "if".

Finally, I think the condition under which the function must be constexpr-friendly is not something we can test for because it says "value-initialization of the alternative type T₀ would satisfy the requirements for a constexpr function", which doesn't imply the value initialization can actually be be performed inside a constexpr context (for example the default constructor could be constexpr friendly but not marked with the constexpr keyword).