This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
Section: 22.2.2 [utility.swap] Status: Resolved Submitter: Orson Peters Opened: 2015-11-01 Last modified: 2020-09-06
Priority: 2
View all other issues in [utility.swap].
View all issues with Resolved status.
Discussion:
The noexcept specification for the std::swap overload for arrays has the effect that all multidimensional arrays — even those of build-in types — would be considered as non-noexcept swapping, as described in the following Stackoverflow article.
Consider the following example code:
#include <utility>
#include <iostream>
int main()
{
int x[2][3];
int y[2][3];
using std::swap;
std::cout << noexcept(swap(x, y)) << "\n";
}
Both clang 3.8.0 and gcc 5.2.0 return 0.
The reason for this unexpected result seems to be a consequence of both core wording rules (6.4.2 [basic.scope.pdecl] says that "The point of declaration for a name is immediately after its complete declarator (Clause 8) and before its initializer (if any)" and the exception specification is part of the declarator) and the fact that the exception-specification of the std::swap overload for arrays uses an expression and not a type trait. At the point where the expression is evaluated, only the non-array std::swap overload is in scope whose noexcept specification evaluates to false since arrays are neither move-constructible nor move-assignable. Daniel: The here described problem is another example for the currently broken swap exception specifications in the Standard library as pointed out by LWG 2456. The paper N4511 describes a resolution that would address this problem. If the array swap overload would be declared instead as follows,template <class T, size_t N> void swap(T (&a)[N], T (&b)[N]) noexcept(is_nothrow_swappable<T>::value);
the expected outcome is obtained.
Revision 2 (P0185R0) of above mentioned paper will available for the mid February 2016 mailing.[2016-03-06, Daniel comments]
With the acceptance of revision 3 P0185R1 during the Jacksonville meeting, this issue should be closed as "resolved": The expected program output is now 1. The current gcc 6.0 trunk has already implemented the relevant parts of P0185R1.
Proposed resolution: