I haven't been able to track down an authoritative answer to my question. However, looking at the C++03 standard and the CWG issues list, I have a rough idea.
Let's review value-initialization in C++03. It is defined for a type T as follows:
- If
T is a class type with a user-declared constructor, then the default constructor is called; - If
T is a non-union class type without a user-declared constructor [which implies that the compiler implicitly declares a default constructor], then each base class subobject and member subobject is value-initialized; - [...]
The second bullet point ensures that direct subobjects of scalar type are zero-initialized and is thus "stronger" than simply calling the implicit default constructor. This was the intent behind value-initialization.
So the wording in C++03 makes sense and (without needing to make any special exception) leads to the following result: when the default constructor is trivial, no function calls actually occur.
In C++11, the definition of zero-initialization was changed so that it would also initialize padding bits to zero (CWG 694). My guess is that the wording around value-initialization was changed in order to guarantee that value-initialization would also be guaranteed to zero out padding bits in the case of a trivial default constructor. So in C++11, when T (a type without a user-provided default constructor) is value-initialized, what happens is stronger than just value-initializing all direct subobjects of T. Rather, the entire T object is zero-initialized first (to ensure padding is zeroed out) and then the default constructor is called.
But again, our question is why C++11 carves out a special exception in the case where the default constructor is trivial, preventing it from being called. The paper, N2762, that made the wording change did not explain why that exception was put in, but we can now see that it preserves the C++03 behaviour wherein a trivial default constructor was not called at all. My guess is that the authors put in the wording intentionally to preserve this behaviour, but their motivations are unclear.
One possible motivation is that trivial default constructors were, in general, not constexpr in C++11, except in the case of empty classes: they would leave scalar members uninitialized, which was not allowed. Therefore, omitting the call to the default constructor during value-initialization makes it possible to possible to value-initialize objects that are trivially default constructible, which is desirable to allow; see CWG 644. However, there is no indication of whether the authors of N2762 intended to allow this. (Aside: for subsequent developments related to CWG 644, see CWG 1452.) Note that in C++20, such trivial default constructors became constexpr. See relevant SO question.
I find it more likely that the authors of N2762 were simply being cautious: in other words, they probably wanted to preserve the C++03 behaviour of not calling the trivial default constructor just in case changing this would cause problems they didn't anticipate. (It probably doesn't have anything to do with performance, though; the compiler can optimize out a call to a trivial default constructor.)
Still, we should observe that the C++11 behaviour isn't quite the same as the C++03 behaviour plus zero-initialization of padding. Let's say we have a type like this:
struct T { struct U { U() {} } u; int x; };
In C++03, value-initialization of T means that U::U is called and then x is zero-initialized. In C++11, it means that the entire T object is zero-initialized and then T::T is called, which in turn calls U::U. So C++11 has an extra function call here compared to C++03. So despite the authors' best efforts, the behaviour is not the same. As far as I can tell though, this difference doesn't break any code.
