https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90532
Bug ID: 90532
Summary: is_constructible_v<int[]> and
is_default_constructible_v<int[]> should agree
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
According to the current standard, is_default_constructible_v<T> is true if
is_constructible_v<T> is true. The current libstdc++ disagrees for arrays of
unknown bound.
Take the following program:
#include <type_traits>
int main()
{
static_assert( std::is_constructible_v<int[]>);
static_assert( std::is_default_constructible_v<int[]>); // fail
static_assert( std:: is_trivially_constructible_v <int[]>);
static_assert( std::is_trivially_default_constructible_v<int[]>); // pass?!
}
I would expect consistency between all 4 traits. For Microsoft and LLVM libc++
libraries, all 4 tests fail. For libstdc++, 3 out of the 4 pass, with only the
'is_defult_constructible_v' test failing.
According to the standard, the trait should be true if an invented variable
initialized as follows (ignoring vexing parses) would be valid:
T t(); // parsed as variable declaration, not function
So my first thought was that this might be related to the new rules for
parenthetical aggregate initialization, as gcc is may be implementing that
first. However, the behavior would still be inconsistent, and does not change
with the language dialect.
Then I realized that even with aggregate initialization, arrays of length zero
are ill-formed, so would deduce an invalid array size.
Finally, I note that the is_nothrow_constructible traits are returning the
expected 'false'.
