Suggestion: investigate noexcept specification for `allocator_traits::deallocate/destroy`

[achabense]

A lot of clear-related functions rely on allocator_traits::destroy/deallocate, and are marked as noexcept (either required by standard or strengethened). Examples are many and are not listed here (search ::deallocate and ::destroy in the library).

However:
allocator_traits is either _Default_allocator_traits or _Normal_allocator_traits.

STL/stl/inc/xmemory

Lines 759 to 760 in 313964b

	struct allocator_traits : conditional_t<_Is_default_allocator<_Alloc>::value, _Default_allocator_traits<_Alloc>,
	_Normal_allocator_traits<_Alloc>> {};

But currently:
_Default_allocator_traits: deallocate is marked as noexcept; but destroy is not.
deallocate: made noexcept by #4977

STL/stl/inc/xmemory

Line 717 in 313964b

static _CONSTEXPR20 void deallocate(_Alloc& _Al, const pointer _Ptr, const size_type _Count) noexcept

destroy: not noexcept.

STL/stl/inc/xmemory

Line 741 in 313964b

static _CONSTEXPR20 void destroy(_Alloc&, _Uty* const _Ptr) {

_Normal_allocator_traits: neither deallocate nor destroy are noexcept.
deallocate:

STL/stl/inc/xmemory

Line 610 in 313964b

static _CONSTEXPR20 void deallocate(_Alloc& _Al, pointer _Ptr, size_type _Count) {

destroy:

STL/stl/inc/xmemory

Line 628 in 313964b

static _CONSTEXPR20 void destroy(_Alloc& _Al, _Ty* _Ptr) {

[frederick-vs-ja]

I haven't found anything in the standard making allocator_traits<NonAllocator> UB or IFNDR. So perhaps _Normal_allocator_traits::{deallocate,destroy} need to propagate exceptions that are possibly unrelated to allocator operations. But [allocator.traits.members]/5 also says "Throws: Nothing".
Also, it seems that [allocator.requirements.general] doesn't require the destroy function not to throw an exception. So perhaps we can't unconditionally strengthen exception specifications.

Moreover, the Cpp17Erasable named requirements don't seem to require non-throwing. Perhaps one or two LWG issue is needed. I'll try to conditionally strengthen exceptions (as for now).

[achabense]

Some noexcept examples that relies on allocator_traits::destroy..

(In vector::pop_back; strengthened)

STL/stl/inc/vector

Line 1757 in 313964b

_Alty_traits::destroy(_Getal(), _Unfancy(_Mylast - 1));

(deque::pop_front(and back); strengthened)

STL/stl/inc/deque

Line 1495 in 313964b

_Alty_traits::destroy(_Getal(), _Get_data()._Address_subscript(_Myoff()));

(Other; not a full list)

STL/stl/inc/list

Lines 316 to 317 in 313964b

	static void _Freenode(_Alnode& _Al, _Nodeptr _Ptr) noexcept { // destroy all members in _Ptr and deallocate with _Al
	allocator_traits<_Alnode>::destroy(_Al, _STD addressof(_Ptr->_Myval));

STL/stl/inc/forward_list

Lines 251 to 253 in 313964b

	static void _Freenode(_Alnode& _Al, _Nodeptr _Pnode) noexcept {
	_Destroy_in_place(_Pnode->_Next);
	allocator_traits<_Alnode>::destroy(_Al, _STD addressof(_Pnode->_Myval));

STL/stl/inc/xnode_handle.h

Lines 81 to 84 in 313964b

	void _Clear() noexcept { // destroy any contained node and return to the empty state
	if (_Ptr != nullptr) {
	_Alloc& _Al = _Getal();
	_Alty_traits::destroy(_Al, _STD addressof(_Ptr->_Myval));

STL/stl/inc/xtree

Lines 390 to 392 in 313964b

	static void _Freenode(_Alloc& _Al, _Nodeptr _Ptr) noexcept {
	static_assert(is_same_v<typename _Alloc::value_type, _Tree_node>, "Bad _Freenode call");
	allocator_traits<_Alloc>::destroy(_Al, _STD addressof(_Ptr->_Myval));

STL/stl/inc/xmemory

Lines 1102 to 1107 in 313964b

	_CONSTEXPR20 void _Destroy_range(_Alloc_ptr_t<_Alloc> _First, const _Alloc_ptr_t<_Alloc> _Last, _Alloc& _Al) noexcept {
	// note that this is an optimization for debug mode codegen; in release mode the BE removes all of this
	using _Ty = typename _Alloc::value_type;
	if constexpr (!conjunction_v<is_trivially_destructible<_Ty>, _Uses_default_destroy<_Alloc, _Ty*>>) {
	for (; _First != _Last; ++_First) {
	allocator_traits<_Alloc>::destroy(_Al, _STD _Unfancy(_First));

STL/stl/inc/memory

Lines 2528 to 2529 in 313964b

	void _Destroy() noexcept override { // destroy managed resource
	allocator_traits<_Rebound>::destroy(this->_Get_val(), _STD addressof(_Storage._Value));

[StephanTLavavej]

I would be in favor of strengthening these to be unconditionally noexcept. I cannot imagine any excuse for why deallocation and destruction should be permitted to throw exceptions.