For most Ts, this is quite surprising behavior and highly unlikely to be desirable. (There is currently an open Ranges TS issue asking whether DefaultConstructible should permit such types.) To take an example from the wording below, it seems reasonable to store a random number distribution as a member of an aggregate and implicitly initialize it if the default argument values are suitable, but we can't do this currently:

Moreover, if the type at issue is a C++03 type, then this also presents a compatibility problem because in C++03 an aggregate member without an explicit initializer is value-initialized, which tolerates explicit default constructors just fine. For example, with the container adaptors:

With the exception of the explicit default constructors intentionally introduced by LWG 2510, most explicit default constructors in the library appear to arise out of historical accident rather than intentional design: they are constructors taking one or more parameters, all of which have default arguments, and so the explicit was added to prevent defining an undesirable implicit conversion from the type of the first parameter. At the time of their design, explicit simply had no effect in the other cases. It is also worth noting that the vast majority of them (container adaptors, random number engines, certain random number distributions, string streams) all have analogs with non-explicit default constructors (containers, random number engine adaptors, sampling distributions, file streams).

We should not use explicit default constructors without a good reason, at least for classes that can conceivably be used in a copy-list-initialization context. LWG 2193 eliminated a number of such constructors for types with initializer-list constructors. The proposed wording below finishes the job.

Note that this paper intentionally does not cover or propose changes on the explicitness of constructors taking >1 parameters. That more difficult question is covered by LWG 2307.

[Drafting note: All facets have explicit default constructors, but they also have protected destructors and so can't normally be constructed in one of the contexts noted above. Even ignoring the access issue, a default-constructed facet is meant to be deleted by the locale, and new is always direct-initialization. Thus, no change is proposed for them. — end drafting note]

[Drafting note: scoped_lock<> has an explicit default constructor in the empty pack case, but I can't think of a reason why one would use it in non-generic code, and in generic code direct-initialization is required anyway. Thus no change to it is proposed. — end drafting note]

[Drafting note: This contains a drive-by fix that makes the two-parameter rvalue-Container constructor non-explicit, to match the two-parameter const lvalue-Container constructor. Regardless of what one might think about the merits of explicit on the two-parameter form, it seems nonsensical for it to turn on the value category of one of the arguments. — end drafting note]

-3- Effects: Constructs a random_device nondeterministic uniform random bit generator object. The semantics and default value of the token parameter and the token value used by the default constructor are implementation-defined. [Footnote:…]