This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
Section: 16.4.6.13 [res.on.exception.handling] Status: New Submitter: Jiang An Opened: 2023-01-07 Last modified: 2023-02-01
Priority: 3
View other active issues in [res.on.exception.handling].
View all other issues in [res.on.exception.handling].
View all issues with New status.
Discussion:
Some standard library types, such as std::pair, std::tuple, and std::array, are currently allowed to have a member or element type with a destructor that is noexcept(false). In order to conform to 16.4.6.13 [res.on.exception.handling]/3, these types can't always have implicitly declared destructors because the implicit exception specification may be noexcept(false).
However, it may be intentional to implement these types with implicitly declared destructors, and mainstream implementations (libc++, libstdc++, and MSVC STL) are already doing so. Furtherly, explicitly declared destructors are not allowed for algorithm result types (27.5 [algorithms.results]), while currently these class templates are allowed to be instantiated with classes with potentially throwing destructors, which is contradictory to 16.4.6.13 [res.on.exception.handling]/3.[2023-01-29; Daniel comments]
This issue has very much overlap with LWG 3229.
[2023-02-01; Reflector poll]
Set priority to 3 after reflector poll. Unclear who the "shall" imposes requirements on. Maybe split into constraint on the library to not put noexcept(false) on destructors, and constraint on users that the library can assume destructors don't throw. Should also make it clear which parts of the subclause are normative and which are not.
Proposed resolution: