Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cplusplus.github.io/LWG/issue742 below:

Enabling swap for proxy iterators

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.

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 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⁽ⁱ⁾. 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 Editorial Resolved. 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 type s 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; andrv 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( s w, t v) void t w has the value originally held by u v, and u v has the value originally held by t w

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 andT 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( s w, 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.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4