Proposed resolution:

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

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

[ 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_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.

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

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

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