[Boost-commit] svn:boost r46761 - sandbox/committee/concepts/stdlib

From: mmarcus_at_[hidden]
Date: 2008-06-26 23:36:09

Author: mmarcus
Date: 2008-06-26 23:36:08 EDT (Thu, 26 Jun 2008)
New Revision: 46761
URL: http://svn.boost.org/trac/boost/changeset/46761

Log:
Add raw version of Howard's issues to list.

Text files modified: 
   sandbox/committee/concepts/stdlib/lib-issues.txt |    44 +++++++++++++++++++++++++++++++++++++++ 
   1 files changed, 43 insertions(+), 1 deletions(-)

Modified: sandbox/committee/concepts/stdlib/lib-issues.txt
==============================================================================
--- sandbox/committee/concepts/stdlib/lib-issues.txt	(original)
+++ sandbox/committee/concepts/stdlib/lib-issues.txt	2008-06-26 23:36:08 EDT (Thu, 26 Jun 2008)
@@ -1,6 +1,7 @@
 Explanation:
 
-This was the third (and final) version of Thomas's list from SA.
+This includes the third (and final) version of Thomas's list from
+SA. Now also includes Howard's issue list at end.
 
 I believe the legend is:
  unmarked lines have status "open"
@@ -392,6 +393,47 @@
 
 y - Add predicate that paragraph 3 must hold.
 
+#####
 
+Howard's list (not yet annotated):
 
 
+    *  23.1 p3 strike "destruct" functions.
+
+    * 23.1.1 Present rationale for constraining container to ForwardIterator? as opposed to input/output iterators.
+
+    * Make Container and SequenceContainer? work with c-arrays (free function for begin/end).
+
+    * Have a preference for free functions in all concepts.
+
+    * Discard member swap, not needed.
+
+    * Add MemberSwappable? so that container swap free functions compile. Change container swap functions to require MemberSwappable?.
+
+    * Review constructors which take default arguments. Default argument no longer implies DefaultConstructible?.
+
+    * Adaptors should require NothrowDestructible? (related issues worthy of exploration).
+
+    * Implementations of stack members will change to free functions.
+
+    * Create new FrontEmplaceSequence? / BackEmplaceSequence? concepts (and member form adaptors for emplace_front/emplace_back).
+
+    * SequenceContainer? second axiom requires bidirectional iterator.
+
+    * In second axiom in SequenceContainer? --c.end() won't compile when iterator is pointer.
+
+    * In FrontInsertionSequence? axiom add ", c".
+
+    * General issue using FrontInsertionSequence? as example: push_front(const value_type&) should be push_front(value_type) to support move only value_types. This supports queue push_front of move only types. Or use two signatures: push_front(const value_type&) and push_front(value_type&&). The axiom may accidently require value_type to be CopyConstructible? depending on how the signatures are resolved. Need to watch out for that.
+
+    * Need axiom involving front().
+
+    * Same issues in BackInsertionSequence?, InsertionSequence?, etc...
+
+    * Container: iterator should be convertible to const_iterator (missing requirement?).
+
+    * InsertionSequence?: insert iterator isn't in sync with the current working paper. Is there a way to fix insert and/or concept to require const_iterator without breaking backward compatibility?
+
+    * Concepts issue 34 came up
+
+    * Missing MoveAssignable? requirement on vector::emplace(const_iterator, Args&&...)