Status updated, Wednesday lunchtime, Bloomington 2011

Author: AlisdairM

xml/issue1214.xml

@@ -3,7 +3,7 @@
   <!ENTITY nbsp "&#160;">
 ] >
 
-<issue num="1214" status="Deferred">
+<issue num="1214" status="Ready">
 <title>Insufficient/inconsistent key immutability requirements for  associative containers</title>
 <section><sref ref="[associative.reqmts]"/></section>
 <submitter>Daniel Kr&uuml;gler</submitter>
@@ -77,6 +77,18 @@ function object constraints of associative and unordered containers.
 We're uncomfortable with the first agenda item, and we can live with the second agenda 
 item being applied before or after Madrid. 
 </p>
+
+<note>
+2011 Bloomington
+</note>
+
+<p>
+Further discussion persuades us this issue is Ready (and so moved).
+We may need a further issue clarifying the notion of key <i>value</i>
+vs. key <i>object</i>, as object identity appears to be important
+to this wording.
+</p>
+
 </discussion>
 
 <resolution>

xml/issue1450.xml

@@ -112,7 +112,7 @@ and</del> <i>Ci &amp; Cj</i> is zero.
 Change bullet 3 of paragraph 4:
 </p>
 <p>
-<del>The</del><ins>A non-zero</ins> value Y is set in the object X if the expression X & Y is nonzero.
+<del>The</del><ins>A non-zero</ins> value Y is set in the object X if the expression X &amp; Y is nonzero.
 </p>
 </discussion>
 

xml/issue1521.xml

@@ -3,7 +3,7 @@
   <!ENTITY nbsp "&#160;">
 ] >
 
-<issue num="1521" status="Deferred">
+<issue num="1521" status="NAD Future">
 <title>Requirements on internal pointer representations in containers</title>
 <section><sref ref="[container.requirements.general]"/></section>
 <submitter>Mike Spertus</submitter>
@@ -48,6 +48,16 @@ in the pre-Batavia mailing.
 
 <p>Deferred</p>
 
+<note>
+2011 Batavia
+</note>
+
+<p>
+This may be an issue, but it is not clear.  We want to gain a few years experience
+with the C++11 allocator model to see if this is already implied by the existing
+specification.
+</p>
+
 </discussion>
 
 <resolution>

xml/issue2005.xml

@@ -133,7 +133,7 @@ The effects of these inserts can be concisely stated in terms of emplace().
 Also, the correct term is "EmplaceConstructible", not "constructible".
 </p>
 <p>
-New wording by Pablo, eliminating duplicate requirements already implied by the effects clause.  Move to Ready.
+New wording by Pablo, eliminating duplicate requirements already implied by the effects clause.  Move to Review.
 </p>
 
 </discussion>