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.
swap for proxy iteratorsSection: 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 other active issues in [utility.arg.requirements].
View all other issues in [utility.arg.requirements].
View all issues with Resolved status.
Discussion:
This issue was split from 672(i). 672(i) 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(i).
[ 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,
TandVareis atypes to be supplied by a C++ program instantiating a template;a,b, andcare values of typeconst T;sandtare modifiable lvalues of typeT;uis a value of type (possiblyconst)T;andrvis a non-constrvalue of typeT;wis a value of typeT; andvis a value of typeV.
Table 37: Swappablerequirements [swappable]expression Return type Post-condition swap(sw,tv)voidtwhas the value originally held byuv, anduvhas the value originally held bytwThe
Swappablerequirement is met by satisfying one or more of the following conditions:
TisSwappableifTandVare the same type andTsatisfies theMoveConstructiblerequirements (Table 33) and theMoveAssignablerequirements (Table 35);TisSwappablewithVif a namespace scope function namedswapexists in the same namespace as the definition ofTorV, such that the expressionswap(is valid and has the semantics described in this table.sw,tv)TisSwappableifTis an array type whose element type isSwappable.
Rationale:
[ post San Francisco: ]
Solved by N2758.