Document number:  PL22.16 10/0214 = WG21 N3224
Date:  2010-11-29
Reply to:  William M. Miller
 Edison Design Group, Inc.
 wmm@edg.com

 Beman Dawes
 bdawes@acm.org









C++ FCD Comment Status

Rev. 4

This document summarizes the status of WG21 as of the conclusion of the November, 2010 (Batavia) meeting in addressing National Body comments on Final Committee Draft document N3092.

In total, 573 comments were received. To date, 300 have been accepted as proposed, 93 have been accepted with modifications, 101 have been rejected, and 79 remain to be addressed. The detailed breakdown:

This document consists of three tables. The first is a table of contents, listing each issue by National Body and comment number and giving its current status. The second is a list of all as-yet unresolved comments, sorted by the responsible party. The third is a comprehensive listing of all the comments received in the same order and with roughly the same organization as in document N3102; the “Disposition” field gives the response, as well as any explanatory comments provided by the responsible party.


SORTED LISTING OF COMMENTS:

In the following table, the “Date” field represents the date on which the Committee affirmed the listed disposition.

ID Responsible Disposition Date Issue Document
CA 1 LWG     1461   
CA 2        
CA 3 CWG        
CA 4 LWG modified  2010-11-13  1449   
CA 5 CWG accepted    1218   
CA 6 CWG rejected    1162   
CA 7 CWG rejected    1157   
CA 8 CWG accepted  2010-11-13    N3196 
CA 9 LWG accepted  2010-11-13  1442  N3196 
CA 10 LWG rejected  2010-08-07     
CA 11 CWG accepted  2010-11-13    N3196 
CA 12 CWG accepted    1176   
CA 13 CWG accepted  2010-11-13    N3196 
CA 14 CWG modified  2010-11-13    N3196 
CA 15 CWG accepted  2010-11-13  1177  N3196 
CA 16 editor accepted       
CA 17 editor rejected       
CA 18 CWG accepted  2010-11-13    N3196 
CA 19 CWG accepted  2010-11-13    N3196 
CA 20 CWG accepted  2010-11-13    N3196 
CA 21 LWG     1459   
CA 22 CWG rejected  2010-11-13    N3196 
CA 23 LWG modified  2010-11-13    N3193 
CA 24 CWG accepted  2010-11-13  1105  N3146 
CH 1 accepted       
CH 2 CWG rejected  2010-11-13    N3196 
CH 3 CWG rejected       
CH 4 CWG accepted  2010-11-13  1062   
CH 5 editor accepted       
CH 6 CWG rejected       
CH 7 CWG rejected       
CH 8 editor        
CH 9 CWG modified  2010-11-13  1147  N3204 
CH 10 CWG rejected       
CH 11 editor rejected       
CH 12 editor accepted       
CH 13 editor accepted       
CH 14 editor accepted       
CH 15 LWG     1421, 1350   
CH 16 LWG modified  2010-11-13  1351  N3148 
CH 17 LWG modified  2010-11-13  1352  N3195 
CH 18 LWG     1353   
CH 19 LWG     1364   
CH 20 LWG rejected  2010-08-07     
CH 21 LWG modified  2010-11-13  1412  N3191 
CH 22 LWG modified  2010-11-13  1455, 1454  N3193 
CH 23 LWG     1475   
CH 24 LWG     1486   
CH 25 LWG     1487   
CH 26 LWG modified  2010-11-13  1489  N3197 
CH 27 LWG modified  2010-11-13  1490  N3197 
CH 28 LWG modified  2010-11-13  1496  N3191 
CH 29 LWG modified  2010-11-13  1498  N3191 
CH 30 LWG     1497   
CH 31 editor rejected       
CH 32 LWG accepted  2010-08-07  1500   
CH 33 editor accepted       
CH 34 editor accepted       
CH 35 LWG     1503   
CH 36 LWG modified  2010-11-13  1513  N3188 
DE 1 accepted       
DE 2 CWG rejected       
DE 3 CWG accepted  2010-11-13  1106   
DE 4 CWG accepted  2010-11-13  1113   
DE 5 editor accepted       
DE 7 CWG rejected       
DE 8 CWG accepted  2010-11-13  1125  N3218 
DE 9 CWG rejected    1110   
DE 10 CWG accepted  2010-11-13  1138   
DE 11 CWG accepted  2010-11-13  1148   
DE 12 CWG accepted  2010-11-13  1155   
DE 13 CWG accepted  2010-11-13  1169   
DE 14 LWG modified  2010-11-13  1366  N3189 
DE 15 LWG modified  2010-11-13  1378  N3140 
DE 16 LWG modified  2010-11-13  1380  N3140 
DE 17 LWG modified  2010-11-13  1390  N3142 
DE 18 LWG modified  2010-11-13  1391  N3142 
DE 19 LWG modified  2010-08-07  1394  N3047 
DE 20 LWG modified  2010-11-13  1411  N3191 
DE 21 LWG accepted  2010-08-07  1416   
DE 22 LWG     1421   
DE 23 LWG accepted  2010-08-07  1483   
ES 1 LWG rejected  2010-08-07     
ES 2 LWG rejected  2010-08-07     
ES 3 LWG accepted  2010-08-07     
FI 1 CWG accepted    1135   
FI 2 CWG accepted    1136   
FI 3 CWG accepted    1137   
FI 4 CWG accepted    1145   
FI 5 CWG accepted    1149   
FI 6 CWG accepted  2010-11-13  1012   
FI 7 CWG rejected       
FI 8 CWG rejected       
FI 9 CWG rejected       
FI 10 CWG accepted  2010-08-07  924   
FI 11 editor        
FI 12 LWG rejected  2010-08-07     
FI 13 editor accepted       
FI 14 editor accepted       
FI 15 CWG rejected       
FI 16 CWG rejected       
FI 17 CWG modified  2010-11-13  1123  N3204 
FI 18 LWG rejected  2010-11-132010-08-07    N3142 
FI 19 CWG rejected    1118   
GB 1 editor accepted       
GB 2 editor        
GB 3 editor accepted       
GB 4 editor accepted       
GB 5 editor accepted       
GB 6 CWG accepted  2010-11-13  1102   
GB 7 CWG accepted  2010-11-13  1173   
GB 8 CWG accepted  2010-11-13    N3196 
GB 9 CWG accepted    1176   
GB 10 CWG accepted  2010-11-13    N3196 
GB 11 CWG accepted  2010-11-13    N3196 
GB 12 CWG accepted  2010-11-13    N3196 
GB 13        
GB 14 CWG rejected       
GB 15 CWG rejected  2010-11-13    N3196 
GB 16 editor rejected       
GB 17 editor accepted       
GB 18 CWG accepted  2010-11-13  1114   
GB 19 editor accepted       
GB 20 editor accepted       
GB 21 CWG rejected       
GB 22 CWG accepted    1120   
GB 23 editor accepted       
GB 24 CWG accepted  2010-11-13  1122   
GB 25 CWG accepted  2010-11-13  1126   
GB 26 CWG accepted    1127   
GB 27 CWG rejected       
GB 28 editor accepted       
GB 29 CWG modified  2010-11-13  1129   
GB 30 CWG rejected       
GB 31 CWG accepted  2010-11-13  1115  N3190 
GB 32 CWG rejected    1132   
GB 33 CWG modified    1130   
GB 34 editor accepted       
GB 35 editor accepted       
GB 36 editor accepted       
GB 37 CWG accepted  2010-11-13  1138   
GB 38 CWG rejected    675   
GB 39 CWG accepted  2010-11-13  1146   
GB 40 CWG modified  2010-11-13  1147  N3204 
GB 41 CWG accepted  2010-11-13  1146   
GB 42 editor accepted       
GB 43 CWG accepted  2010-11-13  1160   
GB 44 CWG accepted  2010-11-13  1161   
GB 45 CWG rejected    1166   
GB 46 CWG accepted    1167   
GB 47 CWG accepted  2010-11-13  1168   
GB 48 editor accepted       
GB 49 CWG rejected       
GB 50 LWG modified  2010-11-13  1355  N3142 
GB 51 LWG modified  2010-11-13  1356  N3142 
GB 52 LWG modified  2010-11-13  1354   
GB 53 LWG modified  2010-11-13  1357  N3110 
GB 54 editor accepted       
GB 55 LWG     1358   
GB 56 LWG rejected  2010-11-13  1359   
GB 57 LWG accepted  2010-08-07  1360   
GB 58 LWG rejected  2010-11-13  1361   
GB 59 editor modified       
GB 60 LWG modified  2010-11-13  1344  N3148 
GB 61 LWG     1345   
GB 62 LWG modified  2010-11-13  1346  N3195 
GB 63 LWG modified  2010-11-13  1347  N3155 
GB 64 LWG     1348   
GB 65 LWG     1349   
GB 66 editor accepted       
GB 68 LWG accepted  2010-08-07  1363   
GB 69 editor accepted       
GB 70 LWG rejected       
GB 71 LWG modified  2010-11-13  1365  N3189 
GB 72 LWG accepted  2010-08-07  1367   
GB 73 LWG modified  2010-11-13  1368   
GB 74 LWG     1369   
GB 75 LWG     1371   
GB 76 LWG accepted  2010-08-07  1372   
GB 77 editor accepted       
GB 78 LWG rejected  2010-08-07     
GB 79 LWG rejected  2010-11-13  1373   
GB 80 LWG rejected  2010-08-07     
GB 81 editor accepted       
GB 82 editor accepted       
GB 84 editor accepted       
GB 85 LWG modified  2010-08-07  1381   
GB 86 LWG rejected  2010-08-07     
GB 87 LWG accepted  2010-08-07  1387   
GB 88 LWG     1385   
GB 89 LWG modified  2010-11-13  1389  N3210 
GB 90 editor rejected       
GB 91 editor rejected  2010-11-13    N3142 
GB 92 LWG modified  2010-11-13  1393  N3142 
GB 93 LWG rejected  2010-08-07     
GB 94 editor        
GB 95 LWG modified  2010-11-13  1397  N3198 
GB 96 LWG rejected  2010-11-13  1398   
GB 97 LWG rejected  2010-08-07     
GB 98 editor        
GB 99 LWG     1401   
GB 100 LWG accepted  2010-08-07  1402   
GB 101 editor accepted       
GB 102 editor rejected       
GB 103 LWG     1408   
GB 104 editor accepted       
GB 105 editor rejected       
GB 106 LWG rejected  2010-08-07     
GB 107 LWG modified  2010-11-13  1410  N3191 
GB 108 editor        
GB 109 LWG modified  2010-11-13  1414   
GB 110 LWG rejected  2010-08-07     
GB 111 editor        
GB 112 LWG accepted  2010-08-07  1417   
GB 113 LWG     1418   
GB 114 editor modified       
GB 115 LWG     1420   
GB 116 editor accepted       
GB 117 editor        
GB 118 LWG rejected  2010-11-13  1422   
GB 119 LWG modified  2010-11-13  1433   
GB 120 LWG modified  2010-11-13  1435   
GB 121 LWG modified  2010-11-13  1436   
GB 122 LWG     1442, 1443   
GB 123 LWG modified  2010-11-13  1414, 1444   
GB 124 LWG     1448   
GB 125 LWG     1452   
GB 126 LWG modified  2010-11-13  1453  N3158 
GB 127 LWG     1450   
GB 128 LWG modified  2010-11-13  1455, 1454  N3193 
GB 129 LWG     1456   
GB 130 LWG     1457   
GB 131 LWG     1458   
GB 132 LWG modified  2010-11-13  1462  N3193 
GB 133 LWG modified  2010-11-13  1469  N3193 
GB 134 editor accepted       
GB 135 LWG     1477   
GB 136 LWG     1478   
GB 137 LWG     1480   
GB 138 LWG modified  2010-11-13  1481  N3197 
GB 139 editor accepted       
GB 140 editor accepted       
GB 141 editor accepted       
GB 142 LWG accepted  2010-11-13  1516   
ITTF 1 editor accepted       
ITTF 2 editor accepted       
ITTF 3 editor accepted       
ITTF 4 editor accepted       
ITTF 5 editor accepted       
ITTF 6 editor accepted       
ITTF 7 editor        
JP 1 CWG accepted  2010-11-13  1117   
JP 2 CWG rejected    1124   
JP 3 LWG accepted  2010-08-07  1399   
JP 4 LWG accepted  2010-08-07  1400   
JP 5 LWG rejected  2010-11-13  1406   
JP 6 LWG accepted  2010-08-07  1423   
JP 7 LWG accepted  2010-08-07     
JP 8 LWG accepted  2010-08-07  1425   
JP 9 LWG accepted  2010-08-07  1426   
JP 10 LWG accepted  2010-08-07  1427   
JP 11 LWG accepted  2010-08-07  1428   
JP 12 LWG accepted  2010-08-07  1429   
JP 13 LWG accepted  2010-08-07  1430   
JP 14 LWG rejected  2010-08-07     
JP 15 editor accepted       
JP 16 editor accepted       
JP 17 editor accepted       
JP 18 editor accepted       
JP 19 editor accepted       
JP 20 editor accepted       
JP 21 editor accepted       
JP 22 editor accepted       
JP 23 editor accepted       
JP 24 editor accepted       
JP 25 editor accepted       
JP 26 editor accepted       
JP 27 editor accepted       
JP 28 editor modified       
JP 29 editor modified       
JP 30 editor accepted       
JP 31 editor accepted       
JP 32 LWG accepted  2010-11-13  1395   
JP 33 editor accepted       
JP 34 editor accepted       
JP 35 editor accepted       
JP 36 editor accepted       
JP 37 editor accepted       
JP 38 editor accepted       
JP 39 editor accepted       
JP 40 editor accepted       
JP 41 editor accepted       
JP 42 editor accepted       
JP 43 editor accepted       
JP 44 editor accepted       
JP 45 editor accepted       
JP 46 editor accepted       
JP 47 editor accepted       
JP 48 editor accepted       
JP 49 editor accepted       
JP 50 editor accepted       
JP 51 editor accepted       
JP 52 editor accepted       
JP 53 editor accepted       
JP 54 editor accepted       
JP 55 editor accepted       
JP 56 editor accepted       
JP 57 editor accepted       
JP 58 editor accepted       
JP 59 editor accepted       
JP 60 editor accepted       
JP 61 editor accepted       
JP 62 editor accepted       
JP 63 editor accepted       
JP 64 editor accepted       
JP 65 editor accepted       
JP 67 editor rejected       
JP 68 editor modified       
JP 69 editor accepted       
JP 70 editor accepted       
JP 71 editor accepted       
JP 72 editor accepted       
JP 73 editor accepted       
JP 74 editor accepted       
JP 75 editor accepted       
JP 76 editor accepted       
JP 77 editor accepted       
JP 78 editor accepted       
JP 79 editor accepted       
JP 80 editor accepted       
JP 81 editor accepted       
JP 82 editor accepted       
JP 83 editor accepted       
JP 84 editor accepted       
JP 85 LWG accepted  2010-08-07  1403   
JP 86 editor accepted       
JP 87 editor accepted       
JP 88 editor accepted       
JP 89 editor accepted       
JP 90 editor accepted       
JP 91 editor modified       
JP 92 editor accepted       
JP 93 editor accepted       
JP 94 editor accepted       
JP 95 editor accepted       
JP 96 editor accepted       
JP 97 editor accepted       
JP 98 editor accepted       
JP 99 editor accepted       
JP 100 editor accepted       
JP 101 editor accepted       
JP 102 editor accepted       
JP 103 editor accepted       
JP 104 editor accepted       
JP 105 editor accepted       
JP 106 editor accepted       
JP 107 editor accepted       
JP 108 editor accepted       
JP 109 editor accepted       
JP 110 editor accepted       
RU 1 editor accepted       
RU 2 editor accepted       
RU 3 editor accepted       
RU 4 editor accepted       
RU 5 editor accepted       
US 1        
US 2 accepted       
US 3 CWG accepted  2010-11-13    N3209 
US 4 editor accepted       
US 5 editor rejected       
US 6 editor accepted       
US 7 editor        
US 8 CWG rejected       
US 9 CWG accepted  2010-11-13    N3196 
US 10 CWG rejected  2010-11-13    N3196 
US 11 CWG accepted  2010-11-13    N3196 
US 12 CWG accepted  2010-11-13    N3196 
US 13 CWG accepted  2010-11-13  1103   
US 14 CWG accepted  2010-11-13  1103   
US 15 CWG accepted  2010-11-13  1104   
US 16 CWG accepted       
US 17 CWG accepted  2010-11-13  1107   
US 18 CWG     1108   
US 19 CWG accepted  2010-11-13  1109  N3214 
US 20 editor accepted       
US 21 editor accepted       
US 22 CWG rejected    1110   
US 23 CWG accepted    1111   
US 24 CWG accepted  2010-11-13  1112   
US 25 CWG accepted    1115   
US 26 CWG rejected       
US 27 CWG accepted    1116   
US 28 CWG rejected       
US 29 CWG rejected    974   
US 30 CWG rejected    975   
US 31 CWG accepted    1022   
US 32 CWG accepted  2010-11-13  1119   
US 33 CWG accepted  2010-11-13  1121   
US 34        
US 35 CWG accepted       
US 36 CWG rejected       
US 37 CWG rejected       
US 38 CWG accepted  2010-11-13    N3196 
US 39 CWG accepted  2010-11-13  1128   
US 40 CWG accepted  2010-11-13  1130   
US 41 CWG accepted  2010-11-13  1131   
US 42 CWG rejected       
US 43 editor accepted       
US 44 CWG accepted  2010-11-13  1133  N3206 
US 45 editor accepted       
US 46 CWG rejected       
US 47 CWG modified  2010-11-13  1134   
US 48 CWG accepted  2010-11-13  1138   
US 49 CWG accepted  2010-11-13  1139   
US 50 CWG accepted    1140   
US 51 CWG     1141   
US 52 CWG accepted  2010-11-13  1142   
US 53 CWG     1143   
US 54 CWG accepted       
US 55 CWG rejected       
US 56 CWG accepted  2010-11-13  1144   
US 57 CWG accepted       
US 58 editor rejected       
US 59 CWG accepted       
US 60 CWG accepted       
US 61 editor accepted       
US 62 CWG accepted  2010-11-13  1051   
US 63 CWG accepted  2010-11-13  1064   
US 64 CWG accepted  2010-11-13  1066   
US 65 CWG     1150   
US 66 CWG accepted    1151   
US 67 CWG modified  2010-11-13  1152   
US 68 CWG accepted  2010-11-13  1153   
US 69 CWG accepted  2010-11-13  1154   
US 70 CWG accepted  2010-11-13  1156   
US 71 accepted       
US 72 CWG accepted       
US 73 CWG accepted  2010-11-13  1158   
US 74 CWG accepted  2010-11-13  1159   
US 75 CWG rejected       
US 76 CWG rejected    1163   
US 77 CWG accepted  2010-11-13  1164   
US 78 CWG accepted  2010-11-13  1165   
US 79 CWG rejected       
US 80 LWG modified  2010-11-13  1347  N3155 
US 81 editor modified       
US 82 LWG modified  2010-11-13  1362   
US 83 editor accepted       
US 84 LWG modified  2010-11-13  1370   
US 85 LWG     1374   
US 86 editor accepted       
US 87 LWG     1375   
US 88 LWG rejected  2010-11-13  1376   
US 89 editor accepted       
US 90 LWG modified  2010-11-13  1377  N3143 
US 91 LWG modified  2010-11-13  1377  N3143 
US 92 LWG rejected  2010-08-07     
US 93 rejected  2010-08-07     
US 94 editor accepted       
US 95 LWG modified  2010-11-13  1379  N3140 
US 96 LWG modified  2010-11-13  1382  N3140 
US 97 LWG modified  2010-11-13  1383  N3140 
US 98 LWG accepted  2010-08-07  1384   
US 99 LWG accepted  2010-08-07  1386   
US 100 LWG accepted  2010-08-07  1388   
US 101 LWG rejected  2010-08-07     
US 102 LWG modified  2010-11-13  1392  N3123 
US 103 LWG rejected  2010-08-07     
US 104 LWG     1396   
US 105 LWG rejected  2010-08-07     
US 106 LWG modified  2010-11-13  1404   
US 107 LWG accepted  2010-08-07  1405   
US 108 LWG modified  2010-08-07  1407  N3109 
US 109 editor accepted       
US 110 LWG rejected  2010-08-07     
US 111 LWG modified  2010-11-13  1409  N3191 
US 112 LWG     1413   
US 113 LWG rejected  2010-08-07     
US 114 LWG modified  2010-08-07    N3108 
US 115 editor modified  2010-11-13    N3173 
US 116 editor rejected       
US 117 LWG accepted  2010-08-07  1419   
US 118 LWG rejected  2010-08-07     
US 119 LWG rejected  2010-08-07     
US 120 LWG accepted  2010-08-07  1431   
US 121 LWG modified  2010-11-13  1432   
US 122 LWG modified  2010-08-07  1434  N3106 
US 123 editor        
US 124 LWG accepted  2010-11-13  1437   
US 125 editor        
US 126 LWG     1438   
US 127 editor        
US 128 editor        
US 129 editor        
US 130 editor        
US 131 editor        
US 132 editor        
US 133 editor        
US 134 LWG accepted  2010-11-13  1439   
US 135 LWG accepted  2010-11-13  1440   
US 136 LWG accepted  2010-08-07  1441   
US 137 LWG modified  2010-11-13  1445  N3168 
US 138 LWG rejected  2010-11-13  1446  N3179 
US 139 LWG modified  2010-11-13  1447  N3168 
US 140 LWG rejected  2010-08-07     
US 141 LWG     1451   
US 142 editor accepted       
US 143 editor accepted       
US 144 editor accepted       
US 145 editor accepted       
US 146 editor accepted       
US 147 editor accepted       
US 148 editor rejected       
US 149 editor accepted       
US 150 editor accepted       
US 151 editor accepted       
US 152 editor rejected       
US 153 editor rejected       
US 154 LWG     1460   
US 155 editor accepted       
US 156 editor accepted       
US 157 LWG modified  2010-11-13  1463  N3193 
US 158 editor accepted       
US 159 editor accepted       
US 160 LWG modified  2010-11-13  1464  N3193 
US 161 LWG modified  2010-11-13  1465  N3193 
US 162 LWG modified  2010-11-13  1466  N3193 
US 163 LWG modified  2010-11-13  1467  N3193 
US 164 LWG modified  2010-11-13  1468  N3193 
US 165 LWG     1470   
US 166 editor accepted       
US 167 editor rejected       
US 168 LWG accepted  2010-11-13  1471  N3196 
US 169 editor rejected       
US 170 editor rejected       
US 171 LWG accepted  2010-11-13  1472  N3196 
US 172 LWG rejected  2010-11-13  1473   
US 173 editor accepted       
US 174 editor rejected       
US 175 LWG     1474   
US 176 editor rejected       
US 177 LWG     1476   
US 178 editor modified       
US 179 LWG     1479   
US 180 editor accepted       
US 181 LWG modified  2010-11-13  1482  N3191 
US 182 LWG rejected  2010-08-07     
US 183 LWG rejected  2010-11-13  1484   
US 184 LWG     1485   
US 185 LWG rejected  2010-11-13  1488   
US 186 LWG modified  2010-11-13  1491  N3209 
US 187 editor modified       
US 188 LWG modified  2010-11-13  1492  N3197 
US 189 LWG rejected  2010-11-13  1493   
US 190 LWG     1494   
US 191 LWG modified  2010-11-13  1495  N3191 
US 192 editor accepted       
US 193 LWG rejected  2010-11-13  1499   
US 194 LWG modified  2010-11-13  1501  N3192 
US 195 LWG     1502   
US 196 LWG     1504   
US 197 LWG     1505   
US 198 LWG accepted  2010-08-07  1506   
US 199 LWG     1507   
US 200 editor accepted       
US 201 LWG modified  2010-11-13  1508  N3194 
US 202 LWG modified  2010-11-13  1509  N3194 
US 203 LWG modified  2010-11-13  1510  N3194 
US 204 LWG modified  2010-11-13  1511  N3194 
US 205 LWG modified  2010-11-13  1512  N3194 
US 206 editor accepted       
US 207 LWG     1514   
US 208 LWG     1515   

UNRESOLVED COMMENTS:

The following table lists the comments for which no resolution has yet been proposed.

ID Responsible Issue
CA 2  
GB 13  
US 1  
US 34  
CA 3 CWG  
US 18 CWG 1108 
US 51 CWG 1141 
US 53 CWG 1143 
US 65 CWG 1150 
CH 8 editor  
FI 11 editor  
GB 2 editor  
GB 94 editor  
GB 98 editor  
GB 108 editor  
GB 111 editor  
GB 117 editor  
ITTF 7 editor  
US 7 editor  
US 123 editor  
US 125 editor  
US 127 editor  
US 128 editor  
US 129 editor  
US 130 editor  
US 131 editor  
US 132 editor  
US 133 editor  
CA 1 LWG 1461 
CA 21 LWG 1459 
CH 15 LWG 1421, 1350 
CH 18 LWG 1353 
CH 19 LWG 1364 
CH 23 LWG 1475 
CH 24 LWG 1486 
CH 25 LWG 1487 
CH 30 LWG 1497 
CH 35 LWG 1503 
DE 22 LWG 1421 
GB 55 LWG 1358 
GB 61 LWG 1345 
GB 64 LWG 1348 
GB 65 LWG 1349 
GB 74 LWG 1369 
GB 75 LWG 1371 
GB 88 LWG 1385 
GB 99 LWG 1401 
GB 103 LWG 1408 
GB 113 LWG 1418 
GB 115 LWG 1420 
GB 122 LWG 1442, 1443 
GB 124 LWG 1448 
GB 125 LWG 1452 
GB 127 LWG 1450 
GB 129 LWG 1456 
GB 130 LWG 1457 
GB 131 LWG 1458 
GB 135 LWG 1477 
GB 136 LWG 1478 
GB 137 LWG 1480 
US 85 LWG 1374 
US 87 LWG 1375 
US 104 LWG 1396 
US 112 LWG 1413 
US 126 LWG 1438 
US 141 LWG 1451 
US 154 LWG 1460 
US 165 LWG 1470 
US 175 LWG 1474 
US 177 LWG 1476 
US 179 LWG 1479 
US 184 LWG 1485 
US 190 LWG 1494 
US 195 LWG 1502 
US 196 LWG 1504 
US 197 LWG 1505 
US 199 LWG 1507 
US 207 LWG 1514 
US 208 LWG 1515 

ALL COMMENTS

ID Ref Comment Proposed Resolution Owner Issue Disposition
ITTF 1 General   The ISO/IEC headers and footers should appear at the top and bottom of every page.   Insert the ISO/IEC headers and footers at the top and bottom of every page.   editor    ACCEPTED  
US 1 1-30   It appears that the C committee could possibly make some changes for C1X that we may still want to follow for C++0X to avoid gratuitous incompatibilities.   Make any appropriate changes to avoid unnecessary incompatibilities with C1X resulting from changes to the WG14 C standard draft.        
US 2 1-30   The active issues identified in the CWG and LWG issues lists as if the date that the FCD was published (N3083 and N3087) must be addressed and appropriate action taken.   Appropriate action would include making changes to the FCD, identifying an issue as not requiring a change to the FCD, or deferring an issue to a later draft or a later standard.       ACCEPTED  
DE 1 1 through 15   Consider applying the resolutions of the active core issues in Ready status (see WG21 N3083).         ACCEPTED  
CH 1 all   The issues on the issues lists (WG21 N3083 and N3087) shall be addressed before the standard becomes final.         ACCEPTED  
US 3 1 - 29   The threading model does not make basic guarantees needed to write correct programs. We should not repeat the error that POSIX made in early standards (and later corrected).   Add requirements that all no-blocked threads will (however slowly) make progress and that all visible side effects will (eventually) be seen by other threads. Possibly use the word “should” if an absolute requirement is impossible.   CWG    ACCEPTED

See paper N3209 
US 4 all ¶ all   Many identifiers are hyphenated and broken across line boundaries. As a consequence, searching for the identifier fails.   Protect all identifiers against hyphenation.   editor    ACCEPTED  
US 5 all ¶ all   The word "object" often copies as "ob ject".     editor    REJECTED

Some PDF viewers do this. Don't know why, or how to avoid it.  
US 6 various ¶ various   ~ (U+007E) is sometimes replaced with ∼ (U+223C), causing cut and paste from the standard to fail, notably in 2.14.5.   Use U+007E consistently   editor    ACCEPTED  
US 7 various ¶ various   ' (U+0027) is consistently replaced with ’ (U+2019), causing cut and paste to fail. This is also an issue with the 1998 standard.   Use U+0027 consistently in code samples (i.e. monospace font)   editor     
GB 1 1.1 ¶ 2   The C99 standard supports inline functions, so this should not be listed as a distinguishing feature of C++.   strike "inline functions" from the list of C++ 'additional facilities'   editor    ACCEPTED  
GB 2 1.2   In [intro.refs] the spec references ISO/IEC 9945:2003 even though a later revision, ISO/IEC 9945:2008 has already been released: http://www.iso.org/iso/catalogue_detail.htm?csnumber=50 516   The section should be updated to reference the latest version.
In addition, since POSIX is a registered trademark of the IEEE, the spec should use the registered trademark (R) symbol wherever it references it. Alternatively, it can refer to ISO/IEC 9945.  
editor     
ITTF 2 1.2   The introductory text to the Normative references is not correct.   Delete the current introductory text to the Normative references and replace with the following:
“The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.”  
editor    ACCEPTED  
ITTF 3 1.3   The title to the subclause does not accurately reflect the content.   Change the title to “Terms and definitions”.   editor    ACCEPTED  
ITTF 4 1.3   3.1 of the ISO/IEC Directives, Part 2, states that the following introductory wording shall be used where all terms and definitions are given the document itself: “For the purposes of this document, the following terms and definitions apply.”   Change the introductory text to:
“For the purposes of this document, the following terms and definitions apply.”  
editor    ACCEPTED  
ITTF 5 1.3   D.1.5.3 of the ISO/IEC Directives, Part 2 states that the form of a definition shall be such that it can replace the term in context.   Delete the definite or indefinite article at the beginning of each definition.
Redraft definitions 1.3.11 and 1.3.13 so that they can replace the term in context (i.e. they should not be more than one sentence).  
editor    ACCEPTED  
ITTF 6 1.3   D.3.1 of the ISO/IEC Directives, Part 2, states that the definition shall not be followed by a full stop.   Remove the full stops at the end of the definitions.   editor    ACCEPTED  
ITTF 7 1.3   D.3.9 of the ISO/IEC Directives, Part 2, provides examples on how to present examples and notes to terms and definitions. The examples and notes to the terms and definitions are not presented in accordance with D.3.9 of the ISO/IEC Directives, Part 2.   Redraft the notes and examples to the terms and definitions in accordance with D.3.9 of the ISO/IEC Directives, Part 2.   editor     
GB 3 1.3 ¶ 1   The library stretches out to clause 30 now, and the terms in 17.3 should cover them too.   Update reference to clause 27 to say clause 30.   editor    ACCEPTED  
JP 15 1.3 ¶ 1   There is a description, "17.3 defines additional terms that are used only in Clauses 17 through 27 and Annex D.", but the terms defined in 17.3 are also used in Clauses 28 through 30, which are added recently. So the scope should be expanded to include them.   17.3 defines additional terms that are used only in Clauses 17 through 30 and Annex D.   editor    ACCEPTED  
GB 4 1.3.10   The phrase "catch clause" in the 2003 standard has become "catch Clause"   Change back the "catch clause"   editor    ACCEPTED  
RU 1 1.7 ¶ p.5, line 5 from end   Reference missed   Insert reference "(2.3)" after "basic execution character set"   editor    ACCEPTED  
GB 5 1.9 ¶ 3   The evaluation of function arguments are now indeterminately sequenced, rather than left completely unspecified, as part of the new language describing the memory model. A clearer example of unspecified behavior should be used here.   [Need to identify a better example to propose]   editor    ACCEPTED  
GB 6 1.9 ¶ 4   There are core issues surrounding the undefined behavior of dereferencing a null pointer. It appears the intent is that dereferencing *is* well defined, but using the result of the dereference will yield undefined behavior. This topic is too confused to be the reference example of undefined behavior, or should be stated more precisely if it is to be retained.   [Identify a better example of undefined behavior to propose]   CWG  1102  ACCEPTED  
CH 2 1.9 and 1.10   It's not clear whether relaxed atomic operations are observable behaviour.   Clarify it.   CWG    REJECTED

Normatively, the behavior is well-defined by 1.9p8. If the atomic object is volatile, then all operations on it are observable, otherwise not. Note that “observable” means “observable outside of the program.”

See paper N3196 
GB 7 1.9.6 ¶ p6   From a naive, first-time reader's point of view, 1.9.6 made me double take, as it seemed it could imply any signal would leave the program in an unspecified state after completing. I believe I understand the intent, but to clarify it, I'd change it to make it clear that the unspecified state applies only for the duration of the signal handler.   Change:
6 When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects which are neither of type volatile std::sig_atomic_t nor lock-free atomic objects (29.4) are unspecified, and the value of any object not in either of these two categories that is modified by the handler becomes undefined. to: 6 When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects which are neither of type volatile std::sig_atomic_t nor lock-free atomic objects (29.4) are unspecified for the duration of the signal handler, and the value of any object not in either of these two categories that is modified by the handler becomes undefined.  
CWG  1173  ACCEPTED

