[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199

Andrew Pinski  changed:

   What|Removed |Added

 CC||luigighiron at gmail dot com

--- Comment #9 from Andrew Pinski  ---
*** Bug 112839 has been marked as a duplicate of this bug. ***

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199

Andrew Pinski  changed:

   What|Removed |Added

 CC||mrjoel at lixil dot net

--- Comment #8 from Andrew Pinski  ---
*** Bug 105606 has been marked as a duplicate of this bug. ***

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199

--- Comment #7 from Jonathan Wakely  ---
Because a user-provided inner() means it's default constructible, period. If
that default constructor happens to be ill-formed, that's your problem and is
outside the immediate context that is checked by is_default_constructible.

Without that user-provided constructor, the compiler has to try to implicitly
define a default constructor, which has to consider all the members and their
default member initializers, which requires the type to be complete.

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[eyalroz1 at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199

--- Comment #6 from Eyal Rozenberg  ---
(In reply to Jonathan Wakely from comment #4)
> See PR 96645 and PR 101227

Ok.

But does that explain why defining an explicit constructor cause g++ to accept
the class as default-constructible?

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[eyalroz1 at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199

--- Comment #5 from Eyal Rozenberg  ---
(In reply to Jonathan Wakely from comment #4)
> See PR 96645 and PR 101227

Ok, I

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199

--- Comment #4 from Jonathan Wakely  ---
See PR 96645 and PR 101227

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[eyalroz1 at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199

--- Comment #3 from Eyal Rozenberg  ---
Andrew: What you're saying would be plausible if g++ would find the structure
to be incomplete. It does not. The completeness check passes; and it is  why
adding the explicit default ctor makes the asserting pass - despite your
rationale applying to that case just as well.

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199

--- Comment #2 from Andrew Pinski  ---
This is because the following is still valid C++11:
struct outer {
struct inner {
// inner() { }
unsigned int x = y;
};
  static constexpr int y =10;
};

That is inner is not completed until outer is completed.

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #1 from Andrew Pinski  ---
THis comes down to when the struct is complete.