Pete and Jeremiah propose wording for issue 1450

Author: AlisdairM

xml/issue1450.xml

@@ -3,7 +3,7 @@
   <!ENTITY nbsp "&#160;">
 ] >
 
-<issue num="1450" status="Deferred">
+<issue num="1450" status="Open">
 <title>[FCD] Contradiction in regex_constants</title>
 <section><sref ref="[re.matchflag]"/></section>
 <submitter>BSI</submitter>
@@ -61,9 +61,8 @@ So, actually <em>both</em> <tt>regex_constants::match_default</tt> and
 <p>The proposed resolution is written against N3126 and considered as a further improvement
 of the fixes suggested by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html">n3110</a>.
 </p>
-</discussion>
 
-<resolution>
+<note>
 <p>
 Add the following sentence to <sref ref="[re.matchflag]"/>  paragraph 1:
 </p>
@@ -74,6 +73,72 @@ rules of the grammar specified for the regular expression object, modified accor
 Table 136 for any bitmask elements set. <ins>Type <tt>regex_constants::match_flag_type</tt> also defines the 
 constants <tt>regex_constants::match_default</tt> and <tt>regex_constants::format_default</tt>.</ins>
 </p></blockquote>
+</note>
+
+<note>
+2011 Bloomington
+</note>
+
+<p>
+It appears the key problem is the phrasing of the bitmask requirements.  Jeremiah supplies updated wording.
+</p>
+
+<p>
+Pete Becker has also provided an alternative resolution.
+</p>
+
+<p>
+Ammend <sref ref="[bitmask.types]"/>:
+</p>
+<p>
+Change the list of values for "enum bit mask" in p2 from
+</p>
+<p>
+<tt><i>V0</i> = 1 &lt;&lt; 0, <i>V1</i> = 1 &lt;&lt; 1, <i>V2</i> = 1 &lt;&lt; 2, <i>V3</i> = 1 &lt;&lt; 3, ...</tt>.
+</p>
+<p>
+to
+</p>
+<p>
+<tt><i>V0</i> = 0, <i>V1</i> = 1 &lt;&lt; 0, <i>V2</i> = 1 &lt;&lt; 1, <i>V3</i> = 1 &lt;&lt; 2,  ...</tt>.
+</p>
+<p>
+Here, the names <i>C0</i>, <i>C1</i>, etc. represent <i>bitmask elements</i> for this particular
+bitmask type. All such <ins>non-zero</ins> elements have distinct values such that, for any pair
+<i>Ci</i> and <i>Cj</i> <ins>where <i>i</i> != <i>j</i></ins>, <del><i>Ci &amp; Ci</i> is nonzero
+and</del> <i>Ci &amp; Cj</i> is zero.
+</p>
+<p>
+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.
+</p>
+</discussion>
+
+<resolution>
+<p>
+Ammend <sref ref="[bitmask.types]"/> p3:
+</p>
+<p>
+Here, the names <i>C0</i>, <i>C1</i>, etc. represent <i>bitmask elements</i> for this particular
+bitmask type. All such elements have distinct<ins>, non-zero</ins> values such that, for any pair
+<i>Ci</i> and <i>Cj</i> <ins>where <i>i</i> != <i>j</i>,</ins> <i>Ci &amp; Ci</i> is nonzero
+and <i>Ci &amp; Cj</i> is zero. <ins>Additionally, the value 0 is used to represent an
+<i>empty bitmask</i>, in which no bitmask elements are set.</ins>
+</p>
+
+<p>
+Add the following sentence to <sref ref="[re.matchflag]"/>  paragraph 1:
+</p>
+<blockquote><p>
+1 The type <tt>regex_constants::match_flag_type</tt> is an implementation-defined bitmask type (17.5.2.1.3).
+<ins>The constants of that type, except for <tt>match_default</tt> and <tt>format_default</tt>, are bitmask
+elements. The <tt>match_default</tt> and <tt>format_default</tt> constants are empty bitmasks.</ins> Matching
+a regular expression against a sequence of characters [first,last) proceeds according to the rules of the
+grammar specified for the regular expression object, modified according to the effects listed in Table 136
+for any bitmask elements set.
+</p></blockquote>
 </resolution>
 
 </issue>

xml/issue2005.xml

@@ -3,7 +3,7 @@
   <!ENTITY nbsp "&#160;">
 ] >
 
-<issue num="2005" status="Open">
+<issue num="2005" status="Review">
 <title><tt>unordered_map::insert(T&amp;&amp;)</tt> protection should apply to <tt>map</tt> too</title>
 <section><sref ref="[map.modifiers]"/><sref ref="[multimap.modifiers]"/>
 <sref ref="[unord.map.modifiers]"/><sref ref="[unord.multimap.modifiers]"/></section>
@@ -129,10 +129,11 @@ We need <tt>is_convertible</tt>, not <tt>is_constructible</tt>, both in ordered
 </note>
 
 <p>
-Move back to open.
 The effects of these inserts can be concisely stated in terms of emplace().
 Also, the correct term is "EmplaceConstructible", not "constructible".
-New wording by Pablo.
+</p>
+<p>
+New wording by Pablo, eliminating duplicate requirements already implied by the effects clause.  Move to Ready.
 </p>
 
 </discussion>