|
|
Boost-Commit : |
From: dgregor_at_[hidden]
Date: 2008-08-25 14:15:12
Author: dgregor
Date: 2008-08-25 14:15:11 EDT (Mon, 25 Aug 2008)
New Revision: 48386
URL: http://svn.boost.org/trac/boost/changeset/48386
Log:
Update issues
Added:
sandbox/committee/concepts/issues/issues/issue47.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue48.xml (contents, props changed)
Text files modified:
sandbox/committee/concepts/issues/issues/concepts-issues.xml | 6 +++++-
sandbox/committee/concepts/issues/issues/issue21.xml | 10 +++++++++-
sandbox/committee/concepts/issues/issues/issue37.xml | 13 +++++++++++++
sandbox/committee/concepts/issues/issues/issue38.xml | 6 +++++-
sandbox/committee/concepts/issues/issues/issue41.xml | 9 ++++++---
sandbox/committee/concepts/issues/section.data | 1 +
sandbox/committee/concepts/stdlib/lib-issues.txt | 20 ++++++++++----------
7 files changed, 49 insertions(+), 16 deletions(-)
Modified: sandbox/committee/concepts/issues/issues/concepts-issues.xml
==============================================================================
--- sandbox/committee/concepts/issues/issues/concepts-issues.xml (original)
+++ sandbox/committee/concepts/issues/issues/concepts-issues.xml 2008-08-25 14:15:11 EDT (Mon, 25 Aug 2008)
@@ -1,4 +1,4 @@
-<issueslist revision="C4"
+<issueslist revision="C5"
maintainer="Douglas Gregor <doug.gregor_at_[hidden]>"
active_docno="Dxxxx=xx-xxxx"
defect_docno="Dxxxx=xx-xxxx"
@@ -104,6 +104,10 @@
<revision_history>
+<revision tag="C5">
+Companion to the concepts proposals in the pre-San Francisco mailing. (25 August 2008)
+</revision>
+
<revision tag="C4">
Companion to the concepts proposals in the post-Antipolis mailing. (30 June 2008)
</revision>
Modified: sandbox/committee/concepts/issues/issues/issue21.xml
==============================================================================
--- sandbox/committee/concepts/issues/issues/issue21.xml (original)
+++ sandbox/committee/concepts/issues/issues/issue21.xml 2008-08-25 14:15:11 EDT (Mon, 25 Aug 2008)
@@ -3,7 +3,7 @@
<!ENTITY nbsp " ">
] >
-<issue num="21" status="New">
+<issue num="21" status="NAD">
<title>Iterator <tt>difference_type</tt> requirements</title>
<section><sref ref="[input.iterators]"/></section>
<submitter>LWG</submitter>
@@ -25,4 +25,12 @@
why can't I use it for the iterator's difference type?</p>
</discussion>
+<resolution>
+ The LWG has reaffirmed that the <code>difference_type</code> should
+ be a built-in integral type, since this requirement was present in
+ the C++98 library. Moreover, the two concepts cannot be fully
+ combined without some tangling of the compiler-supported concepts
+ and the library-defined concepts.
+</resolution>
+
</issue>
Modified: sandbox/committee/concepts/issues/issues/issue37.xml
==============================================================================
--- sandbox/committee/concepts/issues/issues/issue37.xml (original)
+++ sandbox/committee/concepts/issues/issues/issue37.xml 2008-08-25 14:15:11 EDT (Mon, 25 Aug 2008)
@@ -22,6 +22,19 @@
"types which are normal / sensible". The fact you can't sort
a <code>Regular</code> type (as it isn't <code>Swappable</code>)
seems a bit bizarre.</p>
+
+ <p>[<i>Doug</i>: there aren't any algorithms or data structures in the standard library that need a move-equivalent version of <code>Regular</code> or <code>Semiregular</code>, so we shouldn't make up these concepts.]</p>
</discussion>
+<resolution>
+ <p>In [concept.regular], update the definition of <tt>Semiregular</tt> as follows:</p>
+
+ <pre>
+auto concept Semiregular<typename T>
+ : CopyConstructible<T>, CopyAssignable<T>, FreeStoreAllocatable<T><ins>, Swappable<T></ins> {
+ requires SameType<CopyAssignable<T>::result_type, T&>;
+}
+ </pre>
+</resolution>
+
</issue>
Modified: sandbox/committee/concepts/issues/issues/issue38.xml
==============================================================================
--- sandbox/committee/concepts/issues/issues/issue38.xml (original)
+++ sandbox/committee/concepts/issues/issues/issue38.xml 2008-08-25 14:15:11 EDT (Mon, 25 Aug 2008)
@@ -3,7 +3,7 @@
<!ENTITY nbsp " ">
] >
-<issue num="38" status="Open">
+<issue num="38" status="WP">
<title>Container move constructor/assignment operators don't account for scoped allocators</title>
<section><sref ref="[containers]"/></section>
<submitter>Pablo Halpern</submitter>
@@ -15,4 +15,8 @@
on the normal move constructor and the move assignment operator are
missing.</p>
</discussion>
+
+<resolution>
+These problems have been resolved in the latest proposal.
+</resolution>
</issue>
Modified: sandbox/committee/concepts/issues/issues/issue41.xml
==============================================================================
--- sandbox/committee/concepts/issues/issues/issue41.xml (original)
+++ sandbox/committee/concepts/issues/issues/issue41.xml 2008-08-25 14:15:11 EDT (Mon, 25 Aug 2008)
@@ -20,8 +20,10 @@
<resolution>
<p>Modify [concept.copymove] paragraphs 1-3 as follows:</p>
<pre>
-auto concept MoveConstructible<typename T> <del>: HasConstructor<T, T&&></del> {
+auto concept MoveConstructible<typename T> : <del>Constructible<T, T&&></del><ins>NothrowDestructible<T></ins> {
+ requires RvalueOf<T><del> && Constructible<T, RvalueOf<T>::type></del>;
<ins>explicit T::T(T&&);</ins>
+ <ins>explicit T::T(RvalueOf<T>::type);</ins>
}
</pre>
<ol>
@@ -30,6 +32,7 @@
</ol>
<pre>
T::T(T&& rv); <del>// note: inherited from HasConstructor<T, T&&></del>
+<ins>T::T(RvalueOf<T>::type rv);</ins>
</pre>
<ol start="2">
<li><i>Postcondition</i>: the constructed <code>T</code> object is equivalent to the value of <code>rv</code> before the construction. [ <i>Note</i>: there is no
@@ -37,8 +40,8 @@
</ol>
<pre>
-auto concept CopyConstructible<typename T> : MoveConstructible<T><del>, HasConstructor<T, const T&</del>> {
- <ins>T::T(const T&);</ins>
+auto concept CopyConstructible<typename T> : MoveConstructible<T><del>, Constructible<T, const T&</del>> {
+ <ins>explicit T::T(const T&);</ins>
axiom CopyPreservation(T x) {
T(x) == x;
Added: sandbox/committee/concepts/issues/issues/issue47.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue47.xml 2008-08-25 14:15:11 EDT (Mon, 25 Aug 2008)
@@ -0,0 +1,32 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="47" status="New">
+ <title><code>ArithmeticLike</code> conversions from integral, floating-point types should be <code>explicit</code></title>
+<section><sref ref="[concept.arithmetic]"/></section>
+<submitter>Howard Hinnant</submitter>
+<date>25 Aug 2008</date>
+
+<discussion>
+ <p>We would like to use the <code>ArithmeticLike</code> concept in
+ places where the user types might only have explicit conversions
+ from the built-in arithmetic types, e.g., in
+ class <code>duration</code>. For example, the user may have created
+ an arithmetic emulator type but wanted to keep conversions to a
+ minimum to make the type safer to use.</p>
+</discussion>
+
+<resolution>
+ <p>In [concept.arithmetic], update the three constructor requirements in <code>ArithmeticLike</code> as follows:</p>
+ <pre>
+concept ArithmeticLike<typename T>
+ : ... {
+ <ins>explicit</ins> T::T(intmax_t);
+ <ins>explicit</ins> T::T(uintmax_t);
+ <ins>explicit</ins> T::T(long double);
+}
+ </pre>
+</resolution>
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue48.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue48.xml 2008-08-25 14:15:11 EDT (Mon, 25 Aug 2008)
@@ -0,0 +1,35 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="48" status="New">
+ <title>Missing <code>iterator</code> to <code>const_iterator</code> conversion</title>
+<section><sref ref="[container.concepts]"/></section>
+<submitter>LWG</submitter>
+<date>9 Jun 2008</date>
+
+<discussion>
+ <p>The <code>Container</code> and <code>MemberContainer</code>
+ concepts are missing the conversion from <code>iterator</code>
+ to <code>const_iterator</code>.</p>
+</discussion>
+
+<resolution>
+ <p>In [concept.concepts.free], modify the <code>Container</code> concept as follows:</p>
+ <pre>
+concept Container<typename C> {
+ // ...
+ <ins>requires Convertible<iterator, const_iterator>;</ins>
+}
+ </pre>
+ <p>In [container.concepts.member], modify the <code>MemberContainer</code> concept as follows:</p>
+
+ <pre>
+concept MemberContainer<typename C> {
+ // ...
+ <ins>requires Convertible<iterator, const_iterator>;</ins>
+}
+ </pre>
+</resolution>
+</issue>
Modified: sandbox/committee/concepts/issues/section.data
==============================================================================
--- sandbox/committee/concepts/issues/section.data (original)
+++ sandbox/committee/concepts/issues/section.data 2008-08-25 14:15:11 EDT (Mon, 25 Aug 2008)
@@ -762,6 +762,7 @@
23.1.2 [associative.reqmts]
23.1.3 [unord.req]
23.1.3.1 [unord.req.except]
+ 23.1.4 [container.concepts]
23.2 [sequences]
23.2.1 [array]
23.2.1.1 [array.cons]
Modified: sandbox/committee/concepts/stdlib/lib-issues.txt
==============================================================================
--- sandbox/committee/concepts/stdlib/lib-issues.txt (original)
+++ sandbox/committee/concepts/stdlib/lib-issues.txt 2008-08-25 14:15:11 EDT (Mon, 25 Aug 2008)
@@ -421,25 +421,25 @@
y * SequenceContainer? second axiom requires bidirectional iterator.
- * In second axiom in SequenceContainer? --c.end() won't compile when iterator is pointer.
+Y * In second axiom in SequenceContainer? --c.end() won't compile when iterator is pointer.
Y * 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.
+N * 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().
+Y * Need axiom involving front().
- * Same issues in BackInsertionSequence?, InsertionSequence?, etc...
+N * Same issues in BackInsertionSequence?, InsertionSequence?, etc...
- * Container: iterator should be convertible to const_iterator (missing requirement?).
+y * 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?
+Y * 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
+Y * Concepts issue 34 came up
- * Missing MoveAssignable? requirement on
+Y * Missing MoveAssignable? requirement on
vector::emplace(const_iterator, Args&&...)
- * Missing concept: EquivalenceRelation"
+Y * Missing concept: EquivalenceRelation"
- * Check for places where we need to use EquivalenceRelation for the predicate form when the simple form uses EqualityComparable
+Y * Check for places where we need to use EquivalenceRelation for the predicate form when the simple form uses EqualityComparable
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