The redundant T(s can go, too, since this isn't about copy ellision.

@JohelEGP The multi-level T( intends to expose that prvalue of the same class type does not create the temporary object, instead it delays initializing its result object.

I think it's unobservable whether a trivial default constructor is called or not.

I think it's unobservable whether a trivial default constructor is called or not.

The prvalue does value-initialize its result object. Based on this precondition, whether the object is default-initialized or zero-initialized depends on the rules defined in [dcl.init.general] p9.

To value-initialize an object of type T means:

• if T is a (possibly cv-qualified) class type ([class]), then

• if T has either no default constructor ([class.default.ctor]) or a default constructor that is user-provided or deleted, then the object is default-initialized;
• otherwise, the object is zero-initialized and the semantic constraints for default-initialization are checked, and if T has a non-trivial default constructor, the object is default-initialized;

To value-initialize an object of class T, the initialization is either zero-initialization or default-initialization. Only in the default-initialization case, the default constructor will be called.

The comment just says the object will be initialized by the default constructor, which is just wrong. I think it is observable if the object is used in a constant expression.

struct T{
    int a;
};
constexpr T obj = T();  //ok
constexpr T obj2; // error

The reason for the error at obj2 is the same as that of the example in #5422

The constexpr question is CWG2536 and maybe CWG2558.

The constexpr question is CWG2536 and maybe CWG2558.

I meant we can observe whether the default constructor is called in this case. The issue is that the comment arbitrarily says the default constructor is called for x. However, the value-initialization of x is not necessarily the default-initialization, may be zero-initialization, which can initialize T::a to 0, which is not uninitialized.

To value-initialize an object of class T, the initialization is either zero-initialization or default-initialization. Only in the default-initialization case, the default constructor will be called.

Isn't 9.1.2 indicating that both zero-initialization and default-initialization are performed if the default constructor is defaulted and non-trivial?

msvc accepts the following example, while gcc, icc, and clang rejects it (link).

struct Foo {
    int a;
    int b = 1;
};

static_assert(Foo().a == 0);

IIUC, msvc is doing the right thing here.

I think it's unobservable whether a trivial default constructor is called or not.

Yes. However, if it's confirmed that a trivial default constructor is not needed to skip, can we simplify [dcl.init.general]/(9.1.2) as following?

otherwise, the object is zero-initialized and the semantic constraints for default-initialization are checked, and if T has a non-trivial default constructor, the object is then default-initialized;

And I still think "value-initializes" should be used, because both zero- and default-initialization may matter when both are present.

Isn't 9.1.2 indicating that both zero-initialization and default-initialization are performed if the default constructor is defaulted and non-trivial?

Seems that you're right. GCC and Clang might have a misreading here. It might also be the intent here is that the value-initialization of an object of class type(its default constructor is defaulted and non-trivial) is either zero-initialized or default-initialized but not both? GCC and Clang implement the right things just didn't embody them in the current wording?

Seems that you're right. GCC and Clang might have a misreading here. It might also be the intent here is that the value-initialization of an object of class type(its default constructor is defaulted and non-trivial) is either zero-initialized or default-initialized but not both? GCC and Clang implement the right things just didn't embody them in the current wording?

Perhaps a CWG issue is needed. I've opened cplusplus/CWG#40 for this (and possibly another issue touching the same paragraph).

Can we close this issue in favour of the CWG issue then?

The core issue hasn't been created, yet.

The core issue hasn't been created, yet.

Created a CWG issue in cplusplus/CWG#117

No. That's the inbox for new core issues, not the actual core issues list.

See CWG2612

Done in #5984. Closing.