Skip to content

Commit 8d67a74

Browse files
Dani-HubDani-Hub
committed
Merge branch 'master' of github.com:lwg/issues
2 parents 0cc4c42 + 9a07965 commit 8d67a74

File tree

4 files changed

+96
-8
lines changed

4 files changed

+96
-8
lines changed

‎xml/issue1214.xml‎

Lines changed: 13 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@
33
<!ENTITY nbsp "&#160;">
44
] >
55

6-
<issue num="1214" status="Deferred">
6+
<issue num="1214" status="Ready">
77
<title>Insufficient/inconsistent key immutability requirements for associative containers</title>
88
<section><sref ref="[associative.reqmts]"/></section>
99
<submitter>Daniel Kr&uuml;gler</submitter>
@@ -77,6 +77,18 @@ function object constraints of associative and unordered containers.
7777
We're uncomfortable with the first agenda item, and we can live with the second agenda
7878
item being applied before or after Madrid.
7979
</p>
80+
81+
<note>
82+
2011 Bloomington
83+
</note>
84+
85+
<p>
86+
Further discussion persuades us this issue is Ready (and so moved).
87+
We may need a further issue clarifying the notion of key <i>value</i>
88+
vs. key <i>object</i>, as object identity appears to be important
89+
to this wording.
90+
</p>
91+
8092
</discussion>
8193

8294
<resolution>

‎xml/issue1450.xml‎

Lines changed: 68 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@
33
<!ENTITY nbsp "&#160;">
44
] >
55

6-
<issue num="1450" status="Deferred">
6+
<issue num="1450" status="Open">
77
<title>[FCD] Contradiction in regex_constants</title>
88
<section><sref ref="[re.matchflag]"/></section>
99
<submitter>BSI</submitter>
@@ -61,9 +61,8 @@ So, actually <em>both</em> <tt>regex_constants::match_default</tt> and
6161
<p>The proposed resolution is written against N3126 and considered as a further improvement
6262
of the fixes suggested by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html">n3110</a>.
6363
</p>
64-
</discussion>
6564

66-
<resolution>
65+
<note>
6766
<p>
6867
Add the following sentence to <sref ref="[re.matchflag]"/> paragraph 1:
6968
</p>
@@ -74,6 +73,72 @@ rules of the grammar specified for the regular expression object, modified accor
7473
Table 136 for any bitmask elements set. <ins>Type <tt>regex_constants::match_flag_type</tt> also defines the
7574
constants <tt>regex_constants::match_default</tt> and <tt>regex_constants::format_default</tt>.</ins>
7675
</p></blockquote>
76+
</note>
77+
78+
<note>
79+
2011 Bloomington
80+
</note>
81+
82+
<p>
83+
It appears the key problem is the phrasing of the bitmask requirements. Jeremiah supplies updated wording.
84+
</p>
85+
86+
<p>
87+
Pete Becker has also provided an alternative resolution.
88+
</p>
89+
90+
<p>
91+
Ammend <sref ref="[bitmask.types]"/>:
92+
</p>
93+
<p>
94+
Change the list of values for "enum bit mask" in p2 from
95+
</p>
96+
<p>
97+
<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>.
98+
</p>
99+
<p>
100+
to
101+
</p>
102+
<p>
103+
<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>.
104+
</p>
105+
<p>
106+
Here, the names <i>C0</i>, <i>C1</i>, etc. represent <i>bitmask elements</i> for this particular
107+
bitmask type. All such <ins>non-zero</ins> elements have distinct values such that, for any pair
108+
<i>Ci</i> and <i>Cj</i> <ins>where <i>i</i> != <i>j</i></ins>, <del><i>Ci &amp; Ci</i> is nonzero
109+
and</del> <i>Ci &amp; Cj</i> is zero.
110+
</p>
111+
<p>
112+
Change bullet 3 of paragraph 4:
113+
</p>
114+
<p>
115+
<del>The</del><ins>A non-zero</ins> value Y is set in the object X if the expression X &amp; Y is nonzero.
116+
</p>
117+
</discussion>
118+
119+
<resolution>
120+
<p>
121+
Ammend <sref ref="[bitmask.types]"/> p3:
122+
</p>
123+
<p>
124+
Here, the names <i>C0</i>, <i>C1</i>, etc. represent <i>bitmask elements</i> for this particular
125+
bitmask type. All such elements have distinct<ins>, non-zero</ins> values such that, for any pair
126+
<i>Ci</i> and <i>Cj</i> <ins>where <i>i</i> != <i>j</i>,</ins> <i>Ci &amp; Ci</i> is nonzero
127+
and <i>Ci &amp; Cj</i> is zero. <ins>Additionally, the value 0 is used to represent an
128+
<i>empty bitmask</i>, in which no bitmask elements are set.</ins>
129+
</p>
130+
131+
<p>
132+
Add the following sentence to <sref ref="[re.matchflag]"/> paragraph 1:
133+
</p>
134+
<blockquote><p>
135+
1 The type <tt>regex_constants::match_flag_type</tt> is an implementation-defined bitmask type (17.5.2.1.3).
136+
<ins>The constants of that type, except for <tt>match_default</tt> and <tt>format_default</tt>, are bitmask
137+
elements. The <tt>match_default</tt> and <tt>format_default</tt> constants are empty bitmasks.</ins> Matching
138+
a regular expression against a sequence of characters [first,last) proceeds according to the rules of the
139+
grammar specified for the regular expression object, modified according to the effects listed in Table 136
140+
for any bitmask elements set.
141+
</p></blockquote>
77142
</resolution>
78143

79144
</issue>

‎xml/issue1521.xml‎

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@
33
<!ENTITY nbsp "&#160;">
44
] >
55

6-
<issue num="1521" status="Deferred">
6+
<issue num="1521" status="NAD Future">
77
<title>Requirements on internal pointer representations in containers</title>
88
<section><sref ref="[container.requirements.general]"/></section>
99
<submitter>Mike Spertus</submitter>
@@ -48,6 +48,16 @@ in the pre-Batavia mailing.
4848

4949
<p>Deferred</p>
5050

51+
<note>
52+
2011 Batavia
53+
</note>
54+
55+
<p>
56+
This may be an issue, but it is not clear. We want to gain a few years experience
57+
with the C++11 allocator model to see if this is already implied by the existing
58+
specification.
59+
</p>
60+
5161
</discussion>
5262

5363
<resolution>

‎xml/issue2005.xml‎

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@
33
<!ENTITY nbsp "&#160;">
44
] >
55

6-
<issue num="2005" status="Open">
6+
<issue num="2005" status="Review">
77
<title><tt>unordered_map::insert(T&amp;&amp;)</tt> protection should apply to <tt>map</tt> too</title>
88
<section><sref ref="[map.modifiers]"/><sref ref="[multimap.modifiers]"/>
99
<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
129129
</note>
130130

131131
<p>
132-
Move back to open.
133132
The effects of these inserts can be concisely stated in terms of emplace().
134133
Also, the correct term is "EmplaceConstructible", not "constructible".
135-
New wording by Pablo.
134+
</p>
135+
<p>
136+
New wording by Pablo, eliminating duplicate requirements already implied by the effects clause. Move to Review.
136137
</p>
137138

138139
</discussion>

0 commit comments

Comments
 (0)