The reference should be 1.9 paragraph 6, not 1.9.6 (which does not exist).  
US 8 1.9 ¶ footnote 7   The footnote "Overloaded operators are never assumed to be associative or commutative." is either meaningless or overly restrictive.   Change the footnote to "Overloaded operators are assumed to be non-associative and noncommutative until proven otherwise.".   CWG    REJECTED

The statement involved is non-normative and is, in general, correct. An implementation can treat overloaded operators as associative or commutative only under the “as-if” rule, so the statement is clear enough.  
CA 23 1.10, 29 ¶ 1.10, 29   C1x has added new atomics C1x has added new atomics syntax, and in some cases new semantics and operations. C++0x needs to consider aligning with the new C1x atomics   Add back compatibility between C++0x and C1x atomics   LWG    ACCEPTED with MODIFICATIONS

See paper N3193 
CA 14 1.10p4 ¶ 1.10p4   Initialisation of atomics Add the following to 1.10p4: [ Note: There may be non-atomic writes to atomic objects, for example on initialization and reinitialization. - end note] Rationale: We believe the intent is that for any atomic there is a distinguished initialisation write, but that this need not happens-before all the other operations on that atomic - specifically so that the initialisation write might be non-atomic and hence give rise to a data race, and hence undefined behaviour, in examples such as this (from Hans):
atomic< atomic<int> * > p
f()                    |
{ atomic<int>x;        | W_na x
  p.store(&x,mo_rlx);  | W_rlx p=&x
}                      |
(where na is nonatomic and rlx is relaxed). We suspect also that no other mixed atomic/nonatomic access to the same location is intended to be permitted. The possibility of non-atomic writes on atomic objects is not mentioned in 1.10, and (before talking with Hans) we didn't realise it was intended, so we suggest adding the note above to clarify things.  
Add the following to 1.10p4:
[ Note: There may be non-atomic writes to atomic objects, for example on initialization and renitialization. - end note]  
CWG    ACCEPTED with MODIFICATIONS

The suggested update from US 168 was adopted.

See paper N3196 
CA 12 1.10p6 ¶ 1.10p6   The use of maximal in the definition of release sequence (proposed edit seems reasonable to Clark)
We suggest that 1.10p6 be changed to:
A release sequence from a release operation A on an atomic object M is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first operation is A, and every subsequent operation
- is performed by the same thread that performed the release, or
- is an atomic read-modify-write operation.
Rationale: The current wording of the standard suggests that release sequences are maximal with respect to sequence inclusion, i.e. that if there are two release operations in the modification order,
mod       mod
rel1----->rel2----->w
then [rel1;rel2;w] is the only release sequence, as the other candidate [rel2;w] is included in it. This interpretation precludes synchronizing with releases which have other releases sequenced-before them. We believe that the intention is actually to define the maximal release sequence from a particular release operation, which would admit both [rel1;rel2;w] and [rel2;w]. 
We suggest that 1.10p6 be changed to:
A release sequence from a release operation A on an atomic object M is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first operation is A, and every subsequent operation
- is performed by the same thread that performed the release, or
- is an atomic read-modify-write operation. 
CWG  1176  ACCEPTED  
US 9 1.10 ¶ para 4   The "operations on locks" do not provide synchronization, as locks are defined in Clause 30.   Change "operations on locks" to "locking operations".   CWG    ACCEPTED

See paper N3196 
CA 20 1.10p1 ¶ 1.10p1   Reading from the last element in a vsse? Paul wrote:
> If every element in a vsse happens-before a given value
> computation, then that value computation must return
> the value stored by the last element in the vsse.
We wrote:
We're not sure about that. Consider the following, with two relaxed writes to x on one thread that are not sequencedbefore related to each other (eg in different arguments to the same function), but are followed by a release/acquire on a different variable y to another thread that then reads x. We think the final read (e) could read from either (a) or (b), regardless of how (a) and (b) are related in modification order.
a:Wrlx x=1   b:Wrlx x=2
      \     /
     sb\   /sb
        \ /
        c:Wrel y-----------
                           \sw
                            \
                         d:Racq y
                             |
                             |sb
                             |
                         e:Rrlx x=?
| Paul> In that case IIRC, the standard does not specify
Paul> the order, but the code will be generated in some
Paul> order, and that arbitrary choice on the part of the
Paul> compiler will determine the modification order.
We agree that in a normal implementation (eg where the
argument evaluations are not spawned off to new threads - is that intended to be forbidden?), the two writes will indeed be ordered according to the generated-code order (and before the release fence), and hardware coherence will ensure that (e) reads the later one.
But in the draft standard as written, that execution is allowed - the draft doesn't currently impose that aspect of coherence. To make the example more concrete, if there were another thread with
c --sw--> f:Racq y --sb--> g:Rrlx x
then e and g could read different values.
Paul notes:
> But 1.10p1 says:
>
> A thread of execution (also known as a thread) is a
> single flow of control within a program, including
> the initial invocation of a specific top-level
> function, and recursively including every function
> invocation subsequently executed by the thread.
>
> This excludes the possibility of the implementation
> spawing off a new thread -unless- the implementation
> can make things appear as if there was only one thread.
> From this viewpoint, your example shows just how
> careful an implementation must be if it is to fully
> comply with this as-if rule.
We replied
>ok, thanks
to this, but in fact the situation is still unclear.
1.10p1 does indeed rule out the hypothetical implementation that we mentioned, but even if (a) and (b) would be ordered by any reasonable implementation, in terms of the concepts of the standard, that doesn't introduce a sequenced-before edge between (a) and (b).
It seems that Paul is assuming the individual memory accesses in function arguments are indeterminately sequenced rather than unsequenced?  
Please clarify.   CWG    ACCEPTED

See paper N3196 
CA 19 1.10p5 1.10p13 ¶ 1.10p5 1.10p13   Alternative definition of the value read by an atomic operation
Here's an interesting example involving a release/consume pair. We believe that in a direct implementation on hardware, this would be forbidden by coherence, but that the current text allows it. We don't know whether it should be allowed or not.
            hb
            do
            rf
Wx_release ----> Rx_consume
         ^         |
          \        |sb,hb
        mo \       v
             --- Wx_release
Paul claims this is forbidden by 1.10p5, but we don't see how that can be the case. We don't see much room in 1.10p5 for any other interpretation - it says:
- "All modifications to a particular atomic object M occur in some particular total order, called the modification order of M"
- "If A and B are modifications of an atomic object M and A happens before (as defined below) B, then A shall precede B in the modification order of M, which is defined below."
Both of which seem very clear. The only wiggle room is in the Note
- "[Note: This states that the modification orders must respect the "happens before" relationship]"
We took that "must respect" to be a gloss rather than to add any additional constraint.
Earlier we suggested a change, to the constraint on the value read by an atomic operation, that would forbid this example:
The standard introduces visible side effects, which are used first to define the values read by non-atomic operations. They are then re-used to constrain the value read by atomic operations: 1.10p13 says that an atomic operation must read from somewhere in "the" visible sequence of side effects, which must start from *a* visible side effect, i.e. a side effect that (a) happens before the read, and (b) is not happens-before-hidden. We suspect that this re-use of the notion of visible side effect may be a drafting artifact, in which case one might remove the requirement that there is a vse for atomics, and replacing the first two sentences of 1.10p13 by
"An atomic operation must read from somewhere in the modification order that is not happens-before-hidden and does not follow (in modification order) any side effect that happens-after the read."BR/> Now we're not sure how this would fit in with initialisation and reading of indeterminate values; we need to think about it more.  
Please clarify.   CWG    ACCEPTED

See paper N3196 
CA 22 1.10p8 ¶ 1.10p8   Control dependencies for atomics
Given the examples of compilers interchanging data and control dependencies, and that control dependencies are architecturally respected on Power/ARM for load->store (and on Power for load->load with a relatively cheap isync), we're not sure why carries-a-dependency-to does not include control dependencies between atomics.  
Please clarify.   CWG    REJECTED

At the time that the memory model was formulated, there was considerable uncertainty as to what architectures respect control dependencies, and to what extent. It appears that this uncertainty is being cleared up, and our hope is that it will be ripe for standardization in a later TR.

See paper N3196 
CA 15 1.10p9 ¶ 1.10p9   Intra-thread dependency-ordered-before
The current draft has release/acquire synchronize-with edges only between a release on one thread and an acquire on a *different* thread, whereas the definition of dependency-ordered-before permits the release and consume to be on the same thread; it seems odd to permit the latter. (At the moment function arguments can't race or sync with each other, but they can be dependency ordered before each other.)
We don't currently have an example in which this makes a real difference, but for symmetry could suggest changing the definition of dependency-ordered-before in 1.10p9 to the following:
An evaluation A is dependency-ordered before an evaluation B if
- A performs a release operation on an atomic object M, and on another thread, B performs a consume operation on M and reads a value written by any side effect in the release sequence headed by A,
or
- for some evaluation X, A is dependency-ordered before X and X carries a dependency to B.  
We suggest changing the definition of dependency-ordered-before in 1.10p9 to the following:
An evaluation A is dependency-ordered before an evaluation B if
- A performs a release operation on an atomic object M, and on another thread, B performs a consume operation on M and reads a value written by any side effect in the release sequence headed by A, or
- for some evaluation X, A is dependency-ordered before X and X carries a dependency to B.  
CWG  1177  ACCEPTED

See paper N3196 
CA 11 1.10p12 ¶ 1.10p12   "Subsequent" in vsse definition
Remove the word "subsequent" from the definition of visible sequence of side effects in 1.10p12.
(as suggested by Hans)
Rationale: if every element in a vsse happens-before a read, the read should not take the value of the visible side effect.  
Remove the word "subsequent" from the definition of visible sequence of side effects in 1.10p12.   CWG    ACCEPTED

See paper N3196 
CA 17 1.10p12 ¶ 1.10p12   1.10p12 phrasing
1.10p12 last note: "...as defined here..." should be "...as defined below...".  
1.10p12 last note:
"...as defined here..." should be "...as defined below...".  
editor    REJECTED

The reference really should be to "data races as defined in this International Standard", because the note compares this definition with the generally-understood meaning of data races in sequentially-consistent executions. That's far too stilted, and "as defined here" seems like a reasonable way to phrase it in the less formal context of a note.  
CA 13 1.10p13 ¶ 1.10p13   Wording of the read-read coherence condition
In 1.10p13 a coherence condition is stated on the values of atomic reads:
"Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and the value computed by A corresponds to the value stored by side effect X, then the value computed by B shall either equal the value computed by A, or be the value stored by side effect Y, where Y follows X in the modification order of M."
We suggest that this be replaced with the following:
"Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and A takes its value from the side effect X, then the value computed by B shall either be the value stored by X, or the value stored by a side effect Y, where Y follows X in the modification order of M."
Rationale: The words "corresponds to" are not used elsewhere in the standard, as far as we can see, and it is unclear whether they have a special meaning here. In addition taking the value of the read B from the value read by A seems unnecessarily indirect. B could take its value from X instead.  
In 1.10p13 a coherence condition is stated on the values of atomic reads:
"Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and the value computed by A corresponds to the value stored by side effect X, then the value computed by B shall either equal the value computed by A, or be the value stored by side effect Y, where Y follows X in the modification order of M."
We suggest that this be replaced with the following:
"Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and A takes its value from the side effect X, then the value computed by B shall either be the value stored by X, or the value stored by a side effect Y, where Y follows X in the modification order of M."  
CWG    ACCEPTED

See paper N3196 
CA 18 1.10p13 ¶ 1.10p13   Non-unique visible sequences of side effects and happens-before ordering
In 1.10p13, replace
"The visible sequence of side effects on..." by "A visible sequence of side effects on..."
and
"in the visible sequence of M with respect to B" by "in a visible sequence of M with respect to B"
Rationale: the current standard allows multiple visible sequences of side effects (vsse's) for a given read (despite the use of "The" at the start of 1.10p13). We demonstrate this by constructing an execution with two vsse's. The following execution has five memory operations, four of which are read modify writes (RMW's). There are two threads, one with four operations each ordered by sequenced before (sb), the other with a single RMW release.
RMW1             +---RMW3_release
|               /
|sb          do/
v             /
R_consume<---+
|
|sb
v
RMW2
|
|sb
v
RMW4
The modification order in this example is as follows:
mod       mod               mod
RMW1----->RMW2----->RMW3_release----->RMW4
With the modification order we give above, the happens-before relation has exactly these edges, according to 1.10p10:
From sequenced-before:
RMW1      -> R_consume, RMW2, RMW4
R_consume -> RMW2, RMW4
RMW2      -> RMW4
From ithb:
From dependency-ordered-before:
RMW3_release -> R_consume
In particular, there are no edges
RMW3_release -> RMW2 or RMW4.
As we understand it, this is the intended absence of transitivity from dependency-orderedbefore to sequenced-before.
1.10p5 says that if A happens-before B then A precedes B in the modification order, which is true for all the happensbefore edges and the modification order above.
RMW1 and RMW3_release are visible side effects
RMW2 and RMW4 follow R_consume in happens-before, so cannot be in a visible sequence of side effects.
Hence the two visible sequences of side effects are [RMW1] and [RMW3].
The R_consume here must read from the later vsse in modification order for the dependency_ordered edge to exist. The existence of two vsse's relies on the lack of transitivity of happens before (which only occurs in the presence of consume operations).  
In 1.10p13, replace
"The visible sequence of side effects on..."
by
"A visible sequence of side effects on..."
and
"in the visible sequence of M with respect to B"
by
"in a visible sequence of M with respect to B"  
CWG    ACCEPTED

See paper N3196 
US 10 1.10 ¶ Paragraph 14   The definition of a data race does not take into account two overlapping atomic operations   Augment the first sentence:
The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic (or both are atomic and operate on overlapping, but not-identical, memory locations), and neither happens before the other.  
CWG    REJECTED

The premise is incorrect; atomic objects may not overlap. The type argument to the atomic template must be a trivially-copyable type (29.5.3p1) and atomic objects are not trivially copyable. The atomic types provide no means to obtain a reference to internal members; all atomic operations are copy-in/copy-out. In short, any attempt to generate a pair of atomic variables whose memory overlaps results in undefined behavior.

See paper N3196 
US 11 1.10 ¶ para7   There is some confusion between locks and mutexes.   Change "lock" when used as a noun to "mutex".   CWG    ACCEPTED

See paper N3196 
US 12 1.10 ¶ P4,p14, p6,p12,p13   Adapt N3074:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3074.html  
Proposed change in N3074: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3074.html   CWG    ACCEPTED

See paper N3196 
CA 2 various ¶ various   Canada agrees with US 12, 14, 142, 145, 159   Resolve as suggested in these comments        
GB 8 1.10 ¶ 4, 7   The text says that the library "provides ... operations on locks". It should say "operations on mutexes", since it is the mutexes that provide the synchronization. A lock is just an abstract concept (though the library types unique_lock and lock_guard model ownership of locks) and as such cannot have operations performed on it. This mistake is carried through in the notes in that paragraph and in 1.10p7   Change 1.10p4 as follows:
"The library defines a number of atomic operations (Clause 29) and operations on mutexes (Clause 30) that are specially identified as synchronization operations. These operations play a special role in making assignments in one thread visible to another. A synchronization operation on one or more memory locations is either a consume operation, an acquire operation, a release operation, or both an acquire and release operation. A synchronization operation without an associated memory location is a fence and can be either an acquire fence, a release fence, or both an acquire and release fence. In addition, there are relaxed atomic operations, which are not synchronization operations, and atomic read-modify-write operations, which have special characteristics. [ Note: For example, a call that acquires a lock on a mutex will perform an acquire operation on the locations comprising the mutex. Correspondingly, a call that releases the same lock will perform a release operation on those same locations. Informally, performing a release operation on A forces prior side effects on other memory locations to become visible to other threads that later perform a consume or an acquire operation on A. “Relaxed” atomic operations are not synchronization operations even though, like synchronization operations, they cannot contribute to data races. end note ]"
Change 1.10p7 as follows:
"Certain library calls synchronize with other library calls performed by another thread. In particular, an atomic operation A that performs a release operation on an atomic object M synchronizes with an atomic operation B that performs an acquire operation on M and reads a value written by any side effect in the release sequence headed by A. [ Note: Except in the specified cases, reading a later value does not necessarily ensure visibility as described below. Such a requirement would sometimes interfere with efficient implementation. end note ] [ Note: The specifications of the synchronization operations define when one reads the value written by another. For atomic objects, the definition is clear. All operations on a given mutex occur in a single total order. Each lock acquisition “reads the value written” by the last lock release on the same mutex. —end note ]"  
CWG    ACCEPTED

See paper N3196 
GB 9 1.10 ¶ 6   See (B) in attachment Appendix 1 - Additional Details   Request the concurrency working group to determine if changes are needed   CWG  1176  ACCEPTED  
GB 10 1.10 ¶ 10   See (C) in attachment Appendix 1 - Additional Details
The GB would like WG21 to confirm there is no issue related to this.
GB adds:
We agree that if the read from x reads the value written by the write to x the write to x inter-thread-happens-before the write to y. However, the read from y is sequenced before the write to x, so if the read from x reads the value written by the write to x, then the read from y also inter-thread-happens-before the write to y. Consequently, the read from y cannot see the value written by the write to y. The reciprocal ordering also applies, but they cannot both apply in the same execution since if the write to x happens-before the read from x then the read from y happens-before the write to y, and vice-versa. There is thus no contradiction. [see comment below for proper formatting]  
Request the concurrency working group to determine if changes are needed   CWG    ACCEPTED

See paper N3196 
CA 8 1.10p10 ¶ 1.10p10   Rationale: Without this the standard permits executions with a cyclic happens-before relation that it seems clear should be forbidden, e.g.
Rx_consume<--+   +-->Ry_consume
|           rf\ /rf  |
|sb            X     |sb
v             / \    v
Wy_release---+   +---Wx_release
One could instead impose acyclicity on happens-before; that would be equivalent.  
1.10p10, before the Note, add:
"The inter-thread happens-before relation of an execution must be acyclic"  
CWG    ACCEPTED

See paper N3196 
GB 11 1.10 ¶ 12   See (E) in attachment Appendix 1 - Additional Details The GB would like WG21 to confirm there is no issue related to this.
GB adds: [see comment below for proper formatting] The variable in question has a single modification order, which is any of
(a) RMW3, RMW1, RMW2, RMW4.
(b) RMW1, RMW3, RMW2, RMW4.
(c) RMW1, RMW2, RMW3, RMW4.
(d) RMW1, RMW2, RMW4, RMW3.
since RMW1, RMW2 and RMW4 occur in a single thread in that sequence, and RMW3 occurs in a separate thread with no other ordering constraints. Since the R_consume lies between RMW1 and RMW2 in that thread, it must either read the value written by RMW1 (which could happen if it immediately follows RMW1 in any of the sequences), or RMW3 (which could happen with sequence (b)). The visible sequence of side effects for R_consume is thus either RMW3, RMW1 (from (a)), RMW1 (from (b), (c) or (d)), or RMW1, RMW3 (from (b)). Which sequence applies in practice may vary from execution to execution. There is however only a single sequence on any given execution.  
Request the concurrency working group to determine if changes are needed   CWG    ACCEPTED

See paper N3196 
GB 12 1.10 ¶ 13   See (F) in attachment Appendix 1 - Additional Details
The GB would like WG21 to confirm there is no issue related to this. GB adds:
The cycle given is clearly forbidden by the current text. The read is sequenced-before the write in the same thread. If the read sees the value written by the other thread then that write is dependency-ordered-before the read, and thus happens-before the read, and happens-before the write from the reading thread. The write from the left-hand thread thus must occur before the write from the right-hand thread in the modification order of the object by 1.10p5.  
Request the concurrency working group to determine if changes are needed   CWG    ACCEPTED

See paper N3196 
GB 13 1.10 ¶ 13   See (G) in attachment Appendix 1 - Additional Details
GB suggests alternative wording to that in the attached paper:
"Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and A uses the value of M from the side effect X, then the value computed by B shall either be the value stored by X, or the value stored by a side effect Y, where Y follows X in the modification order of M."  
Request the concurrency working group to determine if changes are needed        
GB 14 1.10 ¶ 8   See (I) in attachment Appendix 1 - Additional Details
GB adds: If an implementation can't guarantee the ordering it should refrain from performing the optimisation  
Request the concurrency working group to determine if changes are needed.   CWG    REJECTED

We agree that the implementation needs to address this, and it can.  
GB 15 1.10   See (J) in attachment Appendix 1 - Additional Details   Request the concurrency working group to determine if changes are needed.   CWG    REJECTED

At the time that the memory model was formulated, there was considerable uncertainty as to what architectures respect control dependencies, and to what extent. It appears that this uncertainty is being cleared up, and our hope is that it will be ripe for standardization in a later TR.

See paper N3196 
GB 16 1.10 ¶ 12   See (L) in attachment Appendix 1 - Additional Details   "...as defined here..." should be "...as defined below...".   editor    REJECTED

"As defined here" refers to this standard, which is the intention. If it were normative text the correct phrase would be "in this International Standard", but for a note, the text as written is sufficient.  
US 13 2.2 ¶ 1   “Raw” strings are still only Pittsburgh-rare strings: the reversion in phase 3 only applies to an r-char-sequence.   Make the reversion apply to the entire raw-string.   CWG  1103  ACCEPTED  
US 14 2.2 2.3 2.5 2.14.5 ¶ P1   Precedence of reversal and tokenization
The current paper implies that determination of the characters forming an r-char-sequence occurs while the transformations done in phase 1 and phase 2 are still in effect.
Consider these cases:
  • Line splicing occurred in translation phase 2; the backslash is not there on entry to phase 3 when we try to tokenize:
    const char str[] = R"a()\a")a";
  • Trigraph replacement occurred in phase 1. The right parenthesis is not there on entry to phase 3:
    const char str[] = R"(??)";
  • Trigraph replacement (again). In [lex.string] paragraph 2, there is a footnote 24 in N3092. Note that this provides fuel for anti-trigraph sentiment:
    const char str[] = R"#()??=")#";
Change in [lex.string] from N3077:
Escape sequences and universal-character-names in non-raw string literals have the same meaning as in character literals ....
should be reflected in [lex.phases] paragraph 1, phase 5 (CD2 wording):
Each source character set member and universal-character-name in a character literal or a string literal, as well as each escape sequence in a character literal or a non-raw string literal, is converted to the corresponding member of the execution character set (2.14.3, 2.14.5); if there is no corresponding member, it is converted to an implementation-defined member other than the null (wide) character
and [lex.charset] paragraph 2 (CD2 wording):
Additionally, if the hexadecimal value for a universal-character-name outside the c-char-sequence, s-char-sequence, or r-char-sequence of a character or string literal corresponds to a control character (in either of the ranges 0x00-0x1F or 0x7F-0x9F, both inclusive) or to a character in the basic source character set, the program is ill-formed.
UCNs simply do not occur in the grammar for r-char-sequence anyway.  
In 2.14.5 [lex.string] paragraph 2: Remove footnote 24:
In 2.2 [lex.phases] paragraph 1, phase 1; insert exception:
Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set (introducing new-line characters for end-of-line indicators) if necessary. The set of physical source file characters accepted is implementation-defined. Trigraph sequences (2.4) are replaced by corresponding single-character internal representations. Any source file character not in the basic source character set (2.3) is replaced by the universal-character-name that designates that character. (An implementation may use any internal encoding, so long as an actual extended character encountered in the source file, and the same extended character expressed in the source file as a universal-character-name (i.e., using the \uXXXX notation), are handled equivalently except where this replacement is reverted.)
In 2.2 [lex.phases] paragraph 1, phase 3:
The source file is decomposed into preprocessing tokens (2.5) and sequences of white-space characters (including comments). A source file shall not end in a partial preprocessing token or in a partial comment. Each comment is replaced by one space character. New-line characters are retained. Whether each nonempty sequence of white-space characters other than newline is retained or replaced by one space character is unspecified. The process of dividing a source file's characters into preprocessing tokens is contextdependent. [ Example: see the handling of < within a #include preprocessing directive. —end example ]
In 2.2 [lex.phases] paragraph 1, phase 5:
Each source character set member in a character literal or a string literal, as well as each escape sequence and universal-character-name in a character literal or a non-raw string literal, is converted to the corresponding member of the execution character set (2.14.3, 2.14.5); if there is no corresponding member, it is converted to an implementation-defined member other than the null (wide) character.
In 2.3 [lex.charset] paragraph 2:
.... Additionally, if the hexadecimal value for a universal-character-name outside the c-char-sequence or s-char-sequence of a character or string literal corresponds to a control character (in either of the ranges 0x000x1F or 0x7F 0x9F, both inclusive) or to a character in the basic source character set, the program is ill-formed. [ Footnote: A sequence of characters resembling a universal-character-name in an r-char-sequence (2.14.5 [lex.string]) does not form a universal-character-name. ]
In 2.5 [lex.pptoken] paragraph 3:
If the input stream has been parsed into preprocessing tokens up to a given character:
  • if the next character begins a sequence of characters that could be the prefix and initial double quote of a raw string literal, such as R", the next preprocessing token shall be a raw string literal and any transformations performed in phases 1 and 2 on this input stream (trigraphs, universal-character-names, and line splicing) are reverted for the remainder of the stream until said raw string literal (2.14.5) is matched; [ Footnote: A raw string literal formed through token concatenation (16.3.3) is not parsed from an input stream and is not subject to this reverting. Destringization (16.9) involves an alternate input stream, thus there are no phase 1 or phase 2 transformations to revert. ]
  • otherwise, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token, even if that would cause further lexical analysis to fail.
 
CWG  1103  ACCEPTED  
US 15 2.6 ¶ para 2   The <: digraph causes problem with users unfamiliar with digraphs when passing global objects as template arguments.   Add a special hack for <:: much like the special hack for >>.   CWG  1104  ACCEPTED  
CA 24 2.11 ¶ Various   A list of issues related TR 10176:2003
1) "Combining characters should not appear as the first character of an identifier." Reference: ISO/IEC TR 10176:2003 (Annex A) This is not reflected in FCD.
2) Restrictions on the first character of an identifier are not observed as recommended in TR 10176:2003. The inclusion of digits (outside of those in the basic character set) under identifer-nondigit is implied by FCD.
3) It is implied that only the "main listing" from Annex A is included for C++. That is, the list ends with the Special Characters section. This is not made explicit in FCD. Existing practice in C++03 as well as WG 14 (C, as of N1425) and WG 4 (COBOL, as of N4315) is to include a list in a normative Annex.
4) Specify width sensitivity as implied by C++03: \uFF21 is not the same as A Case sensitivity is already stated in [lex.name].  
Please clarify.   CWG  1105  ACCEPTED

