[Boost-commit] svn:boost r50203 - sandbox/committee/rvalue_ref

Subject: [Boost-commit] svn:boost r50203 - sandbox/committee/rvalue_ref
From: dgregor_at_[hidden]
Date: 2008-12-08 13:15:28

Author: dgregor
Date: 2008-12-08 13:15:27 EST (Mon, 08 Dec 2008)
New Revision: 50203
URL: http://svn.boost.org/trac/boost/changeset/50203

Log:
Remove the Working Section
Text files modified: 
   sandbox/committee/rvalue_ref/n2812_08-0322_soundness.rst |    75 ----------------------------------------
   1 files changed, 0 insertions(+), 75 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-08 13:15:27 EST (Mon, 08 Dec 2008)
@@ -15,81 +15,6 @@
 
 .. contents:: index
 
------------------
- Working Section
------------------
-
-Outline
-=======
-
-* 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.**
-
-    FWIW, **the && change does not affect the three overload free
-    swap. It only affects the single &&-taking member swap.**
-
-    Also FWIW, and IMHO, swapping with an rvalue is an anti-idiomatic
-    way to express move assignment. **If people feel the need to use
-    swap in this way, there's something wrong with the move assignment
-    operator for the type.**
-
-
-* 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.
-
------------------
- Written Section
------------------
-
 Synopsis
 ========