Section: 21.3.5.4 [meta.unary.prop] Status: Open Submitter: Daniel Krügler Opened: 2011-08-20 Last modified: 2016-01-28
Priority: 3
View other active issues in [meta.unary.prop].
View all other issues in [meta.unary.prop].
View all issues with Open status.
Discussion:
The currently agreed on proposed wording for 2015 using
remove_all_extents<T>::type instead of the "an array of
unknown bound" terminology in the precondition should be extended to
some further entries especially in Table 49, notably the
is_*constructible, is_*assignable, and
is_*destructible entries. To prevent ODR violations, incomplete
element types of arrays must be excluded for value-initialization and
destruction for example. Construction and assignment has to be honored,
when we have array-to-pointer conversions or pointer conversions of
incomplete pointees in effect.
[2012, Kona]
The issue is that in three type traits, we are accidentally saying that in certain circumstances the type must give a specified answer when given an incomplete type. (Specifically: an array of unknown bound of incomplete type.) The issue asserts that there's an ODR violation, since the trait returns false in that case but might return a different version when the trait is completed.
Howard argues: no, there is no risk of an ODR violation.
is_constructible<A[]> must return false regardless of whether
A is complete, so there's no reason to forbid an array of unknown bound of
incomplete types. Same argument applies to is_assignable. General agreement
with Howard's reasoning.
There may be a real issue for is_destructible. None of us are sure what
is_destructible is supposed to mean for an array of unknown bound
(regardless of whether its type is complete), and the standard doesn't make it clear.
The middle column doesn't say what it's supposed to do for incomplete types.
In at least one implementation, is_destructible<A[]> does return true
if A is complete, which would result in ODR violation unless we forbid it for
incomplete types.
Move to open. We believe there is no issue for is_constructible or
is_assignable, but that there is a real issue for is_destructible.
Proposed resolution: