This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.

### 672. Swappable requirements need updating

Section: 16.4.4.2 [utility.arg.requirements] Status: CD1 Submitter: Howard Hinnant Opened: 2007-05-04 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [utility.arg.requirements].

View all issues with CD1 status.

Discussion:

The current `Swappable` is:

> Table 37: `Swappable` requirements [swappable]
> expression | return type | post-condition
> --- | --- | ---
> `swap(s,t)` | `void` | `t` has the value originally held by `u`, and `u` has the value originally held by `t`
> The Swappable requirement is met by satisfying one or more of the following conditions: `T` is Swappable if `T` satisfies the `CopyConstructible` requirements (Table 34) and the `CopyAssignable` requirements (Table 36); `T` is Swappable if a namespace scope function named `swap` exists in the same namespace as the definition of `T`, such that the expression `swap(t,u)` is valid and has the semantics described in this table.

With the passage of rvalue reference into the language, `Swappable` needs to be updated to require only `MoveConstructible` and `MoveAssignable`. This is a minimum.

Additionally we may want to support proxy references such that the following code is acceptable:

>     namespace Mine {

>     template <class T>
>     struct proxy {...};

>     template <class T>
>     struct proxied_iterator
>     {
>        typedef T value_type;
>        typedef proxy<T> reference;
>        reference operator*() const;
>        ...
>     };

>     struct A
>     {
>        // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
>        void swap(A&);
>        ...
>     };

>     void swap(A&, A&);
>     void swap(proxy<A>, A&);
>     void swap(A&, proxy<A>);
>     void swap(proxy<A>, proxy<A>);

>     }  // Mine

>     ...

>     Mine::proxied_iterator<Mine::A> i(...)
>     Mine::A a;
>     swap(*i1, a);

I.e. here is a call to `swap` which the user enables swapping between a proxy to a class and the class itself. We do not need to anything in terms of implementation except not block their way with overly constrained concepts. That is, the `Swappable` concept should be expanded to allow swapping between two different types for the case that one is binding to a user-defined `swap`.

Proposed resolution:

Change 16.4.4.2 [utility.arg.requirements]:

> -1- The template definitions in the C++ Standard Library refer to various named requirements whose details are set out in tables 31-38. In these tables, `T` is a type to be supplied by a C++ program instantiating a template; `a`, `b`, and `c` are values of type `const T`; `s` and `t` are modifiable lvalues of type `T`; `u` is a value of type (possibly `const`) `T`; and `rv` is a non-`const` rvalue of type `T`.

> Table 37: `Swappable` requirements [swappable]
> expression | return type | post-condition
> --- | --- | ---
> `swap(s,t)` | `void` | `t` has the value originally held by `u`, and `u` has the value originally held by `t`
> The `Swappable` requirement is met by satisfying one or more of the following conditions: `T` is `Swappable` if `T` satisfies the `CopyConstructible` MoveConstructible requirements (Table 34 33) and the `CopyAssignable` MoveAssignable requirements (Table 36 35); `T` is `Swappable` if a namespace scope function named `swap` exists in the same namespace as the definition of `T`, such that the expression `swap(t,u)` is valid and has the semantics described in this table.

[ Kona (2007): We like the change to the `Swappable` requirements to use move semantics. The issue relating to the support of proxies is separable from the one relating to move semantics, and it's bigger than just swap. We'd like to address only the move semantics changes under this issue, and open a separated issue (742) to handle proxies. Also, there may be a third issue, in that the current definition of `Swappable` does not permit rvalues to be operands to a swap operation, and Howard's proposed resolution would allow the right-most operand to be an rvalue, but it would not allow the left-most operand to be an rvalue (some swap functions in the library have been overloaded to permit left operands to swap to be rvalues). ]