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 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 swap
s, 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
andV
areis atypes to be supplied by a C++ program instantiating a template;a
,b
, andc
are values of typeconst T
;s
andt
are modifiable lvalues of typeT
;u
is a value of type (possiblyconst
)T
;andrv
is a non-const
rvalue of typeT
;w
is a value of typeT
; andv
is a value of typeV
.
Table 37: Swappable
requirements [swappable]expression Return type Post-condition swap(
sw,tv)void
t
w
has the value originally held byu
v
, andu
v
has the value originally held byt
w
The
Swappable
requirement is met by satisfying one or more of the following conditions:
T
isSwappable
ifT
andV
are the same type andT
satisfies theMoveConstructible
requirements (Table 33) and theMoveAssignable
requirements (Table 35);T
isSwappable
withV
if a namespace scope function namedswap
exists in the same namespace as the definition ofT
orV
, such that the expressionswap(
is valid and has the semantics described in this table.sw,tv)T
isSwappable
ifT
is an array type whose element type isSwappable
.
Rationale:
[ post San Francisco: ]
Solved by N2758.