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

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.