Boost logo

Boost-Commit :

Subject: [Boost-commit] svn:boost r50144 - sandbox/committee/rvalue_ref
From: dave_at_[hidden]
Date: 2008-12-05 16:21:29

Author: dave
Date: 2008-12-05 16:21:29 EST (Fri, 05 Dec 2008)
New Revision: 50144

Partial update

Text files modified:
   sandbox/committee/rvalue_ref/n2812_08-0322_soundness.rst | 91 ++++++++++++++++++++++++++++++++++++++++
   1 files changed, 91 insertions(+), 0 deletions(-)

Modified: sandbox/committee/rvalue_ref/n2812_08-0322_soundness.rst
--- sandbox/committee/rvalue_ref/n2812_08-0322_soundness.rst (original)
+++ sandbox/committee/rvalue_ref/n2812_08-0322_soundness.rst 2008-12-05 16:21:29 EST (Fri, 05 Dec 2008)
@@ -1,3 +1,80 @@
+ New Iterator Concepts
+.. Version 1.25 of this ReStructuredText document is the same as
+ n1550_, the paper accepted by the LWG.
+:Author: David Abrahams, Doug Gregor
+:Contact: dave_at_[hidden], doug.gregor_at_[hidden]
+:organization: `BoostPro Computing`_, Apple Computer `Open Systems
+:date: 2008-12-05
+:Number: n2812=08-0322
+.. _`BoostPro Computing`:
+* Description of problem
+* Proposed fix
+* Impact of fix
+* Implementation Experience
+* Pro/con arguments?
+Status of This Document
+Currently aggregating comments from a long discussion thread starting
+Sept. 19 2008 and just trying to make sure all the important material
+is at hand. We will incorporate this material in the main text next.
+Miscellaneous Remarks and Notes
+I've tried to bold-ify what I think are the essential points below
+* Peter
+ Dimov:
+ I think that we don't need idiom 2 [where we want to modify the
+ argument regardless of whether it turns out to be an rvalue] that
+ much. If we're going to change && to not bind to lvalues, the
+ **principled approach would be to omit the &&& at all**. Yes, idiom 2
+ does have its uses, but it also has shown an ability to bite us
+ **(issue 884)**.
+ I also note that **making && bind only to rvalues probably settles
+ the question of whether auto&& should apply the deduction rule** -
+ it wouldn't work for lvalues if it did not.
+ We'll need some additional wording to **keep std::move working**;
+ it binds an rvalue reference to an lvalue.
+ **I find the original motivating example (where the
+ CopyConstructible concept requirement causes the const& overload
+ to be dropped) much better, because it represents neither a
+ mistake nor an oversight.**
+ The std::move implementation takes advantage of the fact that T&&
+ can bind to an lvalue t. The binding can be made explicit, via
+ static_cast, but **a blank prohibition could render even that
+ illegal.**
+* The first version of the paper mentioned back_insert_iterator and
+ how the simple workaround for a problem prevents using it with
+ initializer lists, something Doug apparently understood. Worth
+ mentioning?
+* There was a vote in LWG to roll all swap functions back to the
+ single (T&,T&) form because of issue 884. However, for bureaucratic
+ reasons I'm not sure if that vote had any legal force, so we may
+ need to do something about it.
@@ -33,6 +110,19 @@
 applied when that argument is an unnamed temporary and thus inaccessible and
 invisible to the rest of the program.
+.. Annotation:: Thomas Witt
+ add a sentence or two explaining the overload and binding
+ behavior. Pointing out that *both* overloads are needed to make it
+ safe. That might not be clear to people not familiar with rvalue
+ references.
+ Dave:
+ Technically, only the first overload is needed to make it safe;
+ the second one is needed to make it move. So I can try to
+ emphasize that the first overload is needed.
 How Move-Only Types Work
@@ -130,3 +220,4 @@
 for C++0x to take an rvalue reference first argument would need a second
 overload. If not, we should revert these operators to their original

Boost-Commit list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at