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.
variant
should only support complete typesSection: 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).
Previous resolution [SUPERSEDED]:
This wording is relative to N4618.
Edit 22.6.3 [variant.variant]/2 as indicated:
All types inTypes...
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.