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: 22.6.3 [variant.variant] Status: NAD Submitter: United States Opened: 2017-02-03 Last modified: 2020-09-06
Priority: 0
View all other issues in [variant.variant].
View all issues with NAD status.
Discussion:
Addresses US 114variant 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 16.4.5.8 [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 17.4.3.6 [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 22.6.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 22.6.3 [variant.variant] is not a defect, because the general requirements in 16.4.5.8 [res.on.functions] p2 already impose the requested type completeness constraints.