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.

### 2554. Swapping multidimensional arrays is never `noexcept`

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: