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.
Section: 19.7.3 [variant.variant] Status: NAD Submitter: United States Opened: 2017-02-03 Last modified: 2017-07-18
View all other issues in [variant.variant].
View all issues with NAD status.
Discussion: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 188.8.131.52 [res.on.functions] p2 plus bullet (2.5):
-2- In particular, the effects are undefined in the following cases:
(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_ptr — grant 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 184.108.40.206 [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.
Edit 19.7.3 [variant.variant]/2 as indicated:All types in Types... shall be (possibly cv-qualified) object types that are not arrays.
[2017-07-06 Moved to Tentatively NAD after 5 positive votes on c++std-lib.]
The lack of the explicit constraint in 19.7.3 [variant.variant] is not a defect, because the general requirements in 220.127.116.11 [res.on.functions] p2 already impose the requested type completeness constraints.