Boost logo

Boost-Commit :

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

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
-* 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

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