[except.throw] Non-copyable exception object types can be conditionally-supported

[frederick-vs-ja]

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

Reference (section label): [except.throw], [except.handle], [propagation]

Link to reflector thread (if any):

Issue description: CWG1863 clarified that the type of an exception object must be copyable. However, such restriction seems overly strict. Some (but not all) mainstream implementations (perhaps all implementations using Itanium C++ ABI) can correctly support move-only exception objects, given the operand of throw-expression is an rvalue and the exception is caught by reference, because exception objects are allocated on the heap, and no exception_ptr-related mechanism needs to copy exception objects. On the other hand, CWG1863 predated the acception of P0135R1 (guaranteed RVO since C++17), and the aforementioned implementations seem even support non-movable exception objects in C++17 and later modes.

This issue is related LWG3688. For implementations supporting move-only exception objects, std::bad_expection_access<MoveOnly> can be thrown correctly, see gcc bug 105146.

I think move-only exception object type should be made conditionally-supported to legitimize such existing implementation strategy. The term "thrown object" may be wrong or denote different objects (see editiorial issue 5238), perhaps it should be reworded.

Suggested resolution:

Change [except.throw]/5 as indicated:

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 copy-initialization of the exception object from the operand of the throw-expression shall be well-formed in the context of the throw-expression. T When the operand is of a class type, the destructor is potentially invoked (11.4.7 [class.dtor]). If the copy-initialization of an object of the same type of the exception object from an lvalue of that type would be ill-formed in any context, the throw-expression is conditionally-supported.

Add a bullet after [except.handle]/3:

If the handler is of type cv T, where T is an object type, the copy-initialization of an object of type T from an lvalue of type T shall be well-formed in every possible context.

Change [propagation]/8 as indicated:

... If it is possible to copy the exception object, Iit is unspecified whether the return values of two successive calls to current_exception refer to the same exception object.

Change [propagation]/10 as indicated:

... If it is possible to copy the exception object, Iit is unspecified whether a copy is made, and memory for the copy is allocated in an unspecified way. ...

[jensmaurer]

First of all [except.throw] p5 does not currently refer to throw-expression, because exceptions may be thrown by means other than a throw-expression. Neither the standard library nor e.g. array-new are required to use a throw-expression to throw their exceptions; maybe there is some hidden means in the implementation.

If we do wish to say something about throw-expression in particular, we should amend [expr.throw], not [except.throw].

Then, there are indeed three situations we need to consider: The copy-initialization of the exception object (at the point of the throw), the copy-initialization of the handler parameter, and possible capturing of the copy operation via exception_ptr. The first situation may choose a different copy constructor compared to the other two, and we want to make sure at the throw site all will work.

We could make handlers ill-formed that take move-only classes by value, because those can't be made to work with move-only objects at all. This might be a good sanity check, independent of the rest of the changes.

I think there are some minor tweaks of the wording that might be done, but at the core of this submission seems to be a desire to conditionally-support move-only exception objects. This is possible on Itanium ABI platforms, which have reference-counted exception objects. Given that the status quo is clear that move-only exception objects are not supported, this does not seem to be a defect, but rather a (reasonable) request to extend the language. I'd like to avoid burdening the core issue process with such. Moreover, "conditionally-supported" means "optional feature", and traditionally C++ has shied away from introducing those at scale, for fear of fragmenting the language. Such considerations seem best done by EWG, so please submit a paper.

[jensmaurer]

If you have a more narrow concern that deserves a core issue, feel free to open a new github issue in this tracker.

[frederick-vs-ja]

CWG2711 should have addressed some concerns. I've opened #331 and #332 for the rest.