Proposed resolution (approved by CWG 2024-03-20):

1. Change in 14.2 [except.throw] paragraph 5 as follows:

   When the thrown object is a class object, the constructor selected for the copy-initialization as well as the constructor selected for a copy-initialization considering the thrown object as an lvalue shall be non-deleted and accessible, even if the copy/move operation is elided (11.9.6 [class.copy.elision]). Let T denote the type of the exception object. Copy-initialization of an object of type T from an lvalue of type const T in a context unrelated to T shall be well-formed. If T is a class type, the selected constructor is odr-used (6.3 [basic.def.odr]) and The the destructor of T is potentially invoked (11.4.7 [class.dtor]).

Proposed resolution (approved by CWG 2023-11-10) [SUPERSEDED]:

1. Change in 6.3 [basic.def.odr] paragraph 9 as follows:

   An assignment operator function in a class is odr-used by an implicitly-defined copy assignment or move assignment function for another class as specified in 11.4.6 [class.copy.assign]. A constructor for a class is odr-used as specified in 9.5 [dcl.init] and when selected for the potential copy-initialization as specified in 14.2 [except.throw]. A destructor for a class is odr-used if it is potentially invoked (11.4.7 [class.dtor]).

2. Change in 14.2 [except.throw] paragraph 5 as follows:

   When the thrown object is a class object, the constructor selected for the copy-initialization as well as the constructor selected for a copy-initialization considering the thrown object as an lvalue shall be non-deleted and accessible, even if the copy/move operation is elided (11.9.6 [class.copy.elision]). Let T denote the type of the exception object. Copy-initialization of an object of type T from an lvalue of type const T in a context unrelated to T shall be well-formed. If T is a class type, The the destructor of T is potentially invoked (11.4.7 [class.dtor]).

CWG 2023-11-09

The drafting should also consider odr-use of the constructor potentially invoked for the copy-initialization.

Proposed resolution (approved by CWG 2023-09-15) [SUPERSEDED]:

Change in 14.2 [except.throw] paragraph 5 as follows:

When the thrown object is a class object, the constructor selected for the copy-initialization as well as the constructor selected for a copy-initialization considering the thrown object as an lvalue shall be non-deleted and accessible, even if the copy/move operation is elided (11.9.6 [class.copy.elision]). Let T denote the type of the exception object. Copy-initialization of an object of type T from an lvalue of type const T in a context unrelated to any class shall be well-formed. If T is a class type, The the destructor of T is potentially invoked (11.4.7 [class.dtor]).

[Accepted as a DR at the March, 2024 meeting.]

Subclause 14.2 [except.throw] paragraph 5 specifies:

When the thrown object is a class object, the constructor selected for the copy-initialization as well as the constructor selected for a copy-initialization considering the thrown object as an lvalue shall be non-deleted and accessible, even if the copy/move operation is elided (11.9.6 [class.copy.elision]). The destructor is potentially invoked (11.4.7 [class.dtor]).

This provision is for capturing a copy constructor for implementations not using reference-counted std::exception_ptrs, but that ought to be described separately from the "thrown object", which can be interpreted as the operand of the throw-expression.