Explicit defaulted default constructor and aggregates

Question

How to explain the difference, when I compile #if 0 and #if 1 versions of the following code:

#include <cstdlib>

struct A
{ 
    explicit A() = default; // explicitly defaulted or deleted constructors are allowed for aggregates (since C++11)
#if 1
private :
#endif
    int i;
};

int
main()
{
    A a = {};
    return EXIT_SUCCESS;
}

• for #if 0 all is fine, compilation successful.
• for #if 1 compilation failed with error message:

  error: chosen constructor is explicit in copy-initialization

What is the difference for expression A a = {}; depending on whether A is aggreagate or not?

Answer 1

TL;DR: Clang and GCC are wrong in rejecting your code. CWG 1630´s resolution made default-initialization well-formed regardless of the chosen default constructor being explicit or not.

---

In the variation of your code in which i is private, A is not an aggregate, as these cannot have private members. As long as i is public, however, A is an aggregate¹, and no constructor is invoked since aggregate initialization is performed (see blue box), so your constructor being explicit is irrelevant.

However, as soon as you introduce the private member, you necessitate value-initialization as per the red box. Hence [dcl.init]/(8.2) applies:

[dcl.init]/(7.1) defines default-initialization for this case:

And §13.3.1.3 gives

For […] default-initialization, the candidate functions are all the constructors of the class of the object being initialized.

At no point is the original context - copy- or direct-initialization - considered. (§13.3.1.7 doesn't apply either.) In fact, this is intended; see CWG #1518:

This issue is resolved by the resolution of issue 1630: default initialization now uses 13.3.1.3 [over.match.ctor], which now permits explicit constructors for default-initialization.

Clang and GCC (and VC++) haven't implemented the corresponding DR yet and are thus incorrect in rejecting the code in C++14 mode.

---

¹⁾ Your class has a user-declared constructor, but it isn't user-provided, i.e. not impeding your class from being an aggregate. Recall the definition in [dcl.init.aggr]/1:

An aggregate is an array or a class (Clause 9) with no user-provided constructors (12.1), no private or protected non-static data members (Clause 11), no base classes (Clause 10), and no virtual functions (10.3).