See paper N3146 
GB 17 2.14.2 ¶ Table 5   [lex.icon] 2.14.2/2 Table 5 - 'Types of integer constants' In the penultimate row for this table (for suffix `ll or LL') it gives the `Octal or hexadecimal constant' in the third column as one of: long long int unsigned long int Unless I am misunderstanding something fundamental, this second should be: unsigned long long int   Replace the entry for "ll or LL" and "Octal or hexadecimal constant" in table 5 with "long long int unsigned long long int"   editor    ACCEPTED  
JP 16 2.14.3 ¶ 2 Note   Typo, "wide-charater" should be "wide-character".   Correct typo.
[ Note: the type wchar_t is able to represent all members of the execution wide-character set (see 3.9.1).  
editor    ACCEPTED  
RU 2 2.14.3 ¶ p.23, par.3, line 1   Reference missed   Insert reference "(3.9.1)" after "extended integer type"   editor    ACCEPTED  
DE 2 2.14.4   C++ does not support hexadecimal floating-point literals, although they are useful to specify exact floating-point constants.   Consider supporting the C99 syntax for hexadecimal floating-point literals.   CWG    REJECTED

There was no consensus to adopt this feature at this point in the standardization process.  
US 16 2.14.5 [lex.string]   Raw string literals have no implementation experience.   Either demonstrate a complete implementation of this feature or remove N2146 from the working paper prior the FDIS.   CWG    ACCEPTED

The feature has been implemented.  
DE 3 2.14.7   It is not sufficiently clear that std::nullptr_t is a distinct type and neither a pointer type nor a pointer-to-member type.   Add a note in 2.14.7 stating that, preferably with cross-references to the normative statements in 3.9.   CWG  1106  ACCEPTED  
RU 5 2.14.7 ¶ p. 28   Page layout bug   Move footnote 24 from page 28 to page 27   editor    ACCEPTED  
US 17 2.14.8 ¶ 6   In general, the parameter type of a literal operator must be the same as the argument passed to it. That is not the case for a user-defined-character-literal, where the argument could inadvertently match a literal operator intended for use with user-defined-integer-literals:
typedef unsigned long long ULL;
int operator "" X(ULL);
int i = 'c'X; // operator"" X(ULL('c'))
 
Add the following phrase to the description in paragraph 6:
S shall contain a literal operator whose parameter type is the same as the type of ch.  
CWG  1107  ACCEPTED  
JP 17 2.14.8 ¶ 3   Typo, missing ",".
If S contains a raw literal operator the literal L is treated as  
Correct typo.
If S contains a raw literal operator, the literal L is treated as  
editor    ACCEPTED  
JP 18 2.14.8 ¶ 4   Typo, missing ",".
If S contains a raw literal operator the literal L is treated as  
Correct typo.
If S contains a raw literal operator, the literal L is treated as  
editor    ACCEPTED  
US 18 2.24.8 [lex.ext]   User-defined literals have no implementation experience.   Either demonstrate a complete implementation of this feature or remove N2750 from the working paper prior the FDIS.   CWG  1108  (Reference should be to 2.14.8, not 2.24.8.)  
US 19 3 ¶ 4   It is not always clear when the term "use" is intended as a reference to the definition in 3.2 and when it has its normal English meaning. For example, 3 paragraph 4 reads, "A name is a use of an identifier..."   Replace all occurrences of the word "use" that are not intended as references to 3.2 with some other term, such as "occurrence" or "appearance" or "reference to".   CWG  1109  ACCEPTED

See paper N3214 
US 20 3.1 ¶ para 1 bullet 4   Grammatical number mismatch in "an assignment expressions".     editor    ACCEPTED  
US 21 3.1 ¶ 2   using N::d; does not declare N::d.   using N::d; // declares d   editor    ACCEPTED  
US 22 3.2 ¶ 4   The type of the expression of a decltype-specifier is apparently required to be complete.   Make an exception so that a template specialization type is not instantiated merely because it's the type of the expression in decltype( expression )   CWG  1110  REJECTED

The premise is incorrect: it is the function call, not decltype, that requires a complete type. As described in core language issue 1110, failing to instantiate the return type of a function could prevent plausible uses of SFINAE.  
JP 19 3.2 ¶ 4   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(10)" to "(Clause 10)".   editor    ACCEPTED  
JP 20 3.3.2 ¶ 7   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(9)" to "(Clause 9)".   editor    ACCEPTED  
US 23 3.4.5 ¶ para 1   Global class templates should not hide member templates.   Strike the end of para 1 starting with "If the lookup in the class of the object expression finds a template,". See Appendix 1 - Additional Details   CWG  1111  ACCEPTED  
US 24 3.5 ¶ 3   One of the critieria for giving a name internal linkage is "a variable that is explicitly declared const and neither explicitly declared extern nor previously declared to have external linkage." This should presumably apply to variables declared constexpr as well.   Add parallel wording for the constexpr specifier.   CWG  1112  ACCEPTED  
DE 4 3.5   It is odd that "N" has no linkage and "g" has external linkage in this example:
namespace {
namespace N // has no linkage
{
void g(); // has external linkage
} }
 
  CWG  1113  ACCEPTED  
DE 5 3.7.3   The term "local" was changed globally to "block-scope", but this section still contains the term "local" (see also core issue 642).   Change "local" to "block-scope" in the first paragraph.   editor    ACCEPTED  
RU 3 3.7.4.3 ¶ p.65, line 7   Reference missed   Insert reference "(5.7)" after "well-define pointer arithmetic"   editor    ACCEPTED  
RU 4 3.7.4.3 ¶ p. 65, line 8   Reference missed   Insert references "(4.10, 5.4)" after "well-define pointer conversion"   editor    ACCEPTED  
GB 18 3.8 ¶ 9   It isn't clear that the comment in the example actually reflects the result of the placement new. If the intended placement operator new is supposed to be the one given by the standard library ,by including , the example is ill-formed as the placement-new expression &b is const B* which doesn't implicitly convert to void*.   Replace:
new (&b) const B;
With:
new (const_cast<B*>(&b)) const B;  
CWG  1114  ACCEPTED  
US 25 3.11   C/C++ compatibility problems defined in WG21/N3093.   Make the changes proposed in WG21/N3093   CWG  1115  ACCEPTED  
US 26 3.7.4, 5.3.5, 12.5, 17.6.3.6, 18.6   Programmers may define a static member function operator delete that takes a size parameter indicating the size of the object to be deleted. The equivalent global operator delete is not available. This omission has unfortunate performance consequences.   Permit implementations and programmers to define sized versions of the global operator delete for use in preference to the unsized version. See Appendix 1 - Additional Details   CWG    REJECTED

There was no consensus for making the suggested change at this point in the standardization process.  
US 27 3.8 ¶ 4   Related to core issue 1027, consider:
int f() {
union U { double d; } u1, u2;
(int&)u1.d = 1;
u2 = u1;
return (int&)u2.d;
}
Does this involve undefined behavior? 3.8/4 seems to say that it's OK to clobber u1 with an int object. Then union assignment copies the object representation, possibly creating an int object in u2 and making the return statement well-defined. If this is well-defined, compilers are significantly limited in the assumptions they can make about type aliasing. On the other hand, the variant where U has an array of unsigned char member must be well-defined in order to support std::aligned_storage.  
Clarify that this testcase is undefined, but that adding an array of unsigned char to union U would make it well-defined--if a storage location is allocated with a particular type, it should be undefined to create an object in that storage if it would be undefined to access the stored value of the object through the allocated type.   CWG  1116  ACCEPTED  
US 28 4.4 ¶ para 3   A const member function pointer could safely be applied to a non-const object without violating const correctness.   Add an implicit conversion. See Appendix 1 - Additional Details   CWG    REJECTED

There was no consensus for adding this feature at this point in the standardization process.  
FI 7 4.11 [conv.mem], 5.2.9 [expr.static.cast]   The CD1 comment CH1 should be reconsidered. The request for being able to cast a pointer to member to a pointer to a base class (or any other implicitly convertible type) of the member is a bugfix rather than an extension. It's a safe conversion, thus it should be allowed. There are valid use cases for such conversions that are currently forbidden.   The standard should allow implicit conversions from “pointer to member of T of type cv D” to 'pointer to member of T of type cv B', where D is of class type and B is a public base of D, It should allow explicit conversion the other way around.   CWG    REJECTED

There was no consensus for making this change at this point in the standardization process.  
CH 3 4.11 and 5.2.9   With respect to the target type, pointer to members should behave like normal pointers. The current situation creates an inconsistency in the C++ type system and is therefore a defect in the Standard.   The standard should allow implicit conversions from ``pointer to member of T of type cv D'' to ``pointer to member of T of type cv B'', where D is of class type and B is a public base of D. It should allow explicit conversion in the other direction.   CWG    REJECTED

There was no consensus for making this change at this point in the standardization process.  
JP 21 4.13 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(5)" to "(Clause 5)".   editor    ACCEPTED  
JP 1 5 ¶ Paragraph 6   The first half of the Note(before "In general") indicates that the expression "E1.E2" produces xvalue if E1 is xvalue regardless of E2's type. It will be true even if E2 is of reference type. On the other hand, according to 5.2.5 paragraph 4, if E2 is of reference type, the result of "E1.E2" is lvalue regardless of E1's type. These two descriptions contradict each other. As 5.2.5 paragraph 4 seems correct, 5 paragraph 6 should be corrected.   Modify 5 paragraph 6 so that the result of E1.E2 is lvalue instead of xvalue when E2 is of reference type.   CWG  1117  ACCEPTED  
FI 8 5.1.2 [expr.prim.lambda]   As requested in JP 9 on CD, capturing by moving should be allowed for lambdas. Roshan Naik presents a very compelling use case in the Core Reflector message c++std-core-16341.   Allow specifying capture by move.   CWG    REJECTED

There was no consensus for making the suggested change at this point in the standardization process.  
CH 4 5.1.2 ¶ p1   Document N3067 changed the position of attribute specifiers in various places. However, it left out lambda expressions as an oversight, so that the position of attribute-specifier opt in a lambda-declarator is inconsistent with a function declarator   change the rule for lambda-declarator to
lambda-declarator:
( parameter-declaration-clause ) mutableopt exception-specificationopt attribute-specifieropt trailing-return-typeopt  
CWG  1062  ACCEPTED  
CH 5 5.1.2 ¶ p4 first bullet   typo   Change second 'if' to 'is'.   editor    ACCEPTED  
US 29 5.1.2 ¶ 5   default arguments should be allowed in lambdas (core issue 974)   See Appendix 1 - Additional Details   CWG  974  REJECTED

There was no consensus for making the suggested change at this point in the standardization process. However, core language issue 974 remains open for consideration in a future revision.  
US 30 5.1.2 ¶ 4   lambda return type deduction should allow arbitrary function structure (core issue 975)   See Appendix 1 - Additional Details   CWG  975  REJECTED

There was no consensus for making the suggested change at this point in the standardization process. However, core language issue 975 remains open for consideration in a future revision.  
JP 22 5.1.2 ¶ 7   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(5)" to "(Clause 5)".   editor    ACCEPTED  
CH 6 5.1.2 ¶ p8 and p10   The current capturing rules seem too restrictive.   Consider to make those rules less restrictive.   CWG    REJECTED

The comment made no specific suggestions for change.  
GB 19 5.1.2 ¶ 16   [expr.prim.lambda] 5.1.2/16 has text which begins "If a lambda-expression m1 captures an entity and that entity is captured by an immediately enclosing lambda expression m2..." - that is, it describes a situation with m2 enclosing m1, and then describes the capture transformation in these terms. The example given to support this, however, turns this all around and shows m1 enclosing m2. This doesn't make either the text or the example incorrect in any sense, but I would suggest that it adds a level of confusion that is easily avoided.   All references to m1 from the beginning of 5.1.2/16 up to the last occurrence before '[Example ' to be replaced by m2, and vice versa. Rationale for suggested wording: all other examples that use the 'mN' notation for lambda expressions and which involve nesting apply increasing N (by 1, from 1) to indicate increasing nesting depth.   editor    ACCEPTED  
GB 20 5.1.2 ¶ 12   [expr.prim.lambda] 5.1.2/12. In the example code given the local struct s1 has a member function with signature int s1::work(int n) whose definition does not include an appropriate return statement; neither does it include the conventional "// ..." to indicate that the example is intended to be incomplete.   Suggested change: change the signature of this member function to void s1::work(int n), as the return of int does not contribute to the example.   editor    ACCEPTED  
GB 21 5.1.2   A lambda-capture can be &, which indicates it captures everything by reference (unless otherwise specified), or & /identifier/, which indicates it captures the /identifier/ by reference. It can also be =, to capture everything by value, or /identifier/, for a single thing. Why is = /identifier/ not allowed, for consistency?   Add "= identifier" to the grammar in 5.1.2p1. (The wording already covers the semantics of this, since it refers to captures that "are preceded by &" or "do not contain &")   CWG    REJECTED

There was no consensus for making the suggested change.  
FI 19 5.1.2 [expr.prim.lambda] ¶ 21   “When the lambda-expression is evaluated, the entities that are captured by copy are used to direct-initialize each corresponding non-static data member of the resulting closure object.” This apparently means that if the capture-default is to copy, entities captured by default, implicitly, are copied even in cases where the copy constructors of such entities are explicit.   Don't implicitly copy entities that have explicit copy constructors declared. Require that such entities be captured explicitly, by enumerating them in the capture list. This seems related to Core Issue 1020, so I'd like that issue to be resolved as well. See Appendix 1 - Additional Details   CWG  1118  REJECTED

There was no consensus for the suggested change.  
GB 23 5.2.2 ¶ 4   Order of initialization of arguments in a function is fundamental to the memory model of C++, and the obvious place to look for the definition is in the clause defining function call operators - which currently says nothing. The rules covering this are buried in paragraph 15 of [1.9]. A cross-reference to these words would be most helpful. In particular, it should be made clear that such initialization is indeterminately sequenced (and not unsequenced.)   Add a non-normative note with cross-reference after the first sentance of paragraph 4: "[Note - such initializations are indeterminately sequenced with respect to each other [1.9] - end note]"   editor    ACCEPTED  
US 31 5.2.9;7.2 ¶ 10   it is unclear from the text in 7.2 and 5.2.9 that the "values of the enumeration" term does not exclude a prvalue of an enumeration type from having other values representable in its underlying type (c++std-core-15652).   clarify this. "The value is unchanged if it is in the range of enumeration values of the enumeration type; otherwise the resulting enumeration value is unspecified (and might not be in that range)." Also add a note after paragraph 7 "[Footnote: this set of values is used to define promotion and conversion semantics for the enumeration type; it does not exclude an expression of enumeration type from having a value that falls outside this range.]"   CWG  1022  ACCEPTED  
US 32 5.2.5 ¶ 5   The description of ambiguity ("...if the class of which E2 is directly a member is an ambiguous base (10.2) of the naming class (11.2) of E2") does not cover the following case:
struct A { int i; };
struct B: A { };
struct C: A, B { };
void f(C* p) {
p->i; // Should be ambiguous
}
 
Change the wording to apply also to the case when the naming class is an ambiguous base of the class of the object expression.   CWG  1119  ACCEPTED  
JP 64 5.2.8 ¶ 5   In some code examples, ellipsis(...) is used in ill-formed. In these cases, "..." represents omission of some codes like this:
class A { /* ... */ } ;
But in some cases, it is used without commented-out as below:
class A { ... } ;
It is an inconsistent usage. They all should be enclosed in a comment.  
Change to:
class D { /* ... */ };  
editor    ACCEPTED  
GB 22 5.2.10   It is not legal to use reinterpret_cast<> with pointers to void.   Here's an additional paragraph to add to 5.2.10 that would fix this:
* A pointer to an object type can be explicitly converted to a pointer to void, and vice versa.[1] The result of such a pointer conversion will have the same result as the standard pointer conversion described in 4.10. A value of type “pointer to object” converted to “pointer to void” and back, possibly with different cv-qualification, shall have its original value.
[1] The types may have different cv-qualifiers, subject to the overall restriction that a reinterpret_cast cannot cast away constness.  
CWG  1120  ACCEPTED  
US 33 5.3.1 ¶ 3   The resolution of issue 983 added an error for finding the named member in an ambiguous base. This is an unnecessary special case, since the value of the expression is pointer to member of base. If this value is then converted to pointer to member of derived, an error will be given at that point.   Revert the change for issue 983 (and in the issues list, add a link to issue 203).   CWG  1121  ACCEPTED  
GB 24 5.3.3 ¶ 6   The return type of the sizeof operator is defined as being of type std::size_t, defined in library clause 18.2. This, in turn, says that size_t is defined in the C standard, which in turn says that size_t is defined as the type of the result of the sizeof operator! The C definition of sizeof returns an implementation-defined unsigned integer type, recommended not to have "an integer conversion rank greater than signed long int, unless the implementation supports objects large enough to make this necessary."   The result type of the sizeof operator should explicitly be implementation defined in clause 5.3.3.   CWG  1122  ACCEPTED  
US 34 5.3.4, 5.3.5   Allocations functions are missing happens-before requirements and guarantees.   Add requirements. See Appendix 1 - Additional Details        
US 35 5.3.7 ¶ [expr.unary.noexcept], 15.4 [except.spec]   noexcept has no implementation experience.   Either demonstrate a complete implementation of this feature or remove N3050 from the working paper prior the FDIS.   CWG    ACCEPTED

The feature has been implemented.  
FI 17 5.3.7 [expr.unary.noexcept]   Destructors should by default be noexcept. Such a rule should, I think, be obeyed even for cases where a destructor is defaulted. Then a throwing destructor would need to be declared noexcept(false), and I think the resulting code breakage is acceptable.   Clarify the implicit generation rules and defaulting rules so that destructors are noexcept unless explicitly declared noexcept(false).   CWG  1123  ACCEPTED with MODIFICATIONS

The rule that was adopted makes destructors noexcept if all the base and member destructors are.

See paper N3204 
JP 2 5.5 ¶ 6   Should be corrected because it contradicts with rules in 5.2.5 paragraph 4.   Add the condition that a type of e2 is not a reference type   CWG  1124  REJECTED

There are no pointers to members of reference type (8.3.3p3).  
US 36 5.19 [expr.const]   Generalized constant expressions have no implementation experience.   Either demonstrate a complete implementation of this feature or remove N2235 from the working paper prior the FDIS.   CWG    REJECTED

An implementation is in progress and is expected to be complete before the publication of the FDIS. Also, this feature is needed in the Standard library and thus should not be removed.  
DE 7 5.19 ¶ 4, note   The note in paragraph 4 alludes to the possibility that compile-time and run-time evaluations of floating-point expressions might yield different results. There is no clear normative statement (other than the absence of a restriction) that gives such permission.   Move the second sentence of the note into normative text.   CWG    REJECTED

The possibility of differing results of calculations is implicit in the absence of normative statements constraining their accuracy, so no normative change is needed; the existing note is sufficient to point out this implication.  
DE 8 5.19 ¶ 6   In the definition of "potential constant expression" in paragraph 6, it is unclear how "arbitrary" the substitution of the function parameters is. Does it mean "there exists a value for which the result is a constant expression" or does it mean "for all possible values, the result needs to be a constant expression"? Example:
constexpr int f(int x){return x + 1; }
is a constant expression under the first interpretation, but not under the second (because overflow occurs for x == INT_MAX, cf. 5.19p2 bullet 5). The answer also affects expressions such as:
constexpr int f2(bool v) { return v ? throw 0 : 0; }
constexpr int f3(bool v) { return v && (throw 0, 0); }
 
  CWG  1125  ACCEPTED

See paper N3218 
GB 25 5.19   In trying to pin down the behaviour of constexpr functions, it became apparent that there is disagreement over whether or not the following example is well-formed.
constexpr int f() { return 42 + 84; }
const int sz = f();
int a[sz];
This should have the same effect as
const int sz = 42 + 84;
int a[sz];
otherwise constexpr functions are broken.  
Update the wording in 5.19 to make it clear that both the examples are valid.   CWG  1126  ACCEPTED  
GB 26 5.19   It is not clear how overload resolution applies within a constexpr function. In particular, if an expression in the function body yields an integral value of 0 for some parameter values, and not for others, is it usable as a null pointer constant when evaluated as a constant expression.
typedef char (&One)[1];
typedef char (&Two)[2];
One f(void*); // #1
Two f(...); // #2
constexpr int test(int n) { return sizeof f(n); }
constexpr int test2(int n) { return sizeof f(n*0); }
int q = 0;
#include
int main() {
char a[test(0)];
std::cout << sizeof(a) << std::endl; // #3
std::cout << test(q) << std::endl; // #4
char b[test2(0)];
std::cout << sizeof(b) << std::endl; // #5
std::cout << test2(q) << std::endl; // #6
}
#3 and #4 should print 2, since n is not an integral constant expression with value 0 in the body of test() --- though it is a constant expression when test() is evaluated as a constant expression, it's value is dependent on the invocation. Permitting different results of overload resolution within the same function body in different calling contexts would violate ODR.
On the other hand, in test2(), the answer is no longer dependent on the value of n, since "n*0" always evaluates to 0. However, it is not clear from the FCD whether "n*0" is thus a constant expression (and therefore a valid null pointer constant) inside the body of test2. Either way both #5 and #6 should print the same value; it would violate ODR for #5 to print "1" (indicating that "n*0" was a valid null pointer constant when test2() is evaluated in a constant expression context) whilst #6 prints "2" (since n*0 is not a constant expression if n is not constant). #5 and #6 should thus both print "1", or both print "2".  
Updated 5.19 to make it clear that overload resolution in a constexpr function is not dependent on the context of use, or the value of the arguments.   CWG  1127  ACCEPTED  
US 37 6.5   "for (auto e : range)" creates copies of elements. This seems like a gotcha for new users. Not only are copies inefficient for reading, but writing to copies won't modify the original elements.
Permitting "for ( identifier : expression )" and giving it the same meaning as "for ( auto& identifier : expression )" would make the range-based for statement easier to teach and to use, and should be trivial to specify and to implement.  
Permit "for ( identifier : expression )" or similar, with the same meaning as "for ( auto& identifier : expression )".   CWG    REJECTED

There was no consensus for making the suggested change at this point in the standardization process.  
CA 3 Various ¶ various   Canada agrees with US 37, 44, 47, 85, 77, 92, 97, 102, 105, 109   Resolve as suggested in these comments   CWG     
US 38 6.5 5   The statement that certain infinite loops may be assumed to terminate should also apply to go-to loops and possibly infinite recursion. We expect that compiler analyses that would take advantage of this can often no longer identify the origin of such a loop.   As a strawman, replace the paragraph with
"The implementation may assume that any program will eventually do one of the following:
- terminate,
- make a call to a library I/O function,
- access or modify a volatile object, or
- perform a synchronization operation (1.10) or atomic operation (Clause 29)."
Possibly move this and the attached note to section 1.9, after p8.  
CWG    ACCEPTED

See paper N3196 
JP 69 6.35.1 ¶ 2   Constant width font should be used for 3 "while"s in the paragraph as described in Syntax notation (1.6).   Change the font for "while" to constant width type. When the condition of a while statement is a declaration, the scope of the variable that is declared extends from its point of declaration (3.3.2) to the end of the while statement. A while statement of the form   editor    ACCEPTED  
GB 27 6.5.4p1   6.5.4/1 requires that range-based for loops behave as if they had "{ auto&& __range = (expression); for (auto __begin = begin_expr, __end = end_expr; ..." which implies that __begin and __end must have the same type. However, this prevents stateful iterators with an end sentinel of a different type. Since range-based for loops' equivalent code already introduces a block (for the __range variable), could __begin and __end be placed there, as "auto __begin = begin_expr; auto __end = end_expr;"?
Example of what this change would allow, only the relevant details shown with ctors, op*, op++, etc. omitted: (apologies if the formatting is lost)
struct End {}; struct Counter { Counter& begin() { return *this; } // used by begin_expr End end() { return End(); } // used by end_expr bool operator!=(End) const { return _current != _end; }
Counter(int begin, int end) : _current(begin), _end(end) {} int _current, _end; };
void use_example() { for (auto n : Counter(0, 10)) { // n takes values from 0..9 } }  
Change the "as if" for a range-based for-loop in 6.5.4p1 to move the initialization of __begin and __end outside the loop into the enclosing block:
{ auto&& __range = (expression);
auto __begin = begin_expr; auto __end =
end_expr;
for (; ...
 
CWG    REJECTED

There was no consensus for making the suggested change. Use of iterators of different types is incompatible with the Standard library containers and with the earlier concepts-based specification.  
CH 7 6.5.4 ¶ p1   The phrasing "is equivalent to" is too restrictive and might constrain future improvements.   Make clear that the specification is not necessarily the implementation, i.e. that the expressions in the specification are not necessarily called at all and that the order in which the statement is executed for different values of for-range-declaration is not necessarily the same as if the for loop would have been written the way in the specification.   CWG    REJECTED

There was no consensus for making the suggested change. The Standard needs to specify the meaning of the statement; removing the “equivalent to” phrasing would leave the feature underspecified. Implementations have a good deal of latitude under the “as-if” rule.  
GB 28 7 ¶ 1   "Attributes" is misspelled   Replace "Atrributes" with "Attributes"   editor    ACCEPTED  
US 39 7.1 ¶ 1   The current wording is, "The optional attribute-specifier in a decl-specifier-seq appertains to the type determined by the decl-specifier-seq." However, the rule for decl-specifier-seq in the grammar is recursive, and the intent is for the attribute-specifier to appertain to the top decl-specifier-seq, not the one in which the attribute-specifier directly appears.   Change the wording to indicate that the complete or outermost decl-specifier-seq is intended.   CWG  1128  ACCEPTED  
GB 29 7.1.5   A constexpr function is not permitted to return via an exception. This should be recognised, and a function declared 'constexpr' without an explicit exception specification should be treated as if declared 'noexcept(true)' rather than the usual 'noexcept(false)'. For a function template declared constexpr without an explicit exception specification, it should be considered 'noexcept(true)' if and only if the constexpr keyword is respected on a given instantiation.   Give constexpr functions an implicit non-throwing exception specification.   CWG  1129  ACCEPTED with MODIFICATIONS

The premise is not correct: an exception is forbidden only when a constexpr function is invoked in a context that requires a constant expression. Used as an ordinary function, it can throw. Instead of changing the default exception specification, the result of the noexcept operator was changed, based on whether the invocation of the function is a constant expression or not.  
US 40 7.1.6.2 ¶ 4   The description of decltype does not specify whether the type of a parameter is the declared type or the type as adjusted in 8.3.5p5:
auto f(int a[])->decltype(a);
// ill-formed or int*?
auto g(const int i)->decltype(i);
// int or const int?
 
Clarify the wording to indicate that the type of a parameter is after the array- and function-to-pointer decay but before the removal of cv-qualification.   CWG  1130  ACCEPTED  
DE 9 7.1.6.2 ¶ p4   decltype applied to a function call expression requires a complete type (5.2.2 paragraph 3 and 3.2 paragraph 4), even though decltype's result might be used in a way that does not actually require a complete type. This might cause undesired and excessive template instantiations.   When immediately applying decltype, do not require a complete type, for example for the return type of a function call.   CWG  1110  REJECTED

As described in core language issue 1110, failing to instantiate the return type of a function could prevent plausible uses of SFINAE.  
US 41 7.1.6.3 ¶ 2   The current wording disallows use of typedef-names in elaborated-type-specifiers. This prohibition should also apply to template aliases:
struct A { };
template<typename T> using X = A;
struct X<int>* p2; // ill-formed
 
Add the necessary wording to prohibit a specialization of a template alias in an elaborated-type-specifier.   CWG  1131  ACCEPTED  
US 42 7.1.6.4   The overloaded meaning of the auto specifier is confusing and prevents possible future language enhancements.   Choose another keyword to indicate a late-specified return type. The identifiers lateret and postret have no Google code search hits. The identifiers late, latetype, and posttype have 30-40 hits.   CWG    REJECTED

There was no consensus to make the suggested change.  
US 43 7.6 ¶ 4   The contexts in which an attribute-specifier can appear include statements, described in clause 6, but the crossreferences to clauses describing those contexts do not include clause 6.   Add clause 6 to the list of cross-references in the first sentence.   editor    ACCEPTED  
GB 30 7.6.1 ¶ 6   Making the use of [[ illegal except where introducing an attribute specifier is just reintroducing the problem we had with >> for closing nested templates, albeit in a minor and less common form. As Jason Merrill commented in c++std-core-16046, there is no ambiguity in practice because code couldn't actually be well-formed under interpretation as both an attribute specifier and a lambda introducer. A small amount of lookahead would be required to differentiate the cases, but this should not be a problem. This restriction also means that lambdas in macros must be enclosed in parentheses to avoid accidental interpretation as an illegal attribute specifier if used as an array index.   Delete 7.6.1 paragraph 6.   CWG    REJECTED

There was no consensus for reconsidering the previous explicit decision of the Committee on this issue.  
JP 23 7.6.1 ¶ 4   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(clause 7, clause 8)" to "(Clause 7, Clause 8)".   editor    ACCEPTED  
GB 31 7.6.2   After reviewing the case for attributes, wg14 has opted not to adopt this feature, and is instead using keywords for the few important cases identified in the attributes proposal. For compatibility with C, the change of the 'alignas' keyword to the '[[align]]' attribute should be reversed.   Revert the changes in the initial alignment proposal that changed the 'alignas' keyword into an attribute.   CWG  1115  ACCEPTED

See paper N3190 
GB 32 7.6.3   C has rejected the notion of attributes, and introduced the noreturn facility as a keyword. To continue writing clean, portable code we should replace the [[noreturn]] attribute with a 'noreturn' keyword, following the usual convention that while C obfuscates new keywords with _Capital and adds a macro to map to the comfortable spelling, C++ simply adopts the all-lowercase spelling.   Replace the [[noreturn]] attribute with a new keyword, 'noreturn', with identical semantics. Note that this implies the keyword will not be something that a function can be overloaded upon.   CWG  1132  REJECTED

There was no consensus to make the suggested change.  
US 44 7.6.5   Even if attributes continue to be standardized over continued objections from both of the two vendors who are cited as the principal prior art, we can live with them with the exception of the virtual override controls. This result is just awful, as already shown in the example in 7.6.5 (excerpted):
class D [[base_check]] : public B {
void sone_func [[override]] ();
virtual void h [[ hiding]] (char*);
};
Here we have six keywords (not counting void and char) three normal keywords, and three [[decorated]] keywords. There has already been public ridicule of C++0x about this ugliness. This is just a poor language design, even in the face of backward compatibility concerns (e.g., that some existing code may already use those words as identifiers) because those concerns have already been resolved in other ways in existing practice (see below)
More importantly, this is exactly the abuse of attributes as disguised keywords that was objected to and was explicitly promised not to happen in order to get this proposal passed. The use of attributes for the virtual control keywords is the most egregious abuse of the attribute syntax, and at least that use of attributes must be fixed by replacing them with non-attribute syntax. These virtual override controls are language features, not annotations.
It is possible to have nice names and no conflicts with existing code by using contextual keywords, such as recognizing the word as having the special meaning when it appears in a grammar position where no user identifier can appear, as demonstrated in C++/CLI which has five years of actual field experience with a large number of customers (and exactly no name conflict or programmer confusion problems reported in the field during the five years this has been available):
class D : public B {
void sone_func() override; // same meaning as
[[override]] - explicit override
virtual void h (char*) new; // same meaning as
[[hiding]] - a new function, not an override
};
int override = 42; // ok, override is not a
reserved keyword
The above forms are implementable, have been implemented, have years of practical field experience, and work. Developers love them. Whether the answer is to follow this existing practice or something else, there needs to be a more natural replacement for the currently [[attributed]] keywords for virtual override control which is an ugly novelty that has no field experience and that developers have already ridiculed.  
Change the syntax for virtual override control to not use attributes.   CWG  1133  ACCEPTED

See paper N3206 
US 45 7.6.5 ¶ 6   The example includes a line reading
class D [[base_check]] : public B {
However, the current syntax in 9p1 places the attribute-specifier before the class name.  
Change the example to read
class [[base_check]] D : public B {
 
editor    ACCEPTED  
CH 8 8.1 ¶ p1 (syntax)   'noptr-abstract-declarator:' rule misses 'opt' subscript from the constant expression within the array brackets. This seems to be an editorial oversight   change: "noptr-abstract-declaratoropt [ constant-expression ] attribute-specifieropt"
to
"noptrabstract-declaratoropt [ constant-expressionopt ] attribute-specifieropt"  
editor     
US 46 8.3.2 20.7.6.2 ¶ all Table 49   There is no way to create a prvalue of array type, so there ought to be no way create a (nonsensical) rvalue reference to array type.   In [dcl.ref]/2, disallow declarations of T (&&A)[].
In [dec.ref]/6 add a sentence: If a typedef, a type template-parameter, or a decltype-specifier denotes a type A that is an array type (of known or unknown size), an attempt to create the type “rvalue reference to cv A” creates the type A&.
In [meta.trans.ref]/Table 49 change the third row as follows:
If T names an array type, then the member typedef type shall name T&, otherwise if T names an object or function type...  
CWG    REJECTED

It is possible to create an array prvalue: an array member of a class prvalue is an array prvalue.  
GB 33 8.3.5 ¶ 5   The register keyword is deprecated, so does not make for a good example. Suggest substituting the new storage class specifier, 'thread_local', instead.   Use 'thread_local' in place of 'register' in the following sentance: "[ Example: register char* becomes char* end example ]"   CWG  1130  ACCEPTED with MODIFICATIONS

thread_local cannot be used for a parameter. However, storage class specifiers do not affect the type, so mentioning storage class specifiers was incorrect and has been removed.  
US 47 8.4.2   8.4.2 [dcl.fct.def.default]/4 says: "A special member function is user-provided if it is user-declared and not explicitly defaulted on its first declaration. A user-provided explicitly-defaulted function is..." The second sentence here should say "A user-declared explicitly-defaulted function is...".   Change
"A user-provided explicitly-defaulted function is..."
to
"A user-declared explicitly-defaulted function is...".  
CWG  1134  ACCEPTED with MODIFICATIONS  
GB 34 8.4.2 ¶ p2   It is confusing when a normative paragraph starts with a note. The note starting this paragraph, with its reference to 'this' relating to the previous paragraph and not the content that follows, should be moved into the first paragraph, or the rest of this paragraph after the note should start a new numbered paragraph.   The note starting this paragraph should be moved into the first paragraph, or the rest of this paragraph after the note should start a new numbered paragraph.   editor    ACCEPTED  
FI 1 8.4.2 [dcl.fct.def.default] ¶ Paragraph 2   It should be allowed to explicitly default a non-public special member function on its first declaration. It is very likely that users will want to default protected/private constructors and copy constructors without having to write such defaulting outside the class.   Strike the “it shall be public” bullet.   CWG  1135  ACCEPTED  
FI 2 8.4.2 [dcl.fct.def.default] ¶ Paragraph 2   It should be allowed to explicitly default an explicit special member function on its first declaration. It is very likely that users will want to default explicit copy constructors without having to write such defaulting outside of the class.   Strike the “it shall not be explicit” bullet. See Appendix 1 - Additional Details   CWG  1136  ACCEPTED  
FI 3 8.4.2 [dcl.fct.def.default] ¶ Paragraph 2   It should be allowed to explicitly default a virtual special member function on its first declaration. It is very likely that users will want to default virtual copy assignment operators and destructors without having to write such defaulting outside of the class.   Strike the “it shall not be virtual” bullet. See Appendix 1 - Additional Details   CWG  1137  ACCEPTED  
GB 35 8.5.1 ¶ 7   With the removal of the deprecated string-literal-to-nonconst-char* conversion, member 'b' of struct S should be declared as a 'const' char *.   Fix struct S as: "struct S { int a; const char* b; int c; };"   editor    ACCEPTED  
JP 71 8.5.1 ¶ 7   "char*" should be "const char *".
The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]".
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
There are many code fragments depending on the removed rule. They are ill-formed.  
Change to:
struct S { int a; const char* b; int c; };
S ss = { 1, "asdf" };
 
editor    ACCEPTED  
JP 72 8.5.1 ¶ 15   "char*" should be "const char *".
The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]".
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
There are many code fragments depending on the removed rule. They are ill-formed.  
Change to:
union u { int a; const char* b; };
u a = { 1 };
u b = a;
u c = 1; // error
u d = { 0, "asdf" }; // error
u e = { "asdf" }; // error
 
editor    ACCEPTED  
GB 36 8.5.1 ¶ 17   The 'b' member of union u should be declared const char * to better illustrate the expected cause of failures.   Update union u as: "union u { int a; const char* b; };"   editor    ACCEPTED  
US 48 8.5.3 ¶ 5   The rule "...or the reference shall be an rvalue reference and the initializer expression shall be an rvalue or have a function type" is stated in terms of the rvalue-ness of the expression rather than the eventual target of the reference; this leads to some undesirable results, such as
struct A { };
struct B {
operator A&();
};
A&& aref = B(); // binds to lvalue
(c++std-core-16305)  
Correct the formulation to deal with the rvalueness of the initializer after conversion to the appropriate type.   CWG  1138  ACCEPTED  
US 49 8.5.3 ¶ 5   The FCD does not specify direct binding for this example:
int i;
int main()
{
int&& ir = static_cast<int&&>(i);
ir = 42;
return (i != 42);
}
(c++std-core-16181)  
See Appendix 1 - Additional Details   CWG  1139  ACCEPTED  
GB 37 8.5.3   It seems that lvalues of any sort don't bind to non-const rvalue ref args, even if an intermediate temporary would be created. See the discussion at http://stackoverflow.com/questions/2748866/c0x-rvalue-references-and-temporaries.
I'll summarise that here: Assume that std::vector has push_back overloads declared as follows, with SFINAE omitted for clarity:
void push_back(const T &);
//Copies the const T & into the vector's storage
void push_back(T &&);
//Moves the T && into the vector's storage
Then this code appears to behave as commented, as of N3090:
const char * cchar = "Hello, world"; std::vector<std::string>
v;
v.push_back(cchar);
//makes a temporary string, copies the string
into vector storage using push_back(const T&)
v.push_back(std::string(cchar));
//makes a temporary string, moves the string into vector
storage using push_back(T&&)
v.push_back(std::move(cchar));
//makes a temporary string, moves the string into the
vector using push_back(T&&)
Johannes Schaub (litb) convincingly argued that the reason for this is clause 8.5.3/5 describing reference binding - it allows direct binding of lvalues, bindings that require conversion sequences to const lvalue refs, and rvalues to rvalue refs. But it doesn't allow for lvalues to ever bind to rvalue refs, even if an intermediate temporary would otherwise need to be created.
This isn't what I (as a user of std::vector) expect to happen. I expect all of these push_back calls to do the same thing, namely, select the push_back(T&&) overload, create a temporary string object from 'cchar', bind the temporary string to the argument, and hence move (not copy) the temporary string into vector's storage.
It seems particularly strange that v.push_back(cchar) "requires" an extra copy, but v.push_back(std::move(cchar)) does not. It almost seems like indicating that 'cchar' is potentially-movable (by casting it to an rvalue ref using std::move) allows moving from a completely different object - the temporary string.
I suggest extending the rules for initializing const lvalue refs via implicit conversions (8.5.3/5), to also apply to rvalue refs.
This also raises an additional question of whether lvalues of _copyable_ types should be copied into a temporary object so that they may bind to an rvalue ref. Allowing this would not affect const T&/T&& overload pairs. But it could be potentially useful when writing functions that wish to accept a number of rvalue refs to copyable-but-not-movable types (such as all C++03 classes with user-defined copy constructors), or when writing functions that "take apart" a number their arguments in a way that is different from a straightforward move (perhaps some tree operations would want to do this).
Conversely, it might seem odd that declarations such as:
string && s = string_lvalue;
string && s = string_rvalue_ref_variable;
//mistake, std::move(string_rvalue_ref_variable) was
intended
...would both silently copy their arguments and bind to the copy, instead of being invalid as they are now.
We believe this is core issue 953  
Possible wording: amend the second list item in 8.5.3/5:
Otherwise, the reference shall be an lvalue reference to a non-volatile const type (i.e., cv1 shall be const), or the reference shall be an rvalue reference [deleted the rest of the sentence]. [The last example would also need to be deleted.]  
CWG  1138  ACCEPTED  
DE 10 8.5.3 ¶ te   Reference binding rules for rvalue references should consider temporaries generated from lvalues by implicit conversions. Consider to postpone the lvalue/rvalue analysis of an expression to after the implicit conversion chain has been deduced. Example:
void f(std::string&&);
void g() {
f(std::string("hello")); // #1, ok
f("hello"); // #2, error,
// but should be the same as #1
}
 
  CWG  1138  ACCEPTED  
US 50 9 ¶ 9   the class "struct A { const int i; };" was a POD in C++98, but is not a POD under the FCD rules because it does not have a trivial default constructor; I believe that C++0x POD was intended to be a superset of C++98 POD.   change POD to be standard layout and trivially copyable?   CWG  1140  ACCEPTED  
FI 16 9 9 9 3.9 ¶ 5 trivial 6 std-layout 9 POD 10 literal type   There are definitions for these types in the text, yet it is left unclear what use these classifications have. The types are very close to each other, which makes them confusing. If the reader must rely on external references, then these references should be specified (which is undesirable, or even disallowed by ISO(?)). As it stands, there is an example for using standard-layout classes (with other programming languages). There are also uses specified for literal types. One can imagine many uses for these four/five types, so it is important to have a clear specification of the intent as to where each of these types is expected to be used.   It is necessary to have detailed information on the expected uses of standard-layout, trivial, trivially copyable, literal and POD types.   CWG    REJECTED

The current wording is clear enough.  
JP 81 9 ¶ 9   Missing description of acronym "POD", which existed in C++03: The acronym POD stands for "plain old data."   Add "The acronym POD stands for "plain old data." as an annotation.   editor    ACCEPTED  
US 51 9.2 [class.mem]   Non-static data member initializers have no implementation experience.   Either demonstrate a complete implementation of this feature or remove N2756 from the working paper prior the FDIS.   CWG  1141  C++/CLI has a very similar feature that has been implemented.  
US 52 9.3 ¶ 7   The current wording allows friend declarations to name member functions "after their class has been defined." This appears to prohibit a friend declaration in a nested class defined inside its containing class that names a member function of the containing class, because the containing class is still considered to be incomplete at that point.   Change the wording to allow a friend declaration of a "previously-declared member function."   CWG  1142  ACCEPTED  
US 53 9.3.1 [class.mfct.non-static]   Move semantics for *this have no implementation experience.   Either demonstrate a complete implementation of this feature or remove N1821 from the working paper prior the FDIS.   CWG  1143   
JP 73 9.3.1 ¶ 3   "char*" should be "const char *".
The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]".
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
There are many code fragments depending on the removed rule. They are ill-formed.  
Change to:
struct tnode {
char tword[20];
int count;
tnode *left;
tnode *right;
void set(const char*, tnode* l, tnode* r);
};
void tnode::set(const char* w, tnode* l, tnode* r) {
count = strlen(w)+1;
if (sizeof(tword)<=count)
perror("tnode string too long");
strcpy(tword,w);
left = l;
right = r;
}
void f(tnode n1, tnode n2) {
n1.set("abc",&n2,0);
n2.set("def",0,0);
}
 
editor    ACCEPTED  
US 54 9.5 [class.union]   Unrestricted unions have no implementation experience.   Either demonstrate a complete implementation of this feature or remove N2544 from the working paper prior the FDIS.   CWG    ACCEPTED

The feature has been implemented  
JP 74 9.5 ¶ 6   "char*" should be "const char *".
The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]".
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
There are many code fragments depending on the removed rule. They are ill-formed.  
Change to:
void f() {
union { int a; const char* p; };
a = 1;
p = "Jennifer";
}
 
editor    ACCEPTED  
GB 38 9.6   The signedness of bit-fields is the only time when 'signed int' is any different to just 'int'.
In C it is possible to remember whether a typedef uses 'signed' but in C++ it doesn't make sense and will result in ODR violations if A<long> and A<signed long> are not exactly equivalent.
This also causes portability problems because it is not specified whether typedefs such as int32_t are defined with 'signed' so using the <cstdint> types in bitfields is problematic.
It is common to want to guarantee a bit-field has a minimum number of bits, for which the <cstdint> types are useful, except that the signedness of a bit-field using int32_t might depend on both unspecified and implementation-defined behaviour.  
'signed int' should always be equivalent to 'int' in all contexts.
A possible alternative would be to specify that signed types in <cstdint> are declared with 'signed' so that using them for bit-fields has predictable results, but this doesn't address the ODR issue with A<long> and A<signed long>  
CWG  675  REJECTED

Resolving this question was not deemed essential for this revision of the Standard, but core language issue 675 remains open for possible consideration in a future revision.  
US 55 10.3 ¶ Paragraph 5   The following code not only does not compile on the compilers I've tested, but cannot be fixed through any combinations of forward references
class B {
public:
virtual B *f() = 0;
};
class D1 : public B {
public:
virtual D2 *f();
};
class D2 : public B {
public:
virtual D1 *f();
};
 
In the core mailing list, Daniel Krugler points out that the current wording is ambiguous as to whether this is legal (although an editorial example suggests otherwise), and observes that it should be OK as long as D2 is complete at the point of definition of D1::f. The standard should resolve the ambiguity by saying that D2 only needs to be complete at the point of definition of D1::f.
The core mailing list message text is below:
I would be happy, if the standard would just allow this, but IMO the current wording seems to be readable in different ways (e.g. Comeau rejects the code). I think the reason is that [class.virtual]/5 just says:
"The return type of an overriding function shall be either identical to the return type of the overridden function or covariant with the classes of the functions.[..]"
This restriction is IMO only necessary for the *definition* of D::f. Secondly p. 6 says:
"If the return type of D::f differs from the return type of B::f, the class type in the return type of D::f shall be complete at the point of declaration of D::f or shall be the class type D.[..]"
and shows the following example that explicitly forbids that (simplified):
struct Base {
virtual B* vf5();
};
class A;
struct Derived : public Base {
A* vf5(); // error: returns pointer to incomplete
class
};
 
CWG    REJECTED

It is necessary to be able to calculate the offsets applied to covariant return values when only the class definition is available.  
US 56 11.3 [class.access.decl]   Access declarations were deprecated in the 1998 standard and have no benefits over using declarations.   Remove access declarations from the working paper.   CWG  1144  ACCEPTED  
FI 4 12.1 [class.ctor] ¶ Paragraph 5   What effect does defaulting have on triviality? Related to FI 1, non-public special members defaulted on their first declaration should retain triviality, because they shouldn't be considered user-provided. Related to FI 3, defaulted member functions that are virtual should not be considered trivial, but there's no reason why non-virtuals could not be.
Furthermore, a class with a non-public explicitly-defaulted constructor isn't ever trivially constructible under the current rules. If such a class is used as a subobject, the constructor of the aggregating class should be trivial if it can access the non-public explicitly defaulted constructor of a subobject.  
Change the triviality rules so that a class can have a trivial default constructor if the class has access to the default constructors of its subobjects and the default constructors of the subobjects are explicitly defaulted on first declaration, even if said defaulted constructors are non-public.
See Appendix 1 - Additional Details  
CWG  1145  ACCEPTED  
FI 15 12.3.1 ¶ 2   12.3.1. 2: "A default constructor may be an explicit constructor; such a constructor will be used to perform default-initialization or value-initialization (8.5)."
12.3. 1 also says that an explicit ctor is different from a non-explicit ctor in that it is only invoked when direct-initialization (T a(1); T a{1}. presumably also T a;) or casting is used.
What are the scenarios for the default ctor where explicit actually matters? Temporaries, arrays, ??? When, if ever, is an explicit default ctor different from a non-explicit ctor?  
The difference between a no argument default constructor and an explicit no argument default constructor should be explained in the standard. If there is no difference, this should be explicitly specified.   CWG    REJECTED

The current wording is clear enough.  
US 57 12.3.2 [class.conv.fct]   Explicit conversion operators have no implementation experience.   Either demonstrate a complete implementation of this feature or remove N2437 from the working paper prior the FDIS.   CWG    ACCEPTED

The feature has been implemented.  
GB 39 12.4 ¶ 4   Contradiction between the note and normative language describing when defaulted function definitions might have an exception specification. (See 8.4.2p2 for requirement to provide the exception specification)   Either strike the second sentance of this note, or update it to reflect under which conditions a defaulted definition might have an exception specification.   CWG  1146  ACCEPTED  
GB 40 12.4   It is very difficult to write correct programs that do not call 'terminate' in the presence of destructors that can throw exceptions, and this practice has long been discouraged. Many implicitly declared destructors already carry noexcept declarations (mostly types with trivial destructors) and it is anticipated it will become common practice to want a user-declared destructor to be declared noexcept. This becomes important evaluating the noexcept operator, where any of the unevaluated subexpressions may produce a temporary object. As this is expected to be the overwhelmingly common case, a user-declared destructor that does not supply an exception specification should be considered as if declared noexcept(true) rather than noexcept(false), the default for every other function.   a user-declared destructor that does not supply an exception specification should be considered as if declared noexcept(true) rather than noexcept(false), the default for every other function   CWG  1147  ACCEPTED with MODIFICATIONS

The rule that was adopted makes destructors noexcept if all the base and member destructors are.

See paper N3204 
CH 9 12.4 and 15.4   Destructors should generally not throw exceptions. Consider giving an explicit rule for this.   Add in 12.4 or 15.4 a paragraph to the effect that all destructors not having an exception soecification are considered noexcept(true).   CWG  1147  ACCEPTED with MODIFICATIONS

The rule that was adopted makes destructors noexcept if all the base and member destructors are.

See paper N3204 
US 58 12.5 ¶ foot 117   Missing comma in "is not virtual the size might".   Add the comma.   editor    REJECTED

Because of the comma later in the sentence, a comma here would be wrong.  
US 59 12.6.2 [class.base.init]   Delegating constructors have no implementation experience.   Either demonstrate a complete implementation of this feature or remove N1986 from the working paper prior the FDIS.   CWG    ACCEPTED

The feature has been implemented.  
US 60 12.8 [class.copy]   Implicitly-defined move constructors and move assignment operators have no implementation experience.   Either demonstrate a complete implementation of this feature or remove N3053 from the working paper prior the FDIS.   CWG    ACCEPTED

The feature has been implemented.  
DE 11 12.8   It is unclear whether copy elision can or cannot apply to a case like C f(C c) { return c; }, i.e. where a parameter of class type is returned. Furthermore, if copy elision cannot apply there, it should still be possible to move (instead of copy) the return value.   Amend paragraph 34 to explicitly exclude function parameters from copy elision. Amend paragraph 35 to include function parameters as eligible for move-construction.   CWG  1148  ACCEPTED  
FI 5 12.8 [class.copy] ¶ Paragraph 13, paragraph 27   Same as FI 4, the parts involving copy constructors and copy assignment operators.
A class with a non-public explicitly-defaulted copy constructor isn't ever trivially copyable under the current rules. If such a class is used as a subobject, the copy constructor of the aggregating class should be trivial if it can access the non-public explicitly defaulted copy constructor of a subobject.  
Change the triviality rules so that a class can have a trivial copy constructor if the class has access to the copy constructors of its subobjects and the copy constructors of the subobjects are explicitly defaulted on first declaration, even if said defaulted copy constructors are non-public. See Appendix 1 - Additional Details   CWG  1149  ACCEPTED  
GB 41 12.8 ¶ 15, 29   Contradiction between the notes claiming that defaulted definitions to not have exception specifications, and the normative language in 8.4.2 which declares that they might.   Either strike the second sentance of each note, or update it to reflect under which conditions a defaulted definition might have an exception specification.   CWG  1146  ACCEPTED  
US 61 12.8;20.2.5 ¶ 17,31;table 42   static_cast is broken across two lines   do not hyphenate static_cast   editor    ACCEPTED  
US 62 12.8 ¶ 16   The new wording describing generated copy constructors does not describe the initialization of members of reference type. (Core issue 1051 in N3083.)   Add the required description.   CWG  1051  ACCEPTED  
US 63 12.8 ¶ 16-18   The new wording specifies the behavior of an implicitlydefined copy constructor for a non-union class (p16), an implicitly-defined move constructor for a non-union class (p17), and an implicitly-defined copy constructor for a union (p18), but not an implicitly-defined move constructor for a union. (Core issue 1064 in N3083.)   Add the required description.   CWG  1064  ACCEPTED  
US 64 12.8 ¶ 28   The current wording reads, "A copy/move assignment operator that is defaulted and not defined as deleted is implicitly defined when an object of its class type is assigned a value of its class type or a value of a class type derived from its class type or when it is explicitly defaulted after its first declaration." This sounds as if any assignment to a class object, regardless of whether it is a copy or a move assignment, defines both the copy and move operators. Presumably an assignment should only define the assignment operator chosen by overload resolution for the operation. (Compare the corresponding wording in p14 for the copy/move constructors: "...implicitly defined if it is used to initialize an object of its class type..." (Core issue 1066 in N3083.)   Clarify the wording so that only the operator needed for the operation is implicitly defined.   CWG  1066  ACCEPTED  
US 65 12.9 [class.inhctor]   Inheriting constructors have no implementation experience.   Either demonstrate a complete implementation of this feature or remove N2540 from the working paper prior the FDIS.   CWG  1150   
JP 65 13.1 ¶ 3   In some code examples, ellipsis(...) is used in ill-formed. In these cases, "..." represents omission of some codes like this:
class A { /* ... */ } ;
But in some cases, it is used without commented-out as below:
class A { ... } ;
It is an inconsistent usage. They all should be enclosed in a comment.  
Change to:
int f (int) { /* ... */ } // definition of f(int)
int f (cInt) { /* ... */ } // error: redefinition of f(int)
 
editor    ACCEPTED  
US 66 13.3.1.7 ¶ 1   overload resolution should first look for a viable list constructor, then look for a non-list constructor if no list constructor is viable   See Appendix 1 - Additional Details   CWG  1151  ACCEPTED  
US 67 13.3.2 ¶ 3   To determine whether there is an ICS, 13.3.2 uses 13.3.3.1 instead of just saying “there is an ICS if-and-only-if a copy init would be well-formed.” Apparently this is desired, but to a casual reader or an implementor reading these rules for the first time for a new implementation, it's not clear why that's desired.   Insert a note or annex explaining why 13.3.2 does things as it does.   CWG  1152  ACCEPTED with MODIFICATIONS

The resolution for core language issue 1152 fixes a related problem, but a rationale was not deemed necessary at this time.  
JP 75 13.2 ¶ 1   "char*" should be "const char *".
The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]".
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
There are many code fragments depending on the removed rule. They are ill-formed.  
Change to:
struct B {
int f(int);
};
struct D : B {
int f(const char*);
};
 
editor    ACCEPTED  
JP 76 13.2 ¶ 2   "char*" should be "const char *".
The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]".
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
There are many code fragments depending on the removed rule. They are ill-formed.  
Change to:
void f(const char*);
void g() {
extern void f(int);
f("asdf"); // error: f(int) hides f(const char*)
// so there is no f(const char*) in this scope
}
 
editor    ACCEPTED  
JP 77 13.3.1.2 ¶ 1   "char*" should be "const char *".
The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]".
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
There are many code fragments depending on the removed rule. They are ill-formed.  
Change to:
struct String {
String (const String&);
String (const char*);
operator char* ();
};
String operator + (const String&, const String&);
void f(void) {
char* p= "one" + "two"; // ill-formed because
neither
// operand has user-defined type
int I = 1 + 1; // Always evaluates to 2 even if
// user-defined types exist which
// would perform the operation.
}
 
editor    ACCEPTED  
US 68 13.4 ¶ 1   Overload resolution within the operand of a unary & operator is done by selecting the function "whose type matches the target type required in the context." The criterion for determining whether the types match, however, is not defined. At least three possibilities suggest themselves:
1. The types are identical.
2. The source type can be implicitly converted to the target type.
3. The expression would be well-formed if the function under consideration were not overloaded.
This question arises for pointer-to-member types, where there is an implicit conversion from a pointer-to-base-member to a pointer-to-derived-member, as well as when the context is an explicit type conversion (which allows for static_cast a conversion from pointer-to-derived-member to a pointer-to-base-member and, in the reinterpret_cast interpretation of functional and old-style casts, essentially any conversion).  
Specify the intended criterion for determining whether the types match.   CWG  1153  ACCEPTED  
JP 82 13.5.8 ¶ 8   Typo, "lteral" should be "literal".
// error: invalid lteral suffix identifier  
Correct typo.
// error: invalid literal suffix identifier  
editor    ACCEPTED  
US 69 14.3.2 ¶ para 1   The standard permits the address of thread_local variable as a non-type template parameter. The addresses of these variables are not constant, however.   Require static storage duration for non-type parameters.   CWG  1154  ACCEPTED  
DE 12 14.3.2   Now that local classes can be used as template arguments, it seems odd that there are "external linkage" restrictions on non-type template parameters.   Permit addresses of objects and functions with internal linkage as arguments for non-type template parameters.   CWG  1155  ACCEPTED  
JP 78 14.3.2 ¶ 2   "char*" should be "const char *". If not corrected, type mismatch is another cause of error in the example below, which is not appropriate for an example here.
template<class T, char* p> class X {
X();
X(const char* q) { / ... / }
};
X<int, "Studebaker"> x1; // error: string literal as templateargument
char p[] = "Vivisectionist";
X<int,p> x2; // OK
 
template<class T, const char* p> class X {   editor    ACCEPTED  
JP 83 14.3.2 ¶ 2   Constructors in template declaration are not essential for this example to explain string literal error use.
template<class T, char* p> class X {
X();
X(const char* q) { /* ... */ }
};
X<int, "Studebaker"> x1; // error: string literal as templateargument
char p[] = "Vivisectionist";
X<int,p> x2; // OK
 
Delete two constructors in template declaration as follows.
template<class T, const char* p> class X {
/* ... */
};
X<int, "Studebaker"> x1; // error: string literal as
template-argument
char p[] = "Vivisectionist";
X<int,p> x2; // OK
 
editor    ACCEPTED  
GB 42 14.5.3 ¶ 1   The name "eror" should probably be "error".   Replace:
Tuple<0> eror;
With:
Tuple<0> error;
 
editor    ACCEPTED  
JP 24 14.5.3 ¶ 4   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(10)" to "(Clause 10)".   editor    ACCEPTED  
US 70 14.5.6.2 ¶ 2, 4   14.8.2.4p3 specifies that the deduction used in partial ordering in a non-call context is based on the complete function type of the function templates. The wording in 14.5.6.2p2 (and echoed in p4) reflects an earlier specification, however, saying that the deduction uses only "the function parameter types, or in the case of a conversion function the return type." This is a contradiction.   Update the wording in 14.5.6.2 to say only that deduction is performed as described in 14.8.2.4 and not to specify which types are used.   CWG  1156  ACCEPTED  
US 71 unused ¶ unused           ACCEPTED  
CA 7 14.5.6.2p3 ¶ P3   r country In FCD sub-clause 14.5.6.2 [temp.func.order] paragraph 3, we are told to synthesize, "for each type, non-type, or template template parameter... a unique type, value, or class template respectively." These are then substituted for each occurrence of the respective parameter in the function type of the function template. It is not specified what the properties of said synthetics are, for example, members of a dependent type referred to in non-deduced contexts are not specified to exist, although the transformed function type would be invalid if they do not exist. We may assume, for example, that each synthetic will be given minimal properties such that the transformed function type is valid at the point of definition of the template.
Example 1:
template <typename T, typename U> struct A; template <typename T> void foo(A<T, typename T::u> *) { } // #1 // synthetic T1 has member T1::u template <typename T> void foo(A<T, typename T::u::v> *) { } // #2 // synthetic T2 has member T2::u and member T2::u::v // T in #1 deduces to synthetic T2 in partial ordering; // deduced A for the parameter is A<T2, T2::u> *--this is not necessarily compatible // with A<T2, T2::u::v> * and it does not need to be. See Note 1. The effect is that // (in the call below) the compatibility of B::u and B::u::v is respected. // T in #2 cannot be successfully deduced in partial ordering from A<T1, T1::u> *; // invalid type T1::u::v will be formed when T1 is substituted into non-deduced contexts. struct B { struct u { typedef u v; }; }; int main() { foo((A<B, B::u> *)0); // calls #2 } *Note 1: Template argument deduction is an attempt to match a P and to a deduced A; however, template argument deduction is not specified to fail if the P and the deduced A are incompatible. This may occur in the presence of non-deduced contexts. Notwithstanding the parenthetical statement in [temp.deduct.partial] paragraph 9, template argument deduction may succeed in determining a template argument for every template parameter while producing a deduced A that is not compatible with the corresponding P.
Example 2:
template <typename T, typename U, typename V> struct A; template <typename T> void foo(A<T, struct T::u, struct T::u::u> *); #2.1 // synthetic T1 has member non-union class T1::u template <typename T, typename U> void foo(A<T, U , U> *); #2.2 // synthetic T2 and U2 has no required properties // T in #2.1 cannot be deduced in partial ordering from A<T2, U2, U2> *;// invalid types T2::u and T2::u::u will be formed when T2 is substituted in nondeduced contexts. // T and U in #2.2 deduces to, respectively, T1 and T1::u from A<T1, T1::u, struct T1::u::u> * unless // struct T1::u::u does not refer to the injected-class-name of the class T1::u (if that is possible). struct B { struct u { }; }; int main() { foo((A<B, B::u, struct B::u::u> *)0); // calls #2.1 } It is however unclear to what extent an implementation will have to go to determine these minimal properties.  
This is a test of the interpretation of the resolution to Issue 214. In particular, we would like for the committee to spell out how properties of the synthetics produced for partial ordering are determined   CWG  1157  REJECTED

Resolving this issue was not deemed essential for this revision of the Standard. Core language issue 1157 was opened, however, to allow for possible consideration for a future revision.  
US 72 14.5.7 [temp.alias]   Template aliases have no implementation experience.   Either demonstrate a complete implementation of this feature or remove N2258 from the working paper prior the FDIS.   CWG    ACCEPTED

The feature has been implemented.  
US 73 14.5.7 ¶ 1   The current wording of 7.1.3p2 requires that the identifier in an alias-declaration "...shall not appear in the type-id." With template aliases, however, the name of the alias can be used indirectly:
template<typename T> struct A;
template<typename T> using B=typename A<T>::U;
template<typename T> struct A {
typedef B<T> U;
};
B<short> b;
Here the instantiation of B<short> causes the instantiation of A<short>, and the typedef in A<short> ends up attempting to use B<short>, which is still in the process of being instantiated.  
Add wording to indicate that such usages in template aliases are ill-formed.   CWG  1158  ACCEPTED  
US 74 14.5.7 ¶ 1   An alias-declaration allows a class or enumeration type to be defined in its type-id (7.1.6p3). However, it's not clear that this is desirable when the alias-declaration is part of a template alias:
template<typename T> using A =
struct { void f(T) { } };
 
Either prohibit the definition of classes and enumerations in template aliases, or prohibit the use of template parameters in such definitions, or add an example illustrating this usage.   CWG  1159  ACCEPTED

Definition of a class or enumeration is now prohibited in a template alias.  
FI 10 14.5.7 [temp.alias]   Can template aliases be declared in class scope?   Allow declaring template aliases in class scope, if not allowed by the current grammar.   CWG  924  ACCEPTED  
FI 11 14.5.7 [temp.alias]   We have class templates and function templates, shouldn't we call template aliases alias templates for consistency?   Change “template alias” -> “alias template” everywhere.   editor     
JP 25 14.5.7 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(clause 7)" to "(Clause 7)".   editor    ACCEPTED  
JP 26 14.6.2.1 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(9)" to "(Clause 9)".   editor    ACCEPTED  
GB 43 14.6.2.1p3   If I'm not missing something, 14.6.2.1/3 says that in the definition of a class template or member of a class template, the injected-class-name refers to the current instantiation. The template name followed by the argument list enclosed in “<..>” also refers to the current instantiation, but only in the definition of a primary class template. That results in an odd situation:
template<typename T> struct A { typedef int type; void f(type); }; // here we are outside the definition of 'A'
template<typename T> void A::f(A::type) { } // OK: 'A' is the injected-class-name
template<typename T> void A::f(A<T>::type) { } // ill-formed: 'A<T>' is not the injected-class-name. Needs 'typename '!
If you would define the member-function within the primary class template, bullet 2 would apply:
template<typename T> struct A {
typedef int type; void f(A<T>::type) { } // OK: name of A followed by arguments enclosed in <..>
};
I think that this state of affairs isn't any good.
-> Suggested solution: Change 14.6.2.1/1 bullet2 to apply also to members of the primary class template. The same for bullet4 talking about partial specializations. Since partial specializations are also class templates, i wonder whether one could also smelt together bullet2 and bullet4 and only talk about “class template”.  
Updated 14.6.2.1 [temp.dep.type] p1 bullet 2: " in the definition of a primary class template or a member of a class template, the name of the class template followed by the template argument list of the primary template (as described below) enclosed in <>,"   CWG  1160  ACCEPTED  
GB 44 14.6p5   C++0x does not allow this code
template<typename T> struct id { typedef T type; };
template<typename T> void f() { int id<T>::type::*p = 0; }
struct A { };
int main() { f<A>(); }
The reason is that it requires “typename” before “id<T>::type”, but “typename” is not allowed at that place by the syntax. Ultimately, current compilers accept this.  
Change 14.6/5 to
A qualified name used as the name in a mem-initializer-id, a base-specifier, an elaborated-type-specifier or the nested-name-specifier of a pointer-to-member declarator is implicitly assumed to name a type, without the use of the typename keyword.  
CWG  1161  ACCEPTED  
CA 6 14.6p5 ¶ P5   Given the change in N1376=02-0034 to [temp.res], found in FCD in [temp.res] paragraph 5:
A qualified name used as the name in a mem-initializer-id, a base-specifier, or an elaborated-type-specifier is implicitly assumed to name a type, without the use of the typename keyword
the following appears to be well-formed, with templates foo() being distinct since any type T will produce an invalid type for the second parameter for at least one foo() when T is replaced within the non-deduced context:
template <typename T>
bool *foo(T *, enum T::u_type * = 0) { return 0; }
template <typename T> char *foo(T *, struct T::u_type * =
0) { return 0; }
struct A { enum u_type { I }; }; int main(void) { foo((A*)0); }
In particular, while determining the signature (1.3.11 [defns.signature]) for the function templates foo(), an elaborated-type-specifier qualifies as part of the decl-specifier-seq under 8.3.5 [dcl.fct] paragraph 5 in determining the type of a parameter in the parameter-type-list (absent additional wording). Also, the return type is included in the signature of a function template.
A portion of the GCC 4.5.0 output:
Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See < http://gcc.gnu.org/bugs.html > for instructions.
Implementations do not appear to support this case and the ability to do so brings little value since type traits such as is_enum and is_class cannot be defined using this and equivalent functionality can be achieved using the aforementioned type traits.
template <typename T> struct MY_is_enum :
std::false_type { };
template <typename T> struct MY_is_enum<enum T> :
std::true_type { }; // ill-formed,
elaborated-type-specifier resolves to typedef-name  
Please clarify as the following case appears to be expensive to implement with little functional value to the language.   CWG  1162  REJECTED

The specification is as intended; compilers should handle cases like these.  
US 75 14.7   As described in c++std-core-16425 and its followup messages, writing metaprograms is needlessly hard because specializing template members inside a class is (inadvertently?) not permitted. In addition, this surprising restriction makes C++ less simple and more arbitrary-seeming.   Accept the code like that in c++std-core-16425, like Visual C++ does already   CWG    REJECTED

There was no consensus for making the suggested change.  
JP 79 14.7.1 ¶ 10   "char*" should be "const char *".
The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]".
char * p1 = "..." ; // ill-formed.(removing constness)
char const *p2 = "..." ;// well-formed.
There are many code fragments depending on the removed rule. They are ill-formed.  
Change to:
namespace N {
template<class T> class List {
public:
T* get();
};
}
template<class K, class V> class Map {
public:
N::List<V> lt;
V get(K);
};
void g(Map<const char*,int>& m) {
int i = m.get("Nicholas");
}
a call of lt.get() from Map<const char*,int>::get() would place List<int>::get() in the namespace N rather than in the global namespace. —end example ]  
editor    ACCEPTED  
FI 9 14.7.3 [temp.expl.spec] ¶ Paragraph 2   Explicit specializations in class scope inside class templates should be allowed. It's weird, confusing and inconsistent that they can be declared/defined in some scopes but not in others.   Allow explicit specialization of member templates inside class templates.   CWG    REJECTED

There was no consensus for making the suggested change.  
JP 80 14.8.1 ¶ 5   "char*" should be "const char *".
The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]".
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
There are many code fragments depending on the removed rule. They are ill-formed.  
Change to:
template<class X, class Y, class Z> X f(Y,Z);
template<class ... Args> void f2();
void g() {
f<int,const char*,double>("aa",3.0);
f<int,const char*>("aa",3.0); // Z is deduced to be
double
f<int>("aa",3.0); // Y is deduced to be const char*,
and
// Z is deduced to be double
f("aa",3.0); // error: X cannot be deduced
f2<char, short, int, long>(); // OK
}
 
editor    ACCEPTED  
US 76 14.8.2 ¶ para 9   "extern template" prevents inlining functions not marked inline.   Remove wording about "suppressing the implicit instantiation". See Appendix 1 - Additional Details   CWG  1163  REJECTED

Section reference should be 14.7.2. The suggested change could result in a silent change of meaning between implementations if speculative instantiation for inlining is allowed.  
US 77 14.8.2.1   Core Issue 1014 claims that calling f(const T&) and f(T&&) with a const int lvalue is ambiguous. It's unambiguous because the partial ordering rules consider f(const T&) to be more specialized than f(T&&), for the same reasons that they consider h(const T&) to be more specialized than h(T&).
However, calling z(T&) and z(T&&) with an int lvalue is ambiguous. Because z(T&) accepts a strict subset of the things that z(T&&) accepts, it seems that the partial ordering rules should be modified to consider z(T&) to be more specialized than z(T&&). There may be additional subtleties.  
Modify the partial ordering rules to consider z(T&) to be more specialized than z(T&&).   CWG  1164  ACCEPTED  
US 78 15.2 ¶ 2   This paragraph says that "An object that is... partially destroyed will have destructors executed... for subobjects for which the principal constructor (12.6.2) has completed execution and the destructor has not yet begun execution." This would presumably apply to an example like
struct S { ~S(); } s[10];
If the destructor for s[5] throws an exception, elements 0-4 should still be destroyed. However, the wording specifically refers to "fully constructed base classes and non-variant members," even though array elements are subobjects of the array (1.8p2). This is presumably the effect of stack unwinding (p1), which applies to "all automatic objects constructed since the try block was entered," but whether that should also be expected for arrays of static, thread, and dynamic storage duration is not clear.  
Clarify the intent with respect to array elements and storage duration.   CWG  1165  ACCEPTED  
GB 45 15.3 ¶ 16   The phrasing of this clause suggests all exception-declarations produce objects. There should be some additional wording to clarify that exception-declarations that declare references bind to the exception object by appropriate initialization, and *are* allowed to be references to abstract classes. Likewise, the elipsis form does not initialize any object or temporary.   Distinguish between initializing objects, initializing references, and initializing nothing in the case of an elipsis.   CWG  1166  REJECTED

Resolving this issue was not deemed essential for this revision of the Standard. However, issue 1166 was opened for possible consideration in a future revision.  
CA 5 15.3p8, 15.1p7 ¶ P8, p7   There is an issue with the definition of "currently handled exception" in 15.3 [except.handle] paragraph 8:
The exception with the most recently activated handler that is still active is called the currently handled exception.
This wording implies that the currently handled exception may be changed by another thread. Thus, by 15.1 [except.throw] paragraph 7,
A throw-expression with no operand rethrows the currently handled exception (15.3).
the following may throw an exception that is not of type int. try { throw 0; } catch (...) { throw; } Any solution should also specify what the currently handled exception will be for a thread that is spawned during the handling of an exception by its parent.  
Clarify and fix as suggested.   CWG  1218  ACCEPTED  
US 79 15.4 ¶ p1   Because C has no exception mechanism, functions having "C" language linkage should implicitly be declared noexcept.   Insert a sentence such as:
Any function declared to have "C" linkage shall be treated as if declared noexcept even if the declaration lacks the noexcept keyword.  
CWG    REJECTED

There was no consensus for making the suggested change.  
GB 46 15.4   It is not entirely clear that a function-try-block on a destructor will catch exceptions for a base or member destructor destructor; whether such exceptions might be swallowed with a simple return statement rather than being rethrown; and whether such a clause might be entered multiple times if multiple bases/members throw, or if that is an automatic terminate call.   [Add words to 15.4 clarifying the problem cases.]   CWG  1167  ACCEPTED  
CH 10 15.4 ¶ p9   In case of incorrect program specification, the general rule is that the behaviour is undefined. This should be true for noexcept as well.   Change the second bullet of p9 to "otherwise, the behaviour is undefined.   CWG    REJECTED

There was no consensus to reconsider the explicit decision of the Committee on this point.  
GB 47 15.5.1 ¶ 1   15.5.1:1 [except.terminate] lists the situations in which "exception handling must be abandoned for less subtle error handling techniques". The list seems to omit some new situations added by other c++0x features.   The list should be augmented with the following:
  • when function std::nested_exception::rethrow_nested is called for an object that stores a null exception pointer.
  • when execution of a function registered with std::at_quick_exit exits using an exception.
Also, after the list, add the following sentence:
Function std::terminate is also called by the implementation, when the destrductor or a copy constructor of a class std::thread is called for the object that is joinable.  
CWG  1168  ACCEPTED  
GB 48 15.5.2 ¶ 1-4   This subclause is dealing exclusively with dynamic exception specifications, and should clearly say so.   Replace each italicised occurrence of 'exceptionspecification' with 'dynamic-exceptionspecification' in clause 15.5.2, [except.unexpected]   editor    ACCEPTED  
GB 49 15.5.2 ¶ all   Dynamic exception specifications are deprecated, so clause 15.5.2 that describes how they work should move to Annex D.   Move 15.5.2 [except.unexpected] to Annex D.   CWG    REJECTED

The convention in the core clauses is to note the deprecation but leave the specification in situ.  
CH 11 16.1 ¶ p3   constant-expression as given by C++'s grammar allows far more syntactical constructs than those that are allowed in preprocessor context. The footnote 145 provides some hints on the limitations, but in our opinion it should be made more clear that the "constant-expression" allows less than a lookup of the corresponding grammar rule suggests   Add a note or extend footnote 145 with "Note that constant-expression is much more limited than the C++ grammar rule would suggest. See the following paragraphs how it is limited in the context of conditional inclusion."   editor    REJECTED

The current wording is the same as in C++03, and hasn't caused confusion.  
CH 12 16.3.5 ¶ p5   missing space between '~' and '5' in expansion   line
"f(2 * (2+(3,4)-0,1)) | f(2 *
(~5)) & f(2 * (0,1))^m(0,1);"
should read
"f(2 * (2+(3,4)-0,1)) | f(2 * (~
5)) & f(2 * (0,1))^m(0,1);"
 
