[ 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.

[ 2023-01-29; Daniel comments ]

This issue has very much overlap with LWG 3229.

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 [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 ([algorithms.results]), while currently these class templates are allowed to be instantiated with classes with potentially throwing destructors, which is contradictory to [res.on.exception.handling]/3.