[class.base.init] Overzealous UB on constructor preconditions/destructor postconditions

[notadragon]

Full name of submitter (unless configured in github; will be published with the issue): Joshua Berne

Reference (section label): class.base.init

Link to reflector thread (if any):

Issue description: The precondition of a consructor and postcondition of a destructor cases added to this section apply, as written, to all constructors and destructors but should really apply to the object under construction/destruction.

Suggested resolution:

Add in "of the object under construction" and "of the object under destruction" where appropriate. (It should remain "a constructor" because this applies to delegating constructors as well, but switch to "the destructor" because there is only one).

In [classbase.init] paragraph 18:

Member functions (including virtual member functions, [class.virtual]) can be called for an object under construction or destruction. Similarly, an object under construction or destruction can be the operand of the typeid operator ([expr.typeid]) or of a dynamic_cast ([expr.dynamic.cast]). However, if these operations are performed during evaluation of

• a ctor-initializer (or in a function called directly or indirectly from a ctor-initializer) before all the mem-initializers for base classes have completed,
• a precondition assertion of a constructor of the object under construction, or
• a postcondition assertion of a the destructor of the object under destruction ([dcl.contract.func]),
  the program has undefined behavior ([ub:class.base.init.mem.fun]).

[eisenwave]

I don't understand the problem. Can you call a constructor so that it's not evaluated for an object under construction? Isn't that simply always the case?

[leni536]

I don't understand the problem. Can you call a constructor so that it's not evaluated for an object under construction? Isn't that simply always the case?

Consider:

struct S {
    S() {
        S s(*this); // UB with existing wording
    }
    // other is under construction. other.is_foo() is called in the precondition of a constructor
    S(const S& other) pre(other.is_foo()) {}

    bool is_foo() const;
};

There might be a less contrived example, possibly with some recursive data structure. But reading again, the existing wording doesn't even require the constructor to be of the same class.