editor    ACCEPTED  
CH 13 16.3.5 ¶ p7   superfluous braces in source   change
"int j[] = { t(1,2,3), t(,4,5),
t(6,{,}7), t(8,9,),"
to
"int j[] = {
t(1,2,3), t(,4,5), t(6,,7), t(8,9,),"
 
editor    ACCEPTED  
CH 14 16.3.5 ¶ p9   superfluous spaces after/before parentheses   change
fprintf(stderr, "Flag" );
fprintf(stderr, "X = %d\n", x );
puts( "The first, second, and
third items." );
to
fprintf(stderr, "Flag");
fprintf(stderr, "X = %d\n", x);
puts("The first, second, and third
items.");
 
editor    ACCEPTED  
DE 13 16.8   Committee Draft comment DE 18 has only been partially addressed, and the record of response ignores the missing item, namely the absence of a macro __STDCPP_STRICT_POINTER_SAFETY__ that indicates that a given implementation has strict pointer safety (see 3.7.4.3).   Add the macro to the list of predefined macros in 16.8.   CWG  1169  ACCEPTED  
US 80 [library] 17 - 30   Consider applying noexcept to all of the std::lib.     LWG  1347  ACCEPTED with MODIFICATIONS

See paper N3155 
GB 60 17-30   Dyanamic exception specifications are deprecated; the library should recognise this by replacing all non-throwing exception specifications of the form 'throw()' with the 'noexcept' form.   Replace all non-throwing exception specifications of the form 'throw()' with the 'noexcept' form.   LWG  1344  ACCEPTED with MODIFICATIONS

See documents N3148, N3150, N3195, N3155, N3156, N3199, and N3180.

See paper N3148 
GB 61 17-30   All library types should have non-throwing move constructors and move-assignment operators unless wrapping a type with a potentially throwing moveoperation. When such a type is a class-template, these operations should have a conditional noexcept specification.
There are many other places where a noexcept specification may be considered, but the move operations are a special case that must be called out, to effectively support the move_if_noexcept function template.  
Review every class and class template in the library. If noexcept move constructor/assignment operators can be implicitly declared, then they should be implicitly declared, or explicitly defaulted. Otherwise, a move constructor/moveassingment operator with a 'noexcept' exception specification should be provided.   LWG  1345   
GB 62 17-30   Issues with efficiency and unsatisfactory semantics mean many library functions document they do not throw exceptions with a Throws: Nothing clause, but do not advertise it with an exception specification. The semantic issues are largely resolved with the new 'noexcept' specifications, and the noexcept operator means we will want to detect these guarantees programatically in order to construct programs taking advantage of the guarantee.   Add a 'noexcept' exception specification on each libary API that offers an unconditional Throws: Nothing guarantee. Where the guarantee is conditional, add the appropriate noexcept(constant-expression) if an appropriate constant expression exists.   LWG  1346  ACCEPTED with MODIFICATIONS

See paper N3195 
GB 63 17-30   Since the newly introduced operator noexcept makes it easy (easier than previously) to detect whether or not a function has been declared with the empty exception specification (including noexcept) library functions that cannot throw should be decorated with the empty exception specification. Failing to do so and leaving it as a matter of QoI would be detrimental to portability and efficiency.   Review the whole library, and apply the noexcept specification where it is appropriate.   LWG  1347  ACCEPTED with MODIFICATIONS

See paper N3155 
GB 64 17-30   There are a number of unspecified types used throughout the library, such as the container iterators. Many of these unspecified types have restrictions or expectations on their behaviour in terms of exceptions. Are they permitted or required to use exception specifications, more specifically the new noexcept specification? For example, if vector<T>::iterator is implemented as a native pointer, all its operations will have an (effective) nothrow specification. If the implementation uses a class type to implement this iterator, is it permitted or required to support that same guarantee?   Clearly state the requirements for exception specifications on all unspecified library types. For example, all container iterator operations should be conditionally noexcept, with the condition matching the same operation applied to the allocator pointer_type, a certain subset of which are already required not to throw.   LWG  1348   
GB 65 17-30   Nothrowing swap operations are key to many C++ idioms, notably the common copy/swap idiom to provide the strong exception safety guarantee.   Where possible, all library types should provide a swap operation with an exception specification guaranteeing no exception shall propagate. Where noexcept(true) cannot be guaranteed to not terminate the program, and the swap in questions is a template, an exception specification with the appropriate conditional expression could be specified.   LWG  1349   
GB 66 17-30   The syntax for attributes was altered specifically to make it legal do declare attributes on functions by making the attribute the first token in the declaration, rather than inserting it between the function name and the opening paren of the parameter list. This is much more readable, and should be the preferred style throughout the library. For example, prefer:
[[noreturn]] void exit(int status);
to
void exit [[noreturn]] (int status);  
Update all function declarations throughout the library to use the preferred placement of functionlevel attributes.   editor    ACCEPTED  
CH 15 Library clauses   Due to the new rules about implicit copy and move constructors some library facilities are now move-only.   Make them copyable again.   LWG  1421, 1350   
CH 16 Library clauses   Dynamic exception specifications are deprecated. Deprecated features shouldn't be used in the Standard.   Replace dynamic exception specifications with noexcept.   LWG  1351  ACCEPTED with MODIFICATIONS

See documents N3148, N3150, N3195, N3155, N3156, N3199, and N3180.

See paper N3148 
CH 17 Library clauses   The introduction of noexcept makes "Throws: Nothing" clauses looking strange.   Consider replacing "Throws: Nothing." clause by the respective noexcept specification.   LWG  1352  ACCEPTED with MODIFICATIONS

See paper N3195 
CH 18 17   The general approach on moving is that a library object after moving out is in a "valid but unspecified state". But this is stated at the single object specifications, which is error prone (especially if the move operations are implicit) and unnecessary duplication.   Consider putting a general statement to the same effect into clause 17.   LWG  1353   
JP 27 17.1 ¶ 9   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(25)" to "(Clause 25)".   editor    ACCEPTED  
GB 52 17.3.7   The definition of deadlock in 17.3.7 excludes cases involving a single thread making it incorrect.   The definition should be corrected.   LWG  1354  ACCEPTED with MODIFICATIONS  
GB 50 17.3.13   This definition of move-assignment operator redundant and confusing now that the term move-assignment operator is defined by the core language in subclause 12.8p21.   Strike suclause 17.3.13 [defns.move.assign.op]. Add a cross-reference to (12.8) to 17.3.12.   LWG  1355  ACCEPTED with MODIFICATIONS

See paper N3142 
GB 51 17.3.14   This definition of move-constructor redundant and confusing now that the term constructor is defined by the core language in subclause 12.8p3.   Strike subclause 17.3.14, [defns.move.ctor]   LWG  1356  ACCEPTED with MODIFICATIONS

See paper N3142 
JP 67 17.5.2.1.2 ¶ 2   In some code examples, ellipsis(...) is used in ill-formed. In these cases, "..." represents omission of some codes like this:
class A { /* ... */ } ;
But in some cases, it is used without commented-out as below:
class A { ... } ;
It is an inconsistent usage. They all should be enclosed in a comment. In addition, the number of period should be 3 rather than 5.  
Change to:
enum bitmask {
V0 = 1 << 0, V1 = 1 << 1, V2 = 1 << 2, V3 = 1 <<
3, ...
};
static const
/* ... */
 
editor    REJECTED

This is pseudo-code; okay as written.  
GB 53 17.5.2.1.3   The bitmask types defined in 27.5.2 and 28.5 contradict the bitmask type requirements in 17.5.2.1.3, and have missing or incorrectly defined operators.   See Appendix 1 - Additional Details   LWG  1357  ACCEPTED with MODIFICATIONS

See paper N3110 
GB 54 17.5.2.1.4.x   The defined terms NTC16S, NTC32S, NTWCS, char16-character sequence, null-terminated char16-character string, char32-character sequence, null-terminated char32-character string, wide-character sequence and null-terminated wide-character string do not occur at any point in the standard outside their definitional subclauses and associated footnotes.   Strike 17.5.2.1.4.3, 17.5.2.1.4.4, 17.5.2.1.4.5 and associated footnotes 170, 171, 172, 173, 174 and 175.   editor    ACCEPTED  
GB 55 17.6.1.3 ¶ Table 15   The thread header uses duration types, found in the <chrono> header, and which rely on the ratio types declared in the <ratio> header.   Add the <chrono> and <ratio> headers to the freestanding requirements. It might be necessary to address scaled-down expectations of clock support in a freestanding environment, much like <thread>.   LWG  1358   
GB 56 17.6.1.3 ¶ Table 15   The <utility> header provides support for several important C++ idioms with move, forward and swap. Likewise, declval will be frequently used like a type trait. In order to complete cycles introduced by std::pair, the <tuple> header should also be made available. This is a similarly primitive set of functionality, with no dependency of a hosted environment, but does go beyond the minimal set of functionality otherwise suggested by the freestanding libraries. Alternatively, split the move/forward/swap/declval functions out of <utility> and into a new primitive header, requiring only that of freestanding implementation.   Add <utility> and <tuple> to table 15, headers required for a free-standing implementation.   LWG  1359  REJECTED

No consensus for a change at this time.  
GB 57 17.6.1.3 ¶ Table 15   The atomic operations facility is closely tied to clause 1 and the memory model. It is not easily supplied as an after-market extension, and should be trivial to implement of a single-threaded serial machine. The consequence of not having this facility will be poor interoperability with future C++ libraries that memory model concerns seriously, and attempt to treat them in a portable way.   Add <atomic> to table 15, headers required for a free-standing implementation.   LWG  1360  ACCEPTED  
GB 58 17.6.2   It is not clear whether a library header specified in terms of a typedef name makes that same typedef name available for use, or if it simply requires that the specified type is an alias of the same type, and so the typedef name cannot be used without including the specific header that defines it. For example, is the following code required to be accepted:
#include <vector>
std::size_t x = 0;
Most often, this question concerns the typedefs defined in header <cstddef>  
Add a paragraph under 17.6.2 clarifying whether or not headers specified in terms of std::size_t can be used to access the typedef size_t, or whether the header <cstddef> must be included to reliably use this name.   LWG  1361  REJECTED

The standard is correct as written.  
GB 59 17.6.3.6 ¶ 2   The replaceable functions in header <new> are all described in clause 18.6 [support.dynamic], where it can be seen that all the listed functions have an exception specification which must be compatible with any replacement function. Narrow the reference to (Clause 18) to (Clause 18.6).   Add the missing exception specification on each function signature:
void* operator new(std::size_t size) throw(std::bad_alloc);
void* operator new(std::size_t size, const std::nothrow_t&) throw();
void operator delete(void* ptr) throw();
void operator delete(void* ptr, const std::nothrow_t&) throw();
void* operator new[](std::size_t size) throw(std::bad_alloc);
void* operator new[](std::size_t size, const std::nothrow_t&) throw();
void operator delete[](void* ptr) throw();
void operator delete[](void* ptr, const std::nothrow_t&) throw();
(note that other comments might further want to replace 'throw()' with 'noexcept')  
editor    ACCEPTED with MODIFICATIONS

Cross-reference changed as requested. Additions to name mentions not done: these are not declarations.  
US 81 17.6.3.9 ¶ p1   International Standards do not make “statements”; they “specify” or “require” instead.   s/statements/ specifications/   editor    ACCEPTED with MODIFICATIONS

Removed the offending word.  
US 82 17.6.3.9 ¶ p1, bullet 3   The second Note can benefit by adopting recent nomenclature.   Rephrase the Note in terms of xvalue.   LWG  1362  ACCEPTED with MODIFICATIONS  
US 83 17.6.3.10 ¶ p2, first sent.   The word “constructor” is misspelled.   s/contructor/constructor/   editor    ACCEPTED  
GB 68 18.2 ¶ 4   There is no reason for the offsetof macro to invoke potentially throwing operations, so the result of noexcept(offsetof(type,member-designator)) should be true.   Add to the end of 18.2p4:
"No operation invoked by the offsetof macro shall throw an exception, and noexcept(offsetof(type,member-designator)) shall be true."  
LWG  1363  ACCEPTED  
JP 68 18.3.1.5 ¶ 2   In some code examples, ellipsis(...) is used in ill-formed. In these cases, "..." represents omission of some codes like this:
class A { /* ... */ } ;
But in some cases, it is used without commented-out as below:
class A { ... } ;
It is an inconsistent usage. They all should be enclosed in a comment. More over, in this case, "implementation-defined" would be better than "...".  
Change to:
inline static constexpr float infinity() throw() {
return /* ... */; }
inline static constexpr float quiet_NaN() throw() {
return /* ... */; }
inline static constexpr float signaling_NaN()
throw() { return /* ... */; }
 
editor    ACCEPTED with MODIFICATIONS

Replaced "..." by "value".  
JP 84 18.5 ¶ 5 note   Note in paragraph 5 says "the atexit() functions shall not introduce a data race" and Note in paragraph 10 says "the at_quick_exit() functions do not introduce ...". Such different expressions in similar functions are confusing. If these notes are written for unspecified behaviors just before the sentence, "do" would be preferred.   Replace "shall" with "do".   editor    ACCEPTED  
GB 69 18.5 ¶ 14   ("The function quick_exit() never returns to its caller.") should be removed as redundant. The function is already attributed with [[noreturn]].   Remove paragraph 14   editor    ACCEPTED  
CH 19 18.8.5   It's not clear how exception_ptr is synchronized.   Make clear that accessing in different threads multiple exception_ptr objects that all refer to the same exception introduce a race.   LWG  1364   
GB 70 18.6   std::nothrow_t is a literal type (being an empty POD) so the preferred form of declaration for std::nothrow is as a constexpr literal, rather than an extern symbol.   Replace:
extern const nothrow_t nothrow;
with
constexpr nothrow_t nothrow{};  
LWG    REJECTED

There was consensus that it is too late to make such a change at this time.  
GB 71 18.6.2.4 / 18.8.2.2 / 18.8.3.2   The thread safety of std::set_new_handler(), std::set_unexpected(), std::set_terminate(), is unspecified making the the functions impossible to use in a thread safe manner.   The thread safety guarantees for the functions must be specified and new interfaces should be provided to make it possible to query and install handlers in a thread safe way.   LWG  1365  ACCEPTED with MODIFICATIONS

See paper N3189 
DE 14 18.6.1.4   It is unclear how a user replacement function can simultaneously satisfy the race-free conditions imposed in this clause and query the new-handler in case of a failed allocation with the only available, mutating interface std::set_new_handler.   Offer a non-mutating interface to query the current new-handler.   LWG  1366  ACCEPTED with MODIFICATIONS

See paper N3189 
GB 72 18.8.2   Dynamic exception specifications are deprecated, so clause 18.8.2 that describes library support for this facility should move to Annex D, with the exception of the bad_exception class which is retained to indicate other failures in the exception dispatch mechanism (e.g. calling current_exception()).   With the exception of 18.8.2.1 [bad.exception], move clause 18.8.2 diectly to Annex D. [bad.exception] should simply become the new 18.8.2.   LWG  1367  ACCEPTED  
GB 73 18.8.4   The thread safety std::uncaught_exception() and the result of the function when multiple threads throw exceptions at the same time are unspecified. To make the function safe to use in the presence of exceptions in multiple threads the specification needs to be updated.   Update this clause to support safe calls from multiple threads without placing synchronization requirements on the user.   LWG  1368  ACCEPTED with MODIFICATIONS  
GB 74 18.8.5 ¶ 10   One idea for the exception_ptr type was that a referencecounted implementation could simply 'reactivate' the same exception object in the context of a call to 'rethrow_exception'. Such an implementation would allow the same exception object to be active in multiple threads (such as when multiple threads join on a shared_future) and introduce potential data races in any exception handler that catches exceptions by reference - notably existing library code written before this capability was added. 'rethrow_exception' should *always* make a copy of the target exception object.   Throws: a copy of the exception object to which p refers.   LWG  1369   
US 84 18.8.6 [except.nested] ¶ 6-7   The throw_with_nested spec passes in its argument as T&& (perfect forwarding pattern), but then discusses requirements on T without taking into account that T may be an lvalue-reference type. It is also not clear in the spec that t is intended to be perfectly forwarded.   Patch 6-7 to match the intent with regards to requirements on T and the use of std::forward<T>(t).   LWG  1370  ACCEPTED with MODIFICATIONS  
GB 75 19   None of the exception types defined in clause 19 are allowed to throw an exception on copy or move operations, but there is no clear specification that the operations have an exception specification to prove it. Note that the implicitly declared constructors, taking the exception specification from their base class (ultimately std::exception) will implicitly generate a noexcept exception specification if all of their data members similarly declare noexcept operations. As the representation is unspecified, we cannot assume nonthrowing operations unless we explicitly state this as a constraint on the implementation.   Add a global guarantee that all exception types defined in clause 19 that rely on implicitly declared operations have a non-throwing exception specification on those operations.   LWG  1371   
GB 76 19.5.1.5   The C++0x FCD recommends, in a note (see 19.5.1.1/1), that users create a single error category object for each user defined error category and specifies error_category equality comparsions based on equality of addresses (19.5.1.3). The Draft apparently ignores this when specifying standard error category objects in section 19.5.1.5, by allowing the generic_category() and system_category() functions to return distinct objects for each invocation.   Append a new sentence to 19.5.1.5 [syserr.errcat.objects]/1, which reads "All calls of this function return references to the same object.", and append the same sentence to 19.5.1.5/3.   LWG  1372  ACCEPTED  
GB 77 19.5.6.2 ¶ 14   The description for system_error::what (19.5.6.2/14) changed between the C++ Working Papers N2914 and N2960. The latter document indicates that the Returns clause shall read "Returns: An NTBS incorporating the arguments supplied in the constructor.". Instead, in the FCD it now reads "Returns: An NTBS incorporating and code().message() the arguments supplied in the constructor.".  Remove the extra words from 19.5.6.2 [syserr.syserr.members]/14: "Returns: A NTBS incorporating the arguments supplied in the constructor."   editor    ACCEPTED  
GB 78 19.5.6.2   The FCD contains a requirement that all standard classes which are derived from std::exception have a copy constructor and copy assignment operator which essentially copy the stored what() message (See 18.8.1/2). In contrast, it is unspecified whether copies of system_error return the same error_code on calls to system_error::code().   Insert a new paragraph after 19.5.6.1 [syserr.syserr.overview]/1 which reads "The copy constructor and copy assignment operator of class system_error both have a strengthened postcondition which supplements the basic postcondition for standard library exception classes copy construction and copy assigment (18.8.1): If two objects lhs and rhs both have type system_error and lhs is a copy of rhs, then lhs.code() == rhs.code() shall hold."   LWG    REJECTED

This is already addressed by 17.5.2.2 [functions.within.classes]/1.  
GB 79 20, 22, 24, 28   The library provides several traits mechanisms intended a customization points for users. Typically, they are declared in headers that are growing quite large. This is not a problem for standard library vendors, who can manage their internal file structure to avoid large dependencies, but can be a problem for end users who have no option but to include these large headers.   Move the following traits classes into their own headers, and require the existing header to #include the traits header to support backwards compatibility:
iterator_traits (plus the iterator tag-types)
allocator_traits
pointer_traits
char_traits
regex_traits  
LWG  1373  REJECTED

This suggest is not a defect, as the likely benefit is small, if any, compared to the cost of not just implementating the feature, but also explaining/teaching it.  
US 85 20.2.1 ¶ Table 34   20.2.1 Table 34 "MoveConstructible requirements" says "Note: rv remains a valid object. Its state is unspecified". Some components give stronger guarantees. For example, moved-from shared_ptrs are guaranteed empty (20.9.11.2.1/25). In general, what the standard really should say (preferably as a global blanket statement) is that moved-from objects can be destroyed and can be the destination of an assignment. Anything else is radioactive. For example, containers can be "emptier than empty". This needs to be explicit and required generally.
Note: The last time that one of us mentioned "emptier than empty" (i.e. containers missing sentinel nodes, etc.) the objection was that containers can store sentinel nodes inside themselves in order to avoid dynamically allocating them. This is unacceptable because (a) it forces existing implementations (i.e. Dinkumware's, Microsoft's, IBM's, etc.) to change for no good reason (i.e. permitting more operations on moved-from objects), and (b) it invalidates end iterators when swapping containers. (The Working Paper currently permits end iterator invalidation, which we consider to be wrong, but that's a separate argument. In any event, *mandating* end iterator invalidation is very different from permitting it.)  
State as a general requirement that moved-from objects can be destroyed and can be the destination of an assignment. Any other use is undefined behavior.   LWG  1374   
GB 80 20.2.3 ¶ 2   See (A) in attachment std_issues.txt   as stated in the attached paper   LWG    REJECTED  
CA 10 20.2.3p2 ¶ 20.2.3p2   Reads of indeterminate value result in undefined behaviour
In 20.2.3p2, NullablePointer requirements [nullablepointer.requirements], the standard specifies the behaviour of programs that read indeterminate values:
... A default-initialized object of type P may have an indeterminate value. [ Note: Operations involving indeterminate values may cause undefined behaviour. end note ]
We suggest changing the note to:
[ Note: Operations involving indeterminate values cause undefined behaviour. end note ]
Rationale: The note uses the word "may", but we believe the intention is that such reads will cause undefined behaviour, but implementations are not required to produce an error.
Clark adds:
> Unfortunately, this issue goes deeper than can be
> addressed by deleting the word "may" from a note in
> clause 20. The term "indeterminate value" and its
> meaning were introduced in C99. While the term is
> generally understood to be applicable to C++ (and
> section 20.2.3 reflects that), the term isn't actually
> defined in the C++ WD, and worse yet, there's no
> statement that use of an indeterminate value can result
> in undefined behavior (so the existing note can't be
> deduced from the normative statements of the
standard). > This is tracked by core issue 616. The wording in
> 20.2.3 should be noted as relating to that issue, and
> should be handled as part thereof.
Further on this, in the current draft standard, we can construct executions in which an atomic read happensbefore the initialization of the atomic object, so there is no place to take a read value from. We imagine that such reads should also be of indeterminate values and result in undefined behaviour?  
In 20.2.3p2, the standard specifies the behaviour of programs that read indeterminate values:
... A default-initialized object of type P may have an indeterminate value. [ Note: Operations involving
We suggest changing the note to:
[ Note: Operations involving indeterminate values cause undefined behaviour. end note ]  
LWG    REJECTED

It is an accurate statement because there is at least one operation, assignment with the indeterminate value on the left hand side, that does not involve undefined behavior.  
US 86 20.2.5 ¶ Table 42   In the row for X::propagate_on_container_move_assignment, the note says “copied” when it should say “moved”   Change the note as follows:
true_type only if an allocator of type X should be copiedmoved  
editor    ACCEPTED  
US 87 20.2.5 ¶ Table 42   reference_type should not have been removed from the allocator requirements. Even if it is always the same as value_type&, it is an important customization point for extensions and future features.   Add a row (after value_type) with columns:
Expression: X::reference_type
Return type: T&
Assertion/note...: (empty)
Default: T&
[allocator.traits]: Add reference_type to allocator_traits template, defaulted to value_type&.  
LWG  1375   
US 88 20.2.5   Allocator interface is not backward compatible.   See Appendix 1 - Additional Details   LWG  1376  REJECTED

Withdrawn by the submitter.  
US 89 20.3 [utility]   make_pair is missing from the <utility> synopsis.   Add template <class T1, class T2> pair<V1, V2> make_pair(T1&&, T2&&); to the synopsis in [utility].   editor    ACCEPTED  
GB 81 20.3 ¶ 1   make_pair should be declared in the synopsis of <utility>   add to 20.3 [utility] paragraph 1:
template
see below make_pair(T1&&, T2&&);  
editor    ACCEPTED  
GB 82 20.3 ¶ 1   The <utility> synopsis precedes the tuple_size and tuple_element declarations with a comment saying "// 20.3.5, tuple-like access to pair:" but the sub-clause should be 20.3.5.3 and the comment should probably be below those declarations (since they, like the tuple declaration above them, are defined in <tuple> and are not related to pair.)
Also, there should be a comment above piecewise_construct_t giving the sub-clause 20.3.5.5, and it should be at the end of the synopsis,  
correct the sub-clause reference for tuple-like access to 20.3.5.3, move the comment after the uple_element declaration, and add "// defined in <tuple>" to the tuple_size and tuple_element declarations. Move the piecewise_construct_t and piecewise_constrct declarations to the end of the synopsis and precede them with "// 20.3.5.5 Piecewise construction"   editor    ACCEPTED  
US 90 20.3 ¶ 3   In n3090, at variance with previous iterations of the idea discussed in papers and incorporated in WDs, std::forward is constrained via std::is_convertible, thus is not robust wrt access control. This causes problems in normal uses as implementation detail of member functions. For example, the following snippet leads to a compile time failure, whereas that was not the case for an implementation along the lines of n2835 (using enable_ifs instead of concepts for the constraining, of course)
#include <utility>
struct Base { Base(Base&&); };
struct Derived
: private Base
{
Derived(Derived&& d)
: Base(std::forward<Base>(d)) { }
};
In other terms, LWG 1054 can be resolved in a better way, the present status is not acceptable.  
  LWG  1377  ACCEPTED with MODIFICATIONS

See paper N3143 
JP 28 20.3.1 ¶ 2   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(31)" to "(Clause 31)".   editor    ACCEPTED with MODIFICATIONS

Changed to "(Table 31)".  
JP 29 20.3.1 ¶ 4, 6, 8   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(32)" to "(Clause 32)".   editor    ACCEPTED with MODIFICATIONS

Changed to "(Table 32)".  
JP 30 20.3.2 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(34)" to "(Table 34)".
Change "(36)" to "(Table 36)".  
editor    ACCEPTED  
US 91 Merged with US 90       LWG  1377  ACCEPTED with MODIFICATIONS

See paper N3143 
US 92 20.3.3   std::identity was removed from 20.3.3 [forward], apparently because std::forward() no longer needs it. However, std::identity was useful by itself (to disable template argument deduction, and to provide no transformation when one is requested).   Restore std::identity, possibly in a different section.   LWG    REJECTED

No consensus to restore at this time. common_type can be used for the use case given.  
US 93 20.3.3 ¶ 6   When teaching C++0x, students have consistently found the name std::move confusing because it doesn't actually move the object (it just makes it possible to move). It was also confusing for me.   Choose a name that expresses the semantics more clearly. Suggestion: std::unpin       REJECTED

No consensus for a change.  
US 94 20.3.3 ¶ 9   Returns clause for move_if_noexcept d refers to a nonexistent symbol, t, which should be x.   Modify the Returns clause:
Returns: std::move(tx).  
editor    ACCEPTED  
DE 15 20.3.5.2, 20.4.2.1   Several function templates of pair and tuple allow for too many implicit conversions, for example:
#include <tuple>
std::tuple<char*> p(0); // Error?
struct A { explicit A(int){} };
A a = 1; // Error
std::tuple<A> ta = std::make_tuple(1); // OK?
 
Consider to add wording to constrain these function templates.   LWG  1378  ACCEPTED with MODIFICATIONS

See paper N3140 
JP 31 20.5.1 ¶ 2   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(section 3.9)" to "(3.9)".   editor    ACCEPTED  
GB 84 20.3.5.2   [pairs.pair] defines the class template pair as well as related non-member functions such as comparison operators and make_pair. The related non-member functions should be in a separate sub-clause, otherwise it's not clear that paragraphs below 17 do not refer to members of pair.   Create a new "Pair specialized algorithms" section containing everything below paragraph 17 in [pairs.pair]   editor    ACCEPTED  
US 95 20.3.5.2 ¶ 9   Copy-assignment for pair is defaulted and does not work for pairs with reference members. This is inconsistent with conversion-assignment, which deliberately succeeds even if one or both elements are reference types, just as for tuple. The copy-assignment operator should be consistent with the conversion-assignment operator and with tuple's assignment operators.   Add to pair synopsis:
pair& operator=(const pair& p);
Add before paragraph 9:
pair& operator=(const pair& p);
Requires: T1 and T2 shall satisfy the requirements of CopyAssignable.
Effects: Assigns p.first to first and p.second to second.
Returns: *this.  
LWG  1379  ACCEPTED with MODIFICATIONS

See paper N3140 
DE 16 20.3.5.2, 20.4.2.1   Several pair and tuple functions in regard to move operations are incorrectly specified if the member types are references, because the result of a std::move cannot be assigned to lvalue-references. In this context the usage of the requirement sets MoveConstructible and CopyConstructible also doesn't make sense, because non-const lvalue-references cannot satisfy these requirements.   Replace the usage of std::move by that of std::forward and replace MoveConstructible and CopyConstructible requirements by other requirements.   LWG  1380  ACCEPTED with MODIFICATIONS

See paper N3140 
GB 85 20.3.5.4   While std::pair may happen to hold a pair of iterators forming a valid range, this is more likely a coincidence than a feature guaranteed by the semantics of the pair template. A distinct range-type should be supplied to enable the new for-loop syntax rather than overloading an existing type with a different semantic.   Strike 20.3.5.4 and the matching declarations in 20.3 header synopsis. If a replacement facility is required for C++0x, consider n2995.   LWG  1381  ACCEPTED with MODIFICATIONS  
ES 1 20.3.5.4 [pair.range]   Using pair to represent a range of iterators is too general and does not provide additional useful restrictions (see N2995 and preceding papers).   Provide a separate template range<Iterator>.   LWG    REJECTED

No consensus to make this change.  
US 96 20.3.5.2 20.4.2.1 20.4.2.2 ¶ p 6-14 p 6-20 p 6-18   pair and tuple constructors and assignment operators use std::move when they should use std::forward. This causes lvalue references to be erroneously converted to rvalue references. Related requirements clauses are also wrong.   See Appendix 1 - Additional Details   LWG  1382  ACCEPTED with MODIFICATIONS

See paper N3140 
US 97 20.3.5.2 and 20.4.2   pair's class definition in N3092 20.3.5.2 [pairs.pair] contains "pair(const pair&) = default;" and "pair& operator=(pair&& p);". The latter is described by 20.3.5.2/12-13.
"pair(const pair&) = default;" is a user-declared explicitlydefaulted copy constructor. According to 12.8 [class.copy]/10, this inhibits the implicitly-declared move constructor. pair should be move constructible. (12.8/7 explains that "pair(pair<U, V>&& p)" will never be instantiated to move pair<T1, T2> to pair<T1, T2>.)
"pair& operator=(pair&& p);" is a user-provided move assignment operator (according to 8.4.2 [dcl.fct.def.default]/4: "A special member function is userprovided if it is user-declared and not explicitly defaulted on its first declaration."). According to 12.8/20, this inhibits the implicitly-declared copy assignment operator. pair should be copy assignable, and was in C++98/03. (Again, 12.8/7 explains that "operator=(const pair<U, V>& p)" will never be instantiated to copy pair<T1, T2> to pair<T1, T2>.)
Additionally, "pair& operator=(pair&& p);" is unconditionally defined, whereas according to 12.8/25, defaulted copy/move assignment operators are defined as deleted in several situations, such as when non-static data members of reference type are present.
If "pair(const pair&) = default;" and "pair& operator=(pair&& p);" were removed from pair's class definition in 20.3.5.2 and from 20.3.5.2/12-13, pair would receive implicitly-declared copy/move constructors and copy/move assignment operators, and 12.8/25 would apply. The implicitly-declared copy/move constructors would be trivial when T1 and T2 have trivial copy/move constructors, according to 12.8/13, and similarly for the assignment operators, according to 12.8/27. Notes could be added as a reminder that these functions would be implicitly-declared, but such notes would not be necessary (the Standard Library specification already assumes a high level of familiarity with the Core Language, and casual readers will simply assume that pair is copyable and movable).
Alternatively, pair could be given explicitly-defaulted copy/move constructors and copy/move assignment operators. This is a matter of style.
tuple is also affected. tuple's class definition in 20.4.2 [tuple.tuple] contains:
tuple(const tuple&) = default;
tuple(tuple&&);
tuple& operator=(const tuple&);
tuple& operator=(tuple&&);
They should all be removed or all be explicitly-defaulted, to be consistent with pair. Additionally, 20.4.2.1 [tuple.cnstr]/8-9 specifies the behavior of an explicitlydefaulted function, which is currently inconsistent with pair.  
Either remove "pair(const pair&) = default;" and "pair& operator=(pair&& p);" from pair's class definition in 20.3.5.2 and from 20.3.5.2/12-13, or give pair explicitly-defaulted copy/move constructors and copy/move assignment operators.
Change tuple to match.  
LWG  1383  ACCEPTED with MODIFICATIONS

See paper N3140 
GB 86 20.4   tuple and pair are essentially two implementations of the same type, with the same public interface, and their specification in becoming increasingly intertwined. The tuple library should be merged into the <utility> header to reduce library dependencies and simplify user expectations. The <tuple> header could optionally be retained as a deprecated alias to the <utility> header.   Merge everything declared in 20.4 into the <utility> header. Either remove the <tuple> header entirely, or move it to Annex D as a deprecated alias of the <utility> header.   LWG    REJECTED

There was no consensus to make this change.  
US 98 20.4.2.4 ¶ Paragraph 4   pack_arguments is poorly named. It does not reflect the fact that it is a tuple creation function and that it forwards arguments.   Rename pack_arguments to forward_as_tuple throughout the standard.   LWG  1384  ACCEPTED  
GB 88 20.4.2.4   The tuple_cat template consists of four overloads and that can concatenate only two tuples. A single variadic signature that can concatenate an arbitrary number of tuples would be preferred.   Adopt a simplified form of the proposal in n2795, restricted to tuples and neither requiring nor outlawing support for other tuple-like types.   LWG  1385   
US 99 20.4.2.4 ¶ 4 - 6   pack_arguments is overly complex.   This issue resulted from a lack of understanding of how references are forwarded. The definition of pack_arguments should be simply:
template <class... Types> tuple<ATypes&&> pack_arguments(Types&&...t);
Types:Let Ti be each type in Types....
Effects: ...
Returns:
tuple<ATypes&&...>(std::forward<Types>(t)...)
The synopsis should also change to reflect this simpler signature.  
LWG  1386  ACCEPTED  
GB 87 20.4.2.10   There is no compelling reason to assume a heterogeneous tuple of two elements holds a pair of iterators forming a valid range. Unlike std::pair, there are no functions in the standard library using this as a return type with a valid range, so there is even less reason to try to adapt this type for the new for-loop syntax.   Strike 20.4.2.10 and the matching declarations in the header synopsis in 20.4.   LWG  1387  ACCEPTED  
US 100 20.6.1 [ratio.ratio]   LWG 1281 was discussed in Pittsburgh, and the decision there was to accept the typedef as proposed and move to Review. Unfortunately the issue was accidentally applied to the FCD, and incorrectly. The FCD version of the typedef refers to ratio<N, D>, but the typedef is intended to refer to ratio<num, den> which in general is not the same type.   Accept the current proposed wording of LWG 1281 which adds:
typedef ratio<num, den> type;  
LWG  1388  ACCEPTED  
GB 89 20.6.2   The alias representations of the ratio arithmetic templates do not allow implementations to avoid overflow, since they explicitly specify the form of the aliased template instantiation. For example ratio_multiply,ratio<2,LLONG_MAX>> is *required* to alias ratio<2*LLONG_MAX,LLONG_MAX*2>, which overflows, so is ill-formed. However, this is trivially equal to ratio<1,1>. It also contradicts the opening statement of 20.6.2p1 "implementations may use other algorithms to compute these values".   Change the wording in 20.6.2p2-5 as follows:
template <class R1, class R2> using ratio_add = see below;
The type ratio_add<R1, R2> shall be a synonym for ratio<T1,T2> ratio<U, V> such that ratio<U,V>::num and ratio<U,V>::den are the same as the corresponding members of ratio<T1,T2> would be in the absence of arithmetic overflow where T1 has the value R1::num * R2::den + R2::num * R1::den and T2 has the value R1::den * R2::den. If the required values of ratio<U,V>::num and ratio<U,V>::den cannot be represented in intmax_t then the program is illformed.
template <class R1, class R2> using ratio_subtract = see below;
The type ratio_subtract<R1, R2> shall be a synonym for ratio<T1,T2> ratio<U, V> such that ratio<U,V>::num and ratio<U,V>::den are the same as the corresponding members of ratio<T1,T2> would be in the absence of arithmetic overflow where T1 has the value R1::num * R2::den - R2::num * R1::den and T2 has the value R1::den * R2::den. If the required values of ratio<U,V>::num and ratio<U,V>::den cannot be represented in intmax_t then the program is illformed.
template <class R1, class R2> using ratio_multiply = see below;
The type ratio_multiply<R1, R2> shall be a synonym for ratio<T1,T2> ratio<U, V> such that ratio<U,V>::num and ratio<U,V>::den are the same as the corresponding members of ratio<T1,T2> would be in the absence of arithmetic overflow where T1 has the value R1::num * R2::num and T2 has the value R1::den * R2::den. If the required values of ratio<U,V>::num and ratio<U,V>::den cannot be represented in intmax_t then the program is illformed.
template <class R1, class R2> using ratio_divide = see below;
The type ratio_divide<R1, R2> shall be a synonym for ratio<T1,T2> ratio<U, V> such that ratio<U,V>::num and ratio<U,V>::den are the same as the corresponding members of ratio<T1,T2> would be in the absence of arithmetic overflow where T1 has the value R1::num * R2::den and T2 has the value R1::den * R2::num. If the required values of ratio<U,V>::num and ratio<U,V>::den cannot be represented in intmax_t then the program is illformed.  
LWG  1389  ACCEPTED with MODIFICATIONS

See paper N3210 
US 101 20.7   Paper n2965 was largely rejected after the last CD on the grounds there was no associated national body comment, so I am submitting a national body comment this time.   Consider n2965 in the context of a national body comment.   LWG    REJECTED

There is no consensus to adopt this proposal at this time.  
GB 90 20.7   type_traits is a core support facility offered by the compiler, and exposed with a library interface that is required in a free-standing implementation. It has far more in common with numeric_limits than the utility components in clause 20, and should move to clause 18.   Move clause 20.7 into clause 18.   editor    REJECTED

Type traits support queries about all types, not just built-in types. They do not belong in Clause 18.  
DE 17 20.7   Speculative compilation for std::is_constructible and std::is_convertible should be limited, similar to the core language (see 14.8.2 paragraph 8).     LWG  1390  ACCEPTED with MODIFICATIONS

See paper N3142 
DE 18 20.7   Several type traits require compiler support, e.g. std::is_constructible or std::is_convertible. Their current specification seems to imply, that the corresponding test expressions should be well-formed, even in absense of access:
class X { X(int){} };
constexpr bool test = std::is_constructible<X, int>::value;
The specification does not clarify the context of this test and because it already goes beyond normal language rules, it's hard to argue by means of normal language rules what the context and outcome of the test should be.  
Specify that std::is_constructible and std::is_convertible will return true only for public constructors/conversion functions.   LWG  1391  ACCEPTED with MODIFICATIONS

See paper N3142 
US 102 20.7.4   Despite Library Issue 520's ("Result_of and pointers to data members") resolution of CD1, the FCD's result_of supports neither pointers to member functions nor pointers to data members. It should.   Ensure result_of supports pointers to member functions and pointers to data members.   LWG  1392  ACCEPTED with MODIFICATIONS

See paper N3123 
GB 91 20.7.4.3 ¶ Table 45   It is mildly distasteful to dereference a null pointer as part of our specification, as we are playing on the edges of undefined behaviour. With the addition of the declval function template, already used in these same expressions, this is no longer necessary.   Replace the sub-expression '*(U*)0' with the subexpression 'declval<U&>()' in the specification for has_nothrow_copy_assign and has_nothrow_move_assign type traits.   editor    REJECTED

There is no undefined behavior because the expression is an unevaluated operand. It's not at all clear that the proposed change would be clearer.

See paper N3142 
GB 92 20.7.4.3 ¶ Table 45   Trivial functions implicitly declare a noexcept exception specification, so the references to has_trivial_* traits in the has_nothrow_* traits are redundant, and should be struck for clarity.   For each of the has_nothrow_something traits, remove all references to the matching has_trivial_something traits.   LWG  1393  ACCEPTED with MODIFICATIONS

See paper N3142 
FI 18 20.7.4.3, Table 45 (Type property predicates)   Related to the change proposed in FI 17, there should be a trait for checking whether a destructor throws.   Add the following type predicate: Template
template <typename T> struct
has_nothrow_destructor;
Condition
has_trivial_destructor<T>::value is true or the expression noexcept((*(U*)0).~U()) is well-formed and true, where U is remove_all_extents<T>::type.
Precondition
T shall be a complete type, (possibly cv-qualified) void, or an array of unknown bound.
Reasoning:
With this metafunction the destructor of a class template can adjust its noexcept specification depending on whether destructors of its unbound members (or unbound base classes) might throw:
template <typename T>
struct C
{
T t;
~C()
noexcept(has_nothrow_destructor<T>::value) {}
};
 
LWG    REJECTED

No consensus to make this change at this time.

See paper N3142 
DE 19 20.7.4.3   The fundamental trait is_constructible reports false positives, e.g.
is_constructible<char*, void*>::value
evaluates to true, even though a corresponding variable initialization would be ill-formed.  
Remove all false positives from the domain of is_constructible.   LWG  1394  ACCEPTED with MODIFICATIONS

See paper N3047 
JP 32 20.7.5 ¶ 2, table 47   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(10)" to "(Clause 10)".   LWG  1395  ACCEPTED  
GB 93 20.7.6.2 ¶ Table 49   The comments for add_rvalue_reference say "this rule reflects the semantics of reference collapsing", but reference collapsing is not defined anywhere.   Add a new sentence at the end of 8.3.2p6 "This is called reference collapsing". Add a reference to 8.3.2 to the use of "reference collapsing" in 20.7.6.2/table 49   LWG    REJECTED  
US 103 20.7.6.6 [meta.trans.other]   The current definition of result_of works for function pointers but the condition statement outlaws them. There is even an example in the WP that shows result_of working for function pointers.   Add “pointer to function” to the list of things that Fn shall be.   LWG    REJECTED

Standard is correct as written.  
US 104 28.8   std::basic_regex should have an allocator for all the reasons that a std::string does. For example, I can use boost::interprocess to put a string or vector in shared memory, but not a regex.   Add allocators to regexes   LWG  1396   
GB 94 20.8   This subclause has grown large, with many components, and so should stand alone.   Promote 20.8 and all its contents up to a new numbered clause.   editor     
GB 95 20.8   The adaptable function protocol supported by unary_function/binary_function has been superceded by lambda expressions and std::bind. Despite the name, the protocol is not very adaptable as it requires intrusive support in the adaptable types, rather than offering an external traits-like adaption mechanism. This protocol and related support functions should be deprecated, and we should not make onerous requirements for the specification to support this protocol for callable types introduced in this standard revision, including those adopted from TR1. It is expected that high-quality implementations will provide such support, but we should not have to write robust standard specifications mixing this restricted support with more general components such as function, bind and reference_wrapper.   Move clauses 20.8.3, 20.8.9, 20.8.11 and 20.8.12 to Annex D. Remove the requirements to conditionally derive from unary/binary_function from function, reference_wrapper, and the results of calling mem_fn and bind.   LWG  1397  ACCEPTED with MODIFICATIONS

See paper N3198 
GB 96 20.8   The function templates 'hash', 'less' and 'equal_to' are important customization points for user-defined types to be supported by several standard containers. These are accessed through the <functional> header which has grown significantly larger in C++0x, exposing many more facilities than a user is likely to need through there own header, simply to declare the necessary specialization. There should be a smaller header available for users to make the necessary customization.   Provide a tiny forwarding header for important functor types in the <functional> header that a user may want to specialize. This should contain the template declaration for 'equal_to', 'hash' and 'less'.   LWG  1398  REJECTED

No consensus to make a change.  
GB 97 20.8.10   The bind template is intended as a singe, simple to use replacement for the '98 adaptable function APIs and machinery. It works well in almost all respects, but lacks the ability to easily negate a predicate, or equivalently, act as a replacement for not1 and not2. Two easy ways to solve this omission would be to add a 'bind_not' function that produces a binder that negates its result. However, preference is given to requiring the unspecified bind result type to overload operator! to produce the same effect. This is preferred due to (i) its simpler usage, being the naively expected syntax, but more importantly (ii) some (limited) field experience.   Require the unspecified result of a bind expression to support unary operator! to yield another bind result that, when evaluated, yields '!res', where 'res' is the result of evaluating the original function.   LWG    REJECTED

No consensus for a change at this time.  
JP 3 20.8.14.2   explicit default contructor is defined in std::function. Although it is allowed according to 12.3.1, it seems unnecessary to qualify the constructor as explicit. If it is explicit, there will be a limitation in initializer_list.   Remove explicit.
namespace std {
template<class> class function;
// undefined
template<class R, class... ArgTypes>
class function<R(ArgTypes...)>
: public unary_function<T1, R>
// iff sizeof...(ArgTypes) == 1 and ArgTypes
contains T1
: public binary_function<T1, T2, R>
// iff sizeof...(ArgTypes) == 2 and ArgTypes
contains T1 andT2
{
public:typedef R result_type;
// 20.8.14.2.1, construct/copy/destroy:function();
 
LWG  1399  ACCEPTED  
JP 33 20.8.15 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(37)" to "(Table 37)".   editor    ACCEPTED  
JP 34 20.8.15 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(33)" to "(Table 33)".   editor    ACCEPTED  
JP 4 20.8.14.2.1 ¶ 1   Really does the function require that default constructor is explicit?   Remove explicit.
function();
template <class A>
function(allocator_arg_t, const A& a);
 
LWG  1400  ACCEPTED  
US 105 20.8.15.2   unique_ptr and shared_ptr are inconsistent in their handling of arrays. We can write:
unique_ptr<int[]> p( new int[10] );
// handles deletion correctly
But we cannot write:
shared_ptr<int[]> p( new int[10] );
// incorrect
This is an inconsistency. It is true that we have the following workaround:
std::shared_ptr<int> s(new int[5],
std::default_delete<int[]>());
But this is still inconsistent, not to mention awkward and error-prone because the programmer will occasionally forget the deleter and the code will silently compile and may appear to work on some platforms.  
Support:
shared_ptr<int[]> p( new int[10] );
to handle deletion correctly by calling delete[] on the stored pointer.  
LWG    REJECTED  
GB 98 20.9   This subclause has grown large, with many components, and so should stand alone.   Promote 20.9 and all of its contents to a new, toplevel, numbered clause.   editor     
GB 99 20.9 ¶ 1   One reason that the unique_ptr constructor taking a nullptr_t argument is not explicit is to allow conversion of nullptr to unique_ptr in contexts like equality comparison. Unfortunately operator== for unique_ptr is a little more clever than that, deducing template parameters for both arguments. This means that nullptr does not get deduced as unique_ptr type, and there are no other comparison functions to match.   Add the following signatures to 20.9p1, <memory> header synopsis:
template<typename T, typename D> bool
operator==(const unique_ptr<T, D> & lhs,
nullptr_t);
template<typename T, typename D> bool
operator==(nullptr_t, const unique_ptr<T, D> &
rhs);
template<typename T, typename D> bool
operator!=(const unique_ptr<T, D> & lhs,
nullptr_t);
template<typename T, typename D> bool
operator!=(nullptr_t, const unique_ptr<T, D> &
rhs);
 
LWG  1401   
GB 100 20.9   The unique_ptr and shared_ptr constructors taking nullptr_t delegate to a constexpr constructor, and could be constexpr themselves.   In the 20.9.10.2 [unique.ptr.single] synopsis add "constexpr" to unique_ptr(nullptr_t).
In the 20.9.10.3 [unique.ptr.runtime] synopsis add "constexpr" to unique_ptr(nullptr_t).
In the 20.9.11.2 [util.smartptr.shared] synopsis add "constexpr" to shared_ptr(nullptr_t).  
LWG  1402  ACCEPTED  
JP 85 20.9.1   There are inconsistent definitions for allocator_arg. In 20.9 [memory] paragraph 1,
constexpr allocator_arg_t allocator_arg =
allocator_arg_t();
and in 20.9.1,
const allocator_arg_t allocator_arg = allocator_arg_t();
 
Change "const" to "constexpr" in 20.9.1 as follows.
constexpr allocator_arg_t allocator_arg =
allocator_arg_t();
 
LWG  1403  ACCEPTED  
US 106 20.9.3 ¶ all   pointer_traits should have a size_type member for completeness.   Add “typedef see below size_type;” to the generic pointer_traits template and “typedef size_t size_type;” to pointer_traits<T*>. Use pointer_traits::size_type and pointer_traits::difference_type as the defaults for allocator_traits::size_type and allocator_traits::difference_type.
See Appendix 1 - Additional Details  
LWG  1404  ACCEPTED with MODIFICATIONS  
GB 104 20.9.5.1 ¶ 13   The ~ is missing from the invokation of the destructor of U.   Add the missing ~ : Effects: p->~U()   editor    ACCEPTED  
GB 105 20.9.6 ¶ 1   There is a missing '_' in the piecewise-construct call for pair in the class definition.   Fix the declaration:
template <class T1, class T2, class... Args1,
class... Args2> void construct(pair<T1, T2>* p,
piecewise_construct_t, tuple<Args1...> x,
tuple<Args2...> y);
 
editor    REJECTED

The declaration is identical to the proposed text.  
US 107 20.9.6   scoped_allocator_adaptor should have its own header.   See Appendix 1 - Additional Details   LWG  1405  ACCEPTED  
GB 101 20.9.10 ¶ 5   The first sentence of the paragraph says "Each object of a type U instantiated form the unique_ptr template..." "form" should be "from"   Replace "form" with "from" in the opening sentence: "Each object of a type U instantiated from the unique_ptr template..."   editor    ACCEPTED  
FI 13 20.9.10. ¶ 5   typo   "form the unique_ptr" should be "from the unique_ptr."   editor    ACCEPTED  
GB 102 20.9.10   unique_ptr is a smart pointer so [unique.ptr] should be a sub-clause of [util.smartptr]   move [unique.ptr] to a sub-clause of [util.smartptr]   editor    REJECTED

[util.smartptr] deals with shared_ptr and weak_ptr, which work together. Adding unique_ptr would create a muddle.  
JP 35 20.9.10.2 ¶ 2   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(38)" to "(Table 38)".   editor    ACCEPTED  
JP 36 20.9.10.2.1 ¶ 1, 6   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(33)" to "(Table 33)".   editor    ACCEPTED  
JP 37 20.9.10.2.1 ¶ 18   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(34)" to "(Table 34)".   editor    ACCEPTED  
JP 38 20.9.10.2.3 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(36)" to "(Table 36)".   editor    ACCEPTED  
JP 5 20.9.11.2 ¶ 1   Hash support based on ownership sharing should be supplied for shared_ptr and weak_ptr. For two shared_ptr objects p and q, two distinct equivalence relations can be defined. One is based on equivalence of pointer values, which is derived from the expression p.get() == q.get() (hereafter called addressbased equivalence relation), the other is based on equivalence of ownership sharing, which is derived from the expression !p.owner_before(q) && !q.owner_before(p) (hereafter called ownership-based equivalence relation). These two equivalence relations are independent in general. For example, a shared_ptr object created by the constructor of the signature shared_ptr(shared_ptr<U> const &, T *) could reveal a difference between these two relations. Therefore, hash support based on each equivalence relation should be supplied for shared_ptr. However, while the standard library provides the hash support for address-based one (20.9.11.6 paragraph 2), it lacks the hash support for ownership-based one. In addition, associative containers work well in combination with the shared_ptr's ownership-based comparison but unordered associative containers don't. This is inconsistent.>BR/> For the case of weak_ptr, hash support for the ownershipbased equivalence relation can be safely defined on weak_ptrs, and even on expired ones. The absence of hash support for the ownership-based equivalence relation is fatal, especially for expired weak_ptrs. And the absence of such hash support precludes some quite effective use-cases, e.g. erasing the unordered_map entry of an expired weak_ptr key from a customized deleter supplied to shared_ptrs.
Hash support for the ownership-based equivalence relation cannot be provided by any user-defined manner because information about ownership sharing is not available to users at all. Therefore, the only way to provide ownership-based hash support is to offer it intrusively by the standard library.
As far as we know, such hash support is implementable. Typical implementation of such hash function could return the hash value of the pointer of the counter object that is internally managed by shared_ptr and weak_ptr.  
Add the following non-static member functions to shared_ptr and weak_ptr class template;
// 20.9.11.2 paragraph 1
namespace std{
template<class T> class shared_ptr {
public:
...
size_t owner_hash() const;
...
};
}
// 20.9.11.3 paragraph 1
namespace std{
template<class T> class weak_ptr {
public:
...
size_t owner_hash() const;
...
};
}
These functions satisfy the following requirements. Let p and q be objects of either shared_ptr or weak_ptr, H be a hypothetical function object type that satisfies the hash requirements (20.2.4) and h be an object of the type H. The expression p.owner_hash() behaves as if it were equivalent to the expression h(p). In addition, h(p) == h(q) must become true if p and q share ownership.  
LWG  1406  REJECTED

No consensus to make this change at this time.  
CH 20 20.9.11.2 ¶ p4   Requiring shared_ptr and weak_ptr to always synchronize the use count makes it potentially slow and is inconsistent with the general approach to leave the synchronization to the user of a facility.   Strike 'not' from 'Changes in use_count() do not reflect modifications that can introduce data races.' Possibly add additional synchronized constructors and assignments.   LWG    REJECTED

No consensus to make a change at this time.  
US 108 20.9.11.2.1 [util.smartptr.shared.const]   shared_ptr should have the same policy for constructing from auto_ptr as unique_ptr. Currently it does not.   Add “template <class Y> explicit shared_ptr(auto_ptr<Y>&); to [util.smartptr.shared.const] (and to the synopsis).   LWG  1407  ACCEPTED with MODIFICATIONS

See paper N3109 
US 109 20.9.11.2.6   20.9.11.2.6 [util.smartptr.shared.create]/2 says: "the placement new expression ::new (pv) T() or ::new (pv) T(std::forward<Args>(args)...)". It should simply say "the placement new expression ::new (pv) T(std::forward<Args>(args)...)", because empty parameter packs expand to nothing. This would be consistent with the requirements in paragraph 1.   Change
"the placement new expression ::new (pv) T() or ::new (pv) T(std::forward<Args>(args)...)"
to
"the placement new expression ::new (pv) T(std::forward<Args>(args)...)"  
editor    ACCEPTED  
GB 103 20.9.12 ¶ 12   The precondition to calling declare_no_pointers is that no bytes in the range "have been previously registered" with this call. As written, this precondition includes bytes in ranges, even after they have been explicitly unregistered with a later call to 'undeclare_no_pointers'.   Replace "have been previously registered" with "are currently registered"   LWG  1408   
GB 106 20.10.3   duration is an arithmetic type, unlike time_point, and so should provide a specialization of numeric_limits.   Add a declaration of a partial specialization of numeric_limits for duration to the header synopsis in 20.10.
Add 20.3.8 [time.duration.limits] "duration is an arithmetic type, and so provides an appropriate specialization of numeric_limits."  
LWG    REJECTED

No consensus for a change.  
US 110 20.10.5   Significant parts of the clock section are "unspecified", rather than "implementation-defined".   Make those parts "implementation-defined".   LWG    REJECTED

No consensus to make a change.  
US 111 20.10.5.2 ¶ para 1   What it means for monotonic_clock to be a synonym is undefined. If it may or may not be a typedef, then certain classes of programs become unportable.   Require that it be a distinct class type.   LWG  1409  ACCEPTED with MODIFICATIONS

See paper N3191 
GB 107 20.10.5.2 ¶ 2   1.4p9 states that which conditionally supported constructs are available should be provided in the documentation for the implementation. This doesn't help programmers trying to write portable code, as they must then rely on implementation-specific means to determine the availability of such constructs. In particular, the presence or absence of std::chrono::monotonic_clock may require different code paths to be selected. This is the only conditionally-supported library facility, and differs from the conditionally-supported language facilities in that it has standard-defined semantics rather than implementationdefined semantics.   Provide feature test macro for determining the presence of std::chrono::monotonic_clock. Add _STDCPP_HAS_MONOTONIC_CLOCK to the <chrono> header, which is defined if monotonic_clock is present, and not defined if it is not present.   LWG  1410  ACCEPTED with MODIFICATIONS

See paper N3191 
DE 20 20.10.5.2   The library component monotonic_clock is conditionally supported, but no compile-time flag exists that allows user-code to query its existence. Further-on there exist no portable means to simulate such a query. (To do so, user code would be required to add types to namespace std::chrono.)   Provide a compile-time flag (preferably a macro) that can be used to query the existence of monotonic_clock.   LWG  1411  ACCEPTED with MODIFICATIONS

See paper N3191 
CH 21 20.10.5.2 ¶ p2   Monotonic clocks are generally easy to provide on all systems and are implicitely required by some of the library facilities anyway.   Make monotonic clocks mandatory, i.e. remove p2. Also change 30.2.4p2 accordingly.   LWG  1412  ACCEPTED with MODIFICATIONS

See paper N3191 
US 112 20.10.5.3 ¶ para 1   What it means for high_resolution_clock to be a synonym is undefined. If it may or may not be a typedef, then certain classes of programs become unportable.   Require that it be a distinct class type.   LWG  1413   
JP 39 21.2.2 ¶ 4   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(35)" to "(Table 35)".   editor    ACCEPTED  
GB 108 21.2.3.1 ¶ 2,3   The definition of streamoff/streampos defers to the definition of off_type and pos_type in 21.2.2, which defers back to 27.2.2 for the definition of streamoff/streampos. The actual definition appears to be supplied in 27.3, the synopsis of <iosfwd>.   Update the reference in 21.2.3.1 to refer forward to 27.2.2, rather than back to 21.2.2. Add a cross-reference to from 27.2.2 to 27.3.   editor     
GB 109 21.2.3.2/3/4   It is not clear what the specification means for u16streampos, u32streampos or wstreampos when they refer to the requirements for POS_T in 21.2.2, as there are no longer any such requirements. Similarly the annex D.7 refers to the requirements of type POS_T in 27.3 that no longer exist either.   Clarify the meaning of all cross-reference to the removed type POS_T.   LWG  1414  ACCEPTED with MODIFICATIONS  
JP 40 21.4 ¶ 3   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(96)" to "(Table 96)".   editor    ACCEPTED  
GB 110 21.4.7.1   data() is the function of choice for calling into legacy 'C'-like APIs. Both vector and array designed this function to be callable in a const-correct way while allowing for functions that want to use the result to designate a return buffer.   Add the following overload to basic_string data():
charT * data();
Relax the requirement that programs do not alter values in the array through the pointe retrieved through this new overload.  
LWG    REJECTED

No consensus to make this change.  
GB 111 21.5   Section 17.6.4.8, Data Race Avoidance, requires the C++ Standard Library to avoid data races that might otherwise result from two threads making calls to C++ Standard Library functions on distinct objects. The C standard library is part of the C++ Standard Library and some C++ Standary library functions (parts of the Localization library, as well as Numeric Conversions in 21.5), are specified to make use of the C standard library. Therefore, the C++ standard indirectly imposes a requirement on the thread safety of the C standard library. However, since the C standard does not address the concept of thread safety conforming C implementations exist that do no provide such guarantees. This conflict needs to be reconciled.   remove the requirement to make use of strtol() and sprintf() since these functions depend on the global C locale and thus cannot be made thread safe.   editor     
JP 86 21.7 ¶ 1   Table numbers are listed incorrectly. "74,75. and" should be "74, 75, and".   Correct typo as follows.
Tables 71, 72, 73, 74, 75, and 76 describe  
editor    ACCEPTED  
JP 87 22.3.1   While usage of "traits" and "Traits" are explained in 21.2 as template parameters and arguments respectively, specifying "Traits" as template parameter seems misuse. template <class charT, class Traits, class Allocator> bool operator()(const basic_string<charT,Traits,Allocator>& s1, const basic_string<charT,Traits,Allocator>& s2) const;   Change "Traits" to "traits" in three places.   editor    ACCEPTED  
JP 88 22.6 ¶ 3, Table 91   Typo, duplicated "ispunct" and missing "iswpunct".   Correct as follows.
isprint
ispunct
isspace
:
iswprint
iswpunct
iswspace  
editor    ACCEPTED  
JP 89 23.1 ¶ 2, Table 92   Typo, "<forwardlist>" should be "<forward_list>".   Correct typo. <forward_list>   editor    ACCEPTED  
US 113 23.2 ¶ 5   Resolve LWG 579 one way or the other, but preferably in the direction of changing the two erase overloads to return void.     LWG    REJECTED

No consensus for a change.  
US 114 23.2.1 ¶ Paragraph 9   Requirements on iterators swapping allegiance would disallow the small-string optimization.   Add an exclusion for basic_string to the sentence beginning “Every iterator referring to an element...”. Add a sentence to 21.4.6.8/2 saying that iterators and references to string elements remain valid, but it is not specified whether they refer to the same string or the other string.   LWG    ACCEPTED with MODIFICATIONS

See paper N3108 
DE 21 23.2.1, 23.3.3.4   23.2.1/11 provides a general no-throw guarantee for erase() container functions, exceptions from this are explicitly mentioned for individual containers. Because of its different name, forward_list's erase_after() function is not ruled by this but should so.   Add a "Throws: Nothing" clause to both erase_after overloads in 23.3.3.4.   LWG  1416  ACCEPTED  
US 115 23.2.1 ¶ Paragraph 15   The terms CopyConstructible, MoveConstructible, and constructible from are redefined, then used inconsistently and often incorrectly within the section. New terms should have been introduced and used correctly.   Better terms would be X can copy-insert T, X can move-insert T, and X can construct-insert T with args. See Appendix 1 - Additional Details   editor    ACCEPTED with MODIFICATIONS

See paper N3173 
US 116 23.2.1 ¶ Table 96   The requirement for X(rv) that move construction of the allocator not throw can be misread as requiring that move construction of the whole container not throw.   Add non-normative note:
Requires: move construction of A shall not exit via an exception. [Note: This requirement on allocators exists so that implementations can (optionally) provide a nothrow guarantee on move construction of some containers. end note]  
editor    REJECTED

The text as is seems quite clear; the proposed note just muddles things.  
FI 12 23.2.3 [sequence.reqmts] ¶ Table 97 Sequence container requirements (in addition to container)   The requirement for insert says: “Requires:T shall be CopyConstructible. For vector and deque, T shall also be CopyAssignable.”. Why must T be CopyAssignable? Is it for cases where the object may be already constructed and insert will first copy the existing data out of the way and assign to an existing object? Can't such an implementation do the same with placement-new?   CopyAssignable seems like an overly strict requirement for insert, exposing implementation details in the specification. If such implementation details are achievable without assignment, eg. with placement-new, the CopyAssignable requirement should be removed.   LWG    REJECTED

No consensus to make the change.  
JP 90 23.2.3 ¶ 17, Table 98   In Operational semantics for "a.emplace_front(args)", <Arg> should be <Args>. Prepends an object of type T constructed with std::forward<Arg>(args)...."   Change <Arg> to <Args>.   editor    ACCEPTED  
JP 91 23.2.5 ¶ 10, Table 100   Typo, unnecessary new-line. a_uniq.
emplace(args)
Typo, unnecessary space. a_eq. emplace(args)  
Remove space characters between "." and "emplace" same as other word wrapped columns in the table.   editor    ACCEPTED with MODIFICATIONS

The newline is needed, but the space is unnecessary. Removed the space.  
JP 92 23.2.5 ¶ 11   Typo, "unodified" should be "unmodified".   Correct typo. unmodified   editor    ACCEPTED  
ES 2 23.2.5 [unord.req], Table 100 (Unordered associative container requirements (in addition to container)) ¶ Row for expression a.erase(q)   The expression is required to return the iterator immediately following q prior to the erasure. As explained in N2023, this requirement makes it impossible to achieve average O(1) complexity for unordered associative containers implemented with singly linked lists. This has a theoretical as well as a practical impact, as reported by users of early implementations of these containers. Discussions among committee members have not found any way of remedying this deficiency (other than acknowledging it) by some smart modification of usual singly linked lists implementations.   Change the return type of the expression from iterator to void. Eliminate the sentence “Return value is the iterator immediately following q prior to the erasure”. Change accordingly the appearances of “iterator erase(const_iterator position)” in 23.5.1, 23.5.2, 23.5.3 and 23.5.4.   LWG    REJECTED  
GB 112 23.3.1.7 ¶ p3   Should the effect of calling front/back on a zero sized array really be implementation defined i.e. require the implementor to define behaviour?   Change "implementation defined" to "undefined"   LWG  1417  ACCEPTED  
GB 113 23.3.2.2 ¶ p1   There is no mention of what happens if sz==size(). While it obviously does nothing I feel a standard needs to say this explicitely.   Append "If sz == size(), does nothing" to the effects.   LWG  1418   
US 117 23.3.3   forward_list::erase_after should return an iterator.   See Appendix 1 - Additional Details   LWG  1419  ACCEPTED  
JP 41 23.3.3 ¶ 2   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(table 93)" to "(Table 93)".   editor    ACCEPTED  
GB 114 23.3.4.1 ¶ p11 & p12   It looks like the erase/insert effects given in p11 are intended for p12.   Move the erase/insert effects down to p12   editor    ACCEPTED with MODIFICATIONS

The code in question is a remmant from a previous version. It has now been removed.  
GB 115 23.3.4.2 ¶ p1   There is no mention of what happens if sz==size(). While it obviously does nothing I feel a standard needs to say this explicitly.   Express the semantics as pseudo-code similarly to the way it is done for the copying overload that follows (in p3). Include an else clause that does nothing and covers the sz==size() case.   LWG  1420   
GB 116 23.3.5   The sequence container adaptors consume sequence containers, but are neither containers nor sequences themselves. While they clearly belong in clause 23, they should not interrupt the presentation of the sequence container themselves.   Move clause 23.3.5 out of clause 23.3. Recommending inserting as a 'new' 23.4 immediately following sequence containers, and before the current 23.4 (associative containers) which would be renumbered 23.5.   editor    ACCEPTED  
DE 22 23.3.5.1, 23.3.5.2, 23.3.5.3   With the final acceptance of move operations as special members and introduction of corresponding suppression rules of implicitly generated copy operations the some library types that were copyable in C++03 are no longer copyable (only movable) in C++03, among them queue, priority_queue, and stack.     LWG  1421   
JP 93 23.3.5.2 ¶ 1   Typo, missing ";".
template <class... Args> void emplace(Args&&... args)
n  
Correct typo.
template <class... Args> void emplace(Args&&...
args);
 
editor    ACCEPTED  
GB 117 23.3.6.2 ¶ p9   (Same as for 23.3.2.2p1 i.e. deque::resize). There is no mention of what happens if sz==size(). While it obviously does nothing I feel a standard needs to say this explicitely.   Append "If sz == size(), does nothing" to the effects.   editor     
GB 118 23.3.7   vector<bool> iterators are not random access iterators because their reference type is a special class, and not 'bool &'. All standard libary operations taking iterators should treat this iterator as if it was a random access iterator, rather than a simple input iterator.   Either revise the iterator requirements to support proxy iterators (restoring functionality that was lost when the Concept facility was removed) or add an extra paragraph to the vector<bool> specification requiring the library to treat vector<bool> iterators as-if they were random access iterators, despite having the wrong reference type.   LWG  1422  REJECTED

The LWG does not wish to address this problem at this time. The preference is to deal with it with the more general proxy iterator problem.  
JP 6 23.4.1 ¶ 2   Constructor accepting an allocator as a single parameter should be qualified as explicit.
namespace std {
template <class Key, class T, class Compare =
less<Key>,
class Allocator = allocator<pair<const Key, T> > >
class map {
public:
...
map(const Allocator&);
 
Add explicit.
namespace std {
template <class Key, class T, class Compare =
less<Key>,
class Allocator = allocator<pair<const Key, T> > >
class map {
public:
...
explicit map(const Allocator&);
 
LWG  1423  ACCEPTED  
JP 7 23.4.2 ¶ 2   Constructor accepting an allocator as a single parameter should be qualified as explicit.   Add explicit.
namespace std {
template <class Key, class T, class Compare =
less<Key>,
class Allocator = allocator<pair<const Key, T> > >
class multimap {
public:
...
explicit multimap(const Allocator&);
 
LWG    ACCEPTED  
JP 8 23.4.3 ¶ 2   Constructor accepting an allocator as a single parameter should be qualified as explicit.   Add explicit.
namespace std {
template <class Key, class Compare = less<Key>,
class Allocator = allocator<Key> >
class set {
public:
...
explicit set(const Allocator&);
 
LWG  1425  ACCEPTED  
JP 9 23.4.4 ¶ 2   Constructor accepting an allocator as a single parameter should be qualified as explicit.   Add explicit.
namespace std {
template <class Key, class Compare = less<Key>,
class Allocator = allocator<Key> >
class multiset {
public:
...
explicit multiset(const Allocator&);
 
LWG  1426  ACCEPTED  
US 118 23.5   Some unordered associative container operations have undesirable complexities when the container is implemented using singly linked lists.   See Appendix 1 - Additional Details   LWG    REJECTED

No consensus for a change.  
JP 10 23.5.1 ¶ 3   Constructor accepting an allocator as a single parameter should be qualified as explicit.   Add explicit.
namespace std {
template <class Key,
template <class Key,
class T,
class Hash = hash<Key>,
class Pred = std::equal_to<Key>,
class Alloc = std::allocator<std::pair<const Key,
T> > >
class unordered_map
{
public:
...
explicit unordered_map(const Allocator&);
 
LWG  1427  ACCEPTED  
JP 11 23.5.2 ¶ 3   Constructor accepting an allocator as a single parameter should be qualified as explicit.   Add explicit.
namespace std {
template <class Key,
class T,
class Hash = hash<Key>,
class Pred = std::equal_to<Key>,
class Alloc = std::allocator<std::pair<const Key,
T> > >
class unordered_multimap
{
public:
...
explicit unordered_multimap(const Allocator&);
 
LWG  1428  ACCEPTED  
JP 94 23.5.2 ¶ 1   "see below" should be in italic and need one space between words.
explicit unordered_multimap(size_type n = seebelow,  
Change to:
explicit unordered_multimap(size_type n = see below,  
editor    ACCEPTED  
JP 12 23.5.3 ¶ 3   Constructor accepting an allocator as a single parameter should be qualified as explicit.   Add explicit.
namespace std {
template <class Key,
class Hash = hash<Key>,
class Pred = std::equal_to<Key>,
class Alloc = std::allocator<Key> >
class unordered_set
{
public:
...
explicit unordered_set(const Allocator&);
 
LWG  1429  ACCEPTED  
JP 13 23.5.4 ¶ 3   Constructor accepting an allocator as a single parameter should be qualified as explicit.   Add explicit.
namespace std {
template <class Key,
class Hash = hash<Key>,
class Pred = std::equal_to<Key>,
class Alloc = std::allocator<Key> >
class unordered_multiset
{
public:
...
explicit unordered_multiset(const Allocator&);
 
LWG  1430  ACCEPTED  
US 119 [input.iterators] 24.2.3 ¶ Table 104   Although the section talks about operator==, there is no requirement that it exist.   Add a == b to Table 104   LWG    REJECTED

Standard is correct as is.  
JP 42 25.1 ¶ 8, 9   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(4)" to "(Clause 4)".   editor    ACCEPTED  
US 120 25.2.12 ¶ para 1   is_permutation is underspecified for anything but the simple case where both ranges have the same value type and the comparison function is an equivalence relation.   Restrict is_permutation to the case where it is well specified. See Appendix 1 - Additional Details   LWG  1431  ACCEPTED  
ES 3 25.2.12   is_permutation does not require ForwardIterator1 and ForwardIterator2 to have the same value type. This opens the door to nonsense heterogeneous usage where both ranges have different value types   Require both iterator types to have the same value type   LWG    ACCEPTED  
JP 43 25.3.9 ¶ 5   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(4)" to "(Clause 4)".   editor    ACCEPTED  
US 121 25.3.12 [alg.random.shuffle] ¶ 1   random_shuffle and shuffle should be consistent in how they accept their source of randomness: either both by rvalue reference or both by lvalue reference.   Change random_shuffle to accept its RandomNumberGenerator by lvalue reference.   LWG  1432  ACCEPTED with MODIFICATIONS  
GB 119 25.3.12   The functions random_shuffle and shuffle both take arguments providing a source of randomness, but one take its argument by rvalue reference, and the other requires an lvalue reference. The technical merits of which form of argument passing should be settled for this specific case, and a single preferred form used consistently.   [DEPENDS ON WHETHER RVALUE OR LVALUE REFERENCE IS THE PREFERRED FORM]   LWG  1433  ACCEPTED with MODIFICATIONS  
JP 44 25.4 ¶ 2   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(4)" to "(Clause 4)".   editor    ACCEPTED  
JP 45 25.4.7 ¶ 1, 10, 19   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(32)" to "(Table 32)".   editor    ACCEPTED  
US 122 25.4.7 [alg.min.max]   It was the LWG's intent in Pittsburgh that N2772 be applied to the WP   Apply N2772 to the WP.   LWG  1434  ACCEPTED with MODIFICATIONS

See paper N3106 
US 123 25.5 ¶ p5b, and all uses of lshift   N3056, as adopted, calls for each use of lshift to be followed by a subscripted value.   Adjust all occurrences of the lshift notation so as to match the notation of N3056.   editor     
FI 14 26.3.1. ¶ 3   typo   "floating-point environmnet" should be "floating-point environment."   editor    ACCEPTED  
GB 120 26.4.7   The complex number functions added for compatibility with the C99 standard library are defined purely as a cross-reference, with no hint of what they should return. This is distinct from the style of documentation for the functions in the earlier standard. In the case of the inverse-trigonometric and hyperbolic functions, a reasonable guess of the functionality may be made from the name, this is not true of the cproj function, which apparently returns the projection on the Reimann Sphere. A single line description of each function, associated with the cross-reference, will greatly improve clarity.   [ONE LINE DESCRIPTIONS, AND ASSOCIATED PARAGRAPH NUMBERS, TO FOLLOW IF THE INTENT IS APPROVED]   LWG  1435  ACCEPTED with MODIFICATIONS  
JP 46 26.5.1.6 ¶ 3   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "Clause 21 and 27" to "Clauses 21 and 27".   editor    ACCEPTED  
GB 121 26.5.3   All the random number engine types in this clause have a constructor taking an unsigned integer type, and a constructor template for seed sequences. This means that an attempt to create a random number engine seeded by an integer literal must remember to add the appropriate unsigned suffix to the literal, as a signed integer will attempt to use the seed sequence template, yielding undefined behaviour, as per 26.5.1.1p1a. It would be helpful if at least these anticipated cases produced a defined behaviour, either an erroneous program with diagnostic, or a conversion to unsigned int forwarding to the appropriate constructor.   [WORDING TO FOLLOW ONCE A PREFERRED DIRECTION IS INDICATED]   LWG  1436  ACCEPTED with MODIFICATIONS  
US 124 26.5.3.2 ¶ p4   The Mersenne twister algorithm is meaningless for word sizes less than two, as there are then insufficient bits available to be “twisted”.   Insert the following among the relations that are required to hold: 2u < w.   LWG  1437  ACCEPTED  
US 125 26.5.4.1 [rand.adapt.disc] ¶ 3   The synopsis for min() and max() is lacking “()” in the return statements.   return Engine::min();
return Engine::max();  
editor     
US 126 26.5.4.1 [rand.adapt.disc], 26.5.4.2 [rand.adapt.ibits], 26.5.4.3 [rand.adapt.shuf] ¶ 3   Each adaptor has a member function called base() which has no definition.   Give it the obvious definition.   LWG  1438   
US 127 26.5.4.1 ¶ synopsis after p3   Engine::min is a function and ought be invoked in the context where mentioned, as should Engine::max.   Append parentheses so as to become return Engine::min() and return Engine::max().   editor     
US 128 26.5.4.3 ¶ synopsis after p3   Engine::min is a function and ought be invoked in the context where mentioned, as should Engine::max.   Append parentheses so as to become return Engine::min() and return Engine::max().   editor     
US 129 26.5.7.1 ¶ p8b   The expression begin[x+q] is incorrect since x is unspecified .   Replace x by k so as to obtain begin[k+q].   editor     
US 130 26.5.7.1 ¶ p8c   The phrase “three more times” is misleading.   s/three more times,/again,/   editor     
US 131 26.5.7.1 ¶ p8c   Values r3 and r4 are correctly specified, but in their subsequent use they are interchanged with respect to the original algorithm by Mutso Saito.   Exchange subscripts so as to read as follows: “... update begin[k + p] by xoring it with r3, update begin[k + q] by xoring it with r4, and ...”   editor     
US 132 26.5.7.1 [rand.util.seedseq] ¶ 8b   The last sentence includes “begin[x + q]” but “x” is nonsensical here.   Change “begin[x + q]” to “begin[k + q]”   editor     
US 133 26.5.7.1 [rand.util.seedseq] ¶ 8c   The use of r3 and r4 is reversed in the final sentence of 8c according to the defect report on comp.std.c++ that this specification is based on: http://groups.google.com/group/comp.std.c++/browse_thre ad/thread/e34cbee1932efdb8/aad523dccec12aed?q=grou p:comp.std.c%2B%2B+insubject:seed_seq If you follow the SFMT link to the software, the software also uses r3 and r4 in a manner inconsistent with N3092. I believe N3092 should be changed to be consistent with the defect report.   Change 8c to end:
... update begin[k + p] by xoring it with r3, update begin[k + q] by xoring it with r4, and ...  
editor     
US 134 26.5.8.5.2 [rand.dist.samp.pconst], 26.5.8.5.3 [rand.dist.samp.plinear]   These two distributions have a member function called densities() which returns a vector<double>. The distribution is templated on RealType. The distribution also has another member called intervals() which returns a vector<RealType>. Why doesn't densities return vector<RealType> as well? If RealType is long double, the computed densities property isn't being computed to the precision the client desires. If RealType is float, the densities vector is taking up twice as much space as the client desires.   Change the piecewise constant and linear distributions to hold / return the densities in a vector<result_type>.
If this is not done, at least correct[rand.dist.samp.pconst]/13 which describes the return of densities as a vector<result_type>.  
LWG  1439  ACCEPTED  
US 135 26.5.8.5.3 ¶ 10   This paragraph says: Let bk = xmin+k·δ for k = 0,...,n, and wk = fw(bk +δ) for k = 0,...,n. However I believe that fw(bk) would be far more desirable. I strongly suspect that this is nothing but a type-o.   Change p10 to read:
Let bk = xmin+k·δ for k = 0,...,n, and wk = fw(bk) for k = 0,...,n.  
LWG  1440  ACCEPTED  
JP 47 26.7.1 ¶ 2   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table   Change "(35)" to "(Table 35)".   editor    ACCEPTED  
JP 48 26.7.2 ¶ 2   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(35)" to "(Table 35)".   editor    ACCEPTED  
JP 49 26.7.4 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(36)" to "(Table 36)".   editor    ACCEPTED  
US 136 26.8   Floating-point test functions are incorrectly specified.   See Appendix 1 - Additional Details   LWG  1441  ACCEPTED  
CA 9 27.2.3p2 30.3.1.2p6 30.3.1.5p7 30.6.4p7 30.6.9p5 30.6.10.1p23 ¶ 27.2.3p2 30.3.1.2p6 30.3.1.5p7 30.6.4p7 30.6.9p5 30.6.10.1p23   Imposed happens-before edges should be in synchronizes-with
Each use of the words "happens-before" should be replaced with the words "synchronizes-with" in the following sentences:
27.2.3p2
30.3.1.2p6
30.3.1.5p7
30.6.4p7
30.6.9p5
30.6.10.1p23
Rationale: Happens-before is defined in 1.10p11 in a way that (deliberately) does not make it explicitly transitively closed. Adding edges to happens-before directly, as in 27.2.3p2 etc., does not provide transitivity with sequenced-before or any other existing happens-before edge. This lack of transitivity seems to be unintentional.  
Each use of the words "happens-before" should be replaced with the words "synchronizes-with" in the following sentences:
27.2.3p2
30.3.1.2p6
30.3.1.5p7
30.6.4p7
30.6.9p5
30.6.10.1p23  
LWG  1442  ACCEPTED

See paper N3196 
GB 122 27, 30   See (D) in attachment Appendix 1 - Additional Details   Request the concurrency working group to determine if changes are needed   LWG  1442, 1443   
GB 123 27.5.3.2 ¶ Table 124   Several rows in table 124 specify a Return type of 'OFF_T', which does not appear to be a type defined in this standard.   Resolve outstanding references to the removed type 'OFF_T'.   LWG  1414, 1444  ACCEPTED with MODIFICATIONS  
US 137 27.7   Several iostreams member functions are incorrectly specified.   See Appendix 1 - Additional Details   LWG  1445  ACCEPTED with MODIFICATIONS

See paper N3168 
US 138 27.7   For istreams and ostreams, the move-constructor does not move-construct, the move-assignment operator does not move-assign, and the swap function does not swap because these operations do not manage the rdbuf() pointer. Useful applications of these operations are prevented both by their incorrect semantics and because they are protected.   In short: reverse the resolution of issue 900, then change the semantics to move and swap the rdbuf() pointer. Add a new protected constructor that takes an rvalue reference to a stream and a pointer to a streambuf, a new protected assign() operator that takes the same arguments, and a new protected partial_swap() function that doesn't swap rdbuf(). See Appendix 1 - Additional Details   LWG  1446  REJECTED

The Library Working Group reviewed n3179 and concluded that this change alone was not sufficient, as it would require changes to some of the derived stream types in the library. The preference is not make such a broad fix, and retain the current semnatic. This is closed as NAD rather than NAD future as it will be difficult to rename the new functions introduced in the C++0x revision of the standard at a later date.

See paper N3179 
US 139 27.7 ¶ 1.1.3   Resolve issue LWG 1328 one way or the other, but preferably in the direction outlined in the proposed resolution, which, however, is not complete as-is: in any case, the sentry must not set ok_ = false if is.good() == false, otherwise istream::seekg, being an unformatted input function, does not take any action because the sentry object returns false when converted to type bool. Thus, it remains impossible to seek away from end of file.     LWG  1447  ACCEPTED with MODIFICATIONS

See paper N3168 
US 140 27.8   It should be possible to construct a stringstream with a specific allocator.   Add an allocator_type and overloaded constructors that take an Allocator argument to basic_stringbuf, basic_istringstream, basic_ostringstream, and basic_stringstream. The semantics of allocator propagation should be the same as if the stringbuf contained an embedded basic_string using the same allocator.   LWG    REJECTED

No consensus for a change at this time.  
GB 124 27.8.1.3 ¶ 3   N3092 27.8.1.3 Member functions contains this text specifying the postconditions of basic_stringbuf::str(basic_string):
"Postconditions: If mode & ios_base::out is true, pbase() points to the first underlying character and epptr() >= pbase() + s.size() holds; in addition, if mode & ios_base::in is true, pptr() == pbase() + s.data() holds, otherwise pptr() == pbase() is true. [...]"
Firstly, there's a simple mistake: It should be pbase() + s.length(), not pbase() + s.data().
Secondly, it doesn't match existing implementations. As far as I can tell, GCC 4.5 does not test for mode & ios_base::in in the second part of that sentence, but for mode & (ios_base::app | ios_base_ate), and Visual C++ 9 for mode & ios_base::app. Besides, the wording of the C++0x draft doesn't make any sense to me. I suggest changing the second part of the sentence to one of the following:
Replace ios_base::in with (ios_base::ate | ios_base::app), but this would require Visual C++ to change (replacing only with ios_base::ate would require GCC to change, and would make ios_base::app completely useless with stringstreams):
in addition, if mode & (ios_base::ate | ios_base::app) is true, pptr() == pbase() + s.length() holds, otherwise pptr() == pbase() is true.
Leave pptr() unspecified if mode & ios_base::app, but not mode & ios_base::ate (implementations already differ in this case, and it's always possible to use ios_base::ate to get the effect of appending, so it's not necessary to require any implementation to change): in addition, if mode & ios_base::ate is true, pptr() == pbase() + s.length() holds, if neither mode & ios_base::ate nor mode & ios_base::app is true, pptr() == pbase() holds, otherwise pptr() >= pbase() && pptr() <= pbase() + s.length() (which of the values in this range is unspecified).
Slightly stricter:
in addition, if mode & ios_base::ate is true, pptr() == pbase() + s.length() holds, if neither mode & ios_base::ate nor mode & ios_base::app is true, pptr() == pbase() holds, otherwise pptr() == pbase() || pptr() == pbase() + s.length() (which of these two values is unspecified). A small table might help to better explain the three cases. BTW, at the end of the postconditions is this text: "egptr() == eback() + s.size() hold". Is there a perference for basic_string::length or basic_string::size? It doesn't really matter, but it looks a bit inconsistent.  
  LWG  1448   
CA 4 27.8.2 ¶ various   Subclause 27.9.2 [c.files] specifies that <cinttypes> has declarations for abs() and div(); however, the signatures are not present in this subclause. The signatures proposed under TR1 ([tr.c99.inttypes]) are not present in FCD (unless if intmax_t happened to be long long). It is unclear as to which, if any of the abs() and div() functions in [c.math] are meant to be declared by <cinttypes>. This subclause mentions imaxabs() and imaxdiv(). These functions, among other things, are not specified in FCD to be the functions from Subclause 7.8 of the C Standard. Finally, <cinttypes> is not specified in FCD to include <cstdint> (whereas <inttypes.h> includes <stdint.h> in C).   Please clarify.   LWG  1449  ACCEPTED with MODIFICATIONS  
JP 14 28.4   Support of char16_t/char32_t is insufficient. The <regex> does not have typedefs for char16_t/char32_t.
The reason we need this typedefs is, because anybody may define exactly same type with different typedef names. Doesn't <locale> offer enough operations which is required by regex implementation?  
Add typedefs below
typedef basic_regex<char16_t> u16regex;
typedef basic_regex<char32_t> u32regex;
 
LWG    REJECTED

No consensus to make a change at this time.  
GB 127 28.5.2   The Bitmask Type requirements in 17.5.2.1.3 p3 say that all elements on a bitmask type have distinct values, but 28.5.2 defines regex_constants::match_default and regex_constants::format_default as elements of the bitmask type regex_constants::match-flag_type, both with value 0. This is a contradiction.   One of the bitmask elements should be removed from the declaration and should be defined separately, in the same manner as ios_base::adjustfield, ios_base::basefield and ios_base::floatfield are defined by 27.5.2.1.2p2 and Table 120. These are constants of a bitmask type, but are not distinct elements, they have more than one value set in the bitmask. regex_constants::format_default should be specified as a constant with the same value as regex_constants::match_default.   LWG  1450   
JP 50 28.5.2 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "table 136" to "Table 136".   editor    ACCEPTED  
JP 51 28.5.3 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "table 137" to "Table 137".   editor    ACCEPTED  
US 141 28.8   std::basic_regex should have an allocator for all the reasons that a std::string does. For example, I can use boost::interprocess to put a string or vector in shared memory, but not a regex.   Add allocators to regexes   LWG  1451   
GB 125 28.10.3 ¶ 2   The term "target sequence" is not defined.   Replace "target sequence" with "string being searched/matched"   LWG  1452   
GB 126 28.10.3   It's unclear how match_results should behave if it has been default-constructed. The sub_match objects returned by operator[], prefix and suffix cannot point to the end of the sequence that was searched if no search was done. The iterators held by unmatched sub_match objects might be singular.   Add to match_results::operator[], match_results::prefix and match_results::suffix:
Requires: !empty()  
LWG  1453  ACCEPTED with MODIFICATIONS

See paper N3158 
JP 52 28.11.2 ¶ 3   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "table 139" to "Table 139".   editor    ACCEPTED  
JP 95 28.11.3 ¶ 1   The section number "(24.1.4)" for "Bidirectional Iterator" is wrong. The correct one is "(24.2.6)". In addition, it is written as normal text, but it should be embedded as a link to the section.   Change "(24.1.4)" to "(24.2.6)" and make it a link to section (24.2.6).   editor    ACCEPTED  
JP 53 28.11.3 ¶ 3   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.  Change "table 140" to "Table 140".   editor    ACCEPTED  
JP 54 28.13 ¶ 6   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "table 135" to "Table 135".   editor    ACCEPTED  
GB 128 29   WG14 has made some late changes to their specification of atomics, and care should be taken to ensure that we retain a common subset of language/library syntax to declare headers that are portable to both languages. Ideally, such headers would not require users to define their own macros, especially not macros that map to keywords (which remains undefined behaviour)   Depends on result of the review of WG14 work, which is expected to be out to ballot during the time wg21 is resolving its own ballot comments. Liaison may also want to file comments in WG14 to ensure compatibity from both sides.   LWG  1455, 1454  ACCEPTED with MODIFICATIONS

See paper N3193 
CH 22 29   WG14 currently plans to introduce atomic facilities that are intended to be compatible with the facilities of clause 29. They should be compatible.   Make sure the headers in clause 29 are defined in a way that is compatible with the planned C standard.   LWG  1455, 1454  ACCEPTED with MODIFICATIONS

See paper N3193 
GB 129 29 ¶ Table 143   Table 143 lists the typedefs for various atomic types corresponding to the various standard integer typedefs, such as atomic_int_least8_t for int_least8_t, and atomic_uint_fast64_t for uint_fast64_t. However, there are no atomic typedefs corresponding to the fixed-size standard typedefs int8_t, int16_t, and so forth.   Add the following entries to table 143:
atomic_int8_t => int8_t (optional),
atomic_int16_t => int16_t (optional),
atomic_int32_t => int32_t (optional),
atomic_int64_t => int64_t (optional),
atomic_uint8_t => uint8_t (optional),
atomic_uint16_t => uint16_t (optional),
atomic_uint32_t => uint32_t (optional),
atomic_uint64_t => uint64_t (optional)
These typedefs should be available if the corresponding typedefs from are available.  
LWG  1456   
CA 16 29.1p1 29.3p8 ¶ 29.1p1 footnote 343 29.3p8 footnote 344   Radioactivity
Footnotes 343 and 344 from 29.1p1 and 29.3p8 read: "Atomic objects are neither active nor radioactive" and "Among other implications, atomic variables shall not decay".
We suggest that these be removed - the first is pretty clearly a joke, but it's not obvious that the second doesn't have some technical meaning.  
Footnotes 343 and 344 from 29.1p1 and 29.3p8 should be removed.   editor    ACCEPTED  
US 142 29.1 ¶ P2 table 141   Missing 29.8 Fences   Add 29.8 Fences   editor    ACCEPTED  
US 143 [atomics.syn] 29.2 ¶ before 1   There is no free function atomic_compare_exchange_strong for volatile atomic integral types; there is one for non-volatile types.   Add atomic_compare_exchange_strong for volatile integral types to the synopsis.   editor    ACCEPTED  
US 144 [atomics.syn] 29.2 ¶ before 1   The synopsis lists the macros ATOMIC_INTEGRAL_LOCK_FREE and ATOMIC_ADDRESS_LOCK_FREE; the Lock-free Property requirements don't have ATOMIC_INTEGRAL_LOCK_FREE, but have 8 macros for the various integral types.   Change 29.2 [atomics.syn] to match 29.4 [atomics.lockfree].   editor    ACCEPTED  
US 145 29.2   missing atomic_compare_exchange_strong(volatile ....) and atomic_compare)exchange_strong_explict( ...//no volatile *?
> bool atomic_compare_exchange_weak(volatile atomic_itype*, integral*, integral);
> bool atomic_compare_exchange_weak(atomic_itype*, integral*, integral);
> bool atomic_compare_exchange_strong(atomic_itype*, integral*, integral);
> bool atomic_compare_exchange_weak_explicit(volatile atomic_itype*, integral*,
> integral, memory_order, memory_order);
> bool atomic_compare_exchange_weak_explicit(atomic_itype*, integral*,
> integral, memory_order, memory_order);
> bool atomic_compare_exchange_strong_explicit(volatile atomic_itype*, integral*,
> integral, memory_order, memory_order);  
Repair as suggested   editor    ACCEPTED  
GB 130 29.2   The synopsis for the <atomic> header lists the macros ATOMIC_INTEGRAL_LOCK_FREE and ATOMIC_ADDRESS_LOCK_FREE. The ATOMIC_INTEGRAL_LOCK_FREE macro has been replaced with a set of macros for each integral type, as listed in 29.4   Replace "#define ATOMIC_INTEGRAL_LOCK_FREE unspecified" with
#define ATOMIC_CHAR_LOCK_FREE
implementation-defined
#define ATOMIC_CHAR16_T_LOCK_FREE
implementation-defined
#define ATOMIC_CHAR32_T_LOCK_FREE
implementation-defined
#define ATOMIC_WCHAR_T_LOCK_FREE
implementation-defined
#define ATOMIC_SHORT_LOCK_FREE
implementation-defined
#define ATOMIC_INT_LOCK_FREE
implementation-defined
#define ATOMIC_LONG_LOCK_FREE
implementation-defined
#define ATOMIC_LLONG_LOCK_FREE
implementation-defined
 
LWG  1457   
US 146 29.2 ¶ syn 29.4   The ATOMIC_..._LOCK_FREE macros have not had changes applied.   Change to match 29.4/0.   editor    ACCEPTED  
US 147 29.2 ¶ syn 29.7   The declaration of ATOMIC_VAR_INIT should be referenced to section 29.6 [atomics.types.operations], not 29.7.   Change it to 29.6.   editor    ACCEPTED  
US 148 29.2 ¶ syn 29.7   The definition of ATOMIC_VAR_INIT should be 'implementation defined' rather than 'see below'.   Change it to 'implementation defined'.   editor    REJECTED

No, definitely not implementation defined. "See below "is correct.  
US 149 29.2 ¶ syn 29.5.1   The synopsis is missing the atomic_init function declarations for the bool, integral and address types.   Copy them from 29.5.1.   editor    ACCEPTED  
US 150 29.2 ¶ syn 29.5.1   There are missing function prototypes bool atomic_compare_exchange_strong(volatile atomic_itype*, integral*, integral); and integral atomic_fetch_add(volatile atomic_itype*, integral);   Add them.   editor    ACCEPTED  
US 151 29.2 ¶ syn 29.5.1   There is a duplicate function declaration of integral atomic_fetch_or(volatile atomic_itype*, integral);   Remove the volatile qualifier from the second declaration.   editor    ACCEPTED  
US 152 29.3 ¶ para 1   The table shows no disinct meaning for memory_order_seq_cst.   Add another bullet: "- memory_order_seq_cst: See below."   editor    REJECTED

It's named in the second and fourth bullet items.  
GB 131 29.3 ¶ 8   See (H) in attachment Appendix 1 - Additional Details   Request the concurrency working group to determine if changes are needed. Consider changing the use of "sequence" in 29.3   LWG  1458   
CA 21 9.3p8 1.9p13 ¶ 29.3p8 1.9p13   Overlapping evaluations are allowed
29.3p8 states:
"An atomic store shall only store a value that has been computed from constants and program input values by a finite sequence of program evaluations, such that each evaluation observes the values of variables as computed by the last prior assignment in the sequence."
... but 1.9p13 states: "If A is not sequenced before B and B is not sequenced before A, then A and B are unsequenced. [ Note: The execution of unsequenced evaluations can overlap. -end note ]"
Overlapping executions can make it impossible to construct the sequence described in 29.3p8. We are not sure of the intention here and do not offer a suggestion for change, but note that 29.3p8 is the condition that prevents out-of-thin-air reads.
For an example, suppose we have a function invocation f(e1,e2). The evaluations of e1 and e2 can overlap. Suppose that the evaluation of e1 writes y and reads x whereas the evaluation of e2 reads y and writes x, with reads-from edges as below (all this is within a single thread).
 e1           e2
Wrlx y--   --Wrlx x
      rf\ /rf
         X
        / \
Rrlx x<-   ->Rrlx y
This seems like it should be allowed, but there seems to be no way to produce a sequence of evaluations with the property above.
In more detail, here the two evaluations, e1 and e2, are being executed as the arguments of a function and are consequently not sequenced-before each other. In practice we'd expect that they could overlap (as allowed by 1.9p13), with the two writes taking effect before the two reads. However, if we have to construct a linear order of evaluations, as in 29.3p8, then the execution above is not permited. Is that really intended?  
Please clarify.   LWG  1459   
US 153 [atomics.lockfree] 29.4 ¶ before 1   The macros are all specified as "implementation-deifned"; they should be "see below", since the required values are spelled out.   Change the definitions of the macros in 29.4 [atomics.lockfree] from "implementation-defined" to "see below".   editor    REJECTED

Implementation defined requires that the implementation document what it does. Removing this requirement would be a technical change.  
US 154 [atomics.lockfree] 29.4 ¶ before 1   There is no ATOMIC_BOOL_LOCK_FREE macro.   Add ATOMIC_BOOL_LOCK_FREE to 29.4 [atomics.lockfree] and to 29.2 [atomics.syn]   LWG  1460   
US 155 29.4 ¶ para 3   The 'via' 'by' word pairing is awkward.   Replace 'by' with 'via' in 'communication via memory ... and by memory'.   editor    ACCEPTED  
CA 1 29.4, 29.6 29.7 ¶ various   All ATOMIC_... macros should be prefixed with STD_ as in STD_ATOMIC_... to indicate they are STD macros as other standard macros. The rationale that they all seem too long seems weak.   This covers the following macros which we suggest prepending with STD_:
29.4:
#define ATOMIC_CHAR_LOCK_FREE implementation-defined
#define ATOMIC_CHAR16_T_LOCK_FREE implementation-defined
#define ATOMIC_CHAR32_T_LOCK_FREE implementation-defined
#define ATOMIC_WCHAR_T_LOCK_FREE implementation-defined
#define ATOMIC_SHORT_LOCK_FREE implementation-defined
#define ATOMIC_INT_LOCK_FREE implementation-defined
#define ATOMIC_LONG_LOCK_FREE implementation-defined
#define ATOMIC_LLONG_LOCK_FREE implementation-defined
#define ATOMIC_ADDRESS_LOCK_FREE implementation-defined
29.6:
#define ATOMIC_VAR_INIT(value) see below
29.7:
#define ATOMIC_FLAG_INIT see below  
LWG  1461   
US 156 [atomics.types.integral] 29.5.1 ¶ before 1   The list of member functions for atomic_bool has four versions of compare_exchange_weak taking one memory_order argument; the last two should be compare_exchange_strong.   Change the last two member functions comapare_exchange_weak taking two memory_order arguments to compare_exchange_strong.   editor    ACCEPTED  
JP 55 29.5.1 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "table 142" to "Table 142".   editor    ACCEPTED  
GB 132 29.5.1   The atomic_itype types and atomic_address have two overloads of operator= --- one is volatile qualified, and the other is not. atomic_bool only has the volatile qualified version:
bool operator=(bool) volatile;
On a non-volatile-qualified object this is ambiguous with the deleted copy-assignment operator
atomic_bool& operator=(atomic_bool const&) = delete;
due to the need for a single standard conversion in each case when assigning a bool to an atomic_bool as in:
atomic_bool b;
b=true;
The conversions are atomic_bool& -> atomic_bool volatile& vs bool -> atomic_bool  
Add the "bool operator=(bool);" overload to atomic_bool in 29.5.1   LWG  1462  ACCEPTED with MODIFICATIONS

See paper N3193 
US 157 [atomics.types.integral] 29.5.1 ¶ before 1   atomic_bool has a volatile assignment operator but not a non-volatile operator The other integral types have both..   Add a non-volatile assignment operator to atomic_bool.   LWG  1463  ACCEPTED with MODIFICATIONS

See paper N3193 
US 158 29.5.1 ¶ para 0   There is a space before the second & in the declaration atomic_itype& operator=(const atomic_itype &) = delete;   Remove the space.   editor    ACCEPTED  
US 159 29.5.1   Last 2 should be compare_exchane_strong
> bool compare_exchange_weak(bool&, bool, memory_order, memory_order) volatile;
> bool compare_exchange_weak(bool&, bool, memory_order, memory_order);
> bool compare_exchange_strong(bool&, bool, memory_order, memory_order) volatile;
> bool compare_exchange_strong(bool&, bool, memory_order, memory_order);
> bool compare_exchange_weak(bool&, bool, memory_order = memory_order_seq_cst) volatile;
> bool compare_exchange_weak(bool&, bool, memory_order = memory_order_seq_cst);
> bool compare_exchange_weak(bool&, bool, memory_order = memory_order_seq_cst) volatile;
> bool compare_exchange_weak(bool&, bool, memory_order = memory_order_seq_cst);  
Fix last 2   editor    ACCEPTED  
US 160 [atomic.types.integral] 29.5.1 ¶ 1   The last sentence of 29.5.1 [atomics.types.integral]/1 says "Table 143 shows typedefs to atomic integral classes and the corresponding typedefs." That's nice, but nothing says these are supposed to be part of the implementation, and they are not listed in the synopsis.   Remove Table 143 and the last sentence of 29.5.1 [atomics.types.integral]/1.   LWG  1464  ACCEPTED with MODIFICATIONS

See paper N3193 
US 161 [atomic.types.address] 29.5.2 ¶ before 1   atomic_address has operator+= and operator-=, but no operator++ or operator--. The template specialization atomic<Ty*> has all of them.   Add operator++(int) volatile, operator++(int), operator++() volatile, operator++(), operator--(int) volatile, operator--(int), operator--() volatile, and operator--() to atomic_address.   LWG  1465  ACCEPTED with MODIFICATIONS

See paper N3193 
US 162 [atomics.typres.address] 29.5.2   The compare_exchange_weak and compare_exchange_strong member functions that take const void* arguments lead to a silent removal of const, because the load member function and other acessors return the stored value as a void*.   Remove the const void* overloads of compare_exchange_weak and compare_exchange_strong   LWG  1466  ACCEPTED with MODIFICATIONS

See paper N3193 
US 163 [atomics.type.address], [atomics.types.generic] 29.5.2, 29.5.3   Requiring atomic<Ty*> to be derived from atomic_address breaks type safety:
atomic<double*> ip;
char ch;
atomic_store(&ip, &ch);
*ip.load() = 3.14159;
The last line overwrites ch with a value of type double  
Remove the requirement that atomic<Ty*> be derived from atomic_address.   LWG  1467  ACCEPTED with MODIFICATIONS

See paper N3193 
US 164 [atomics.types.address] 29.5.2 ¶ before 1   atomic_address has member functions compare_exchange_weak and compare_exchange_strong that take arguments of type const void*, in addition to the void* versions. If these member functions survive, there should be corresponding free functions.   Add atomic_compare_exchange_weak and atomic_compare_exchange_strong free functions taking pointers to volatile and non-volatile atomic_address objects and const void* arguments.   LWG  1468  ACCEPTED with MODIFICATIONS

See paper N3193 
JP 56 29.5.3 ¶ 3   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "table 142 or table 143" to "Table 142 or Table 143".   editor    ACCEPTED  
GB 133 29.5.3   The free functions that operate on atomic_address can be used to store a pointer to an unrelated type in an atomic<T*> without a cast. e.g.
int i;
atomic<int*> ai(&i);
string s;
atomic_store(&ai,&s);
 
Overload the atomic_store, atomic_exchange and atomic_compare_exchange_[weak/strong] operations for atomic<T*> to allow storing only pointers to T:
template<typename T>
void atomic_store(atomic<T*>&,T*);
template<typename T>
void atomic_store(atomic<T*>&,void*) = delete;
template<typename T>
void
atomic_store_explicit(atomic<T*>&,T*,memory_or
der);
template<typename T>
void
atomic_store_explicit(atomic<T*>&,void*,memory
_order) = delete;
template<typename T>
T* atomic_exchange(atomic<T*>&,T*);
template<typename T>
T* atomic_exchange(atomic<T*>&,void*) = delete;
template<typename T>
T*
atomic_exchange_explicit(atomic<T*>&,T*,memor
y_order);
template<typename T>
T*
atomic_exchange_explicit(atomic<T*>&,void*,me
mory_order) = delete;
template<typename T>
T*
atomic_compare_exchange_weak(atomic<T*>&,T
**,T*);
template<typename T>
T*
atomic_compare_exchange_weak(atomic<T*>&,v
oid**,void*) = delete;
template<typename T>
T*
atomic_compare_exchange_weak_explicit(atomic
<T*>&,T**,T*,memory_order);
template<typename T>
T*
atomic_compare_exchange_weak_explicit(atomic
<T*>&,void**,void*,memory_order) = delete;
template<typename T>
T*
atomic_compare_exchange_strong(atomic<T*>&,
T**,T*);
template<typename T>
T*
atomic_compare_exchange_strong(atomic<T*>&,
void**,void*) = delete;
template<typename T>
T*
atomic_compare_exchange_strong_explicit(atomi
c<T*>&,T**,T*,memory_order);
template<typename T>
T*
atomic_compare_exchange_strong_explicit(atomi
c<T*>&,void**,void*,memory_order) = delete;
 
LWG  1469  ACCEPTED with MODIFICATIONS

See paper N3193 
US 165 29.5.3 ¶ Paragraph 23   “is the same that same as that of” is not grammatical (and is not clear)     LWG  1470   
US 166 29.6 ¶ para 2   The first three bullets seem to be missing terminal punctuation.   Add semicolons to ends of the bullets.   editor    ACCEPTED  
US 167 29.6 ¶ para 3   The first three bullets seem to be missing terminal punctuation.   Add semicolons to ends of the bullets.   editor    REJECTED

Seems to be a duplicate of US 166 but with the wrong section number.  
US 168 29.6 ¶ para 4   The definition of the default constructor needs exposition.   Add a new paragraph: A::A() = default; Effects: Leaves the atomic object in an uninitialized state. [Note: These semantics ensure compatiblity with C. --end note]   LWG  1471  ACCEPTED

See paper N3196 
US 169 29.6 ¶ para 5   The definition of ATOMIC_VAR_INIT should be 'implementation defined' rather than 'see below'.   Change it to 'implementation defined'.   editor    REJECTED

No, we should not require implementors to document the details of how they do this.  
US 170 29.6 ¶ para 6   The definition of atomic_init should be grouped with the value constructor.   Move the atomic_init definition to just after the constructor definition.   editor    REJECTED

The current order reflects the order of declarations. No need to change it.  
GB 134 29.6 ¶ 5   Some of the declarations of is_lock_free seem to be missing return types.   Replace:
A::is_lock_free() const volatile;
A::is_lock_free() const;
With:
bool A::is_lock_free() const volatile;
bool A::is_lock_free() const;  
editor    ACCEPTED  
US 171 29.6 ¶ para 6   The atomic_init definition "Non-atomically assigns the value" is not quite correct, as the atomic_init purpose is initialization.   Change "Non-atomically assigns the value desired to *object." with "Initializes *object with value desired". Add the note: "[Note: This function should only be applied to objects that have been default constructed. These semantics ensure compatibility with C. --end note]"   LWG  1472  ACCEPTED

See paper N3196 
US 172 29.6 ¶ para 9, 13, 17, 20   The order specifications are incomplete because the non-_explicit functions do not have such parameters.   Add a new sentence: "If the program does not specify an order, it shall be memory_order_seq_cst." Or perhaps: "The non-_explicit non-member functions shall affect memory as though they were _explicit with memory_order_seq_cst."   LWG  1473  REJECTED

The Concurrency subgroup reviewed this, and deemed it NAD according to 29.6 [atomics.types.operations] paragraph 2, bullet 4.  
US 173 29.6 ¶ para 20   Misspelling.   Replace "operations ate atomic" with "operations are atomic".   editor    ACCEPTED  
US 174 29.6 ¶ para 22   The first note is about effects, not returns.   Move this note to just after the Effects paragraph.   editor    REJECTED

This would require a significant rewrite, because the Returns clause refers to the "result of the comparison" from the Effects clause. Okay as written.  
US 175 29.6 ¶ para 23   The first sentence is grammatically incorrect.   Replace the sentence with two: "The weak compare-and-exchange operations may fail spuriously. That is, it may return false while leaving the contents of memory pointed to by expected the same as it was before the operation."   LWG  1474   
CH 23 29.6 ¶ p23   The first sentence has non-English syntax.   Change to "The weak compare-and-exchange operations may fail spuriously, that is, return false while leaving the contents of memory pointed to by expected unchanged."   LWG  1475   
US 176 29.6 ¶ para 23   Unintended paragraph break.   Proposal: Remove the paragraph break between "will be in a loop." and "When a compare-andexchange is in a loop,".   editor    REJECTED

Okay as written. Two different subjects, two paragraphs.  
US 177 [atomics.types.operations] 29.6 ¶ 23   The first sentence of this paragraph doesn't make sense.   Figure out what it's supposed to say, and say it.   LWG  1476   
GB 135 29.6 ¶ 23   The first sentence of 29.6p23 was changed by n2992 but now makes no sense: "that is, return false while leaving the contents of memory pointed to by expected before the operation is the same that same as that of the object and the same as that of expected after the operation." There's a minor editorial difference between n2992 ("is that same as that" vs "is the same that same as that") but neither version makes sense. Also, the remark talks about "object" which should probably be "object or this" to cover the member functions which have no object parameter.   Fix the Remark to say whatever was intended.   LWG  1477   
GB 136 29.6   See (K) in attachment Appendix 1 - Additional Details   GB requests normative clarification in 29.6p4 that concurrent access constitutes a race, as already done on p6 and p7.   LWG  1478   
US 178 29.7 ¶ para 7   The sentence "The order argument shall not be memory_order_acquire nor memory_order_acq_rel." is awkwardly phrased.   Change the sentence to "The order argument shall be neither memory_order_acquire nor memory_order_acq_rel."   editor    ACCEPTED with MODIFICATIONS

Changed "nor" to "or".  
US 179 29.8 ¶ para 5, 6   The fence functions should be extern "C", for C compatibility.   Add extern "C" to their declarations in 29.8 and in 29.2.   LWG  1479   
GB 137 29.8 ¶ 6   Thread fence not only establish synchronizes with relationships, there are semantics of fences that are expressed not in terms of synchronizes with relationships (for example see 29.3p5). These semantics also need to apply to the use of atomic_signal_fence in a restricted way.   Change 29.8p6 to "Effects: equivalent to atomic_thread_fence(order), except that the resulting ordering constraints are established only between a thread and a signal handler executed in the same thread."   LWG  1480   
US 180 30.1 ¶ para 1   The introductory sentence is missing futures.   Replace "communicate conditions between threads" with "communicate conditions and values between threads".   editor    ACCEPTED  
GB 138 30.2   The FCD combines the requirements for lockable objects with those for the standard mutex objects. These should be separate. This is LWG issue 1268.   See attached Appendix 1 - Additional Details   LWG  1481  ACCEPTED with MODIFICATIONS

See paper N3197 
US 181 30.2.4 ¶ para 2   The timeout operations are under-specified.   Define precise semantics for timeout_until and timeout_for. See Appendix 1 - Additional Details   LWG  1482  ACCEPTED with MODIFICATIONS

See paper N3191 
US 182 [thread.req.native] 30.2.3   native_handle and native-handle_type should be removed. It is implementation-defined whether these names are present in the various thread support classes, and if present, it is implementation-defined what the name native_handle_type refers to. This is exactly what the implementor namespace is for. There is no benefit to programmers from providing a way to portably detect that an implementation provides non-portable extensions. The standard should not reserve these names, with unspecified semantics; it if does, the names will never become portable because implementations will differ on what they mean.   Remove [thread.req.native] 30.2.3 and remove all mentions of native_handle and native_handle_type.   LWG    REJECTED

No consensus to make a change at this time.  
DE 23 30.3   Predefined macros usually start and end with two underscores, see 16.8 and FDIS 29124 = WG21 N3060 clause 7. __STDCPP_THREADS should blend in.   Change the macro name to __STDCPP_THREADS__.   LWG  1483  ACCEPTED  
US 183 30.3.1   There is no way to join a thread with a timeout.   Add join_for and join_until. Or decide one should never join a thread with a timeout since pthread_join doesn't have a timeout version.   LWG  1484  REJECTED

The concurrency working group deemed this an extension beyond the scope of C++0x.  
US 184 30.3.1.1 ¶ para 2   It is unclear when a thread::id ceases to be meaningful. The sentence "The library may reuse the value of a thread::id of a terminated thread that can no longer be joined." implies that some terminated threads can be joined. It says nothing about detached threads.   Require a unique thread::id for every thread that is (1) detached and not terminated or (2) has an associated std::thread object.   LWG  1485   
JP 97 30.3.1.5 ¶ 9   In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.   Change to:
Throws: system_error  
editor    ACCEPTED  
JP 98 30.3.1.5 ¶ 14   In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.   Change to:
Throws: system_error  
editor    ACCEPTED  
CH 24 30.3.2 ¶ p1   What would be the value this_thread::get_id() when called from a detached thread?   Add some text to clarify that get_id() still returns the same value even after detaching.   LWG  1486   
CH 25 30.3.2 ¶ p8 and p11   Clock related operations are currently not required not to throw. So "Throws: Nothing." is not always true.   Either require clock related operations not to throw (in 20.10) or change the Throws clauses in 30.3.2. Also possibly add a note that abs_time in the past or negative rel_time is allowed.   LWG  1487   
US 185 30.4   Cooperate with WG14 to improve interoperability between the C++0x and C1x threads APIs. In particular, C1x mutexes should be conveniently usable with a C++0x lock_guard. Performance overheads for this combination should be considered.   Remove C++0x timed_mutex and timed_recursive_mutex if that facilitates development of more compatible APIs.   LWG  1488  REJECTED

The concurrency group reviewed the options, and decided that closer harmony should wait until both standards are published.  
CH 26 30.4   Specifications of unlock member functions and unlock mutex requirements are inconsistent wrt to exceptions and pre- and postconditions.   unlock should specifiy the precondition that the current thread "owns the lock", this will make calls without holding the locks "undefined behavior". unlock in [mutex.requirements] should either be noexcept(true) or be allowed to throw system_error like unique_lock::unlock, or the latter should be nothrow(true) and have the precondition owns==true. Furthermore unique_lock's postcondition is wrong in the case of a recursive mutex where owns might stay true, when it is not the last unlock needed to be called.   LWG  1489  ACCEPTED with MODIFICATIONS

See paper N3197 
CH 27 30.4.1 ¶ p18   The mutex requirements force try_lock to be noexcept(true). However, where they are used by the generic algorithms, those relax this requirement and say that try_lock may throw. This means the requirement is too stringent, also a non-throwing try_lock does not allow for a diagnostic such as system_error that lock() will give us.   delete p18, adjust 30.4.4 p1 and p4 accordingly   LWG  1490  ACCEPTED with MODIFICATIONS

See paper N3197 
JP 99 30.4.1 ¶ 11   In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.   Change to:
Throws: system_error  
editor    ACCEPTED  
US 186 30.4.1 ¶ 14   try_lock does not provide a guarantee of forward progress because it is allowed to spuriously fail.   The standard mutex types must not fail spuriously in try_lock. See Appendix 1 - Additional Details   LWG  1491  ACCEPTED with MODIFICATIONS

See paper N3209 
US 187 30.4.1 ¶ 14   Paragraph mentions compare_exchange, which no longer exists.   Change “compare_exchange” to “compare_exchange_weak”.   editor    ACCEPTED with MODIFICATIONS

Changed compare_exchange to "compare and exchange".  
JP 57 30.4.1 ¶ 14   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(29)" to "(Clause 29)".   editor    ACCEPTED  
US 188 30.4.1 ¶ 20, 21   Mutex requirements should not be bound to threads   See Appendix 1 - Additional Details   LWG  1492  ACCEPTED with MODIFICATIONS

See paper N3197 
JP 58 30.4.1.1 ¶ 3   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(9)" to "(Clause 9)".   editor    ACCEPTED  
US 189 30.4.1.1 30.4.1.2   mutex and recursive_mutex should have an is_locked() member function. is_locked allows a user to test a lock without acquiring it and can be used to implement a lightweight try_try_lock.   Add a member function:
bool is_locked() const;
to std::mutex and std::recursive_mutex. These functions return true if the current thread would not be able to obtain a mutex. These functions do not synchronize with anything (and, thus, can avoid a memory fence).  
LWG  1493  REJECTED

The Concurrency subgroup reviewed this issue and deemed it to be an extension to be handled after publishing C++0x.  
JP 59 30.4.1.2 ¶ 2   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(9)" to "(Clause 9)".   editor    ACCEPTED  
JP 60 30.4.2.1 ¶ 2   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(9)" to "(Clause 9)".   editor    ACCEPTED  
JP 61 30.4.2.2 ¶ 2   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(9)" to "(Clause 9)".   editor    ACCEPTED  
JP 70 30.4.3.2 ¶ 18   Constant width font should be used for "std::system_error"s in the paragraph as described in Syntax notation (1.6).   Change the font for "std::system_error" to constant width type.
Throws: system_error when an exception is required  
editor    ACCEPTED  
JP 100 30.4.3.2.2 ¶ 18   In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.   Change to:
Throws: system_error  
editor    ACCEPTED  
US 190 30.4.5.2 ¶ para 2, 3   The term "are serialized" is never defined.   Remove the sentence with "are serialized" from paragraph 2. Add "Calls to call_once on the same once_flag object shall not introduce data races (17.6.4.8)." to paragraph 3.   LWG  1494   
JP 101 30.4.5.2 ¶ 4   In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.   Change to:
Throws: system_error  
editor    ACCEPTED  
US 191 30.5   The condition variable wait_for returning cv_status is insufficient.   Return a duration of timeout remaining instead. See Appendix 1 - Additional Details   LWG  1495  ACCEPTED with MODIFICATIONS

See paper N3191 
GB 139 30.5 ¶ 7   The text says "... ownership of the lock as the current thred exits, ...", with "thread" misspelled.   Replace "thred" with "thread"   editor    ACCEPTED  
GB 140 30.5 ¶ 9   The text says "... waiting threds ..." with "threads" misspelled.   Replace "threds" with "threads".   editor    ACCEPTED  
CH 28 30.5.1   Requiring wait_until makes it impossible to implement condition_variable correctly using respective objects provided by the operating system (i.e. implementing the native_handle() function) on many platforms (e.g. POSIX, Windows, MacOS X) or using the same object as for the condition variable proposed for C.   Remove the wait_until functions or make them at least conditionally supported.   LWG  1496  ACCEPTED with MODIFICATIONS

See paper N3191 
JP 102 30.5.1 ¶ 3   In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.   Change to:
Throws: system_error  
editor    ACCEPTED  
CH 30 30.5.1 and 30.5.2 ¶ p13, last bullet, and corresponding paragraphs in all wait functions   If lock.lock() throws an exception, the postcondition can not be generally achieved.   Either state that the postcondition might not be achieved, depending on the error condition, or state that terminate() is called in this case.   LWG  1497   
JP 103 30.5.1 ¶ 15   In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.   Change to:
Throws: system_error  
editor    ACCEPTED  
CH 31 30.5.1 and 30.5.2 ¶ p19, third bullet, and corresponding paragraphs in all wait_for/wait_until functions   The sentences contain superflous "or"s.   Change "The function will unblock when signaled by a call to notify_one() or a call to notify_all(), if abs_time <= Clock::now(), or spuriously." to "The function will unblock when signaled by a call to notify_one(), a call to notify_all(), if abs_time <= Clock::now(), or spuriously."   editor    REJECTED

This is correct as written. There are three conditions: "when signalled", "if", "spuriously". The first has two parts, separated by "or".  
JP 104 30.5.1 ¶ 22   In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.   Change to:
Throws: system_error  
editor    ACCEPTED  
US 192 30.5.1 ¶ para 26   The identifier cv_status::no_timeout is not in code font.   Change it to code font.   editor    ACCEPTED  
CH 29 30.5.1 and 30.5.2 ¶ p34 and p28, respectively   It is unclear if a spurious wake-up during the loop and reentering of the blocked state due to a repeated execution of the loop will adjust the timer of the blocking with the respect to the previously specified rel_time value.   Make it clear (e.g. by a note) that when reexecuting the loop the waiting time when blocked will be adjusted with respect to the elapsed time of the previous loop executions.   LWG  1498  ACCEPTED with MODIFICATIONS

See paper N3191 
US 193 30.5.1, 30.5.2   Condition variables preclude a wakeup optimization.   Change condition_variable to allow such optimization. See Appendix 1 - Additional Details   LWG  1499  REJECTED

THe Concurrency subgroup reviewed the issue, and deemed it an extension to be handled after C++0x.  
JP 62 30.5.1 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(9)" to "(Clause 9)".   editor    ACCEPTED  
CH 32 30.5.2   Given that the lock type can be something the underlying doesn't know 'native_handle()' is probably unimplementable on essentially all platforms.   Consider the removal of 'native_handle()'.   LWG  1500  ACCEPTED  
JP 105 30.5.2 ¶ 12   In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.   Change to:
Throws: system_error  
editor    ACCEPTED  
JP 106 30.5.2 ¶ 18   In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error.   Change to:
Throws: system_error  
editor    ACCEPTED  
CH 33 30.5.2 ¶ before p25   Template function wait_until is missing class Clock template parameter.   Change "template <class Lock, class Duration, class Predicate>" to "template <class Lock, class Clock, class Duration, class Predicate>".   editor    ACCEPTED  
JP 96 30.5.3 ¶ 2   Inconsistency between 30.4 paragraph 1 and 30.4.3 paragraph 2. In 30.4 paragraph 1:
namespace std {
...
constexpr defer_lock_t defer_lock { };
constexpr try_to_lock_t try_to_lock { };
constexpr adopt_lock_t adopt_lock { };
}
In 30.4.3 paragraph 2:
namespace std {
...
extern const defer_lock_t defer_lock { };
extern const try_to_lock_t try_to_lock { };
extern const adopt_lock_t adopt_lock { };
}
The writer seems to have forgotten to rewrite latter cases, so 30.4.3 paragraph 2 should be modified as this proposal.  
Change "extern const" to "constexpr".
namespace std {
...
constexpr defer_lock_t defer_lock { };
constexpr try_to_lock_t try_to_lock { };
constexpr adopt_lock_t adopt_lock { };
}
 
editor    ACCEPTED  
US 194 30.6   The specification for managing associated asynchronous state is confusing, sometimes omitted, and redundantly specified.   Define terms-of-art for releasing, making ready, and abandoning an associated asynchronous state. Use those terms where appropriate. See Appendix 1 - Additional Details   LWG  1501  ACCEPTED with MODIFICATIONS

See paper N3192 
CH 34 30.6.1 ¶ p1   The paragraph is misleading and incorrect wrt to the current specification, since an async call with launch::sync will execute in the same thread.   Change the paragraph to '30.6 describes components that a C++ program can use to retrieve the result (value or exception) of a function that has run in a (potentially different) thread.'   editor    ACCEPTED  
US 195 30.6.4 ¶ para 8   The intent and meaning of the paragraph is not apparent.     LWG  1502   
CH 35 30.6.4ff   The term "associated asynchronous state" is long, ugly and misleading terminology. When introduced we agreed upon that we should come up with a better name. Here it is: "liaison state". Since the state is hidden and provides synchronization of a future with its corresponding promise, we believe "liaison state" is a much better and shorter name (liaison ~ (typically hidden) relationship)   Change all occurrences of "associated asynchronous state" to "liaison state".   LWG  1503   
US 196 30.6.5 ¶ para 21, 25   The term "are serialized" is not defined.   Replace "are serialized" with "shall not introduce a data race (17.6.4.8)".   LWG  1504   
US 197 30.6.5 ¶ para 21, 25   There is no defined synchronization between promise::set_value and future::get.   Replace "[Note: and they synchronize and serialize with other functions through the referred associated asynchronous state. --end note]" with the normative "They synchronize with (1.10) any operation on a future object with the same associated asynchronous state marked ready."   LWG  1505   
US 198 30.6.5 ¶ 22   promise::set_exception can be called with a null pointer, but none of the descriptions of the get() functions for the three types of futures say what happens for this case.   Add the following sentence to the end of 30.6.5/22: The behavior of a program that calls set_exception with a null pointer is undefined.   LWG  1506  ACCEPTED  
US 199 [futures.promise] 30.6.5 ¶ 26ff, 29ff   promise::XXX_at_thread_exit functions have no synchronization requirements. Specifying synchronization for these member functions requires coordinating with the words in 30.6.5/21 and 25, which give synchronization requirements for promise::set_value and promise::set_exception.   Change 30.6.5/21 to mention set_value_at_thread_exit and set_exception_at_thread_exit; with this text, replace 30.6.5/25 and add two new paragraphs, after 30.6.5/28 and 30.6.5/31.   LWG  1507   
US 200 30.6.6 ¶ para 26   The paragraph is missing the "Returns:" label.   Add the label.   editor    ACCEPTED  
US 201 [futures.unique_future], [futures.shared_future], [futures.atomic_future], [futures.task] 30.6.6 30.6.7 30.6.8 30.6.10   packaged_task provides operator bool() to check whether an object has an associated asynchronous state. The various future types provide a member function valid() that does the same thing. The names of these members should be the same.   Replaced the name packaged_task::operator bool() with packaged_task::valid() in the synopsis (30.6.10 [futures.task]/2) and the member function specification (before 30.6.10.1 [futures.task.members]/15).   LWG  1508  ACCEPTED with MODIFICATIONS

See paper N3194 
US 202 [futures.atomic_future] 30.6.8 ¶ 18   The note in this paragraph says "unlike future, calling get more than once on the same atomic_future object is well defined and produces the result again." There is nothing in future that says anything negative about calling get more than once.   Remove this note, or add words to the requirements for future that reflect what this note says.   LWG  1509  ACCEPTED with MODIFICATIONS

See paper N3194 
US 203 [futures.atomic_future] 30.6.8   Both future and shared_future specify that calling most member functions on an object for which valid() == false produces undefined behavior. There is no such statement for atomic_future.   Add a new paragraph after 30.6.8 [futures.atomic_future]/2 with the same words as 30.6.7 [futures.shared_future]/3.   LWG  1510  ACCEPTED with MODIFICATIONS

See paper N3194 
US 204 30.6.8 ¶ Paragraph 7-8   According to the definition of atomic_future, all members of atomic_future are synchronizing except constructors. However, it would probably be appropriate for a move constructor to be synchronizing on the source object. If not, the postconditions on paragraphs 7-8, might not be satisfied. This may be applicable if a collection of futures are being doled out to a set of threads that process their value.   Make the move constructor for atomic future lock the source   LWG  1511  ACCEPTED with MODIFICATIONS

See paper N3194 
US 205 [futures.async] 30.6.9 ¶ 3   The third sentence says "If the invocation is not deferred, a call to a waiting function on an asynchronous return object that shares the associated asynchronous state created by this async call shall block until the associated thread has completed." The next sentence says "If the invocation is not deferred, the join() on the created thread..." Blocking until a thread completes is not necessarily a join.   Decide whether the requirement is to block until finished or to call join, and rewrite to match.   LWG  1512  ACCEPTED with MODIFICATIONS

See paper N3194 
CH 36 30.6.9 and 30.6.1 ¶ <future> synopsis and p3, respectively   Providing only three different possible values for the enum launch and saying that launch::any means either launch::sync or launch::async is very restricting. This hinders future implementors to provide clever infrastructures that can simply by used by a call to async(launch::any,...). Also there is no hook for an implementation to provide additional alternatives to launch enumeration and no useful means to combine those (i.e. interpret them like flags). We believe something like async(launch::sync | launch::async, ...) should be allowed and can become especially useful if one could say also something like async(launch::any & ~launch::sync, ....) respectively. This flexibility might limit the features usable in the function called through async(), but it will allow a path to effortless profit from improved hardware/software without complicating the programming model when just using async(launch::any,...)   Change in 30.6.1 'enum class launch' to allow further implementation defined values and provide the following bit-operators on the launch values (operator|, operator&, operator~ delivering a launch value).
Note: a possible implementation might use an unsigned value to represent the launch enums, but we shouldn't limit the standard to just 32 or 64 available bits in that case and also should keep the launch enums in their own enum namespace.
Change [future.async] p3 according to the changes to enum launch. change --launch::any to "the implementation may choose any of the policies it provides." Note: this can mean that an implementation may restrict the called function to take all required information by copy in case it will be called in a different address space, or even, on a different processor type. To ensure that a call is either performed like launch::async or launch::sync describe one should call async(launch::sync|launch::async,...)  
LWG  1513  ACCEPTED with MODIFICATIONS

See paper N3188 
JP 107 30.6.9 ¶ 3   Typo, "." should be ">". decay_copy(std::forward<Args.(args))...   Correct typo. decay_copy(std::forward<Args>(args))...   editor    ACCEPTED  
JP 108 30.6.9 ¶ 3   <Arg> should be <Args>. launch::sync Stores decay_copy(std::forward<F>(f)) and decay_copy(std::forward<Arg>(args))...   Change to:
launch::sync Stores decay_copy(std::forward<F>(f)) and decay_copy(std::forward<Args>(args))...  
editor    ACCEPTED  
US 206 [futures.task.members] 30.6.10.1 ¶ 27, 28   The text of paragraph 27 says that reset() moves the function object, but the text of paragraph 28 talks about exceptions thrown by the copy constructor.   Change "copy constructor" to "move constructor" in 30.6.10.1/28, bullet 2.   editor    ACCEPTED  
US 207 [futures.task.members] 30.6.10.1 ¶ 1-8   The constructor that takes R(*)(ArgTypes...) is not needed; the constructor that takes a callable type works for this argument type. More generally, the constructors for packaged_task should parallel those for function.   Review the constructors for packaged_task and provide the same ones as function, except where inappropriate.   LWG  1514   
US 208 [futures.task.members] 30.6.10.1 ¶ 24-26   packaged_task::make_ready_at_thread_exit has no synchronization requirements.   Figure out what the synchronization requirements should be and write them.   LWG  1515   
GB 141 Appendix A [gram] paragraph 1   The links for disambiguation rules go to 6.8, 7.1 and 10.2. Section 8.2 covers ambiguity in declarators, so should be added   Added a link to 8.2 [dcl.ambig.res] to Appendix A p1   editor    ACCEPTED  
JP 63 A.1 ¶ 1   Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z.   Change "(clause 9)" to "(Clause 9)". Change "(clause 14)" to "(Clause 14)".   editor    ACCEPTED  
FI 6 D.2 [depr.static] ¶ Paragraph 1   The use of static in namespace scope should not be deprecated. Anonymous namespaces are not a sufficient replacement for the functionality.   Strike [depr.static] completely.   CWG  1012  ACCEPTED  
GB 142 D10   auto_ptr does not appear in the <memory> synopsis and [depr.auto.ptr] doesn't say which header declares it. Conversely, the deprecated binders bind1st etc. are in the <functional> synopsis, this is inconsistent   Either auto_ptr should be declared in the <memory> synopsis, or the deprecated binders should be removed from the <functional> synopsis and appendix D should say which header declares the binders and auto_ptr   LWG  1516  ACCEPTED  
JP 109 Annex B   Although implementation limits for at_quick_exit() is mentioned in 18.5 paragraph 5, it is not on the list of Implementation quantities.   Add the following line. — Functions registered by at_quick_exit()[32].   editor    ACCEPTED  
JP 110 Index   "local scope" has been renamed to "block scope", but the reference to "local scope" still remains in Index.
block scope; see local scope, 37
"local scope" should refer to "block scope".  
Change to:
local scope; see block scope, 37  
editor    ACCEPTED