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: