@@ -73,9 +73,7 @@ to simply
73
73
there is no effect on the forward_list"
74
74
</p >
75
75
76
- </discussion >
77
-
78
- <resolution >
76
+ <superseded >
79
77
<p >This wording is relative to <paper num =" n4988" />.</p >
80
78
81
79
<ol >
@@ -97,6 +95,47 @@ there <del>shall be</del> <ins>is</ins> no effect
97
95
</li >
98
96
</ol >
99
97
98
+ </superseded >
99
+
100
+ <note >2024-10-09; LWG suggested improved wording</note >
101
+ <p >
102
+ The proposed resolution potentially mandates a change to `resize` when
103
+ increasing the size, requiring implementations to "roll back" earlier
104
+ insertions if a later one throws, so that the size is left unchanged.
105
+ It appears that all of libstdc++, libc++ and MSVC already do this.
106
+ </p >
107
+
108
+ </discussion >
109
+
110
+ <resolution >
111
+ <p >This wording is relative to <paper num =" n4988" />.</p >
112
+
113
+ <ol >
114
+ <li >
115
+ <p >Change <sref ref =" [forward.list.modifiers]" /> as indicated:</p >
116
+ <blockquote >
117
+ <del >
118
+ None of the overloads of `insert_after` shall
119
+ affect the validity of iterators and references,
120
+ and `erase_after` shall invalidate
121
+ only iterators and references to the erased elements.
122
+ </del >
123
+ <ins >The member functions in this subclause do not
124
+ affect the validity of iterators and references when inserting elements,
125
+ and when erasing elements invalidate iterators and references
126
+ to the erased elements only.
127
+ </ins >
128
+ If an exception is thrown
129
+ <del >during `insert_after`</del >
130
+ <ins >by any of these member functions</ins >
131
+ there <del >shall be</del > <ins >is</ins > no effect
132
+ <ins >on the container</ins >.
133
+ </blockquote >
134
+
135
+ </li >
136
+ </ol >
137
+
138
+
100
139
</resolution >
101
140
102
141
</issue >
0 commit comments