Subject: [Boost-commit] svn:boost r50144 - sandbox/committee/rvalue_ref
Date: 2008-12-05 16:21:29
Date: 2008-12-05 16:21:29 EST (Fri, 05 Dec 2008)
New Revision: 50144
Text files modified:
sandbox/committee/rvalue_ref/n2812_08-0322_soundness.rst | 91 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 91 insertions(+), 0 deletions(-)
--- 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
+.. _`BoostPro Computing`: http://www.boostpro.com
+* 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
+ 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
+* 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
+* 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
+ 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 acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk