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 evaluationconstexpr 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: