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.

742. Enabling swap for proxy iterators

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

Priority: Not Prioritized

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

View all issues with Resolved status.

Discussion:

This issue was split from 672⁽ⁱ⁾. 672⁽ⁱ⁾ now just deals with changing the requirements of T in the Swappable requirement from CopyConstructible and CopyAssignable to MoveConstructible and MoveAssignable.

This issue seeks to widen the Swappable requirement to support proxy iterators. Here is example code:

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);

The key point to note in the above code is that in the call to swap, *i1 and a are different types (currently types can only be Swappable with the same type). A secondary point is that to support proxies, one must be able to pass rvalues to swap. But note that I am not stating that the general purpose std::swap should accept rvalues! Only that overloaded swaps, as in the example above, be allowed to take rvalues.

That is, no standard library code needs to change. We simply need to have a more flexible definition of Swappable.

[ Bellevue: ]

While we believe Concepts work will define a swappable concept, we should still resolve this issue if possible to give guidance to the Concepts work.

Would an ambiguous swap function in two namespaces found by ADL break this wording? Suggest that the phrase "valid expression" means such a pair of types would still not be swappable.

Motivation is proxy-iterators, but facility is considerably more general. Are we happy going so far?

We think this wording is probably correct and probably an improvement on what's there in the WP. On the other hand, what's already there in the WP is awfully complicated. Why do we need the two bullet points? They're too implementation-centric. They don't add anything to the semantics of what swap() means, which is there in the post-condition. What's wrong with saying that types are swappable if you can call swap() and it satisfies the semantics of swapping?

[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]

[ 2009-10 Santa Cruz: ]

Leave as Open. Dave to provide wording.

[ 2009-11-08 Howard adds: ]

Updated wording to sync with N3000. Also this issue is very closely related to 594⁽ⁱ⁾.

[ 2010 Pittsburgh: ]

Moved to NAD EditorialResolved. Rationale added.

Rationale:

Solved by N3048.

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 and V are is a types 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; w is a value of type T; and v is a value of type V.

Table 37: Swappable requirements [swappable]

expression	Return type	Post-condition
swap(sw,tv)	void	tw has the value originally held by uv, and uv has the value originally held by tw
The Swappable requirement is met by satisfying one or more of the following conditions: T is Swappable if T and V are the same type and T satisfies the MoveConstructible requirements (Table 33) and the MoveAssignable requirements (Table 35); T is Swappable with V if a namespace scope function named swap exists in the same namespace as the definition of T or V, such that the expression swap(sw,t v) is valid and has the semantics described in this table. T is Swappable if T is an array type whose element type is Swappable.

Rationale:

[ post San Francisco: ]

Solved by N2758.