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

2902. variant should only support complete types

Section: 23.7.3 [variant.variant] Status: NAD Submitter: United States Opened: 2017-02-03 Last modified: 2017-07-17

Priority: 0

View all other issues in [variant.variant].

View all issues with NAD status.


Addresses US 114

variant needs to know the size of an object in order to compute the size of its internal buffer, so require that any cv-qualified object type in Types... be a complete type.

Proposed change: Add 'complete' in p2

[2017-07-01, Daniel comments]

I recommend to close this issue as NAD: According to [res.on.functions] p2 plus bullet (2.5):

-2- In particular, the effects are undefined in the following cases:

  1. — […]

  2. (2.5) — if an incomplete type (6.9) is used as a template argument when instantiating a template component, unless specifically allowed for that component.

In other words: The standard currently already requires type completeness for all types in Types... of std::variant<Types...>, we therefore should not repeat that again (Note that other templates — such as shared_ptrgrant type incompleteness allowance for that reason).

The criteria for the alternative resolution form Resolved do not apply for this case, because the quoted constraint do exist since C++98 (see [lib.res.on.functions] p2 b5), so the issue was not even an issue at the point of the submission.

Previous resolution [SUPERSEDED]:

This wording is relative to N4618.

  1. Edit 23.7.3 [variant.variant]/2 as indicated:

    All types in Types... shall be (possibly cv-qualified) complete object types that are not arrays.

[2017-07-06 Moved to Tentatively NAD after 5 positive votes on c++std-lib.]

Proposed resolution:

The lack of the explicit constraint in 23.7.3 [variant.variant] is not a defect, because the general requirements in [res.on.functions] p2 already impose the requested type completeness constraints.