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

Subject: [Boost-commit] svn:boost r51901 - sandbox/committee/rvalue_ref
From: dgregor_at_[hidden]
Date: 2009-03-22 12:17:22

Author: dgregor
Date: 2009-03-22 12:17:22 EDT (Sun, 22 Mar 2009)
New Revision: 51901
URL: http://svn.boost.org/trac/boost/changeset/51901

Log:
Notes about no-throw move construction
Added:
   sandbox/committee/rvalue_ref/nothrowmove.org   (contents, props changed)

Added: sandbox/committee/rvalue_ref/nothrowmove.org
==============================================================================
--- (empty file)
+++ sandbox/committee/rvalue_ref/nothrowmove.org	2009-03-22 12:17:22 EDT (Sun, 22 Mar 2009)
@@ -0,0 +1,67 @@
+Move Constructors and Exceptions  -*- mode: org; fill-column: 78 -*-
+
+* Directly Relevant
+** Tasks
+#+CATEGORY: Tasks
+*** TODO Consider MoveAssignable; same problem?
+   [2009-03-21 Sat]
+*** TODO Look through all move ctors for need to handle like pair.
+   [2009-03-21 Sat]
+** Notes
+* Incidental Issues
+** Tasks
+*** TODO Look at all cases of unconstrained rvalue ref parameters and check that concept req'ts work when T deduced as reference.
+   [2009-03-21 Sat]
+
+** Notes
+*** [2009-03-21 Sat] p. 535 at the top we need MoveConstructible V1, MoveConstructible V2 (where V1,V2 are defined on 539).  Also make_tuple on 550
+*** [2009-03-21 Sat] p1183 thread ctor, and in general, we need a way to talk about "copiable from generalized rvalue ref argument" for cases where we're going to forward and copy.
+
+   This issue may well be quite large.  Language in para 4 about "if
+   an lvalue" is wrong because types aren't expressions.
+
+   p1199, call_once has all the same issues.
+
+*** [2009-03-21 Sat] p869 InputIterator pointer type should not be required to be convertible to const value_type*, rather it needs to have a operator-> of its own that can be used for the value type.
+*** [2009-03-21 Sat] p818 stack has the same problem with default ctor.
+*** [2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so
+
+   requires MoveConstructible<Cont>
+     explicit priority_queue(const Compare& x = Compare(), Cont&& = Cont());
+
+   Don't require MoveConstructible when default constructing Cont.
+   Also missing semantics for move ctor.
+
+*** [2009-03-21 Sat] Why are Allocators required to be CopyConstructible as opposed to MoveConstructible?
+*** [2009-03-21 Sat] p813 queue needs a separate default ctor (Cont needn't be MoveConstructible).  No documented semantics for move c'tor.  Or *any* of its 7 ctors!
+*** [2009-03-21 Sat] std::array should have constructors for C++0x, consequently must consider move construction.
+*** [2009-03-21 Sat] p622 all messed up.
+
+   para 8 "implementation-defined" is the wrong term; should be "see
+   below" or something.
+
+   para 12 "will be selected" doesn't make any sense because we're not
+   talking about actual arg types.
+
+   paras 9-13 need to be totally rewritten for concepts.
+
+*** [2009-03-21 Sat] Null pointer comparisons (p587) have all become unconstrained.  Need to fix that
+*** [2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration.  We think CopyConstructible is the right reqt.
+*** make_pair needs Constructible<V1, T1&&> requirements!
+*** make_tuple needs something similar
+*** tuple bug in synopsis: template <class... UTypes>
+   requires Constructible<Types, const UTypes&>...
+   template <class... UTypes>
+   requires Constructible<Types, RvalueOf<UTypes>::type>...
+
+   Note: removal of MoveConstructible requirements in std::function makes
+   these routines unconstrained!
+
+*** these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ]
+ unique_ptr(pointer p, implementation-defined d);
+ unique_ptr(pointer p, implementation-defined d);
+
+*** multimap range constructor should not have MoveConstructible<value_type> requirement.
+
+   same with insert(..., P&&); multiset has the same issue, as do
+   unordered_multiset and unordered_multimap. Review these!