Recently, when investigating stuffs in the standard library affected by WG21-N4258, I found that this exception specification isn't really strengthened:
|
list& operator=(list&& _Right)
|
|
noexcept(_Choose_pocma_v<_Alnode> == _Pocma_values::_Equal_allocators) /* strengthened */ {
|
The standard requirement (in [list.overview]/2) is saying noexcept(allocator_traits<Allocator>::is_always_equal::value), which hasn't changed since the adoption of N4258.
Looking at the definition of _Choose_pocma_v, it can be inferred that _Choose_pocma_v<_Alnode> == _Pocma_values::_Equal_allocators and allocator_traits<_Alnode>::is_always_equal::value are actually equal.
|
enum class _Pocma_values {
|
|
_Equal_allocators, // usually allows contents to be stolen (e.g. with swap)
|
|
_Propagate_allocators, // usually allows the allocator to be propagated, and then contents stolen
|
|
_No_propagate_allocators, // usually turns moves into copies
|
|
};
|
|
|
|
template <class _Alloc>
|
|
constexpr _Pocma_values _Choose_pocma_v = allocator_traits<_Alloc>::is_always_equal::value
|
|
? _Pocma_values::_Equal_allocators
|
|
: (allocator_traits<_Alloc>::propagate_on_container_move_assignment::value
|
|
? _Pocma_values::_Propagate_allocators
|
|
: _Pocma_values::_No_propagate_allocators);
|
It's not very clear whether we're allowed use this value, see LWG-3267. But it is clear that this is not strengthening!
I believe we should remove the misleading /* strengthened */ comment.
Moreover, the exception specification of the move assignment operators of deque and (unordered) associative containers are spelt differently and more close to the forms specified in the standard. So perhaps we should spell the one of list as noexcept(_Alnode_traits::is_always_equal::value).
There's another _Choose_pocma_v<_Alnode> == _Pocma_values::_Equal_allocators in <xtree>. I guess it would be more consistent to write _Alnode_traits::is_always_equal::value instead.
|
_Tree& operator=(_Tree&& _Right) noexcept(
|
|
_Choose_pocma_v<_Alnode> == _Pocma_values::_Equal_allocators && is_nothrow_move_assignable_v<key_compare>) {
|
This issue is intended for a new contributor (especially one new to GitHub) to get started with the simplest possible change.
Please feel free to submit a pull request if there isn't one already linked here - no need to ask for permission! 😸
You can (and should) link your pull request to this issue using GitHub's close/fix/resolve syntax.
(in the PR description not the commit message)
Recently, when investigating stuffs in the standard library affected by WG21-N4258, I found that this exception specification isn't really strengthened:
STL/stl/inc/list
Lines 923 to 924 in 926d458
The standard requirement (in [list.overview]/2) is saying
noexcept(allocator_traits<Allocator>::is_always_equal::value), which hasn't changed since the adoption of N4258.Looking at the definition of
_Choose_pocma_v, it can be inferred that_Choose_pocma_v<_Alnode> == _Pocma_values::_Equal_allocatorsandallocator_traits<_Alnode>::is_always_equal::valueare actually equal.STL/stl/inc/xmemory
Lines 735 to 746 in 926d458
It's not very clear whether we're allowed use this value, see LWG-3267. But it is clear that this is not strengthening!
I believe we should remove the misleading
/* strengthened */comment.Moreover, the exception specification of the move assignment operators of
dequeand (unordered) associative containers are spelt differently and more close to the forms specified in the standard. So perhaps we should spell the one oflistasnoexcept(_Alnode_traits::is_always_equal::value).There's another
_Choose_pocma_v<_Alnode> == _Pocma_values::_Equal_allocatorsin<xtree>. I guess it would be more consistent to write_Alnode_traits::is_always_equal::valueinstead.STL/stl/inc/xtree
Lines 943 to 944 in 926d458
This issue is intended for a new contributor (especially one new to GitHub) to get started with the simplest possible change.
Please feel free to submit a pull request if there isn't one already linked here - no need to ask for permission! 😸
You can (and should) link your pull request to this issue using GitHub's close/fix/resolve syntax.
(in the PR description not the commit message)