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

### 3215. `variant` default constructor has vague `constexpr` requirements

Section: 22.6.3.2 [variant.ctor] Status: New Submitter: Louis Dionne Opened: 2019-06-04 Last modified: 2020-09-06

Priority: 2

View other active issues in [variant.ctor].

View all other issues in [variant.ctor].

View all issues with New status.

Discussion:

In 22.6.3.2 [variant.ctor] p5, we say:

> Remarks: This function shall be `constexpr` if and only if the value-initialization of the alternative type `T0` 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 `T0` 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).

[2017-06-17, Tim Song comments]

This issue is related to LWG 2833.

[2019-07 Issue Prioritization]

Priority to 2 after discussion on the reflector.

Previous resolution from Daniel [SUPERSEDED]:

> This wording is relative to N4810.

> 1. Modify 22.6.3.2 [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 `T0` can be value-initialized in a context that requires constant evaluation `constexpr` if and only if the value-initialization of the alternative type `T0` would satisfy the requirements for a constexpr function. […]

[2020-06-08 Nina Dinka Ranns comments]

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

Proposed resolution: