Document number:  PL22.16 09/0053 = WG21 N2863
Date:  2009-03-23
Reply to:  William M. Miller
 Edison Design Group, Inc.
 wmm@edg.com






C++ CD1 Comment Status

This document summarizes the progress of WG21 in addressing National Body comments on Committee Draft document N2800. In total, 591 comments were received. To date, 216 have been accepted or tentatively accepted as proposed, 27 have been accepted or tentatively accepted with modifications, 99 have been rejected, and 249 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 N2837; the “Disposition” field gives the response, as well as any explanatory comments provided by the responsible party. (The internal formatting of the text of the national body comments will be improved in future revisions of this document.)


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 CWG accepted       
CA 2 LWG accepted       
CH 1 CWG     794   
CH 2 CWG accepted       
DE 1 CWG accepted       
DE 2 LWG        
DE 3 CWG     735   
DE 4 CWG     693   
DE 5 CWG     731   
DE 6 CWG modified  2009-03-06    N2845 
DE 7 editor rejected       
DE 8 CWG accepted  2009-03-06    N2841 
DE 9 CWG     720   
DE 10 CWG     731   
DE 11 CWG accepted  2009-03-06    N2841 
DE 12 CWG     731   
DE 13 CWG     732   
DE 14 CWG     730   
DE 15 CWG        
DE 16 LWG     902   
DE 17 LWG     1078   
DE 18 LWG        
DE 20 editor accepted       
DE 21 LWG accepted    817   
DE 22 LWG accepted    1023   
DE 23 CWG     699   
DE 24 LWG     922   
DE 25 CWG     831   
FI 1 CWG        
FI 2 CWG rejected       
FI 3 CWG rejected       
FI 4 editor accepted       
FI 5 editor accepted       
FI 6 LWG        
FI 7 editor accepted       
FR 1 CWG        
FR 2 editor        
FR 3 editor        
FR 4 editor        
FR 5 CWG     690   
FR 6 editor        
FR 7 editor rejected       
FR 8 editor rejected       
FR 9 editor accepted       
FR 10 CWG     788   
FR 11 editor accepted       
FR 12 CWG rejected       
FR 13 editor modified       
FR 14 editor accepted       
FR 15 editor accepted       
FR 16 CWG     481   
FR 17 CWG     791   
FR 18 editor accepted       
FR 19 CWG rejected       
FR 20 CWG rejected       
FR 21 CWG rejected       
FR 22 CWG rejected       
FR 23 CWG rejected       
FR 24 CWG rejected       
FR 25 CWG rejected       
FR 26 CWG        
FR 27 CWG rejected       
FR 28 CWG accepted  2009-03-06    N2841 
FR 29 CWG     823   
FR 30 CWG rejected       
FR 31 CWG        
FR 32 LWG     902   
FR 33 editor accepted       
FR 34 editor accepted       
FR 35 LWG        
FR 36 editor accepted       
FR 37 editor accepted       
FR 38 LWG accepted       
FR 39 editor        
JP 1 editor accepted       
JP 2 editor accepted       
JP 3 editor accepted       
JP 4 editor accepted       
JP 5 CWG     790   
JP 6 editor accepted       
JP 7 editor accepted       
JP 8 CWG     743   
JP 9 CWG rejected       
JP 10 CWG rejected       
JP 11 CWG rejected       
JP 12 CWG     699   
JP 13 editor accepted       
JP 14 CWG     812   
JP 15 editor rejected       
JP 16 editor accepted       
JP 17 CWG rejected       
JP 18 CWG rejected       
JP 19 editor accepted       
JP 20 CWG     825   
JP 21 LWG rejected       
JP 22 editor rejected       
JP 23 LWG     1003   
JP 24 editor accepted       
JP 25 editor accepted       
JP 26 LWG     1005   
JP 27 LWG        
JP 28 LWG rejected       
JP 29 LWG     1007   
JP 30 LWG        
JP 31 LWG     1008   
JP 32 LWG rejected       
JP 33 LWG     1016   
JP 34 editor accepted       
JP 35 editor accepted       
JP 36 editor accepted       
JP 37 editor accepted       
JP 38 LWG     817   
JP 39 LWG modified    1024   
JP 40 editor accepted       
JP 41 LWG rejected       
JP 42 editor accepted       
JP 43 editor accepted       
JP 44 LWG accepted    1030   
JP 45 LWG     1032   
JP 46 LWG     1081   
JP 47 editor accepted       
JP 48 LWG     1081   
JP 49 LWG     1082   
JP 50 LWG     991   
JP 51 editor accepted       
JP 52 LWG     1083   
JP 53 LWG     1083   
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 LWG rejected       
JP 61 editor accepted       
JP 62 LWG rejected       
JP 63 LWG accepted  2009-03-06  874  N2836 
JP 64 LWG        
JP 65 LWG        
JP 66 LWG        
JP 67 LWG        
JP 68 LWG        
JP 69 LWG        
JP 71 editor accepted       
JP 72 LWG        
JP 73 LWG        
JP 74 LWG     1014   
JP 75 LWG rejected       
JP 76 LWG     1089   
JP 77 LWG        
JP 78 editor accepted       
JP 79 LWG        
JP 80 editor accepted       
JP 81 LWG        
UK 1 editor rejected       
UK 2 editor rejected       
UK 3 CWG     783   
UK 4 CWG rejected       
UK 5 editor        
UK 6 CWG     784   
UK 7 CWG     785   
UK 8 CWG     785   
UK 9 CWG     787   
UK 10 CWG accepted  2009-03-06    N2841 
UK 11 CWG     789   
UK 12 CWG     787   
UK 13 CWG     832   
UK 14 editor accepted       
UK 15 CWG rejected       
UK 16 editor accepted       
UK 17 CWG rejected       
UK 18 CWG rejected       
UK 19 CWG rejected       
UK 20 editor        
UK 21 editor        
UK 22 CWG     633   
UK 23 CWG     758   
UK 24 CWG rejected       
UK 25 CWG accepted  2009-03-06    N2841 
UK 26 CWG     570   
UK 27 CWG accepted  2009-03-06    N2841 
UK 28 CWG accepted  2009-03-06    N2841 
UK 29 CWG rejected       
UK 30 CWG     791   
UK 31 CWG accepted  2009-03-06    N2841 
UK 32 CWG accepted  2009-03-06    N2841 
UK 33 CWG accepted  2009-03-06    N2841 
UK 34 editor accepted       
UK 35 editor accepted       
UK 36 CWG accepted  2009-03-06    N2841 
UK 37 CWG rejected       
UK 38 CWG rejected       
UK 39 CWG     759   
UK 40 CWG     796   
UK 41 CWG modified  2009-03-06    N2845 
UK 42 CWG     797   
UK 43 CWG modified  2009-03-06    N2845 
UK 44 CWG rejected       
UK 45 CWG     795   
UK 46 CWG modified  2009-03-06    N2845 
UK 47 CWG accepted  2009-03-06    N2841 
UK 48 editor accepted       
UK 49 CWG     699   
UK 50 CWG     806   
UK 51 CWG     807   
UK 52 editor modified       
UK 53 CWG     798   
UK 54 CWG accepted  2009-03-06    N2841 
UK 55 CWG   2009-03-06  799  N2841 
UK 56 CWG modified  2009-03-06    N2841 
UK 57 CWG     800   
UK 58 CWG     801   
UK 59 CWG accepted  2009-03-06    N2841 
UK 60 editor accepted       
UK 61 editor accepted       
UK 62 CWG accepted  2009-03-06    N2841 
UK 63 editor accepted       
UK 64 editor accepted       
UK 65 CWG modified  2009-03-06    N2841 
UK 66 CWG accepted  2009-03-06    N2841 
UK 67 CWG accepted  2009-03-06    N2841 
UK 68 CWG accepted  2009-03-06    N2841 
UK 69 CWG     802   
UK 70 CWG     803   
UK 71 CWG     804   
UK 72 CWG     805   
UK 73 CWG rejected       
UK 74 CWG rejected       
UK 75 editor accepted       
UK 76 CWG rejected       
UK 77 editor accepted       
UK 78 LWG     1001   
UK 79 CWG rejected       
UK 80 editor modified       
UK 81 CWG rejected       
UK 82 CWG rejected       
UK 83 CWG     808   
UK 84 CWG accepted  2009-03-06    N2841 
UK 85 CWG        
UK 86 CWG     809   
UK 87 CWG     810   
UK 89 CWG     811   
UK 90 editor accepted       
UK 91 CWG modified  2009-03-06    N2841 
UK 92 editor accepted       
UK 93 editor accepted       
UK 94 editor accepted       
UK 95 CWG     746   
UK 96 CWG     628   
UK 97 editor accepted       
UK 98 LWG     1055   
UK 99 CWG rejected       
UK 100 CWG rejected       
UK 101 CWG     813   
UK 102 editor modified       
UK 103 CWG     815   
UK 104 editor rejected       
UK 105 CWG rejected       
UK 106 editor accepted       
UK 107 editor accepted       
UK 108 CWG     816   
UK 109 editor accepted       
UK 110 CWG accepted  2009-03-06    N2841 
UK 111 editor accepted       
UK 112 editor rejected       
UK 113 editor accepted       
UK 114 CWG rejected       
UK 115 CWG     820   
UK 116 CWG     821   
UK 117 CWG     822   
UK 118 editor accepted       
UK 119 CWG     791   
UK 120 editor accepted       
UK 121 editor accepted       
UK 122 CWG        
UK 123 CWG        
UK 124 editor accepted       
UK 125 CWG        
UK 126 editor accepted       
UK 127 editor        
UK 128 editor accepted       
UK 129 CWG     826   
UK 130 CWG     828   
UK 131 CWG accepted  2009-03-06    N2844 
UK 132 CWG accepted  2009-03-06    N2841 
UK 133 CWG accepted  2009-03-06    N2841 
UK 134 editor accepted       
UK 135 CWG     829   
UK 136 CWG     830   
UK 137 editor accepted       
UK 138 editor rejected       
UK 139 CWG accepted  2009-03-06    N2841 
UK 140 editor accepted       
UK 141 editor accepted       
UK 142 editor accepted       
UK 143 editor accepted       
UK 144 editor accepted       
UK 145 editor accepted       
UK 146 editor accepted       
UK 147 editor accepted       
UK 148 editor        
UK 149 editor modified       
UK 150 editor        
UK 151 editor modified       
UK 152 LWG     1064   
UK 153 editor accepted       
UK 154 editor rejected       
UK 155 editor accepted       
UK 156 editor accepted       
UK 157 editor accepted       
UK 158 editor accepted       
UK 159 editor accepted       
UK 160 editor        
UK 161 editor rejected       
UK 162 editor accepted       
UK 163 LWG     997   
UK 164 editor        
UK 165 LWG        
UK 166 editor accepted       
UK 167 editor accepted       
UK 168 LWG     1065   
UK 169 LWG     992   
UK 170 LWG     1002   
UK 171 editor accepted       
UK 172 LWG rejected       
UK 173 LWG        
UK 174 editor accepted       
UK 175 LWG accepted       
UK 176 editor modified       
UK 177 editor accepted       
UK 178 editor rejected       
UK 179 LWG accepted    1004   
UK 180 LWG rejected       
UK 181 editor accepted       
UK 182 LWG rejected       
UK 184 editor        
UK 185 editor accepted       
UK 186 editor accepted       
UK 187 LWG        
UK 188 LWG accepted    993   
UK 189 LWG accepted    1066   
UK 190 LWG accepted    1006   
UK 191 editor modified       
UK 192 CWG     805   
UK 193 LWG     994   
UK 194 LWG        
UK 195 LWG        
UK 196 LWG        
UK 197 LWG rejected       
UK 198 editor        
UK 199 LWG accepted    1015   
UK 200 LWG rejected       
UK 201 LWG rejected       
UK 202 editor accepted       
UK 203 editor accepted       
UK 204 LWG accepted    1020   
UK 205 LWG accepted    1019   
UK 206 LWG accepted       
UK 207 editor accepted       
UK 208 LWG rejected       
UK 209 LWG     1026   
UK 210 LWG     1029   
UK 211 LWG accepted    1021   
UK 212 LWG modified       
UK 213 LWG accepted    1027   
UK 214 LWG     1028   
UK 215 editor accepted       
UK 216 LWG     1081   
UK 217 editor accepted       
UK 218 LWG        
UK 219 editor accepted       
UK 220 LWG        
UK 221 editor accepted       
UK 222 LWG     1034   
UK 223 LWG accepted  2009-03-06    N2840 
UK 224 LWG modified  2009-03-06    N2840 
UK 225 editor accepted       
UK 226 LWG     1035   
UK 227 editor accepted       
UK 228 editor accepted       
UK 229 editor accepted       
UK 230 LWG rejected       
UK 231 LWG     1036   
UK 232 LWG accepted    1037   
UK 233 LWG accepted    1038   
UK 234 LWG accepted    1039   
UK 235 editor accepted       
UK 236 editor modified       
UK 237 editor accepted       
UK 238 LWG modified    1040   
UK 239 LWG     1041   
UK 240 LWG        
UK 241 LWG        
UK 242 editor accepted       
UK 243 LWG rejected       
UK 244 LWG     1042   
UK 245 LWG rejected       
UK 246 LWG     1091   
UK 247 LWG rejected       
UK 248 editor accepted       
UK 249 LWG rejected       
UK 250 LWG     1084   
UK 251 LWG     1009   
UK 252 editor accepted       
UK 253 editor accepted       
UK 254 LWG        
UK 255 LWG        
UK 256 LWG        
UK 257 LWG rejected       
UK 258 LWG     1085   
UK 259 LWG rejected       
UK 260 LWG        
UK 261 LWG rejected       
UK 262 LWG        
UK 263 LWG     1010   
UK 264 LWG        
UK 265 LWG     1079   
UK 266 LWG        
UK 267 LWG        
UK 268 editor accepted       
UK 269 editor accepted       
UK 270 LWG     940   
UK 271 LWG     1011   
UK 272 LWG rejected       
UK 274 editor accepted       
UK 275 LWG rejected       
UK 276 LWG rejected       
UK 277 LWG     1012   
UK 278 LWG rejected       
UK 279 LWG     1051   
UK 280 editor accepted       
UK 281 LWG     1052   
UK 282 LWG     901   
UK 283 LWG rejected       
UK 284 LWG accepted    1086   
UK 285 editor        
UK 286 editor        
UK 287 LWG     788   
UK 288 editor        
UK 289 editor        
UK 290 editor accepted       
UK 291 LWG rejected       
UK 292 editor        
UK 293 editor        
UK 294 LWG rejected       
UK 295 LWG     1053   
UK 296 LWG rejected       
UK 297 editor accepted       
UK 298 editor accepted       
UK 299 editor        
UK 300 LWG rejected       
UK 301 LWG     1087   
UK 302 editor rejected       
UK 303 editor rejected       
UK 304 editor rejected       
UK 305 LWG accepted    1013   
UK 306 LWG accepted  2009-03-06    N2836 
UK 307 editor accepted       
UK 308 LWG        
UK 309 LWG        
UK 310 LWG        
UK 311 LWG        
UK 312 LWG        
UK 313 LWG     926   
UK 314 LWG        
UK 315 editor accepted       
UK 316 LWG accepted    723   
UK 317 LWG     1014   
UK 318 editor accepted       
UK 319 LWG     909   
UK 320 LWG        
UK 321 editor        
UK 322 LWG        
UK 323 LWG accepted    929   
UK 324 LWG rejected    889   
UK 325 LWG     1044   
UK 326 LWG accepted    1045   
UK 327 LWG        
UK 328 LWG        
UK 329 LWG     1046   
UK 330 editor accepted       
UK 331 LWG        
UK 332 editor        
UK 333 LWG        
UK 334 LWG accepted    1047   
UK 335 LWG     1048   
UK 336 LWG        
UK 337 LWG        
UK 338 LWG        
UK 339 LWG accepted    1049   
UK 340 LWG accepted    1050   
UK 341 LWG        
UK 342 LWG     1088   
UK 343 LWG        
UK 344 CWG rejected       
US 1 CWG accepted       
US 2 LWG accepted       
US 3 editor modified       
US 4 editor        
US 5 editor        
US 6 CWG rejected       
US 7 editor accepted       
US 8 editor accepted       
US 9 editor accepted       
US 10 editor accepted       
US 11 editor accepted       
US 12 CWG modified  2009-03-06    N2841 
US 13 CWG rejected       
US 14 CWG accepted  2009-03-06    N2841 
US 15 CWG rejected       
US 16 CWG     785   
US 17 CWG     786   
US 18 editor accepted       
US 19 editor accepted       
US 20 CWG rejected       
US 21 editor rejected       
US 22 editor accepted       
US 23 editor accepted       
US 24 CWG     792   
US 25 editor rejected       
US 26 CWG     793   
US 27 editor accepted       
US 28 editor accepted       
US 29 CWG     762   
US 30 CWG     762   
US 31 CWG     752   
US 32 editor accepted       
US 33 CWG     680   
US 34 editor accepted       
US 35 editor accepted       
US 36 CWG     717   
US 37 editor accepted       
US 38 editor rejected       
US 39 CWG rejected       
US 40 CWG     814   
US 41 CWG        
US 42 CWG     817   
US 43 CWG        
US 44 editor accepted       
US 45 CWG     818   
US 46 CWG accepted  2009-03-06    N2844 
US 49 editor        
US 50 CWG     819   
US 51 editor accepted       
US 52 editor accepted       
US 53 CWG     824   
US 54 CWG accepted       
US 55 editor accepted       
US 56 editor rejected       
US 57 editor rejected       
US 58 editor accepted       
US 59 CWG        
US 60 CWG     827   
US 61 LWG accepted       
US 62 LWG accepted       
US 63 LWG        
US 64 editor accepted       
US 65 LWG     1075   
US 66 LWG     1017   
US 67 editor modified       
US 68 editor accepted       
US 69 editor        
US 70 LWG     1018   
US 71 editor modified       
US 72 LWG     817   
US 73 CWG accepted  2009-03-06  750  N2845 
US 74.1 LWG   2009-03-06  1075  N2840 
US 74.2 editor modified       
US 75 LWG modified  2009-03-06    N2840 
US 77 LWG        
US 78 LWG     1031   
US 79 LWG accepted    932   
US 80 editor modified       
US 81 LWG accepted    934   
US 82 editor accepted       
US 83 editor accepted       
US 84 LWG        
US 85 LWG        
US 86 LWG        
US 87 LWG        
US 88 LWG        
US 89 LWG     937   
US 90 LWG     908   
US 91 LWG accepted    1043   
US 92 LWG rejected       
US 93 LWG        
US 94 editor accepted       
US 95 LWG rejected       
US 96 LWG rejected       
US 97 LWG   2009-03-06    N2802 
US 98 LWG        

UNRESOLVED COMMENTS:

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

ID Responsible Issue
CH 1 CWG 794 
DE 3 CWG 735 
DE 4 CWG 693 
DE 5 CWG 731 
DE 9 CWG 720 
DE 10 CWG 731 
DE 12 CWG 731 
DE 13 CWG 732 
DE 14 CWG 730 
DE 15 CWG  
DE 23 CWG 699 
DE 25 CWG 831 
FI 1 CWG  
FR 1 CWG  
FR 5 CWG 690 
FR 10 CWG 788 
FR 16 CWG 481 
FR 17 CWG 791 
FR 26 CWG  
FR 29 CWG 823 
FR 31 CWG  
JP 5 CWG 790 
JP 8 CWG 743 
JP 12 CWG 699 
JP 14 CWG 812 
JP 20 CWG 825 
UK 3 CWG 783 
UK 6 CWG 784 
UK 7 CWG 785 
UK 8 CWG 785 
UK 9 CWG 787 
UK 11 CWG 789 
UK 12 CWG 787 
UK 13 CWG 832 
UK 22 CWG 633 
UK 23 CWG 758 
UK 26 CWG 570 
UK 30 CWG 791 
UK 39 CWG 759 
UK 40 CWG 796 
UK 42 CWG 797 
UK 45 CWG 795 
UK 49 CWG 699 
UK 50 CWG 806 
UK 51 CWG 807 
UK 53 CWG 798 
UK 55 CWG 799 
UK 57 CWG 800 
UK 58 CWG 801 
UK 69 CWG 802 
UK 70 CWG 803 
UK 71 CWG 804 
UK 72 CWG 805 
UK 83 CWG 808 
UK 85 CWG  
UK 86 CWG 809 
UK 87 CWG 810 
UK 89 CWG 811 
UK 95 CWG 746 
UK 96 CWG 628 
UK 101 CWG 813 
UK 103 CWG 815 
UK 108 CWG 816 
UK 115 CWG 820 
UK 116 CWG 821 
UK 117 CWG 822 
UK 119 CWG 791 
UK 122 CWG  
UK 123 CWG  
UK 125 CWG  
UK 129 CWG 826 
UK 130 CWG 828 
UK 135 CWG 829 
UK 136 CWG 830 
UK 192 CWG 805 
US 16 CWG 785 
US 17 CWG 786 
US 24 CWG 792 
US 26 CWG 793 
US 29 CWG 762 
US 30 CWG 762 
US 31 CWG 752 
US 33 CWG 680 
US 36 CWG 717 
US 40 CWG 814 
US 41 CWG  
US 42 CWG 817 
US 43 CWG  
US 45 CWG 818 
US 50 CWG 819 
US 53 CWG 824 
US 59 CWG  
US 60 CWG 827 
FR 2 editor  
FR 3 editor  
FR 4 editor  
FR 6 editor  
FR 39 editor  
UK 5 editor  
UK 20 editor  
UK 21 editor  
UK 127 editor  
UK 148 editor  
UK 150 editor  
UK 160 editor  
UK 164 editor  
UK 184 editor  
UK 198 editor  
UK 285 editor  
UK 286 editor  
UK 288 editor  
UK 289 editor  
UK 292 editor  
UK 293 editor  
UK 299 editor  
UK 321 editor  
UK 332 editor  
US 4 editor  
US 5 editor  
US 49 editor  
US 69 editor  
DE 2 LWG  
DE 16 LWG 902 
DE 17 LWG 1078 
DE 18 LWG  
DE 24 LWG 922 
FI 6 LWG  
FR 32 LWG 902 
FR 35 LWG  
JP 23 LWG 1003 
JP 26 LWG 1005 
JP 27 LWG  
JP 29 LWG 1007 
JP 30 LWG  
JP 31 LWG 1008 
JP 33 LWG 1016 
JP 38 LWG 817 
JP 45 LWG 1032 
JP 46 LWG 1081 
JP 48 LWG 1081 
JP 49 LWG 1082 
JP 50 LWG 991 
JP 52 LWG 1083 
JP 53 LWG 1083 
JP 64 LWG  
JP 65 LWG  
JP 66 LWG  
JP 67 LWG  
JP 68 LWG  
JP 69 LWG  
JP 72 LWG  
JP 73 LWG  
JP 74 LWG 1014 
JP 76 LWG 1089 
JP 77 LWG  
JP 79 LWG  
JP 81 LWG  
UK 78 LWG 1001 
UK 98 LWG 1055 
UK 152 LWG 1064 
UK 163 LWG 997 
UK 165 LWG  
UK 168 LWG 1065 
UK 169 LWG 992 
UK 170 LWG 1002 
UK 173 LWG  
UK 187 LWG  
UK 193 LWG 994 
UK 194 LWG  
UK 195 LWG  
UK 196 LWG  
UK 209 LWG 1026 
UK 210 LWG 1029 
UK 214 LWG 1028 
UK 216 LWG 1081 
UK 218 LWG  
UK 220 LWG  
UK 222 LWG 1034 
UK 226 LWG 1035 
UK 231 LWG 1036 
UK 239 LWG 1041 
UK 240 LWG  
UK 241 LWG  
UK 244 LWG 1042 
UK 246 LWG 1091 
UK 250 LWG 1084 
UK 251 LWG 1009 
UK 254 LWG  
UK 255 LWG  
UK 256 LWG  
UK 258 LWG 1085 
UK 260 LWG  
UK 262 LWG  
UK 263 LWG 1010 
UK 264 LWG  
UK 265 LWG 1079 
UK 266 LWG  
UK 267 LWG  
UK 270 LWG 940 
UK 271 LWG 1011 
UK 277 LWG 1012 
UK 279 LWG 1051 
UK 281 LWG 1052 
UK 282 LWG 901 
UK 287 LWG 788 
UK 295 LWG 1053 
UK 301 LWG 1087 
UK 308 LWG  
UK 309 LWG  
UK 310 LWG  
UK 311 LWG  
UK 312 LWG  
UK 313 LWG 926 
UK 314 LWG  
UK 317 LWG 1014 
UK 319 LWG 909 
UK 320 LWG  
UK 322 LWG  
UK 325 LWG 1044 
UK 327 LWG  
UK 328 LWG  
UK 329 LWG 1046 
UK 331 LWG  
UK 333 LWG  
UK 335 LWG 1048 
UK 336 LWG  
UK 337 LWG  
UK 338 LWG  
UK 341 LWG  
UK 342 LWG 1088 
UK 343 LWG  
US 63 LWG  
US 65 LWG 1075 
US 66 LWG 1017 
US 70 LWG 1018 
US 72 LWG 817 
US 74.1 LWG 1075 
US 77 LWG  
US 78 LWG 1031 
US 84 LWG  
US 85 LWG  
US 86 LWG  
US 87 LWG  
US 88 LWG  
US 89 LWG 937 
US 90 LWG 908 
US 93 LWG  
US 97 LWG  
US 98 LWG  

ALL COMMENTS

ID Ref Comment Proposed Resolution Owner Issue Disposition
FR 1 General Comment   Interactions between several new features appear obscure, and very few examples are offered to guide understanding of the formal text on interaction between these new additions. We worry about the complexity of the programming model so created.     CWG    Need more information from NB, including a suggested resolution, in order to respond effectively to this comment.  
US 1 1-16   The active issues identified in WG21 N2803, C++ Standard Core Language Active Issues, must be addressed and appropriate action taken.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html  
Appropriate action would include making changes to the CD, identifying an issue as not requiring a change to the CD, or deferring the issue to a later point in time.   CWG    ACCEPTED  
CA 1   There are quite a number of defects for the current CD recorded in SC22/WG21-N2803 and N2806   Consider these comments and update ISO/IEC CD 14882 accordingly   CWG    ACCEPTED  
DE 1 1 through 16   DE-1 Consider addressing a significant part of the unresolved core language issues presented in WG21 document N2791 "C++ Standard Core Language Active Issues, Revision 59", available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html .     CWG    ACCEPTED  
CH 2 all   The issues on the issues lists shall be addressed before the standard becomes final.     CWG    ACCEPTED  
US 3 all   Latin abbreviations are presented incorrectly.   Italicize all Latin abbreviations, append commas after each occurrence of i.e. and e.g., and remove extraneous space after each such abbreviation.   editor    ACCEPTED with MODIFICATIONS

The "Chicago Manual of Style" says that i.e. and e.g. are never italicized and always followed by a comma, so that's how they now appear.  
FR 3 1 [intro.scope] ¶ 2   C++ is split at the end of line.     editor     
US 4 1.1 ¶ 2   There is a bad line break in "C++".     editor     
UK 1
[214]
1.1 ¶ 2   List of additional facilities over C has been extended with this standard, so should be mentioned in the introductory material.   Add the following to the list in 1.1p2: atomic operations concurrency alignment control user-defined literals attributes   editor    REJECTED

This list is highlights, not all differences. Okay as is.  
FR 4 1.2 [intro.refs] ¶ 1   Is the lack of reference to ISO/CEI 9899/AC3:2007 voluntary?     editor     
UK 2
[215]
1.2 ¶ 1   We recommend taking the latest update to each listed standard, yet the C standard is quite deliberately held back to the 1990 version without comment.+   ... not sure ...   editor    REJECTED

1.2 (Normative references) cites 9899:1999, 9899:1999/Corl.1:2001, and 9899:1999/Cor.2:2004, which collectively constitute C99.  
UK 3
[217]
1.3.1   The definition of an argument does not seem to cover many assumed use cases, and we believe that is not intentional.   Revise the definition of argument to answer question such as: Are lambda-captures arguments? Are type names in a throw-spec arguments? 'Argument' to casts, typeid, alignof, alignas, decltype and sizeof? why in x[arg] : arg is not an agrument, but the value forwarded to operator[]() is ? Does not apply to operators as call-points not bounded by parenthises ? Similar for copy initialization and conversion? what are Deduced template 'arguments'? what are 'default arguments'? can attributes have arguments? what about concepts, requires clauses and concept_map instantiations? What about user-defined literals where parens are not used?   CWG  783   
UK 4
[216]
1.3.3   This definition is essentially worthless, as it says nothing about what distinguished a diagnostic message from other output messages provided by the implementation   ... add something about the diagnostic message being a message issues by the implementation when translating a program that violates the rules of the standard. ...   CWG    REJECTED

Characterizing the output of a translator is essentially a quality-of-implementation issue and beyond the scope of the Standard.  
FR 5 1.3.4 [defns. dynamic.type]   "The dynamic type of an rvalue expression is its static type." Is this true with rvalue references?     CWG  690   
US 5 1.3.5   The wording is unclear as to whether it is the input or the implementation "that is not a well-formed program".   Reword to clarify that it is the input that is here considered not well-formed.   editor     
FR 6 1.3.6 [defns. impl.defined]   There is a page break between the title and the paragraph.     editor     
FR 7 1.3.13 [defns. undefined]   [intro.execution]/5 explicitly allows non causal undefined behaviour,   Adding it to the note outlying possible undefined behaviours.   editor    REJECTED

This is covered by the first alternative in the note, "ignoring the situation completely with unpredictable results".  
US 6 1.3.14   Unspecified behavior does not clearly state whether or not undefined behavior is permitted. (The standard says that "usually, the range of possible behaviors is delineated", but what happens if the range is not delineated? Is a crash, or worse, allowed?)   Clearly state whether or not Unspecified behavior includes undefined behavior.   CWG    REJECTED

The cited text is in a note and thus non-normative. The acceptable range for unspecified behavior is a quality-of-implementation issue.  
FR 8 1.4 [intro. compliance] ¶ 8   The paragraph as its stands seems to require that violations of the ODR (which make a program ill-formed) are required to be diagnosed if the program also uses an extension which defines some cases of ODR.     editor    REJECTED

Yes, that seems to be the intention. That's the mechanism for extensions: issue a diagnostic and then do the extension.  
UK 5
[1]
1.5   Missing checklist of implementation defined behaviour (see ISO/IEC TR 10176, 4.1.1p6)   Provide a new annex with the missing checklist   editor     
UK 6
[2]
1.5   Missing annex describing potential incompatibility to previous edition of the standard (see ISO/IEC TR 10176, 4.1.1p9)   Provide a new annex with the missing documentation. See n2733(08-0243) for a starting point   CWG  784   
US 7 1.5 ¶ 2   There is no mention of Clause 17.   Include Clause 17 among the list of Clauses that specify the Standard Library.   editor    ACCEPTED  
US 8 1.5 ¶ 2   The paragraph omits to mention concepts and concept maps among its list of entities defined in the Standard Library.   Mention concepts and concept maps among the list of entities.   editor    ACCEPTED  
US 9 1.6 ¶ 1   The syntax description does not account for lines that wrap.     editor    ACCEPTED  
US 10 1.7 ¶ 3   The term thread is used before defined.   Reference 1.10 [intro.multithread].   editor    ACCEPTED  
US 11 1.7 ¶ ¶ 3 last sent.   The phrase “threads of execution” should be accompanied by a reference to [intro.multithread].   Insert the recommended reference.   editor    ACCEPTED  
US 12 1.7 ¶ ¶ 3 first sent.   A memory location is not an object as the sentence claims.   Clarify that a memory location “holds” an object rather than that it “is” an object.   CWG    ACCEPTED with MODIFICATIONS

This is the definition of the term “memory location” for reference in the following text. The current wording is appropriate for that usage; the formatting will be changed to indicate that the term is being defined.

See paper N2841 
US 13 1.7 ¶ ¶ 3 last sent.   It is unclear what is meant by memory locations that are "separate": are they distinct? non-overlapping? how much "separation" is needed?   Provide either a better definition of “separate” or reword (this and subsequent paragraphs) to avoid this term.   CWG    REJECTED

The current text is clear enough: “separate” in the sense of “distinct” is common usage elsewhere in the Standard.  
US 14 1.7 ¶ ¶ 4   The phrase "no matter what the sizes of the intervening bit-fields happen to be" contradicts the claim of separation "by a zero-length bit-field declaration".   Delete the “no matter…” phrase, or resolve the contradiction in a different way.   CWG    ACCEPTED

See paper N2841 
US 15 1.7 ¶ ¶ 5   A struct does not “contain” memory locations.   Reword so that a struct is “held in” one or more memory locations.   CWG    REJECTED

The phrasing is consistent with the definition of “memory location” given in paragraph 3.  
US 16 1.9   The discussion of observable behavior in 1.9 is not consistent with the addition of threads to the language. Volatile reads and writes and other observable actions no longer occur in a single "sequence”.   Remove/replace various occurrences of "sequence" in 1.9.   CWG  785   
UK 8
[222]
1.9 ¶ 5   With parallel execution there is no longer the idea of a single execution sequence for a program. Instead, a program may be considered a set of exectution sequences.   Update first sentance as: A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible SETS OF execution sequences of the corresponding instance of the abstract machine CONFORMING TO THE MEMORY MODEL (1.10) with the same program and the same input.   CWG  785   
UK 7
[218]
1.9 ¶ 6   Does the term 'sequence' imply all reads/writes through volatile memory much be serialized, and cannot occur in parallel on truly parallel hardware? Allow for multiple concurrent sequences where each sequence is constrained by this observable behaviour rule, and multiple sequences are constrained by the memory model and happens-before relationships defined in 1.10   Replace 'sequence' with 'sequences'.   CWG  785   
FR 9 1.9 [intro.execution] ¶ 16   This example use int *v while the other examples seems to use notation like int* v.     editor    ACCEPTED  
US 17 1.10 ¶ 1   This definition of “thread” is poor, and assumes the user already knows what multi-threaded means (probably true!). In particular, it does not deal adequately with the concept that all threads share the same address space.   Replace first sentence of para 1 as follows:
Under a hosted implementation, a C++ program can have more than one thread of execution (a.k.a. thread) running concurrently. Each thread is a single flow of control within a program. Anything whose address may be determined by a thread, including but not limited to static objects, storage obtained via new or by any dynamic allocator, directly addressable storage obtained through implementation-defined functions, and automatic variables, are accessible to all threads in the same program.
 
CWG  786   
UK 9
[133]
2.1 ¶ 2, 4   Undefined behaviour is a drastic way to silently ignore minor issues. The cases in this paragraph could be easily defined. In this case opt for conditionally supported behaviour, which mandates a diagnostic if the compiler is not prepared to handle the syntax consistently.   Replace undefined behaviour with conditionally supported behavior. Conditional behaviour may be implementation defined, although suggest there is a reasonable default in each case. For creating a universal-character name, splice text to create a universal-character. In the case of a file ending without a newline, treat as if the newline was implictly added, with an empty line to follow if the last character was a back-slash.   CWG  787   
UK 10
[134]
2.1 ¶ 3   Implementation defined seems unnecessarily burdensome for negligible gain. I am yet to see code that depended on whether non-empty sequences of whitespace were concatenated. Better left unspecified.   How the compiler treats non-empty sequences of whitespace should be left unspecified, rather than implementation-defined.   CWG    ACCEPTED

See paper N2841 
FR 10 2.1 [lex.phases]/5 and 2.2 [lex.charset]/3   [defns.multibyte] "the extended character set."

[lex.charset]/3 cited below implies that there is an extended character set per locale.

[lex.phases]/5 "Each [...] universal-character-name [...] is converted to the corresponding member of the execution character set"

[lex.charset]/3 "The values of the members of the execution character sets are implementation defined, and any additional members are locale-specific."

Together they seem to imply that what is locale-specific is if a value is valid or not for the current locale, not the representation of a given universal character.

This is not the behaviour of at least some compilers I've access to which are allowing different codes for the same abstract character in different locale. During phase 5, they are using an implementation defined char set.  
  CWG  788   
UK 11
[135]
2.3   Trigraphs are a complicated solution to an old problem, that cause more problems than they solve in the modern environment. Unexpected trigraphs in string literals and occasionally in comments can be very confusing for the non-expert.   Deprecate the whole of 2.3 and move it to appendix D.   CWG  789   
UK 12
[137]
2.4, 2.8 ¶ 2   This undefined behaviour in token concatenation is worrying and we believe hard to justify. An implementation should either support this in a defined way, or issue a diagnosic. Documenting existing practice should not break existing implementations, although unconditionally requiring a diagnostic would lead to more portable programs.   Replace undefined behaviour with conditionally supported behaviour with implementation defined semantics.   CWG  787   
US 18 2.4 ¶ ¶ 2   The paragraph begins with an empty line.   Delete the empty line.   editor    ACCEPTED  
FR 11 2.4 [lex.pptokens] ¶ 3   There are spurious empty lines.     editor    ACCEPTED  
FR 12 2.5 [lex.digraph] and 2.11 [lex.key]/2   The alternative representations are reserved as such even in attribute. Is that what is wanted?     CWG    REJECTED

The current specification is as intended.  
FI 2 2.5 ¶ Table 2   Add eq, for spelling out == in order to distinguish it from the assignment operator.   See eq-keyword.doc, eq-keyword.ppt   CWG    REJECTED

Adding a new keyword would break existing code that uses eq as an identifier.  
UK 13
[138]
2.9 ¶ 2   This text is confusing in isolation, as it implies pp-numbers do not have a value in translation phase 4 when evaluating #if preprocessor expressions.   Add a note with a cross-refernce to 16.1 that a pp-number may briefly acquire a value during translation phase 4 while evaluating #if expressions.   CWG  832   
UK 14
[395]
2.11 ¶ table 3   The table is nearly sorted, but not quite. It was sorted in previous versions of the standard.   Sort the table.   editor    ACCEPTED  
JP 1 2.11 ¶ Table 3   Keywords in the table are listed disorderly. Also, a part of a frame of the table is not drawn.   Sort it in alphabetical order. Complete the table frame.   editor    ACCEPTED  
US 19 2.13.1 ¶ Table 5, rows “l or L” and “ll or LL”   The final entry in the last column (“unsigned long int”) is incorrect.   Replace the incorrect entries by “unsigned long long int”.   editor    ACCEPTED  
US 20 2.13.1, 2.13.3   Long strings of digits in literals are a continuing problem in the production and maintenance of programs.   Adopt the 1983 technology of Ada and use underscores to separate digits. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2281.html   CWG    REJECTED

This was already considered and rejected.  
UK 15
[139]
2.13.2 ¶ 2   Inconsistency between definition of a multicharacter literal and a wide character literal containing multiple c-chars.   Define the term multicharacter wide literal for a wchar_t literal containing multiple elements, and specify its type is integer (or wider)   CWG    REJECTED

The current specification is well-defined, and there was no consensus for changing it.  
UK 16
[140]
2.13.2 ¶ 3   Not immediately clear why the question mark needs escaping. A note would help.   Add a note explaining that the ? character may need escaping to avoid accidentally creating a trigraph.   editor    ACCEPTED  
JP 2 2.13.4 ¶ 1st para, 2nd line   Typo, R"..." should be R"[...]"   Correct typo.   editor    ACCEPTED  
JP 3 2.13.4 ¶ 2nd paragraph   We think that the explanation of d-char-sequence is not enough.   Add the following.
  1. Add the following to the explanation of d-char-sequence, more easily to understand.

    ...prefix is a raw string literal. The d-char-sequence is used as delimiter. The terminating d-char-sequence of ...

  2. Add the following note that there are square brackets in r-char-sequence.

    [Note:
      char foo[] =
      R"delimiter[[a-z] specifies a range
      which matches any lowercase letter
      from "a" to "z".]delimiter";
    
    the expression statement behaves exactly the same as
      char foo[] = "[a-z] specifies a range
      which matches any lowercase letter
      from \"a\" to \"z\".";
    
    end note]
 
editor    ACCEPTED  
JP 4 2.13.4 ¶ 3rd para, 1st line of example   Typo. Lack of a necessary backslash in the first line of the example as follows:
  const char *p = R"[a
  b
  c]";
        
should be
  const char *p = R"[a\
  b
  c]";
 
Correct typo.   editor    ACCEPTED  
US 21 2.13.4 ¶ ¶ 3   The paragraph, marked as a Note, contains an embedded example not marked as such.   Denote the code (and perhaps also its commentary) as an Example.   editor    REJECTED

Marking things as Note or Example distinguishes them from normative text. Examples in Notes do not need to be marked.  
US 22 2.13.4 ¶ ¶ 3   The code does not have the effect predicted by its accompanying narrative.   Append a backslash to the first line of the code.   editor    ACCEPTED  
JP 5 2.13.4 ¶ 11th para, Table 7   It is not explicit how to combine raw-string and non-raw-string.   Add rules containing raw-string in the table 7.   CWG  790   
FR 13 2.13.4 [lex.string] ¶ 3   Shouldn't the assert be
  assert(std::strcmp(p, "a\nb\nc") == 0);
 
  editor    ACCEPTED with MODIFICATIONS

The assert is correct but the preceding raw string is wrong. See JP 4.  
UK 17
[141]
2.13.4 ¶ 10   It would be preferred for attempts to modify string literals to be diagnosable errors. This is not possible due to the deprecated implicit conversion to pointer to null-terminated character sequence of non-const characters. If this deprecated conversion were remove (see other comments) then string literals are always accessed through const types, and the compiler can enforce the no modification rule. The only exception would be using const_cast to cast away constness, but this is already covered under the const_cast rules so needs no further detail here.   (asssuming deprecated conversion to non-const array is removed or can be turned off) Strike the sentence on undefined behaviour.   CWG    REJECTED

The specification covers all attempts to modify the contents of a string literal, including via a pointer to the string when it is not apparent that a string literal is the target. This is consistent with the general treatment of const objects.  
UK 18
[142]
2.13.4   The addition of static_assert (7p4) to the language raises the need to concatenate string representations of integral constant expressions (typically from a sizeof or alignof expression) with narrow string literals to provide an informative error message. There is no need to support arbitrary constant expressions and especially not floating point values or formatting flags. Likewise, the need is purely to support static_assert so only narrow string literal support is required, although generalizing to other literal types would be useful.   Define a syntax to support string-ization of integral constant expressions in a form eligible for string literal concatenation, 2.13.4p6. Suggested syntax: I" integral-constant-expression ". There is no raw variant, although it could combine with type specifier in the same way that the R prefix does, supporting u8I, uI, UI and LI.   CWG    REJECTED

There was no consensus to adopt this new functionality at this point in the standardization process.  
UK 19
[143]
2.13.4   The grammar for string literal is becoming unwieldy and could easily be refactored into the type optional specifier and the string contents.   Refactor string-literal grammar as: (note - current Drupal view loses formatting which is vital to clearly read the grammar) string-literal: string-literal-type-specifierOPT string-literal-body string-literal-type-specifier: one of u8 u U L string-literal-body: " s-char-sequenceOPT " R raw-string   CWG    REJECTED

The Standard is correct as written. The suggestion would change the shift/reduce conflicts in the grammar and is thus not editorial.  
FR 14 3 [basic] ¶ 7   "In general it is necessary to determine whether a name denotes one of these entities before parsing the program that contains it."   Would prefer

"... before continuing to parse the program that contains it."

or even

"... to complete the parsing of the program that contains it."

as some names denotes entities declared after the first occurrence.  
editor    ACCEPTED  
FR 15 3 [basic] ¶ 8   /operator-function-id/, /conversion-function-id/, /template-id/ are followed by a space and then a "s" while usually such production names aren't followed by a space when put in plural (see /identifier/).     editor    ACCEPTED  
UK 20
[209]
3   Chapter 3 ("Basic concepts") provides common definitions used in the rest of the document. Now that we have concepts as a primary feature, the title of this chapter can be confusing as it does not refer to the language feature but to definitions used in the document.   Change the title to "Basic definitions".   editor     
UK 21
[359]
3 ¶ 2   Concepts is now the name of a specific feature of the language, the term now risks confusion and ambiguity when used in the more general sense.   Rename the chapter Basic ???. THe note in p2 specifically needs similar rewording   editor     
UK 22
[362]
3 ¶ 6   References are frequently considered variables, but this definition only applies to objects.   Add "or reference" after both uses of "object"   CWG  633   
UK 23
[277]
3.1 ¶ 2   alias-declarations are not definitions and should be added to the list   Add alias-declaration after typedef declaration.   CWG  758   
UK 24
[360]
3.1 ¶ 2   The current words suggest the declaration of a static integral constant data member of a class cannot be a definition. Trying to fix this wording in-place will be verbose and risk raising more confusion than it solves, so suggest a footnote to call out the special case   Add a footnote attached to the static data membmer rule: *static data member delcarations of intergral type may also be definitions if a constant integral expression is provided for an initializer.   CWG    REJECTED

The in-class declaration of such a static data member is, in fact, not a definition; an out-of-class definition must be provided if the member is "used" as described in 3.2.  
UK 25
[361]
3.1 ¶ 3   Example is misleading as implicitly defined default constructor uses default initialization, not value initialization, for non-static data members. In the case of std::String this makes no difference, but it makes a big difference for fundamental types and pointers.   Remove the : s() from the illustrated default constructor: struct C { std::string s; C() { } C(const C& x): s(x.s) { } C& operator=(const C& x) { s = x.s; return *this; } ~C() { } };   CWG    ACCEPTED

See paper N2841 
UK 26
[363]
3.2 ¶ 1   THe one definition rule should cover references, and unless the term 'variable' is extended to cover references the list in this paragraph is incomplete.   Either include references in the definition of 'variable' (see earlier comment) or add reference to the list in this paragraph.   CWG  570   
UK 27
[364]
3.2 ¶ 4   A class type must be complete when catching exceptions, even by reference or pointer. See 15.3.   Add "when used in an exception-handler (15.3)" to the list.   CWG    ACCEPTED

See paper N2841 
FR 16 3.3 [Declarative regions and scopes.]   The scope of function parameters is defined, but what is the scope of template parameters?     CWG  481   
UK 28
[365]
3.3.1 ¶ 3   Class templates are not classes, so we should include this case.   ammend "class" to "class or class template"   CWG    ACCEPTED

See paper N2841 
UK 29
[366]
3.3.10 ¶ 3   operators and conversion functions do not have names, yet are susceptible to 'name hiding' within a class - indeed we rely on this for the implicitly declared copy-assignment operator.   Add the additional phrase "The declaration of an operator or conversion function in a derived class (Clause 10) hides the declaration of an operator or conversion function of a base class of the same operator or type;"   CWG    REJECTED

These entities do, in fact, have names, as described in 3¶4.  
FR 17 3.5 [Program and linkage]   This section does not specify whether concept names have linkage. Do they or not? If concept names do not have linkage, then a note is appropriate, and that would be a bit surprising and curious. What is the rationale?     CWG  791   
UK 30
[367]
3.5 ¶ 2   This paragraph implies concepts have no linkage (do they need it?) and that the entities behind names without linkage cannot be used in other scopes. This maybe a bigger problem for concept maps?   Add a note to clarify that concepts don't need linkage.   CWG  791   
UK 31
[368]
3.5 ¶ 4   What is the linkage of names declared inside a namespace, in turn declared inside an anonymous namespace? It is not clear why such a namespace has no linkage, and there is no language suggesting its memmbers should lose linkage with it, which we assume is the intended consequence.   Clarify rules for namespaces inside nested namespaces, or remove the restriction.   CWG    ACCEPTED

See paper N2841 
US 23 3.5 ¶ 6   Bad paragraph break.     editor    ACCEPTED  
FR 18 3.5 [basic.link] ¶ 6   The paragraph number is not aligned with the text.     editor    ACCEPTED  
FR 19 3.6 [Start and termination]   This section completely ignores the real world and practical case of dynamically linked or loaded libraries. In current computing environments, they are ubiquitous and they cannot be ignored in practical C++ programs. The Standard should address this aspect.     CWG    REJECTED

The Committee explicitly voted that this issue could not be addressed within the time frame for this revision of the Standard.  
UK 32
[369]
3.6.1 ¶ 3   Do we really want to allow: constexpr int main() { return 0; } as a valid program?   Add constexpr to the list of ill-formed things to annotate main   CWG    ACCEPTED

See paper N2841 
US 24 3.6.1 ¶ 4   std::quick_exit is not referenced.   Reference std::quick_exit as well as std::exit in saying that automatic objects are not destroyed. It should not do so in saying that calling std::quick_exit is undefined from within destructors for static or thread duration objects.   CWG  792   
US 25 3.6.3 ¶ ¶ 2 last sent.   The parenthesized phrase, introduced via “i.e.” is in the nature of an example.   Change “i.e.” to “e.g.”   editor    REJECTED

The parenthesized phrase is in the nature of a clarification, so "i.e." is appropriate.  
JP 6 3.7.4.1 ¶ 4th para, 4th line   Typo.

Lack of a comma right after “(3.7.2)” in the sentence while there are commas after any other recitations like “(3.7.1)”. It is just a unification matter.

[ Note: in particular, a global allocation function is not called to allocate storage for objects with static storage duration (3.7.1), for objects or references with thread storage duration (3.7.2) for objects of type std::type_info (5.2.8), or for the copy of an object thrown by a throw expression (15.1). -end note ]

should be

[ Note: in particular, a global allocation function is not called to allocate storage for objects with static storage duration (3.7.1), for objects or references with thread storage duration (3.7.2), for objects of type std::type_info (5.2.8), or for the copy of an object thrown by a throw expression (15.1). -end note ]  
Correct typo.   editor    ACCEPTED  
DE 3 3.7.4.3   DE-3 It is unclear whether the following code has well-defined behavior; none of the bullets in the second paragraph seem to apply.

int& i = *new int(5);

delete &i;  
Clarify that &i is considered a safely-derived pointer value.   CWG  735   
US 26 3.8 ¶ 1 and 5   Use of object fields during destruction is excessively and erroneously constrained.   See the attached document "Issues with the C++ Standard" under Chapter 3 "Use of objects, especially from other threads, during destruction".   CWG  793   
US 27 3.9 ¶ ¶ 9 first sent.   There is a superfluous/extraneous “and”.   Delete “and” from the phrase “and std::nullptr_t”.   editor    ACCEPTED  
FR 20 3.9 [Types]   The phrase 'effective type' is defined and used in a way that is incompatible with C99. Such a deliberate incompatible choice of terminology is both unfortunate and confusing, given past practice of the committee to maintain greater compatibility with C99. We strongly suggest that the phrase 'effective type' not be used in such an incompatible way.     CWG    REJECTED

The choice of the term was previously discussed and no better term could be found.  
JP 7 3.9.2 ¶ 3rd para, 13th line   over-aligned type was added as new notion. So it is preferable to add the link after that.   Add (3.11) after over-aligned type as the link.

[ Note: pointers to over-aligned types(3.11) have no special representation, but their range of valid values is restricted by the extended alignment requirement. This International Standard specifies only two ways of obtaining such a pointer: taking the address of a valid object with an over-aligned type(3.11), and using one of the runtime pointer alignment functions. An implementation may provide other means of obtaining a valid pointer value for an over-aligned type(3.11).—end note ]  
editor    ACCEPTED  
US 28 3.9.3 ¶ ¶ 5 first sent.   The closing braces of the first two sets are preceded by extraneous space.   Delete the extra spaces.   editor    ACCEPTED  
DE 4 4.2 ¶ p2   DE-4 The deprecated conversion from string literals to pointer to non-const character types should be limited to those conversions and types of string literals that were already present in ISO/IEC 14882:2003, or the deprecated conversions should be removed entirely.   Consider applying the proposed resolution presented in core issue 693 in WG21 document N2714 “C++ Standard Core Language Active Issues, Revision 58“, available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2714.html ; or remove only the conversions to "pointer to char16_t", "pointer to char32_t" in 4.2 paragraph 2 and 15.1 paragraph 3.   CWG  693   
CH 1 4.11 and 5.2.9   With respect to the target type, pointer to members should behave like normal pointers (least surprise principle).   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  794  Section reference corrected from 4.9.  
DE 5 4.11, 5.3.1, 5.5   DE-5 Ref-qualification has not been integrated with pointer-to-members.   Review implicit conversions (4.11), forming pointer-to-members (5.3.1), and dereferencing pointer-to-members (5.5) for type-safety concerns in the presence of ref-qualifiers on the member.   CWG  731   
UK 33
[374]
4.13 ¶ 1   We have: "No two signed integer types shall have the same rank ..." "the rank of char shall equal the rank of signed char" Can we therefore deduce that char may not be signed?   Replace the first sentence with "No two signed integer types shall have the same rank, even if they have the same representation, except that signed char shall have the same rank as char even if char is signed (3.9.1/1)."   CWG    ACCEPTED

See paper N2841 
UK 34
[375]
4.13 ¶ 1   6th bullet, "the rank of char" - first letter should be capitalised for consistency with the other bullets   The rank of char   editor    ACCEPTED  
UK 36
[407]
5.1 ¶ 1   Primary expressions are literals, names, names qualified by the scope resolution operator ::, and lambda expressions. The immediately following grammar flatly contradicts this - this and (e) are also lambda expressions.   Delete this paragraph.   CWG    ACCEPTED

The introductory sentence was deleted, but the paragraph (containing the grammar) remains.

See paper N2841 
UK 37
[224]
5.1 ¶ 11   Member function templates are not member functions, so should also be listed in the 3rd bullet   Add member function templates to the 3rd bullet   CWG    REJECTED

The text is clear enough as it is. There are many places in the Standard where function templates are not explicitly mentioned in a reference to functions.  
UK 38
[230]
5.1 ¶ 3   this might be useful in a few more places than it is permitted, specifically in decltype expressions within a class. Two examples that would be ill-formed at class scope without changes: typedef decltype( *this ) this_type; decltype( [this]{ return this->memfun(); } ) my_lambda;   ... words to follow ...   CWG    REJECTED

There was no consensus for this change.  
JP 8 5.1 ¶ 7th para, Syntax rules   In the current syntax definition, a scope operator(::) cannot be applied to decltype, but it should be. It would be useful in the case to obtain member type(nested-type) from an instance as follows:

vector<int> v;

decltype(v)::value_type i = 0; // int i = 0;  
Add “decltype ( expression ) :: “ to nested-name-specifier syntax like below.

nested-name-specifier:
type-name ::
namespace-name ::
nested-name-specifier identifier ::
nested-name-specifier templateopt simple-template-id ::
nested-name-specifieropt concept-id ::
decltype ( expression ) ::  
CWG  743   
JP 9 5.1.1   It would be preferable that “&&” could be specified in a lambda expression to declare move capture.

Here is an example from N2709.

template<typename F>
std::unique_future<typename std::result_of<F()>::type> spawn_task(F f){
typedef typename std::result_of<F()>::type result_type;

struct local_task {
std::promise<result_type> promise;
F func;
local_task(local_task const& other)=delete;
local_task(F func_):
func(func_)
{}

local_task(local_task&& other):
promise(std::move(other.promise)),
f(std::move(other.f))
{}

void operator() {
try
{
promise.set_value(f());
}
catch(...)
{
promise.set_exception(std::current_exception());
}
}
};

local_task task(std::move(f));

std::unique_future<result_type> res(task.promise.get_future());
std::thread(std::move(task));
return res;
}

This can be rewritten simply as follows if move capture can be used in a lambda expression.

template<typename F>
std::unique_future<typename std::result_of<F()>::type> spawn_task(F f){
typedef typename std::result_of<F()>::type result_type;

std::promise<result_type> promise;
std::unique_future<result_type> res(promise.get_future());
std::thread([&&promise, &&f]() {
try
{
promise.set_value(f());
}
catch(...)
{
promise.set_exception(std::current_exception());
}
});
return res;
}
 
Add move capture in a lambda expression.   CWG    REJECTED

This would be a dangerous feature, allowing “moving” from named variables. It would also contradict the change made by paper N2844, prohibiting the binding of rvalue references to lvalues, which was adopted at the March, 2009 meeting.  
JP 10 5.1.1   In the current syntax definition, a returned type of a function object cannot be obtained by using result_of from an unnamed function object generated by a lambda expression because it doesn’t have result type.

template <class F>
void foo(F f)
{
typedef std::result_of<F()>::type result; // error
}
foo([]{});

If “Callable” or “Predicate” concept is specified, a returned type can be obtained from a function object without result_type. But it is preferable to be able to obtain it with template.  
Add result_type to the syntax of an unnamed function object generated by a lambda expression.   CWG    REJECTED

This is not a defect. The definition of std::result_of now uses decltype and does not require a result_type member typedef, so the desired functionality is already present in the current specification.  
US 29 5.1.1   The standard does not state whether or not direct recursion of lambdas is possible.     CWG  762   
US 30 5.1.1   The standard does not clarify the meaning of this in lambdas. Does it mean this lambda, or this class within which the lambda is nested?     CWG  762   
US 31 5.1.1   The current wording does not specify how context capturing and name resolution take place when the inner lambda refers to the outer lambda's locals variables and parameters.     CWG  752   
UK 45
[444]
5.1.1 ¶ para 2   Lambda is a language feature with an apparent dependency on <functional>. This increases dependency of language on library, and is inconsistent with the definition of freestanding in 17.6.2.4.   Change the text "a closure object behaves as a function object" to "a closure object is a built-in object which behaves as a function object"; and after "context.", insert " A closure object may be used without any need for <functional>." This makes clear what may already be implied, namely that lambdas can be used in freestanding implementations and don't increase dependency of language on library. (Marked as technical comment anyway because this clarity is technically important).   CWG  795   
US 32 5.1.1 ¶ 3   The final italic "this" in the paragraph should be a teletype "this".     editor    ACCEPTED  
UK 39
[408]
5.1.1 ¶ 11   This paragraph lists all the special member functions for the class representing a lambda. But it omits the destructor, which is awkward.   Add "F has an implicitly-declared destructor".   CWG  759   
UK 40
[409]
5.1.1 ¶ 13   If one or more names in the effective capture set are preceded by &, the effect of invoking a closure object or a copy after the innermost block scope of the context of the lambda expression has been exited is undefined. That is too restrictive. The behaviour should be undefined iff the lifetime of any of the variables referenced has ended. This should be safe and legal; currently it has undefined behaviour: int i; reference_closure<void ()> f; if (blah) { f = [&i]() { }; } if (f) f();   If one or more names in the effective capture set are preceded by &, the effect of invoking a closure object or a copy after the lifetime of any of the variables referenced has ended is undefined.   CWG  796  Paragraph reference corrected from 12.  
UK 41
[225]
5.1.1 ¶ 12   For argument dependant lookup (3.4.2) the associated namespaces for a class include its bases, and associated namespaces of its bases. Requiring the result of a lambda expression *to dervide from* std::reference_closure means that ADL will look in namespace std when the lambda capture is entirely by reference, which might have surprising results. Also, relying on the idea of implicitly slicing objects is uncomfortable.   Replace inheritance with implicit conversion.   CWG    ACCEPTED with MODIFICATIONS

std::reference_closure was removed at the March, 2009 meeting, rendering the issue moot.

See paper N2845 
UK 42
[226]
5.1.1   A lambda with an empty capture list has identical semantics to a regular function type. By requiring this mapping we get an efficient lambda type with a known API that is also compatible with existing operating system and C library functions.   Add a new paragraph: "A lambda expression with an empty capture set shall be convertible to pointer to function type R(P), where R is the return type and P is the parameter-type-list of the lambda expression." Additionally it might be good to (a) allow conversion to function reference (b) allow extern "C" function pointer types   CWG  797   
UK 43
[231]
5.1.1 ¶ 12   The note spells out the intent that objects from lambda-expressions with an effective capture list of references should be implemented as a pair of pointers. However, nothing in the rest of 5.1.1 lifts the requirement of to declare a reference member for each captured name, and a non-normative note is not enough to relax that.   ... provvide exceptions in the right places ...   CWG    ACCEPTED with MODIFICATIONS

std::reference_closure was removed at the March, 2009 meeting, rendering the issue moot.

See paper N2845 
UK 44
[252]
5.1.1 ¶ 12   There is a strong similarity between a [&]{} lambda capturing a stack frame, and a [this]{} lambda binding a member function to a class instance. The reference_closure requirement should be extended to the second case, although we need some syntax to create such an object that is distinct from the existing pointer-to-member syntax. This would be a cleaner alternative to the new std::mem_fn library component.   Extend reference_closure requirement to cover [this] lambdas. Consider a simple syntax for creating such bound expressions.   CWG    REJECTED

There was no consensus to make the suggested change at this point in the standardization process. Furthermore, std::reference_closure was removed at the March, 2009 meeting, rendering the issue moot.  
UK 46
[449]
5.1.1 ¶ para 12   The requirement that a lambda meeting appropriate conditions be an object derived from reference_closure makes lambda the language feature dependent on <functional>, which increases dependency of the language on the library and bloats the definition of freestanding C++.   Replace text "is publicly derived from" with "shall be implemented in a manner indistinguishable from". This places an ABI constraint on reference closures such that compiler and library implementer have to do compatible things. But it cuts the dependency of lambda syntax on <functional>.   CWG    ACCEPTED with MODIFICATIONS

std::reference_closure was removed at the March, 2009 meeting, rendering the issue moot.

See paper N2845 
DE 6 5.1.1, 20.7.18   DE-6 Some uses of lambda expressions refer to specializations of the unconstrained class template std::reference_closure (5.1.1). If the lambda expression appears in a constrained context and the return type or a parameter type for the lambda depend on a template parameter (see 14.10), such a use is ill-formed.   In 20.7.18, for the class template std::reference_closure, require Returnable for R and VariableType for each of the ArgTypes.   CWG    ACCEPTED with MODIFICATIONS

std::reference_closure was removed at the March, 2009 meeting, rendering the issue moot.

See paper N2845 
DE 7 5.1.1 ¶ p10   DE-7 The note at the end of paragraph 10 appears to be garbled.   Remove "or references" in the note.   editor    REJECTED

Looks okay: "captured" applies to "variables or references".  
DE 8 5.1.1 ¶ p10   DE-8 The construction of the function call operator signature is missing specifications for the ref-qualifier and the attribute-specifier.   Add bullets that say that the ref-qualifier and the attribute-specifier are absent.   CWG    ACCEPTED

See paper N2841 
US 33 5.1.1 ¶ 11   There is no definition of “move constructor” or “move operation”   Since this is the first place the terms are used, a definition should either be added here, or a cross reference to one.   CWG  680   
DE 9 5.1.1   DE-9 There is not a single example of a lambda-expression in the standard. See also core issue 720 in WG21 document N2791 "C++ Standard Core Language Active Issues, Revision 59", available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2791.html .   Add a few well-chosen examples.   CWG  720   
UK 52
[232]
5.2 ¶ 3   This paragraph seens out of place, assignment expressions are covered in 5.17   Move p3 to subsection 5.17   editor    ACCEPTED with MODIFICATIONS

Removed the paragraph; grammar changes make it moot.  
UK 53
[233]
5.2.1   The definition in p1 makes no allowance for overloaded operator[] that treats the expression as a simple function call, and does not support the interchangability of arguments. Howver p2 relies on this definition when describing the use of brace-init-lists inside [].   Insert a new p2 describing the changed semantics for overloaded operator[]. This should be a note to avoid introducing normative text that could potentially conflict with the later definiton of these semantics.   CWG  798   
UK 59
[410]
5.2.2 ¶ 7   When there is no parameter for a given argument, the argument is passed in such a way that the receiving function can obtain the value of the argument by invoking va_arg. That shouldn't apply to parameter packs. template <class ... Types> void f(Types ... pack); f(1, 2, 3);   Clarify that this sentence only applies where the ellipsis is used.   CWG    ACCEPTED

See paper N2841 
UK 60
[411]
5.2.5 ¶ 3   In the remainder of 5.2.5, cq represents either const or the absence of const vq represents either volatile or the absence of volatile.   Add "and" before vq   editor    ACCEPTED  
UK 61
[234]
5.2.5 ¶ p1   Together with footnote 60 there may be confusion that the postfix expression is always evaluated - even when part of an unevaluated operand. We believe the standard does not require this, and a comment in the existing note would be a useful clarification.   Clarify in footnote 60 that this will not happen if the whole expression is an unevaluated operand.   editor    ACCEPTED  
UK 62
[235]
5.2.5 ¶ 4   In the final bullet, what does 'not an lvalue' mean? Does it imply rvalue, or are there other possible meanings? Should clauses that trigger on rvalues pick up on this?   Replace 'not an lvalue' with 'is an rvalue'.   CWG    ACCEPTED

See paper N2841 
DE 10 5.2.5   DE-10 If E1.E2 is referring to a non-static member function, the potential ref-qualification on E2 should be taken into account.   Adjust the presentation of the types involved as appropriate.   CWG  731   
UK 63
[412]
5.2.6 ¶ 2   Paragraph 2 is missing its number.   Add one.   editor    ACCEPTED  
UK 64
[413]
5.2.7 ¶ 3   A new name R is introduced for use in paragraphs 3 and 4. But R is the same as T.   Replace R with T and replace "the required result type (which, for convenience, will be called R in this description)" with "T".   editor    ACCEPTED  
UK 65
[414]
5.2.7 ¶ 8   In the first two bullets we have "the result is a pointer (an lvalue referring) to". But para 2 makes clear that a dynamic_cast of an rvalue references produces a rvalue. (Can an lvalue refer to anything anyway?)   Replace "an lvalue referring to" with "reference", twice.   CWG    ACCEPTED with MODIFICATIONS

See paper N2841 
UK 66
[415]
5.2.8 ¶ 1   typeid may return "an implementation-defined class derived from std :: type_info". The derivation must be public.   an implementation-defined class publicly derived from std :: type_info   CWG    ACCEPTED

See paper N2841 
UK 67
[416]
5.2.9 ¶ 1, 2, 3   Paragraph 1 specifies when the result of static_cast is an lvalue; repeating it is unnecessary.   In para 2, delete "It is an lvalue if the type cast to is an lvalue reference; otherwise, it is an rvalue." and "The result is an rvalue.". In para 3, delete "The result is an lvalue if T is an lvalue reference type (8.3.2), and an rvalue otherwise."   CWG    ACCEPTED

The sentence in question is 20.1.1/5.

See paper N2841 
UK 54
[417]
5.2.10 ¶ 3, 6   Para 3: "The mapping performed by reinterpret_cast is implementation-defined.". Para 6: "... the result of such a pointer conversion is unspecified." Which is it?   In para 6, replace unspecified with implementation-defined. Alternatively, delete paragraph 3, since individual cases are labelled appropriately.   CWG    ACCEPTED

See paper N2841 
UK 55
[236]
5.2.10 ¶ 2   dynamic_cast and reinterpret_cast crossreference 5.2.11 without creating an extra note. The second half of the note is unrelated to the crossrefernce, and would serve as well in normative text.   Strike the note about definition of casting away constness, preserve the cross-reference. The second sentance on reintrepret_cast to its own type should move out of the note into the normative text.   CWG  799  The repetition of the reference to 5.2.11 was handled as a quasi-editorial change. An issue will be opened for the question about casting to the same type as the operand.

See paper N2841 
UK 56
[237]
5.2.10 ¶ 5   The notion of safely derived pointers means this conversion may not be as safe in the revised standard as the original. It would be good to call attention to the changed semantics with a note.   Add: [Note: the result of such a conversion will not be a safely-derived pointer value (3.7.4.3) -- end note]   CWG    ACCEPTED with MODIFICATIONS

See paper N2841 
UK 57
[238]
5.2.10 ¶ 8   Conditionally supported behaviour gives a wide range or permission, so clarify relationship between safely-derived object pointers and function pointers in a note.   Add: [Note: In such cases, the implementation shall also define whether a safely-derived object pointer cast to a function pointer can be safely cast back -- end note]   CWG  800   
UK 58
[418]
5.2.11 ¶ 9   Casting from an lvalue of type T1 to an lvalue of type T2 using a reference cast casts away constness if a cast from an rvalue of type “pointer to T1” to the type “pointer to T2” casts away constness. That doesn't cover rvalue references.   Replace lvalue with "lvalue or rvalue" twice.   CWG  801   
US 34 5.3 ¶ 1   The list of unary operator should be in teletype font.     editor    ACCEPTED  
UK 68
[419]
5.3.1 ¶ 2-9   All the unary operands other than * return rvalues - but this is not stated.   Add a paragraph 1a "The following unary operators all produce results that are rvalues."   CWG    ACCEPTED

See paper N2841 
UK 69
[240]
5.3.1 ¶ 2   If we cannot bind references/take address of functions in concept_maps, does that mean we cannot use generic bind in constrained templates? Launch threads with expressions found via concept map lookup? Hit problems creating std::function objects? Does the problem only occur if we use qualified lookup to explicitly name a concept map? Does it only kick in if we rely on the implicit function implementation provided by a concept_map, so some types will work and others won't for the same algorithm?!   ... unknown ...   CWG  802   
UK 70
[420]
5.3.3 ¶ 1   The sizeof operator shall not be applied to ... an enumeration type before all its enumerators have been declared We should allow enum E : int; sizeof(E).   Change "an enumeration type" to "an enumeration type whose underlying type is not fixed".   CWG  803   
UK 71
[254]
5.3.4 ¶ 2   The type of an allocated object wih the type specifier auto is determined by the rules of copy initialization, but the initialization applied will be direct initialization. This would affect classes which declare their copy constructor explicit, for instance. For consistency, use the same form of initiailization for the deduction as the new expression.   Replace T x = e; with T x(e);   CWG  804   
UK 72
[257]
5.3.4 ¶ 7   The library headers have been carefully structured to limit the dependencies between core language and specific headers. The exception thrown should be catchable by a handler for a type lised in <exception> header in cluase 18. This might be accomplished by moving length_error into the <exception> header, but its dependency on logic_error with its std::string constructors suggest this is not a good idea. Prefer to pick an existing exception instead.   Throw std::bad_alloc instead of std::length_error.   CWG  805   
UK 73
[258]
5.3.4 ¶ 6   A class type with conversion operator can only be used if the conversion type is constexpr and the class is a literal type. Adding the single word 'literal' before class type will clarify this.   Add 'literal' before 'class type'   CWG    REJECTED

This is not a defect. The leftmost subscript in the noptr-new-declarator (the expression, as opposed to the constant-expression) need not be constant.  
UK 74
[259]
5.3.4 ¶ 8   operators, like constructors and destructors, do not have names. However, in certain circumstances they can be treated as if they had a name, but usually the stanadard is very clear not to actually describe their name as a distinct property.   Change "the allocation function’s name is operator new" to "the allocation function is named operator new" and similarly for operator delete.   CWG    REJECTED

The premise is incorrect: according to 3 [basic] paragraph 4, operators do indeed have names.  
UK 35
[260]
5.3.4 ¶ 9   Missing period in middle of paragraph between "in the scope of T" and "If this lookup fails"   Add a period between "in the scope of T" and "If this lookup fails"   editor    ACCEPTED  
UK 75
[262]
5.3.5 ¶ 8   A paragraph strarting with [Note... is easily skipped when reading, missing the normative text at the end.   Swap order of the note and normative text.   editor    ACCEPTED  
FR 21 5.3.6 [Alignof   Should not the type of alignof-expression be of type std::max_align_t?     CWG    REJECTED

std::max_align_t is not guaranteed to be integral, only a POD. std::size_t is the correct choice.  
US 35 5.8 ¶ 2 and 3   There is curious spacing in the expressions "E1 <<E2" and "E1 >>E2". This is a formatting change since previous versions of the Standard.     editor    ACCEPTED  
UK 47
[242]
5.14 / 5.15 ¶ 2   Why are the descriptions of order of evaluation of expressions and side effects different between && and || operators. The interaction with the memory model should be identical, so identical words should be used to avoid accidential inconsistencies in interpretation.   Pick one form of wording as 'the best' and apply it in both places.   CWG    ACCEPTED

See paper N2841 
UK 48
[249]
5.18 ¶ 1   The defining feature of the comma operator is the guaranteed sequencing of two expressions. This guarantee is lost when presented with an overloaded operator, and this change is subtle enough to call attention to it.   Add: [Note: There are no guarantees on the order of value computation for an overloaded comma operator -- end note]   editor    ACCEPTED  
UK 49
[376]
5.19 ¶ 2   Is an implementation permitted to reject this? constexpr int f() { return f(); } int a[f()]; AFAICT it is well-formed; f() seems to satisfy all the rules to make it a constant expression. I would hate compilation to become a potentially non-terminating experience.   Add an escape clause to allow the implementation to reject excessively deep nesting of constexpr function evaluations. (This can possibly be a note, since it is arguable that this point is handled by the general rule on resource limits in 1.4/2. A sufficiently smart compiler could use tail recursion above, meaning that it would never run out of memory given this program though.)   CWG  699   
UK 50
[378]
5.19 ¶ 2   The following should be valid: enum E { foo = 4}; const E c = foo; int a[c]; But currently it is not - c is not an lvalue of effective integral type (4th bullet). (See also 7.1.6.1/2)   Change "effective integral type" to "effective integral or enumeration type" in the 4th bullet, 1st sub-bullet.   CWG  806   
UK 51
[251]
5.19 ¶ 2   typeid expressions can never be constant, whether or not the operand is a polymorphic class type. The result of the expression is a reference, and the typeinfo class that the reference refers to is polymorphic, with a virtual destructor - it can never be a literal type.   Strike the words "whose operand is of a polymorphic class type" on the bullet for typeid expressions.   CWG  807   
UK 76
[131]
6.3   Do we really need two different terms that say the same thing?   Pick either 'block' or 'compound statement' as the preferred term and use it consistently throughout the standard.   CWG    REJECTED

Both terms are in common use, and there was no consensus for removing one of them.  
FR 22 6.4.2 [The switch statement]   The constant-expression in

case constant-expression

should be allowed to be of any constant expression of literal type for which a constexpr comparison operator (operator< and operator==) is in scope. Now that constant expressions of other integral types are evaluated at compile time, the restriction for case-labels is at best artificial.  
  CWG    REJECTED

There was no consensus for making this change at this point in the standardization process.  
UK 77
[132]
6.5 ¶ 5   The terms i/o operation, synchronize operation and atomic operation have very specific meanings within the standard. The paragraph would be much easier to understand with the terms crossreferenced.   Profide a cross-reference for the terms: i/o operation, synchronize operation and atomic operation   editor    ACCEPTED  
JP 11 6.5.4 ¶ 1st para, 5th line   There is no _RangeT type in the equivalent code to “range-base for” statement. It existed in N2049.   Add a typedef for _RangeT in the example as follows:

{
typedef decltype( expression ) _RangeT;
auto && __range = ( expression );
for ( auto __begin = std::Range<_RangeT>:: begin(__range),
__end = std::Range<_RangeT>:: end(__range);
__begin != __end;
++__begin )
{
for-range-declaration = *__begin;
statement
}
}  
CWG    REJECTED

The change was intentional; the term is defined in the descriptive text.  
UK 78
[130]
6.5.4 ¶ 2   Including the header <iterator_concepts> is far too unwieldy to enable an important and (expected to be) frequently used syntax.   Merge <iterator_concepts> into <concepts> and change 6.5.4p2 to refer to <concepts>, or make the Range concept fundamental along with the other support concepts in 14.9.4 and strike any reference to including a header.   LWG  1001   
UK 79
[445]
6.5.4   The definition of for (for-range-declaration : expression) statement is expanded in terms which require a Range concept, and the program is ill-formed if <iterator_concepts> isn't included. For users, iterating through old-fashioned arrays, this is a sledge-hammer to crack a nut and compares poorly with other languages. It's also not possible to implement this without adversely impacting the freestanding definition in 17.6.2.4.   When expression is an array a of length N whose length is known at compile time, expand range-for as 'for (... p=a, p!=a+N, p++) ...' without requiring the Range concept or <iterator_concepts>. Also, when expression is an initializer_list, expand range-for similarly without requiring <iterator_concepts>.   CWG    REJECTED

This idea was already considered and rejected, and there was no consensus for changing it now. This suggestion would remove functionality; with the current definition, a user could provide his/her own Range concept for an array with a user-defined type.  
DE 11 6.9 ¶ p1   DE-11 A sentence in paragraph 1 reads: "Outside of a constrained context, the late-checked block has no effect." This, at face value, specifies that the compound-statement of such a late-checked block is never executed, which appears to be unintended.   State that such a late-checked block has the same meaning as if the late_check keyword were absent.   CWG    ACCEPTED

See paper N2841 
UK 80
[370]
7 ¶ 1   Many of the sections and major subsections open with a sentence summarising the content. I'm not sure this is necessary; this isn't a tutorial. The problem with these summaries is that because they omit much of the detail, they tend to be inaccurate. This may not matter, but I feel the document would be improved by omitting them. There's a prime example here: "Declarations specify how names are to be interpreted." Not true for static_assert, an asm declaration nor an anonymous bit field.   Strike the first sentence.   editor    ACCEPTED with MODIFICATIONS

Tweaked first sentence.  
UK 81
[371]
7 ¶ 4   String literal concatenation happens in phase 6, before parsing, so it is legal and useful to use it for the string literal in a static_assert. It would be useful to add a note mentioning this.   Add a note: Multiple adjacent string literals may be used instead of a single /string-literal/; see [lex.phases].   CWG    REJECTED

The Standard is already clear enough on this point.  
UK 82
[386]
7 ¶ 2   Paragraph 2 talks about declarations that can have nested declarations within them. It doesn't mention scoped enumerations - but according to 7.2/11, "Each scoped enumerator is declared in the scope of the enumeration."   Add "scoped enumeration" to the list in the second sentence.   CWG    REJECTED

This suggestion was already considered and rejected. In particular, the following statement (“These nested scopes, in turn, can have declarations nested within them”) is not true of an enumeration scope.  
UK 83
[372]
7.1 ¶ 2   The longest sequence of decl-specifiers that could possibly be a type name is taken as the decl-specifier-seq of a declaration. But many sequences of decl-specifiers cannot possibly be a type name - eg the sequence "friend int", or "typedef int".   Not sure. I understand the rule, just not how to say it.   CWG  808   
UK 84
[404]
7.1 ¶ 1   The grammar includes alignment-specifier as a production for decl-specifier, but there is no production for alignment-specifier. I suspect this is a holdover from before alignment was handled as an attribute.   Delete the production (including the duplicate in A6)   CWG    ACCEPTED

See paper N2841 
FI 3 7.1 ¶ [dcl. spec. auto]   While it’s considered too late for this standard revision, consider loosening the restrictions for auto specifier and making it more a mirror of a deduced template function parameter.   See restricted-auto.ppt   CWG    REJECTED

As noted, the suggestion comes too late for consideration at this point in the standardization process.  
UK 85
[373]
7.1.1 ¶ 1   ... the init-declarator-list of the declaration shall not be empty (except for global anonymous unions, which shall be declared static). Global here means "declared at namespace scope". (cf 9.5/3 "Anonymous unions declared in a named namespace or in the global namespace shall be declared static.").   Replace "global" with "namespace scope".   CWG     
UK 86
[403]
7.1.1 ¶ 2,3   The register keyword serves very little function, offering no more than a hint that a note says is typically ignored. It should be deprecated in this version of the standard, freeing the reserved name up for use in a future standard, much like auto has been re-used this time around for being similarly useless.   Deprecate current usage of the register keyword.   CWG  809   
UK 87
[405]
7.1.1 ¶ 1, 4, 5   Why require two keywords, where one on its own becomes ill-formed? thread_local should imply 'static' in this case, and the combination of keywords should be banned rather than required. This would also eliminate the one of two exceptions documented in 7.1.1p1.   Drop requirement to combine static keyword with thread_local at block-scope inside a function definition.   CWG  810   
US 36 7.1.1 ¶ 4   The permission to use thread_local static data members is missing.   Add the static members as a permitted use.   CWG  717   
FR 23 7.1.5 [constexpr]   'constexpr' functions should be allowed to take const reference parameters, as long as their uses are in a context where a constant expression may be required. For example, the following should be allowed

template<typename T, int N>
int size(const T(&)[N]) { return N; }

int a[] = { 41,42,43,44 };
enum { v = size(a) };  
  CWG    REJECTED

There was no consensus for making this change without a more complete proposal.  
JP 12 7.1.5   It should be allowed to define constexpr recursively.

There is an explanation in N2235, Generalized Constant Expressions—Revision 5, as follows.

We (still) prohibit recursion in all its form in constant expressions. That is not strictly necessary because an implementation limit on recursion depth in constant expression evaluation would save us from the possibility of the compiler recursing forever. However, until we see a convincing use case for recursion, we don’t propose to allow it.

Then, here are the use cases where allowing recursion for constexpr is very useful.

Range of problem to be handled with constexpr would become extended. For example, user defined type (e.g. Complex type) could be placed in ROM area. But with current specification, a function defined with constexpr cannot be called recursively. As a side effect is not allowed in compile-time, it cannot be implemented to repeat anything without recursion. Although it could be implemented without recursion like func0, func1, func2 in an example below, it is not elegant solution.

constexpr double func0(double x) { /* ... */}
constexpr double func1(double x) { /* call for func0 */ }
constexpr double func2(double x) { /* call for func1 */ }
/* ... */

- Compile-time and runtime

As constexpr can be also evaluated both in compile-time and runtime, we need to discuss about both cases.

Runtime evaluation is just to execute it. If you eliminate constexpr keyword, it is executable as of now. Any modern compiler may optimize tail recursion easily.

Compile-time evaluation is the same thing as template recursion. It is necessary to support floating point operation, but it is already possible to calculate it in compile-time, so it’s ok.

- Sample

Here is an example to calculate a square root using constexpr recursively.

/*constexpr*/ double SqrtHelper(double x, double a, int n)
{
return n == 0 ? a : SqrtHelper(x, (x / a + a) / 2.0, n - 1);
}

/*constexpr*/ double Sqrt(double x)
{
return SqrtHelper(x, x, 20);
}

/*constexpr*/ double root2 = Sqrt(2.0); // 1.41421...  
Allow constexpr recursion.   CWG  699   
US 37 7.1.6.1 ¶ 1   There is a "Note: 3.9.3 describes how cv-qualifiers affect object and function types." So far as I can see, 3.9.3 CV-qualifiers only describes cv-qualifiers for objects, cv-qualifiers for (member) functions being described in 8.3.5 Functions.     editor    ACCEPTED  
UK 89
[377]
7.1.6.1 ¶ 2   The two normative sentences in this paragraph appear to duplicate text elsewhere - but they aren't exact duplicates, which introduces uncertainty. 1. "An object declared in namespace scope with a const-qualified type has internal linkage unless it is explicitly declared extern or unless it was previously declared to have external linkage.". This nearly repeats 7.1.1/7: "Objects declared const and not explicitly declared extern have internal linkage." The former seems to allow more wiggle room - can an object be "previously declared to have external linkage" without having been "explicitly declared extern"? 2. "A variable of non-volatile const-qualified integral or enumeration type initialized by an integral constant expression can be used in integral constant expressions (5.19)." This nearly duplicates 5.19/2, bullet 4, 1st sub-bullet - "[... an integaral constant expression can use] an lvalue of effective integral type that refers to a non-volatile const variable or static data member initialized with constant expressions". The latter does not allow for lvalues of enumeration type (neither scoped not unscoped enumerations are integral types - 3.9.1/7, and note 44). This seems to be a flaw in 5.19/2.   Make the normative text in this section into one or more notes, with cross references, and correct the referenced text if necessary.   CWG  811   
UK 90
[379]
7.1.6.2 ¶ para 1 and table 9   The grammar in paragraph one makes "nested-name-specifier template simple-template-id" a simple-type-specifier, but unlike all the others it is omitted from table 9.   Add a row to table 9 mentioning simple-template-id and punting to clause 14 (cf decltype(expression)).   editor    ACCEPTED  
UK 91
[380]
7.1.6.2 ¶ 4   5.1/5 says "[A] parenthesized expression can be used in exactly the same contexts as those where the enclosed expression can be used, and with the same meaning, except as otherwise indicated." When the first bullet point of this paragraph, describing the type denoted by decltype(e), says "if e is an id-expression ... decltype(e) is the type of the entity named by e", 5.1/5 is not excluded, which would imply that decltype((e)) was also the type of e. But the intention appears that it should be caught by the third bullet and treated as an lvalue expression, so decltype((e)) should be a reference to the type of e. Conversely, the second bullet point says "(parentheses around e are ignored)", which is redundant because of 5.1/5.   Insert "unparenthised" in the first bullet point - "if e is an *unparenthised* id-expression ...". In the second bullet point, move "(parentheses around e are ignored)" into a note.   CWG    ACCEPTED with MODIFICATIONS

See paper N2841 
UK 92
[382]
7.1.6.3 ¶ 2   The note correctly indicates that, if T is a template type parameter, then "friend class T;" is ill-formed. It might be worth pointing out at the same time that the alternative "friend T;" is now allowed - see 11.4/3.   Either strike the note or add reference to 11.4/3 and/or mention of "friend T;".   editor    ACCEPTED  
UK 93
[454]
7.1.6.3 ¶ Grammar before para 1   In the third production, "enum ::opt nested-name-specifieropt identifier", enum should not be in italics; its referring to the enum keyword.   Change to keyword font   editor    ACCEPTED  
UK 94
[383]
7.1.6.4 ¶ 1   The auto type-specifier signifies that the type of an object being declared shall be deduced from its initializer or specified explicitly at the end of a function declarator. A function declarator does not declare an object.   The auto type-specifier signifies that the type of an object being declared shall be deduced from its initializer or that the return type of a function is specified explicitly at the end of a function declarator.   editor    ACCEPTED  
UK 95
[396]
7.1.6.4 ¶ 4   (See also c++std-core-13583) This paragraph allows auto "in the type-specifier-seq in a new-type-id (5.3.4)" (and nowhere else not listed). Specifically, it isn't allowed in a type-id in a new-expression. That allows "new auto (42)", but not "new (auto)(42)". However, 5.3.4/2 suggests the latter should be allowed "If the auto type-specifier appears in the type-specifier-seq of a new-type-id or type-id of a new-expression ...". The inconsistency should be resolved, ideally in favour of allowing both forms.   Change "in a new-type-id" to "in a new-type-id or type-id in a new-expression".   CWG  746   
FR 24 7.1.6.4 [auto specifier]   Now that 'auto' is finally used in its most obvious sense to state `deduce the type of this variable from initializer', it should also be allowed in template parameter declarations, as in

template<auto n> struct X { /* … */ };

X<903> x;

X<&Widget::callback> y;

instead of the current, often verbose and cumbersome

template<typename T, T n> struct X { /* … */ };

X<int,903> x;

X<void (Widget::*)(),&Widget::callback> y;

We understand that 'auto' is used in 14.1/18 in a different way (for constrained template), but that usable appears very strange syntax, unnatural and does not fit well with the usage in this section.  
  CWG    REJECTED

There was no consensus to make this change at this point in the standardization process.  
US 38 7.2 ¶ 1   The discussion of attribute specifiers should be a separate paragraph.     editor    REJECTED

It's okay where it is. It's a list of constraints on the grammar.  
US 39 7.2 ¶ 2   The paragraph says in part "An opaque-enum-declaration declaring an unscoped enumeration shall not omit the enum-base." This statement implies that the base may be omitted for scoped enumerations, which is somewhat inconsistent with paragraph 3 and somewhat consistent with paragraph 5.   As this implication leaves no representation, it should be either affirmed here or the statement should be expanded. Perhaps a note is warranted.   CWG    REJECTED

The current specification is consistent. A scoped enumeration with an omitted enum-base has an underlying type of int.  
JP 13 7.2 ¶ para 3   In the description for an unscoped enumeration, enum-base in redeclaration must be the same underlying type as in the 1st declaration, but it is not described explicitly, while it is referred that all enum-bases in redeclarations must specify the same underlying type.   Replace the description, "same underlying type", with "same as underlying type of (previous) declaration."   editor    ACCEPTED  
UK 96
[384]
7.2 ¶ 7   enum E { }; What are the values of E? It has neither a smallest nor largest enumerator, so paragraph 7 doesn't help. (Paragraph 6 indicates that the underlying type is as if E had a single enumerator with value 0, but that does not define the values of E.)   Add a second sentence to paragraph 7 (before "Otherwise"): "If the enumerator-list is empty, 0 is the only value of the enumeration."   CWG  628   
UK 97
[385]
7.2 ¶ 9   Missing punctuation after "blue" in: "The possible values of an object of type color are red, yellow, green, blue these values can be converted ..."   Add a semicolon: "The possible values of an object of type color are red, yellow, green, blue; these values can be converted ..."   editor    ACCEPTED  
UK 98
[402]
20.5.6   It would be useful to be able to determine the underlying type of an arbitrary enumeration type. This would allow safe casting to an integral type (especially needed for scoped enums, which do not promote), and would allow use of numeric_limits. In general it makes generic programming with enumerations easier.   Add a TransformationTrait to 20.5.6 that returns the underlying type of an enumeration type.   LWG  1055  Section reference corrected from 7.2.
Note that the EnumerationType concept (14.9.4 paragraph 41) has a member underlying_type that provides this information.  
UK 99
[421]
7.2 ¶ 3   It is unclear whether an enumeration type is complete after an opaque-enum-declaration. This paragraph only says so in a note, and the general rule in 3.9/5 ("Incompletely-defined object types ... are incomplete types") is unclear in this situation.   Move "an enumeration declared by an opaque-enum-declaration ... is a complete type" from the note to normative text.   CWG    REJECTED

The definition of an incomplete type in 3.9 paragraph 5 does not mention opaque enumeration types; therefore, an opaque enumeration type is not an incomplete type.  
JP 14 7.3.1  

The description of the behavior when a member that was defined with same name in other namespace was referred.

  • It seems that the behavior of the following case is not defined. So we think that it is necessary to define that.

      namespace Q {
        inline namespace V {
          int g;
        }
        int g;
      }
      Q::g = 1; // ill-fromed,
                // Q::V::g = 1;,
                // or Q::g = 1;?
    
  • Add that the following case is ill-formed to more easily to understand.

      namespace Q {
        inline namespace V1 {
          int g;
        }
        inline namespace V2 {
          int g;
        }
      }
      Q::g = 1;  // ill-formed
    
 
Add the description of the behavior when a member that was defined with same name in other namespace was referred.   CWG  812   
UK 100
[387]
7.3.3 ¶ 10 and 13   Para 10 says "A using-declaration is a declaration and can therefore be used repeatedly where (and only where) multiple declarations are allowed." Para 13 says "Since a using-declaration is a declaration, the restrictions on declarations of the same name in the same declarative region (3.3) also apply to using-declarations." These appear to be saying exactly the same thing.   Delete para 10, moving its example into para 13.   CWG    REJECTED

The two citations are different: paragraph 10 is referring to repeated declarations of the same entity, while paragraph 13 deals with declarations of different entities with the same name.  
UK 101
[388]
7.3.3 ¶ 20   If a using-declaration uses the keyword typename and specifies a dependent name (14.6.2), the name introduced by the using-declaration is treated as a typedef-name (7.1.3). That doesn't specify at all what the effect of using typename with a non-dependent name is. Is it allowed? What about outside any template? What if the name isn't a type? (14.6/4 doesn't cover this, I think.)   Allow typename for non-dependent names iff they refer to a type.   CWG  813   
DE 12 7.3.3 ¶ p15   DE-12 Overriding and hiding of member functions named in using-declarations should consider ref-qualifiers, because they are part of the function type.     CWG  731   
FR 25 7.3.3 [The using declaration] ¶ Para 21   The syntax for concept map alias is unnecessarily both confused and verbose.   We strongly suggest simplifications, e.g.

using N1::C<int>;

that fits well with existing constructs. The syntactic complexity is too high for a new feature presumably designed to support sound programming.  
CWG    REJECTED

The complexity is considered necessary to allow concepts and concept maps to be members of different namespaces, as illustrated in the example.  
UK 102
[389]
7.3.4 ¶ 6   This paragraph says "If name lookup finds a declaration for a name in two different namespaces, and the declarations do not declare the same entity and do not declare functions, the use of the name is ill-formed." But the example uses declaration of functions, so is not covered by this paragraph.   Move the example to paragraph 7, and/or replace it with an appropriate example.   editor    ACCEPTED with MODIFICATIONS

Changed the example slightly to make it clearer.  
US 40 7.6   The list of attributes is missing an attribute to indicate that a function with a throw() (throws nothing) clause need not have the unexpected() catch clause generated. This attribute was a motivating example for the attribute syntax, and its omission is surprising.   Add the attribute.   CWG  814   
US 41 7.6   A common problem is unintentionally declaring a new virtual member function instead of overriding a base virtual member function.   An attribute stating intent to override would enable better diagnostics.   CWG    We are awaiting a full proposal to evaluate.  
FR 26 7.6[Attributes]   Are they part of object types or not? The section does not appear to indicate that clearly.     CWG     
FI 1 7.6   Add override-attribute for functions in order to avoid mistakes when overriding functions.   See override­-attribute.doc, override-attribute.ppt   CWG    We are awaiting a full proposal to evaluate.  
FR 27 7.6.1   This section specifies that no name lookup is performed on any identifier contained in an attribute-token. This in particular implies that, for example, it is impossible to define a template class parameterized by its alignment. That restriction is unacceptable.

The original alignment proposal made that useful construct possible.

Furthermore paragraph 7.6.1/2 appears contradictory with the rest of that section -- since no name lookup is performed, how a 'type-id'is determined?  
  CWG    REJECTED

The comment is based on a misunderstanding: what is not looked up is, informally, the attribute name (e.g., align), including the attribute-namespace, if any. The attribute-argument-clause, if present, can have identifiers that are looked up, depending on the attribute.  
UK 103
[397]
7.6.1   Attributes should support pack expansion. For example, this would be extremely useful with the align attribute, directly supporting the (removed) functionality of aligned_union. NOte that aligned_union was removed as varaiant-unions were considered a complete replacement - however this is not true for variadic templates. Adding this support to attributes would remove the remaining need, and support similar attributes in the future.   Add: attribute... to the grammar for attribute-list Add to list in 14.5.3p4: "In an attribute-list(7.6.1); the pattern is an attribute."   CWG  815   
UK 104
[398]
7.6.1 ¶ 1   It is helpful for each subclause to contain a short paragraph introducing its intent an purpose. 7.6 has such a paragraph, but it is nested under a more specific subsection.   7.6.1p1 should move up one level to become 7.6p1. There grammar should remain under 7.6.1   editor    REJECTED

ISO editing guidelines insist that only leaf clauses have text. Moving this sentence to 7.6 would violate that rule (not that the standard doesn't violate it in many places, but we shouldn't make this worse now).  
UK 105
[448]
7.6.1 ¶ 1   Allowing only one level of namespaces in attributes seems unnecessarily limiting.   To: attribute-scoped-token: attribute-namespace :: identifier add attribute-namespace :: attribute-scoped-token   CWG    REJECTED

This suggestion was discussed earlier and rejected, and there was no consensus for reconsideration.  
UK 106
[391]
7.6.2 ¶ 1   Extensive use of alignment and related terms without cross reference.   Add cross-reference to 3.11.   editor    ACCEPTED  
JP 15 7.6.2   An abbreviation of 7.6.2 should be “[decl.attr.align]” instead of “[dcl.align]”. Section name “[dcl.align]” is not consistent with others, because others in 7.6 are the form of “dcl.attr.*”. In N2761, the section name of 7.1.7 had been changed from “[dcl.align]” to “[dcl.attr.align]”, but in N2800 it was reverted to “[dcl.align]” along with a change of section number, 7.1.7 to 7.6.2.   Change "[dcl.align]" of 7.6.2 to "[decl.attr.align]".   editor    REJECTED

Tags don't change. This section used to be somewhere else, and the tag was appropriate there.  
UK 107
[399]
7.6.3   While undefined behaviour might be the best we can guarantee, it would be helpful to encourage implementations to diagnose function definitions that might execute a return.   Adda a [Note : implementations are encouraged to issue a diagnostic where the definition of a function marked [[noreturn]] might execute a return statement -- end note]   editor    ACCEPTED  
UK 108
[401]
7.6.4 ¶ 2   It is unclear why no diagnostic is required for an easily detectable violation. It is even more surprising that the associated footnote mandates behaviour for an ill-formed program.   Strike "no diagnostic required" and the associated footnote.   CWG  816   
US 42 7.6.4   The meaning of the [[final]] attribute applied to classes is inconsistent with other languages and not desirable in its own right.   Modify the semantics of [[final]] applied to classes. See the attached paper "Issues with the C++ Standard" under Chapter 7 "Meaning of [[final]] attribute applied to classes".   CWG  817   
UK 109
[392]
7.6.5 ¶ 4   The example code refers in comments to "Compilation unit" A and B. The term should be "Translation unit" (2/1)   Replace "Compilation" with "Translation" in two places   editor    ACCEPTED  
UK 110
[393]
7.6.5 ¶ 4   The code in the example (compilation unit A) has: "foo_head[i].load(memory_order_consume)". foo_head[i] is of type foo *, so it does not have a load member.   Change the type of foo_head to atomic<foo *>[].   CWG    ACCEPTED

See paper N2841 
US 43 8   With the introduction of late-specified return types for functions and lambda expressions, we now have three different syntaxes for declaring functions. The -> late declaration is used in two. The auto keyword is used in one, but also used differently in variable definitions.   Some simplification is needed.   CWG     
UK 111
[457]
8.3.5 ¶ 13   Example missing closing bracket in template<typename... T> void f(T (* ...t)(int, int);   Add closing bracket like this: template<typename... T> void f(T (* ...t)(int, int));   editor    ACCEPTED  
US 44 8.3.5 ¶ 13   In the Example, "template void f(T (* ...t)(int, int);" is missing a close parenthesis.   It presumably should read: "template void f(T (* ...t))(int, int);".   editor    ACCEPTED  
US 45 8.3.5 ¶ 13   At present, function parameter packs can only occur at the end of a parameter-declaration-list. This restriction unnecessarily prohibits uses of function parameter packs in cases where template argument deduction isn’t needed, e.g.,

template<class... T> struct X { };

template<class... T1, class... T2>
struct X<pair<T1, T2>...> {
void f(T1..., T2...);
};

More importantly, this restriction is inconsistent with the way pack expansions are handled. For example, this template is well-formed (but X<T..., int> is a non-deduced context):

template<class... T> void f(X<T..., int>);

Therefore, the restriction that limits function parameter packs to the end of the parameter-declaration-list should be removed. Instead, function parameter packs not at the end of the parameter-declaration-list should be considered non-deduced contexts.  
In 8.3.5p13, remove the sentence “A function parameter pack, if present, shall occur at the end of the parameter-declaration-list.”

In 14.8.2.1p1, replace the phrase “For a function parameter pack” with “For a function parameter pack that occurs at the end of a parameter-declaration-list”.

Replace the note text “A function parameter pack can only occur at the end of a parameter-declaration-list (8.3.5).” with “A function parameter pack that does not occur at the end of a parameter-declaration-list is a non-deduced context.”

In 14.8.2.5p5, add a new bullet: “A function parameter pack that does not occur at the end of its parameter-declaration-list.”

In 14.8.2.5p10, replace “If the parameter-declaration corresponding to Pi is a function parameter pack” with “If the parameter-declaration corresponding to Pi is a function parameter pack and Pi occurs at the end of the parameter-declaration-list”.

Replace the note text “A function parameter pack can only occur at the end of a parameter-declaration-list (8.3.5).” with “A function parameter pack that does not occur at the end of a parameter-declaration-list is a non-deduced context.”  
CWG  818   
DE 13 8.4 ¶ p2   DE-13 The second paragraph, quoting the grammar for the declarator of a function declaration, is not considering late-specified return types and attributes.   Properly quote the grammar from 8.3.5.   CWG  732   
JP 16 8.5 ¶ 15th para, 1st line   Typo, duplicated "in"

"The initialization that occurs in in the forms"  
Remove one.   editor    ACCEPTED  
US 46 8.5.3   The ability for an rvalue reference to bind to an lvalue opens a type-safety hole that becomes very dangerous with concepts. For example, consider vector’s push_back operation:

requires MoveConstructible<T> void push_back(T&&);

requires CopyConstructible<T> void push_back(const T&);

For a copy-constructible T (which is also move-constructible), push_back does the right thing. However, if T is something that is move-constructible (e.g., unique_ptr<int>), the second overload is removed from considered (it is effectively SFINAE’d away), so only the first overload remains. Therefore, one could accidentally call push_back with an lvalue of type T, and push_back would silently move from the lvalue. The same problem occurs without concepts (albeit less frequently).  
Prohibit rvalue references from binding to lvalues.

Unfortunately this change will break some current use cases of rvalue reference including the use of rvalue streams, and of the forward function itself. To resolve this we may want to consider three types of references:
  1. The current reference.
  2. A non-const reference that only binds to rvalues.
  3. A non-const reference that will bind to both lvalues and rvalues.
Still another solution would be to adopt the “deleted function” solution for all functions. This solution is described in comment for 12.1, 12.4, 12.8, but restricted to special functions in that comment. (See US NN).  
CWG    ACCEPTED

See paper N2844 
US 49 8.5.4 ¶ 6   In the Example, the comments could be improved.   See the attached paper "Issues with the C++ Standard" under "Editorial Issues" and "8.5.4/6".   editor     
UK 112
[440]
9 ¶ 4-9   We now have concepts that should (or should not?) map to the terms described in Clause 9 - these should be at least referenced.   Add appropriate forward references to 14.9.4   editor    REJECTED

This seems excessive. If people want to know about concepts they should read about concepts.  
UK 113
[250]
9.4.2 ¶ 3   Mis-applied edit from the paper n2756   The term 'constant-initializer' should have been struck out when replaced by brace-or-equal-initializer. There are two occurrences in this paragraph   editor    ACCEPTED  
US 50 12.1, 12.4, 12.8   Implicitly-declared default constructors, destructors, copy constructors, and copy assignment operators are deleted when their definitions would be ill-formed. However, unlike with overloading and template argument deduction, access control is performed as part of the check for making one of these special function deleted. This inconsistency should be removed.

This change would sacrifice some backward compatibility in favor of consistency. With the current wording, checking that the following class ‘A’ is CopyConstructible would proceed without error (it is not CopyConstructible):

class A { A(const A&); };

With the proposed change, testing whether A is CopyConstructible would produce a diagnostic. To fix the problem, the user would have to use a deleted function:

class A { A(const A&) = delete; };  
In 12.1p5, remove the phrase “or inaccessible from the implicitly-declared default constructor”.

In 12.4p3, remove the phrase “or a destructor that is inaccessible from the implicitly-declared destructor,” and the phrase “or a destructor that is inaccessible from the implicitly-declared destructor”.

In 12.8p5, remove the phrase “or inaccessible from the implicitly-declared copy constructor” from the two places it occurs.

In 12.8p10, remove the phrase “or inaccessible from the implicitly-declared copy assignment operator” from the two places it occurs.  
CWG  819   
FR 28 12.6.1 [Explicit initialization]   This section, in particular the example with `g' appears contradictory with the syntax for uniform initialization.     CWG    ACCEPTED

See paper N2841 
US 51 12.6.2 ¶ 2   The discussion of delegating constructors should be in its own paragraph.     editor    ACCEPTED  
UK 114
[167]
12.6.2 ¶ 1   Despite all the attempts to unify initialization syntax, it is still not possible to copy-initialize base classes or non-static data members, which means the explicit keyword cannot have a bearing during evaluation of a constructor. A minimal addition to the grammar, allowing an optional = between the mem-initializer-id and braced-init-list would allow the user to choose between copy and direct initialization   Ammend the grammar for mem-initializer: mem-initializer-id =OPT braced-init-list Extend p3 to allow for Copy Initialization if the optional = is present: 3 The expression-list or braced-init-list in a mem-initializer is used to initialize the base class or non-static data member subobject denoted by the mem-initializer-id according to the initialization rules of 8.5 for direct-initialization, OR COPY-INITIALIZATION IF THE OPTIONAL = IS PRESENT BETWEEN THE MEM-INITIALIZER-ID and the BRACED-INIT-LIST. [Example:...   CWG    REJECTED

There was no consensus for making this changes.  
US 52 13.5.8 ¶ ¶ 5   A word is misspelled.   Change “shal” to “shall”.   editor    ACCEPTED  
UK 115
[432]
14 ¶ 6-11   Exported templates were a great idea that is generally understood to have failed. In the decade since the standard was adopted, only one implementation has appeared. No current vendors appear interested in creating another. We tentatively suggest this makes the feature ripe for deprecation. Our main concern with deprecation is that it might turn out that exported constrained templates become an important compile-time optimization, as the constraints would be checked once in the exported definition and not in each translation unit consuming the exported declarations.   Consider deprecating exported templates, but no action yet. Examine interaction with constrained templates, and see if other more appropriate mechanism will support compile-time optimization.   CWG  820   
UK 116
[434]
14 ¶ 6-11   Is it possible to export a concept map template? The current wording suggests it is possible, but it is not entirely clear what it would mean.   Either prohibit exporting concept map templates, or more directly address what it means to export a concept map.   CWG  821   
UK 117
[430]
14 ¶ 2   It would be nice to allow template alias within a function scope, and possibly a scoped concept map. As these affect name lookup and resolution, rather than defining new callable code, they are not seen to present the same problems that prevented class and function templates in the past.   Allow template aliases to be declared inside a function scope, and consider scoped concept maps.   CWG  822   
UK 118
[431]
14 ¶ 6-11   Exported templates are a complicated feature with surprisingly little text. To make this important text more visible, split it off into its own subclause [temp.export]   Create a new subclause [temp.export] containing 14p6-11. Move 14p12 ahead of this subclause.   editor    ACCEPTED  
UK 119
[433]
14 ¶ 4   Does a concept map have linkage? Reading this paragraph and 3.5 suggests a concept map template has external linkage, but not a 'regular' concept map. Believe this is an oversight that the linkage words were not updated to provide an exception, rather than linkage of concept maps is intended.   Add an exception that concept map templates have no linkage, or add concept maps to the list of entities with linkage in 3.5   CWG  791   
UK 120
[422]
14.1 ¶ 9   As this is the first time the phrase “parameter pack” appears in Ch 14 I would like to see the section 8.3.5 referenced here (as well as in 14.1p17).   Insert “(8.3.5)” after “parameter pack”   editor    ACCEPTED  
UK 121
[423]
14.1 ¶ 18   The example (that follows the normative text) has no begin example marker   Prefix the example code with "[ Example:"   editor    ACCEPTED  
FR 29 14.3 [Template arguments]   Constant expressions of any literal type should be allowed as template arguments.     CWG  823   
US 53 14.5.1 ¶ 5   If the requirements of a constrained member that is a copy constructor, copy assignment operator, or destructor are not satisfied, then that user-declared special function will not exist. It appears that, in this case, the special function will then be implicitly defined, which is likely to either (a) fail to compile or (b) produce a function with the wrong semantics. For example:

template<ObjectType T> class vector {
T* first, last, end;
public:
requires CopyConstructible<T> vector(const vector&);
};

If instantiated with a type that is not CopyConstructible, vector will get an implicitly-defined copy constructor that performs a copy of the pointers.  
Add to 14.5.1p5:

If the constrained member is a copy constructor (12.8), destructor (12.4), or copy assignment operator and its template requirements are not satisfied, then a copy constructor, destructor, or copy assignment operator, respectively, with the same signature as the constrained member (after substituting the class template’s template arguments for its template parameters) will be declared as a deleted function (8.4).  
CWG  824   
UK 122
[426]
14.5.3 ¶ 4   Variadic templates should be supported in axioms. There are axioms in the library that rely on this feature, such as the FrontEmplacement axiom in FrontEmplacementContainer (23.1.6.1p10)   Add clarification in p2 that function parameter packs can be used to declare axioms, much like p1 clarifies they can be used to declare concepts as well as templates.   CWG     
FR 30 14.5.7 [Template aliases]   When are two template alias names equivalent? E.g. given

template<template<class> class> struct X { };

template<typename,typename> struct Y { };
template<typename T>
using Z1 = Y<int,T>;
template<typename T>
using Z2 = Y<int,T>;

Are the types X<Z1> and X<Z2> equivalent?

We would suggest yes (since Z1<T> and Z2<T> are the same for all T), but we do not see any wording to that effect.  
  CWG    REJECTED

This is already clear in the Standard; see 14.5.7 paragraph 2 and 14.4 paragraph 1. The last example in 14.4 paragraph 1 is very similar to the one given here.  
JP 17 14.7.2 ¶ 2nd para, 15th line   Typo.

if that namespace is inline, any namespace from its enclosing namespace set.

should be

if that namespace is inline, any namespace forming its enclosing namespace set.  
Replace "from" with "forming"   CWG    REJECTED

The current wording is correct.  
DE 14 14.7.3 ¶ p1   DE-14 The bulleted list neither addresses "member function template of a class" nor "member class template of a class".   Add the respective bullets.   CWG  730   
JP 18 14.7.3 ¶ 2nd para, 2nd line   Typo,

any namespace from its enclosing namespace set

should be

any namespace forming its enclosing namespace set  
Replace "from" with "forming"   CWG    REJECTED

The current wording is correct.  
JP 19 14.8.2 ¶ 6th para, 1st line   Typo, duplicated "is"

"At certain points in the template argument deduction process it is is necessary"  
Remove one   editor    ACCEPTED  
US 54 14.9 [concept], 14.10 [temp. constrained]   Concepts is of course the largest new feature in C++0x (in terms of new text inserted into the wording), and already we have found some significant defects with it. So far nothing devastating has been found, but more time is needed to shake more bugs out.   I propose no specific change here.   CWG    ACCEPTED  
US 55 14.9.1 ¶ ¶ 6   The paragraph number is in the wrong place, causing a grammar rule to be indented more than its fellows.   Move the paragraph number so as to follow the grammar rules, thus numbering the single sentence, “The body of a concept … .”   editor    ACCEPTED  
US 56 14.9.1 ¶ ¶ 6   The sentence contains two references to 14.9.1.3 [concept.req].   Change the second such reference (at the end of the sentence) to 14.9.1.4 [concept.axiom].   editor    REJECTED

Yes; they apply to different terms.  
US 57 14.9.1.4 ¶ ¶ 3   A word is misplaced, changing the intended meaning.   Change “only find … if” to “find … only if”.   editor    REJECTED

These mean the same thing, and the latter is stilted.  
US 58 14.9.1.4 ¶ ¶ 3   The listed phrases are not grammatically parallel.   Insert “in” before “one” so as to obtain “... in the concept, in one of its less refined concepts, or in an associated requirement.”   editor    ACCEPTED  
US 59 14.9.1.4   Axioms are under-specified and provide little benefit to programmers, so they should be removed from the working paper. The optimizations permitted by axioms (see 14.9.1.4p4-5) are not compulsory (and, therefore, programmers cannot rely on them) and the semantics expressed by axioms cannot be verified by any implementation. The resulting specification has lead to great confusion (see the reflector thread “Are floating point types Regular?” starting with c++std-lib-22717). Given the level of confusion and the inability to verify the correctness of axioms, it is likely that many axioms written by programmers (including those specified in the candidate draft) will be incorrect.   Remove clause 14.9.1.4 [concept.axiom]

In 2.11p1, remove “axiom” from the list of keywords.

In 14.5.8p7, remove “, or if the resulting concept map fails to satisfy the axioms of the corresponding concept”

In 14.9.1p6, remove axiom-definition from the list of grammar productions for concept-member-specifier. Remove “, and axioms” from the final sentence, and instead “and” prior to “associated requirements” in the final sentence.

Remove paragraph 14 of clause 14.9.2.

In 14.10.1p6, remove the sentence, “When the concept-instance-alias-def appears in the optional requires-clause of an axiom-definition (14.9.1.4), the potential scope of the identifier begins at its point of declaration and terminates at the end of the axiom-definition.”

In clauses 20.2.5, 20.2.8, 23.1.6.1, 23.1.6.2, and 24.1.4, remove the axiom-definitions and replace them with paragraphs (denoted Requires, Postconditions, or Effects, as appropriate) that express the intended semantics of the concepts from which the axiom-definitions were removed.

In 24.1.4p2, replace the word “axiom” with “condition.”  
CWG     
FR 31 14.9.1.4 [Axioms]   This section states that an axiom-definition defines a new semantics axiom but is unusually vague as to what those semantics might be.

The use of the '==' and '!=' with completely new semantics, unrelated to anything we have seen before in C++ is both unwise and confusing, especially if the types involved in the expressions happen to have operator== and operator!= defined.

We strongly suggest use of different tokens, e.g. , and opposed to this obscure usage/overload.

The description is very vague. How many times is an implementation permitted to replace one expression by another one when they have side effects?  
  CWG     
DE 15 14.9.1.4   DE-15 There is no implementation experience for axioms. Use of axioms is an area of active scientific research. It is likely that syntax changes will become necessary to make good use of axioms; having the syntax space already crowded is unhelpful. Axioms ought to be useful in concepts applicable to floating-point types (such as EqualityComparable), but IEEE floating-point types have special values such as NaN violating the axioms.   Remove section 14.9.1.4 and any reference to axioms in the rest of the proposed standard other than the keyword reservation in section 2.11.   CWG     
UK 123
[248]
14.9.1.4   auto concepts and axioms are incompatible. An axiom defines the semantics of an operaton or set of operations that describes the run time behaviour. A concept describes purely syntactic requirements at compile time. Where an auto concept will match anything that meets the syntax requirements, there is no way to know if the axioms will be met or not, and no way to opt out via some kind of negative concept map.   Add a paragraph making axioms ill-formed inside an auto concept.   CWG     
UK 124
[288]
14.9.1.4 ¶ 6   Spelling mistake, double-e in were.   weere -> were   editor    ACCEPTED  
UK 125
[289]
14.9.1.4 ¶ 2   The implicit equality comparison operator available to axioms has no semantic. It is not clear what expressing the condition if( a == b ) { conditional-axiom } would mean if a and b are not truly EqualityComparable. We suspect the intent of the 'implicit defefinition' is to support declaring the equivalence of statements, a context where the operator will not actually be evaluated.   Define the semantics of the implicitly declared comparison operators, or restrict their usage to declaring equivalence between statements.   CWG     
UK 126
[438]
14.9.4 ¶ 41   This paragraph contains the only definition of the underlying_type member - but it's a note, so not normative.   Move the second sentence to the Requires clause in paragraph 42.   editor    ACCEPTED  
UK 127
[118]
14.9.4   Provide a diagram clearly showing refinement relationship between the different support concepts. Several were created during development of this clause and they were very helpful.   Provide the diagram.   editor     
UK 128
[435]
14.9.4 ¶ 4   It is surprising for many people that non-copyable move-only types can be used with a return statement, and so Returnable does not always imply CopyConstructible.   A non-normative note: [Note: 'move only' types that are constructible from rvalue references may be Returnable, but not CopyConstructible(20.1.8) - end note]   editor    ACCEPTED  
JP 20 14.9.4 ¶ 2nd para   Trivially copyable type was added in “3.9 Types”, so we think that it is necessary to add concept to trivially copyable type like “TriviallyCopyableType”.   Add TriviallyCopyableType that is trivially copyable type as concept.   CWG  825   
UK 129
[128]
14.10.1, 20.1.2   It should be possible to support boolean constant expressions as requirements without resorting to defining the True concept in the library. Boolean expressions are very likely to be constraints when deadline with non-type template parameters and variadic templates, and constraints in these cases should feel just as natural as constraints on the type system.   Remove the True concept and library subclause 20.1.2. Provide support in 14.10.1 for boolean constant expressions as constraints. This may involve overloading the true keyword to disambiguate but ideally would not.   CWG  826   
US 60 14.10.1 ¶ 1   The use of && as the separator for a list of requirements has shown itself to be a serious teachability problem. The mental model behind ‘&&’ treats concepts as simple predicates, which ignores the role of concepts in type-checking templates. The more programmers read into the ‘&&’ (and especially try to fake || with && and !), the harder it is for them to understand the role of concept maps. Simply changing the separator to ‘,’ would eliminate a significant source of confusion.   Replace

requirement-list:
requirement-list ... [opt] && requirement
requirement ... [opt]

with

requirement-list
requirement-list ...[opt] , requirement
requirement ... [opt]

In 14.5.4p6, replace the first sentence with:

The instantiation of an expansion produces a comma-separated list E1, E2, ..., EN, where N is the number of elements in the pack expansion parameters.  
CWG  827   
UK 130
[32]
15.1 ¶ 4   With the new crrent_exception API it is possible to capture a reference to an exception that will outlive its last active handler. That is in conflict with the sentance "When the last remaining active handler for the exception exits by any means other than throw; the temporary object is destroyed and the implementation may deallocate the memory for the temporary object;"   Update sentence to allow for exceptions held in excpetion_ptr objects.   CWG  828   
UK 131
[34]
15.3 ¶ 3   A handler catching its parameter by rvalue-reference is syntactically valid, but will never be activated.   Disallow handlers catching by rvalue-reference.   CWG    ACCEPTED

See paper N2844 
UK 132
[36]
15.3 ¶ 16   There are obscure cases whrere a copy constructor is not usually the best match to copy-initialize an object, e.g. A converting constructor template taking arguments by non-const reference. A footnote explaining such cases would be helpful, or the sentance could be rewritten using copy-initialization instead of directly calling a copy constructor.   Rewite using copy-initialization rather than directly invoking the copy constructor   CWG    ACCEPTED

See paper N2841 
UK 133
[37]
15.4 ¶ 2   Template aliases have the same semantics as a typedef so should also be disallowed   add "or alias-declaration" after "shall not appear in a typedef declaration".   CWG    ACCEPTED

See paper N2841 
UK 134
[38]
15.4 ¶ 6   The sentance "An exception-specification can also include the class std::bad_exception (18.7.2.1)." is redundant.   Either strike the quoted sentance, or add a note explaining why it is worth calling special attention to this class.   editor    ACCEPTED  
UK 135
[39]
15.4 ¶ 8   Unclear if std::unexpected is called before or after the function arguments have been destroyed   Clarify the sequence of calling unexpected with respect to interesting objects, such as function arguments or partially constructed bases and members when called from a constructor or destructor   CWG  829   
UK 136
[40]
15.4   Exception specifications have proven close to worthless in practice, while adding a measurable overhead to programs. The feature should be deprecated. The one exception to the rule is the empty throw specification which could serve a legitimate optimizing role if the requirement to call the runtime unexpected mechanism was relaxed in this case.   Move 15.4 and the parts of 15.5 that refer to it to Appendix D. Replace 15.4 with a simpler specification for empty throw specifications, where the std::unexpected call is conditionally supported allowing vendors to choose between optimizing and providing runtime checks. Ideally require vendors to provide a mode where the runtime checks are always disabled.   CWG  830   
UK 137
[44]
15.5   There is no mention of the current_exception API which can extend the lifetime of an exception object. There should at least be a forward reference to the library clause 18.7.5   Add another paragraph outlining 18.7.5 and the ability of an exception_ptr to extend the lifetime of an exception object   editor    ACCEPTED  
UK 138
[41]
15.5.1 ¶ 1   The third bullet is redundant with the first, as it is a subset of the same conditions.   Merge the third bullet into the first bullet as a note or example.   editor    REJECTED

They're subtly different. The first bullet is about calls made to create, copy, and destroy the exception object itself. The third bullet is about destructors of stack objects during stack unwinding.  
UK 139
[42]
15.5.1 ¶ 1   According to the first bullet it is perfectly alright for a library function to exit by throwing an exception during stack unwinding, This is clearly not true.   Strike the word 'user' from the first bullet point.   CWG    ACCEPTED

See paper N2841 
UK 140
[43]
15.5.2 ¶ 2   The detailed specification can fool people into thinking an exception will automatically be translated into bad_exception, where the default behaviour of std::unexcepted is to immediately call std::terminate();   Add a note highlighting the default behaviour of std::unexpected if the user does not supply a hander-function   editor    ACCEPTED  
UK 141
[45]
15.6   This whole subclause is redundant due to 15.1p5 and 15.3p17   Strike 15.6   editor    ACCEPTED  
UK 142
[455]
16.3.5 ¶ 3   This paragraph opens with "[ Note" but has no corresponding "end note ]"   Add "end note ]"   editor    ACCEPTED  
UK 143
[456]
16.3.5 ¶ 7   Example uses #define t(x,y.z) x ## y ## z   Change "x,y.z" to "x,y,z"   editor    ACCEPTED  
US 2 17-30   The active issues identified in WG21 N2806, C++ Standard Library Active Issues, must be addressed and appropriate action taken.
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html  
Appropriate action would include making changes to the CD, identifying an issue as not requiring a change to the CD, or deferring the issue to a later point in time.   LWG    ACCEPTED  
FR 2 General Comment ¶ Library   The adoption of the library `constexpr' proposal was not reflected in the draft, despite formal WG21 committee vote.   FR 2   editor     
US 61 17 onward   The concepts core language feature is applied to only some of the Standard Library clauses, and even then not always consistently.   Review all clauses of the Standard Library, and consistently apply concept technology wherever possible and appropriate. The proposed wording in WG21 N2781 exemplifies the necessary level of detail.   LWG    ACCEPTED  
CA 2 17 Library   “Concepts” are a significant new addition to the language, but are not exploited uniformly in the library as documented in CD 14882.   Fix the standard library so that “Concepts” are used appropriately in the library.   LWG    ACCEPTED  
US 62 17-30   Provide concepts and requirements clauses for all standard library templates     LWG    ACCEPTED  
US 63 17-30   The behavior of the library in the presence of threads is incompletely specified.

For example, if thread 1 assigns to X, then writes data to file f, which is read by thread 2, and then accesses variable X, is thread 2 guaranteed to be able to see the value assigned to X by thread 1? In other words, does the write of the data "happen before" the read?

Another example: does simultaneous access using operator at() to different characters in the same non-const string really introduce a data race?  
  LWG     
DE 2 17 through 30   DE-2 Marking a constructor with "explicit" has semantics even for a constructor with zero or several parameters: Such a constructor cannot be used with list-initialization in a copy-initialization context, see 13.3.1.7. The standard library apparently has not been reviewed for marking non-single-parameter constructors as "explicit".   Consider marking zero-parameter and multi-parameter constructors "explicit" in classes that have at least one constructor marked "explicit" and that do not have an initializer-list constructor.   LWG     
JP 21 21.2, 21.4, 27.2, 27.6, 27.7, 27.8.1, 28.4   Support of char16_t/char32_t is insufficient. The basic_xxx classes of <iostream>, <fstream>, <regex>, etc. does not have typedefs for char16_t/char32_t.

Functions such as stoi, to_string in ‘21.4 Numeric Conversion’ does not support char16_t/char32_t types.  
Add commented lines corresponding to char16_t, char32_t.

21.2 paragraph1

namespace std {
...

// 21.4: numeric conversions
...

int stoi(const u16string& str, size_t *idx = 0, int base = 10);
long stol(const u16string& str, size_t *idx = 0, int base = 10);
unsigned long stoul(const u16string& str, size_t *idx = 0, int base = 10);
long long stoll(const u16string& str, size_t *idx = 0, int base = 10);
unsigned long long stoull(const u16string& str, size_t *idx = 0, int base = 10);
float stof(const u16string& str, size_t *idx = 0);
double stod(const u16string& str, size_t *idx = 0);
long double stold(const u16string& str, size_t *idx = 0);
u16string to_u16string(long long val);
u16string to_u16string(unsigned long long val);
u16string to_u16string(long double val);

int stoi(const u32string& str, size_t *idx = 0, int base = 10);
long stol(const u32string& str, size_t *idx = 0, int base = 10);
unsigned long stoul(const u32string& str, size_t *idx = 0, int base = 10);
long long stoll(const u32string& str, size_t *idx = 0, int base = 10);
unsigned long long stoull(const u32string& str, size_t *idx = 0, int base = 10);
float stof(const u32string& str, size_t *idx = 0);
double stod(const u32string& str, size_t *idx = 0);
long double stold(const u32string& str, size_t *idx = 0);
u32string to_u32string(long long val);
u32string to_u32string(unsigned long long val);
u32string to_u32string(long double val);
}

27.2

namespace std {
...
typedef basic_ios<char> ios;
typedef basic_ios<wchar_t> wios;
typedef basic_ios<char16_t> u16ios;
typedef basic_ios<char32_t> u32ios;

...
typedef basic_ifstream<wchar_t> wifstream;
typedef basic_ofstream<wchar_t> wofstream;
typedef basic_fstream<wchar_t> wfstream;

typedef basic_streambuf<char16_t> u16streambuf;
typedef basic_istream<char16_t> u16istream;
typedef basic_ostream<char16_t> u16ostream;
typedef basic_iostream<char16_t> u16iostream;

typedef basic_stringbuf<char16_t> u16stringbuf;
typedef basic_istringstream<char16_t> u16istringstream;
typedef basic_ostringstream<char16_t> u16ostringstream;
typedef basic_stringstream<char16_t> u16stringstream;
typedef basic_filebuf<char16_t> u16filebuf;

typedef basic_ifstream<char16_t> u16ifstream;
typedef basic_ofstream<char16_t> u16ofstream;
typedef basic_fstream<char16_t> u16fstream;

typedef basic_streambuf<char32_t> u32streambuf;
typedef basic_istream<char32_t> u32istream;
typedef basic_ostream<char32_t> u32ostream;
typedef basic_iostream<char32_t> u32iostream;

typedef basic_stringbuf<char32_t> u32stringbuf;
typedef basic_istringstream<char32_t> u32istringstream;
typedef basic_ostringstream<char32_t> u32ostringstream;
typedef basic_stringstream<char32_t> u32stringstream;
typedef basic_filebuf<char32_t> u32filebuf;

typedef basic_ifstream<char32_t> u32ifstream;
typedef basic_ofstream<char32_t> u32ofstream;
typedef basic_fstream<char32_t> u32fstream;

...
template <class state> class fpos;
typedef fpos<char_traits<char>::state_type> streampos;
typedef fpos<char_traits<wchar_t>::state_type> wstreampos;
typedef fpos<char_traits<char16_t>::state_type> u16streampos;
typedef fpos<char_traits<char32_t>::state_type> u32streampos;
}

27.6

namespace std {
template <class charT, class traits = char_traits<charT> >
class basic_istream;
typedef basic_istream<char> istream;
typedef basic_istream<wchar_t> wistream;
typedef basic_istream<char16_t> u16istream;
typedef basic_istream<char32_t> u32istream;

template <class charT, class traits = char_traits<charT> >
class basic_iostream;
typedef basic_iostream<char> iostream;
typedef basic_iostream<wchar_t> wiostream;
typedef basic_iostream<char16_t> u16iostream;
typedef basic_iostream<char32_t> u32iostream;
}

namespace std {
template <class charT, class traits = char_traits<charT> >
class basic_ostream;
typedef basic_ostream<char> ostream;
typedef basic_ostream<wchar_t> wostream;
typedef basic_ostream<char16_t> u16ostream;
typedef basic_ostream<char32_t> u32ostream;
}

27.7 paragraph 1

namespace std {
template <class charT, class traits = char_traits<charT>,
class Allocator = allocator<charT> >
class basic_stringbuf;

typedef basic_stringbuf<char> stringbuf;
typedef basic_stringbuf<wchar_t> wstringbuf;
typedef basic_stringbuf<char16_t> u16stringbuf;
typedef basic_stringbuf<char32_t> u32stringbuf;

template <class charT, class traits = char_traits<charT>,
class Allocator = allocator<charT> >
class basic_istringstream;

typedef basic_istringstream<char> istringstream;
typedef basic_istringstream<wchar_t> wistringstream;
typedef basic_istringstream<char16_t> u16istringstream;
typedef basic_istringstream<char32_t> u32istringstream;

template <class charT, class traits = char_traits<charT>,
class Allocator = allocator<charT> >
class basic_ostringstream;

typedef basic_ostringstream<char> ostringstream;
typedef basic_ostringstream<wchar_t> wostringstream;
typedef basic_ostringstream<char16_t> u16ostringstream;
typedef basic_ostringstream<char32_t> u32ostringstream;

template <class charT, class traits = char_traits<charT>,
class Allocator = allocator<charT> >
class basic_stringstream;

typedef basic_stringstream<char> stringstream;
typedef basic_stringstream<wchar_t> wstringstream;
typedef basic_stringstream<char16_t> u16stringstream;
typedef basic_stringstream<char32_t> u32stringstream;
}

27.8.1 paragraph 1

namespace std {
template <class charT, class traits = char_traits<charT> >
class basic_filebuf;
typedef basic_filebuf<char> filebuf;
typedef basic_filebuf<wchar_t> wfilebuf;
typedef basic_filebuf<char16_t> u16filebuf;
typedef basic_filebuf<char32_t> u32filebuf;

template <class charT, class traits = char_traits<charT> >
class basic_ifstream;
typedef basic_ifstream<char> ifstream;
typedef basic_ifstream<wchar_t> wifstream;
typedef basic_ifstream<char16_t> u16ifstream;
typedef basic_ifstream<char32_t> u32ifstream;

template <class charT, class traits = char_traits<charT> >
class basic_ofstream;
typedef basic_ofstream<char> ofstream;
typedef basic_ofstream<wchar_t> wofstream;
typedef basic_ofstream<char16_t> u16ofstream;
typedef basic_ofstream<char32_t> u32ofstream;

template <class charT, class traits = char_traits<charT> >
class basic_fstream;
typedef basic_fstream<char> fstream;
typedef basic_fstream<wchar_t> wfstream;
typedef basic_fstream<char16_t> u16fstream;
typedef basic_fstream<char32_t> u32fstream;
}

28.4

namespace std {
...
typedef basic_regex<char> regex;
typedef basic_regex<wchar_t> wregex;
typedef basic_regex<char16_t> u16regex;
typedef basic_regex<char32_t> u32regex;

...
typedef sub_match<const char*> csub_match;
typedef sub_match<const wchar_t*> wcsub_match;
typedef sub_match<const char16_t*> u16csub_match;
typedef sub_match<const char32_t*> u16csub_match;
typedef sub_match<string::const_iterator> ssub_match;
typedef sub_match<wstring::const_iterator> wssub_match;
typedef sub_match<u16string::const_iterator> u16ssub_match;
typedef sub_match<u32string::const_iterator> u32ssub_match;

...
typedef match_results<const char*> cmatch;
typedef match_results<const wchar_t*> wcmatch;
typedef match_results<const char16_t*> u16cmatch;
typedef match_results<const char32_t*> u32cmatch;
typedef match_results<string::const_iterator> smatch;
typedef match_results<wstring::const_iterator> wsmatch;
typedef match_results<u16string::const_iterator> u16smatch;
typedef match_results<u32string::const_iterator> u32smatch;

...
typedef regex_iterator<const char*> cregex_iterator;
typedef regex_iterator<const wchar_t*> wcregex_iterator;
typedef regex_iterator<const cha16r_t*> u16cregex_iterator;
typedef regex_iterator<const char32_t*> u32cregex_iterator;
typedef regex_iterator<string::const_iterator> sregex_iterator;
typedef regex_iterator<wstring::const_iterator> wsregex_iterator;
typedef regex_iterator<u16string::const_iterator> u16sregex_iterator;
typedef regex_iterator<u32string::const_iterator> u32sregex_iterator;

...
typedef regex_token_iterator<const char*> cregex_token_iterator;
typedef regex_token_iterator<const wchar_t*> wcregex_token_iterator;
typedef regex_token_iterator<const char16_t*> u16cregex_token_iterator;
typedef regex_token_iterator<const char32_t*> u32cregex_token_iterator;
typedef regex_token_iterator<string::const_iterator> sregex_token_iterator;
typedef regex_token_iterator<wstring::const_iterator>    wsregex_token_iterator;
typedef regex_token_iterator<u16string::const_iterator> u16sregex_token_iterator;
typedef regex_token_iterator<u32string::const_iterator>  u32sregex_token_iterator;
}  
LWG    REJECTED

Previously considered; we decided not to do it. We believe it is not too onerous to use wbuffer_convert and wstring_convert which were added as intermediaries to avoid proliferation of types.  
UK 144
[72]
17.1 ¶ 2   List of contents of library should be extened to cover new clauses   Add "regular expressions, atomic operations and threads"   editor    ACCEPTED  
UK 145
[73]
17.1 ¶ 6   Summary of numeric facilities should mention random numbers   Add random number framework to the list of library facilities   editor    ACCEPTED  
UK 146
[74]
17.1   Add a summary paragraph for regular expressions   Add a summary paragraph for regular expressions   editor    ACCEPTED  
UK 147
[75]
17.1   Add a summary paragraph for threads   Add a summary paragraph for threads   editor    ACCEPTED  
UK 148
[247]
17.2 ¶ Table 12   Table 12 is mentioned in and relates to section 17.2, but has been pushed down to appear directly after the title of section 17.3 which is rather unfortunate/confusing for the reader.   Make sure tables are rendered in the section to which they relate.   editor     
UK 149
[84]
17.3   For consistency with narrow-oriented and wide-oriented streams, we should add terms for streams of Unicode character sequences   Define Utf16-oriented stream classes and Uft32-oriented stream classes for streams of char16_t/char32_t values.   editor    ACCEPTED with MODIFICATIONS

The terms "narrow-oriented iostream classes" and "wide-oriented iostream classes" are never used in the standard (except in a somewhat garbled passage that I have rewritten without them), so rather than proliferate definitions of unused terms, I've removed the original culprits.  
UK 150
[199]
17.3   The addition of move semantics to the language means that many library APIs leave an object in a safely-destructible state, where no other operations can safely be performed unless it is assigned a new value. Library presentation would be simplified and made more precise if we introduce a term for this state. By analogy with singular iterators suggest the term 'singular object' or 'the object is in a singular state'.   Define 'singular state' such that an object with a singular state can only be assigned to or safely destroyed. Assiging a new value typically removes the singular state. Note that objects with a singular state may not be safely copied, so you cannot put an object into a singular state by copying another object in a singular state. Use this new term in the postcondition of all library APIs that move from an rvalue reference. It might also be used to simplify the definition of singular iterator to an iterator value with a singular state.   editor     
UK 151
[77]
17.3.1   Missing crossreference to 17.3.17 [defns.repositional.stream]   Add cross-reference in the existing empty brackets   editor    ACCEPTED with MODIFICATIONS

Removed the reference.  
UK 152
[80]
17.3.12   Object state is using a definition of object (instance of a class) from outside the standard, rather than the 'region of storage' definiton in 1.8p1   Clarify terms and usage   LWG  1064   
UK 153
[82]
17.3.17   If a repositional stream can only seek to a position previously encountered, then an arbitrary-positional-stream cannot satisfy this definition, as cross-referenced in 17.3.17   Strike the word 'only'. A note might be added to reinforce the intent   editor    ACCEPTED  
UK 154
[83]
17.3.20   Missing definition of a stable partition algorithm   Add definition from 25.2.12p7   editor    REJECTED

Since the term "stable partition algorithm" is never used, there is no need to define it. The requirements for the algorithm stable_partition are clear as written.  
UK 155
[78]
17.3.3   Add clause 28 to list that use this definition of character   Add clause 28 to list that use this definition of character   editor    ACCEPTED  
UK 156
[79]
17.3.4   Add regular expressions to set of templates using character container type   Add regular expressions to set of templates using character container type   editor    ACCEPTED  
UK 157
[86]
17.5.2.2 ¶ 3   Add concepts to the ordered list of presentation   Add concepts into the sequence   editor    ACCEPTED  
UK 158
[87]
17.5.2.2 ¶ 3   templates are neither classes nor functions   Replace 'classes' and 'functions' with 'classes and class templates' and 'functions and function templates'   editor    ACCEPTED  
UK 159
[88]
17.5.2.4 ¶ Footnote 152   This informative footnote was relevant in 1998, not 2008. The term 'existing vendors' may imply something different now   Strike the footnote, or replace 'existing' with 'original' or similar   editor    ACCEPTED  
UK 160
[89]
17.5.2.4 ¶ 3   requires is now a keyword with a specific meaning related to concepts, and its use in library specifcation may be confusing. Generally the Requires clause is used to make requirements on the caller, not the library, so typically providing runtime pre-conditions. Suggest a new name to refflect that. Note that Clause 30 already seems to be written to this convention.   Replace 'Requires' with 'Preconditions'   editor     
UK 161
[90]
17.5.2.4 ¶ 4   This paragraph is redundant as the definition of the term 'handler function' is already provided in 17.3. Are we in danger of proving two definitions of the same terms? Which is the 'controlling' definition?   Strike 17.5.2.4p4   editor    REJECTED

17.3 defines "handler function"; 17.5.2.4/4 imposes requirements on handler functions and replacement functions. There is no redundancy.  
UK 162
[170]
17.5.2.4 ¶ 3   Clause 30 makes use of a 'Synchronization' semantic element, that frequently appears either between Effects: and Postconditions:, or between Returns: and Throws:   Add 'Synchronization' to the list either between Effects: and Postconditions:, or between Returns: and Throws:.   editor    ACCEPTED  
UK 163
[219]
17.5.2.4 ¶ 3   Many functions are defined as "Effects: Equivalent to a...", which seems to also define the preconditions, effects, etc. But this is not made clear.   Introduce an explicit "Equivalent to", which defines all of the properties of the function.   LWG  997   
UK 164
[91]
17.5.3.2.1 ¶ 1   This phrasing predates concepts. While this kind of description is still used, the examples provided are now all concepts, and should be replaced with appropriate examples   Use better names for the examples. Ideally totally replace the need by constraining all templates in library, so that real concepts are all that is needed. Note if retained that CopyConstructible is mis-spelled.   editor     
UK 165
[92]
17.5.3.2.2, 17.5.3.2.3   constraints on bitmask and enumation types were supposed to be tightened up as part of the motivation for the constexpr feature - see paper n2235 for deails   Adopt wording in line with the motivation described in N2235   LWG     
UK 166
[93]
17.5.3.2.4.1, 17.5.3.3   List of library clauses should go up to 30, not 27   Replace initial refernce to ch27 with ch30   editor    ACCEPTED  
UK 167
[246]
17.5.3.4 Private members   Comment marker in wrong place.   Change: // streambuf* sb; exposition only to streambuf* sb; // exposition only To reflect actual usage.   editor    ACCEPTED  
UK 168
[406]
17.6.2.2 ¶ 2   We should make it clear (either by note or normatively) that namespace std may contain inline namespaces, and that entities specified to be defined in std may in fact be defined in one of these inline namespaces. (If we're going to use them for versioning, eg when TR2 comes along, we're going to need that.)   Replace "namespace std or namespaces nested within namespace std" with "namespace std or namespaces nested within namespace std or inline namespaces nested directly or indirectly within namespace std"   LWG  1065   
UK 169
[95]
17.6.2.2   This phrasing contradicts later freedom to implement the C standard library portions in the global namespace as well as std. (17.6.2.3p4)   Resolve conflict in either place   LWG  992   
UK 170
[96]
17.6.2.3   One of goals of C++0x is to make language easier to teach and for 'incidental' programmers. The fine-grained headers of the C++ library are valuable in large scale systems for managing dependencies and optimising build times, but overcomplicated for simple development and tutorials. Add additional headers to support the whole library through a single include statement.   Add a new header <std> that has the effect of including everything in tables 13 and 14, except <iosfwd> and <cassert>. Add an additional header <fwd> that adds all declarations from <std> but no definitions.   LWG  1002   
UK 171
[98]
17.6.2.4 ¶ 3   Does freestanding implementation require a full implementation of all listed headers? The reference to abort, at_exit and exit is confusing. Is a conforming implementation allow to deliver partial forms of these headers? If so which ones? Are empty versions of everything but <cstdlib> conforming?   Either strike the references to abort, at_exit and exit, or clarify which headers only require partial support.   editor    ACCEPTED  
UK 172
[99]
17.6.2.4 ¶ 3   No reference to new functions quick_exit and at_quick_exit   Add reference to quick_exit and at_quick_exit   LWG    REJECTED

NAD. We do not belive at_exit and at_quick_exit should be required by freestanding implementations.  
UK 173
[450]
17.6.2.4 ¶ table 15   <initializer_list> is missing from headers required in freestanding implementations.   Add 18.8, initializer lists, <initializer_list>, to the end of the table.   LWG     
JP 23 17.6.2.4 ¶ 2nd para, Table 15   There is a freestanding implementation including <type_traits>, <array>, <ratio>, lately added to Table 13, C++ library headers. Programmers think them useful and hope that these headers are also added to Table 15, C++ headers for freestanding implementations, that shows the set of headers which a freestanding implementation shall include at least.   Add <type_traits>, <array>, <ration> to Table 15.   LWG  1003   
UK 174
[100]
17.6.3.2 ¶ 3   The phrasing is mildly ambiguous when using the word 'it' to refer back to the header - an unfotunate reading might confuse it with the translate unit, which is the subject of the surrounding clause.   Replace 'the first reference to any of the entities declared in that header by the translation unit' with 'the first reference to any of the entities that header declares in the translation unit'   editor    ACCEPTED  
UK 175
[101]
17.6.4.2.1 ¶ 2   Local types can now be used to instantiate templates, but don't have external linkage   Remove the reference to external linkage   LWG    ACCEPTED  
UK 176
[102]
17.6.4.3.3 ¶ Footnote 175   Reference to namespace ::std should be 17.6.4.2   Change referfence from 17.6.4.3 to 17.6.4.2   editor    ACCEPTED with MODIFICATIONS

Removed footnote.  
UK 177
[103]
17.6.4.3.4 ¶ 3   Sentence is redundant as double underscores are reserved in all contexts by 17.6.4.3.3   Strike the sentence   editor    ACCEPTED  
UK 178
[104]
17.6.4.8 ¶ 2   The last sentence of the third bullet "Operations on such types can report a failure by throwing an exception unless otherwise specified" is redundant as behaviour is already undefined.   Strike the sentence   editor    REJECTED

The sentence is not redundant. It points out that the behavior is sometimes circumscribed by a prohibition on throwing exceptions.  
UK 179
[105]
17.6.4.8 ¶ 2   According to the 4th bullet there is a problem if "if any replacement function or handler function or destructor operation throws an exception". There should be no problem throwing exceptions so long as they are caught within the function.   Replace the word 'throws' with 'propogates'   LWG  1004  ACCEPTED  
JP 22 17.6.5.7 ¶ 4th para, 1st line   The statement below describes relation among two or more threads using words “between threads”: [Note: This means, for example, that implementations can’t use a static object for internal purposes without synchronization because it could cause a data race even in programs that do not explicitly share objects between threads. —end note ]

In such case, “among” is preferred instead of “between”.  
Change "between threads" to "among threads".

There are same cases in 17.6.1 paragraph 2, 17.6.5.7 paragraph 6, 30.1 paragraph 1, 30.3.1 paragraph 1 also.  
editor    REJECTED

"Between" expresses one-to-one relations of pairs in a group; "among" refers to collective relations in a group. "Between" is correct here.  
UK 180
[107]
17.6.5.10 ¶ 1, 4   It should not be possible to strengthen the exception specification for virtual functions as this could break user code. Note this is not a problem in practice as there are no virtual functions with exception specifications in the current library, other than empty throw specifications which it is not possible to strengthen.   Add restriction that exception specification of virtual functions cannot be tightened.   LWG    REJECTED

NAD, the standard already has the desired restriction.  
UK 181
[108]
17.6.5.10 ¶ Footnote 186   This footnote is wrong. C library functions do not have any exception specification, but might be treated as if they had an empty throw specification   Clarify that this note does not mean the functions are genuinely declared with the specification, but are treated as-if.   editor    ACCEPTED  
UK 182
[109]
17.6.5.10 ¶ Footnote 188   It is very helpful to assume all exceptions thrown by the standard library derive from std::exception. The 'encouragement' of this note should be made normative.   Make this footnote normative   LWG    REJECTED

NAD. We cannot mandate all standard-library functions that might use some third-party library.  
UK 184
[144]
18 -> 30   The new alias-declaration syntax is generally easier to read than a typedef declaration. This is especially true for complex types like function pointers.   Replace all typedef declarations in the standard library with alias-declarations, except in the standard C library.   editor     
JP 24 18 ¶ 2nd para, Table 16   Subclauses are listed in Table 16 as:

"18.6 Type identification …"

"18.8 Initializer lists …"

"18.7 Exception handling …".  
Sort them in the increasing order "18.6 Type identification …"

"18.7 Exception handling …".

"18.8 Initializer lists …"  
editor    ACCEPTED  
JP 25 18.1 ¶ 6th para , last line, SEE ALSO   max_align_t is described in 18.1, so add 3.11 Alignment as the reference.   Add "3.11, Alignment" to SEE ALSO.   editor    ACCEPTED  
FR 32 18.2.1 [Numeric limits]   The definition of numeric_limits<> as requiring a regular type is both conceptually wrong and operationally illogical. As we pointed before, this mistake needs to be corrected. For example, the template can be left unconstrained. In fact this reflects a much more general problem with concept_maps/axioms and their interpretations. It appears that the current text heavily leans toward experimental academic type theory.   We suggest that a more pragmatic approach, in the spirit of C and C++, be taken so that calls to constrained function templates are interpreted as assertions on *values*, not necessarily semantics assertions on the carrier type.   LWG  902   
DE 16 18.2.1   DE-16 The class template numeric_limits should not specify the Regular concept requirement for its template parameter, because it contains functions returning NaN values for floating-point types; these values violate the semantics of EqualityComparable. See also library issue 902 in WG21 document N2794 "C++ Standard Library Active Issues List (Revision R60)", available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2794.html .   Specify a concept requirement with fewer constraints as appropriate, for example SemiRegular.   LWG  902   
JP 26 18.2.1.1   numeric_limits does not use concept.   Correct as follows.

template<class T> class numeric_limits<const T>;
template<class T> class numeric_limits<volatile T>;
template<class T> class numeric_limits<const volatile T>;

should be

template<Regular T> class numeric_limits<const T>;
template<Regular T> class numeric_limits<volatile T>;
template<Regular T> class numeric_limits<const volatile T>;  
LWG  1005   
DE 17 18.2.6   DE-17 The class type_index should be removed; it provides no additional functionality beyond providing appropriate concept maps.   Specify concept maps for "const type_info *" as required by the ordered and unordered containers and remove the class type_index.   LWG  1078   
UK 185
[264]
18.3.1 ¶ 2   There is no header <stdint>, it should either be <stdint.h> or <cstdint>   Replace <stdint> with <cstdint>   editor    ACCEPTED  
DE 18 18.4   DE-18 The proposed C++ standard makes a considerable number of existing programs that have well-defined behavior according to ISO/IEC 14882:2003 have undefined behavior without a diagnostic hint to the programmer at all. This applies to the presence of threads and to pointer safety (the latter was introduced to support garbage collection). In order to avoid requiring a full code review for user code, facilities should be present that allow the compile-time detection of the advanced features of the proposed C++ standard. It is expected that C++ implementations will provide a means (for example, a command-line switch) to turn off either or both of threads and garbage collection support, turning potentially undefined programs into well-defined ones. Note: This issue is contributing significantly to Germany's overall “no” vote.   Consider applying the changes proposed in WG21 document N2693 "Requirements on programs and backwards compatibility", available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html .   LWG     
UK 186
[265]
18.4 ¶ Footnote 221   What is the purpose of this comment? The standard stream objects (cin, cerr etc.) have a peculiar lifetime that extends beyond the program. They may never be destroyed so will not be responsible for flushing buffers at the stated time.   Remove the footnote   editor    ACCEPTED  
UK 187
[266]
18.4 ¶ 9   The term "thread safe" is not defined nor used in this context anywhere else in the standard.   Clarify the intended meaing of "thread safe"   LWG     
UK 188
[267]
18.4 ¶ 12   The function _Exit does not appear to be defined in this standard. Should it be added to the table of functions included-by-reference to the C standard?   Depends on where _Exit comes from   LWG  993  ACCEPTED  
UK 189
[273]
18.4, 18.7   The addition of the [[noreturn]] attribute to the language will be an important aid for static analysis tools.   The following functions should be declared in C++ with the [[noreturn]] attribute: abort exit quick_exit terminate unexpected rethrow_exception throw_with_nested   LWG  1066  ACCEPTED  
JP 27 18.4, 18.9, 18.7.2.2, 18.7.3.1   There are Standard library functions that never return to the caller. They are explained so in the Standard but not declared explicitly.   Consider to add the attribute [[noreturn]] to such functions,



15.5.2 unexpected 18.4: abort(), exit(), quick_exit, 18.7.2.2: unexpected_handler, 18.7.3.1: terminate_handler,

18.7.6 rethrow_nested

18.7.6 throw_with_nested 18.9: longjmp.  
LWG     
UK 190
[268]
18.5.1 ¶ various   It is not entirely clear how the current specification acts in the presence of a garbage collected implementation.   All deallocation functions taking a pointer parameter should have a Precondition : ptr is a safely-derived pointer value.   LWG  1006  ACCEPTED  
UK 191
[271]
18.5.1.1 ¶ 4   According to the second bullet, behaviour becomes undefined (for lack of a specification) if the user has not yet called set_new_handler.   Rephrase the second bullet in terms of a new handler being installed, and update any definition of handler function necessary to be sure the term 'installed' is defined.   editor    ACCEPTED with MODIFICATIONS

Reworded, but not with "installed".  
UK 192
[269]
18.5.1.2   The declared signature is not compatible with the current requirement to throw std::length_error. It is too late to weaken the exception specification, so the only other change is to preserve new (improved) behaviour is to throw std::bad_alloc, or something derived from std::bad_alloc.   Fix 5.3.4p7 by required std::bad_alloc rather than std::length_error   CWG  805   
UK 193
[272]
18.5.2.2 ¶ 2   quick_exit has been added as a new valid way to terminate a program in a well defined way   Change 3rd bullet: call either abort(), exit() or quick_exit();   LWG  994   
UK 194
[443]
18.6   The inclusion of type_index and hash<type_index> in <typeinfo> brings dependencies into <typeinfo> which are inconsistent with the definition of freestanding C++ in 17.6.2.4.   Move type_index and hash<type_index> out of <typeinfo> and into a new header, <typeindex>.   LWG     
JP 28 18.6, 18.7, 19.1   Errors reported by Exception classes are of types char or std::string only. For example, std::exception is declared with char, std::string types, therefore types wchar_t/wstring, char16_t/u16string, or char32_t/u32string can not be used.   Consider other types.   LWG    REJECTED

NAD. There is already guidance in the CD. It is the caller's responsibility to internationalize MB character string.  
JP 29 18.7.6   throw_with_nested does not use concept.   Correct as follows.

template<class T> void throw_with_nested(T&& t); // [[noreturn]]



should be



template<CopyConstructible T> void throw_with_nested(T&& t); // [[noreturn]]  
LWG  1007   
JP 30 18.7.6   To handle nested exceptions strictly, error information of tree structure will be required though, the nested_exception does not support tree structure. It is insufficient as error handling.   Consider nested_exception to support tree structure.   LWG     
JP 31 18.7.6   It is difficult to understand in which case nested_exception is applied.   Consider to add a sample program which rethrows exception.   LWG  1008   
UK 195
[451]
18.8   The class definition of std::initializer_list contains concept-maps to Range which should be out of the class, and in <iterator_concepts> instead. Otherwise, it's not possible to use initializer_lists in a freestanding C++ implementation.   Delete the two concept maps from std::initializer_list.   LWG     
UK 196
[452]
18.8.3   Concept maps for initializer_list to Range should not be in language support headers, but instead in iterator concepts.   Remove section 18.8.3 and put it in 24.1.8.1 instead, so that the concept_maps from initializer_list to Range are specified under Range instead of under initializer lists; also, so that they're implemented in <iterator_concepts> instead of <initializer_list>.   LWG     
UK 197
[275]
19   All the exception classes in this clause take a std::string argument by const reference. They should all be overloaded to accept std::string by rvalue rerefence for an efficient move as well.   Provide a constructor for every exception class in clause 19 accepting a std::string by rvalue reference, with the semantics that the passed string may be moved.   LWG    REJECTED

NAD. Implementations are permitted to add the requested signature under the as-if rule. See clause 17.  
JP 32 19.1   Messages returned by the member function what() of standard exception classes seem difficult to judge.

For example, following messages are returned by what() of std::bad_alloc of existing implementations:



Compiler: Message returned by what()

---------------------------------------------

Borland C++ 5.6.4: no named exception thrown

Visual C++ 8.0: bad allocation

Code Warrior 8.0: exception

g++ 3.4.4: St9exception



It is difficult to recognize what exception was thrown when using those compilers except Visual C++.  
Consider to add footnote that recommends what() returns message easy to recognize what exception was thrown.   LWG    REJECTED

NAD. This is a quality of implementation issue that is beyond the scope of the standard.  
US 64 19.3 ¶ 1   See also: ISO C 7.1.4, 7.2, Amendment 1 4.3.” It is unclear why this cross reference is here. Amendment 1 was to C89, not C99.   Delete this cross reference. If necessary, expand the main text to include the relevant referenced text   editor    ACCEPTED  
US 65 20   Scoped allocators and allocator propagation traits add a small amount of utility at the cost of a great deal of machinery. The machinery is user visible, and it extends to library components that don't have any obvious connection to allocators, including basic concepts and simple components like pair and tuple.   Sketch of proposed resolution: Eliminate scoped allocators, replace allocator propagation traits with a simple uniform rule (e.g. always propagate on copy and move), remove all mention of allocators from components that don't explicitly allocate memory (e.g. pair), and adjust container interfaces to reflect this simplification.

Components that I propose eliminating include HasAllocatorType ?, is_scoped_allocator, allocator_propagation_map, scoped_allocator_adaptor, and ConstructibleAsElement ?.  
LWG  1075   
UK 198
[126]
20   The organization of clause 20 could be improved to better group related items, making the standard easier to navigate.   20.6.7, 20.6.8, 20.6.9 and 20.6.10 should be grouped under a section called "operator wrappers" or similar. The goal of all 4 subsections combined is to provide a functor for every operator in the language. 20.6.17 class template hash should numerically appear immediately after the operator wrappers, as they are functors that are used in similar ways 20.6.11, 20.6.12, 20.6.13, 20.6.14, 20.6.15 are strongly related to 20.6.3, and to an extent 20.6.2. These should all come under a subheading of "function adapters" 20.7.1, 20.7.3, 20.7.4, 20.7.5, 20.7.6, 20.7.7 and 20.7.10 should all be grouped as subclauses under [20.7.2 Allocators] [20.7.12 unique_ptr] should be a sub-section of [20.7.13 smart pointers] [20.7.13 smart pointers] is important enough to have a high level bullet after [20.7 memory], suggest renumbering as [20.8 smart pointers] [20.7.13.7 Pointer safety] is nothing to do with smart pointers and should become its own subclause [20.7.14 Pointer safety] [20.9 date and time functions] should be moved under [20.8 time utilities] and retitled [20.8.6 C Library] (as per memory management/C Library) [20.6.18 reference_closure] is fundamentally a language support feature and should move to clause 18, see separate comment [20.6.5 reference_wrapper] should be simplified and moved into [2.2 utility components], see separate comment [20.6.4 result_of] should be reorganised as a type trait - see separate comment Tuples and pairs are closely related so merge tuple and pair into the same subclause - see more general comment on this   editor     
UK 199
[127]
20.1.1, 20.1.2 ¶ 2   The requirement that programs do not supply concept_maps should probably be users do not supply their own concept_map specializations. THe program will almost certainly supply concept_maps - the standard itself supplies a specialization for RvalueOf? references. Note that the term _program_ is defined in 3.5p1 and makes no account of the standard library being treated differently to user written code.   Replace the term 'program' with 'user'.   LWG  1015  ACCEPTED  
UK 200
[354]
20.1.4   All standard library use expects Predicates to be CopyConstructible, and this should be recognised easily without reatedly stating on every use-case.   Either require CopyConstructible<F> as part of Predicate, or create a refined concept, StdPredicate, used throughout the library that requires CopyConstructible as well as Callable. Consider making (Std)Predicate SemiRegular.   LWG    REJECTED

After further discussion of UK200, we do not think adding constraints to predicates is a good idea. Straw poll on UK200: status quo, 5 pro - 2 con; remove copy-constructible, 3 pro - 4 con; pred must be copy-constructible, 4 pro - 3 con; no consensus for moving away from the status quo.

Also see UK245.  
UK 201
[290]
20.1.5   The Consistency axiom for LessThanComparable will not compile.   Add a requires clause to the Consistency axiomL requires HasLessEquals<T> && HasGreaterEquals<T>, or split the Consistency axiom into two so that 'basic' consistency can be asserted regardless of the <=/>= requirement.   LWG    REJECTED

After consultation with the submitter, we agreed that the suggestion was in error and there is nothing else to be done.  
JP 33 20.1.5   LessThanComparable and EqualityComparable don't correspond to NaN.   Apply concept_map to these concepts at FloatingPointType   LWG  1016   
US 66 20.1.10   Application of the "Regular" concept to floating-point types appears to be controversial (see long discussion on std-lib reflector).   State that the “Regular” concept does not apply to floating-point types.   LWG  1017   
JP 34 20.2 ¶ 1st para, 4th line   Though N2672 pointed at adding "#include<initializer_list>", it isn't reflected.   add followings

#include <initializer_list> // for concept_map  
editor    ACCEPTED  
US 67 20.2.1 ¶ 5 first sent.   Some connective words are missing.   Insert “corresponding to” before “an lvalue reference type.”   editor    ACCEPTED with MODIFICATIONS  
JP 35 20.2.3 ¶ 6th para, 1st line   Typo,

"stdforward" should be "std::forward"  
Correct typo.   editor    ACCEPTED  
UK 202
[213]
20.2.4   The references to pair in the tuple-like access to pair functions qualify pair with std::pair even though they are in a namespace std block.   Remove the std:: qualification from these references to pair.   editor    ACCEPTED  
US 68 20.1.12 ¶ IntegralLike   The code defining the context is syntactically incorrect.   Insert a comma in two places: at the end of the third line of refinements, and at the end of the fourth line of refinements.   editor    ACCEPTED

Section reference corrected from 20.2.12.  
UK 203
[229]
20.3.2 ¶ 1-4   The ratio_xyz types have a misplaced '}'. For example: template <class R1, class R2> struct ratio_add { typedef see below} type; ;   Move the '}' to after the typedef: template <class R1, class R2> struct ratio_add { typedef see below type; };   editor    ACCEPTED  
JP 36 20.4.2.1 ¶ 19th para, 6th line   Typo.

"it it" should be "it is"  
Correct typo.   editor    ACCEPTED  
UK 204
[239]
20.5.7 [meta.trans.other] ¶ Table 41   It is not possible to create a variant union based on a parameter pack expansion, e.g. to implement a classic discriminated union template.   Restore aligned_union template that was removed by LWG issue 856.   LWG  1020  ACCEPTED

Section reference corrected from 20.5.  
US 69 20.5   This section, dealing with tuple<>, should be in the same section as the similar utility pair<>.   Restructure Clause 20 so as to bring these similar components together.   editor     
UK 205
[253]
20.5.3   integral_constant objects should be usable in integral-constant-expressions. The addition to the language of literal types and the enhanced rules for constant expressions make this possible.   Add a constexpr conversion operator to class tempalate integral_constant: constexpr operator value_type() { return value; }   LWG  1019  ACCEPTED  
UK 206
[255]
20.5.5 ¶ para 4   Currently the std says: "In order to instantiate the template is_convertible<From, To>, the following code shall be well formed:" But the code shown is the requirement for the result of is_convertible to be a true_type, not a precondition on whether the template can be instantiated.   Change: "In order to instantiate the template is_convertible<From, To>, the following code shall be well formed:" To: "The template is_convertible<From, To> inherits either directly or indirectly from true_type if the following code is well formed:"   LWG    ACCEPTED  
UK 207
[256]
20.5.6.1 ¶ Table 36   suffix "::type" is missing from the some of the examples.   Change: Example:remove_const<const volatile int>::type evaluates to volatile int, whereas remove_const<const int*> is const int*. —end example To: Example:remove_const<const volatile int>::type evaluates to volatile int, whereas remove_const<const int*>::type is const int*. —end example And change: Example:remove_volatile<const volatile int>::type evaluates to const int, whereas remove_volatile<volatile int*> is volatile int*. —end example To: Example:remove_volatile<const volatile int>::type evaluates to const int, whereas remove_volatile<volatile int*>::type is volatile int*. —end example And change: Example:remove_cv<const volatile int>::type evaluates to int, whereas remove_cv<const volatile int*> is const volatile int*. —end example To: Example:remove_cv<const volatile int>::type evaluates to int, whereas remove_cv<const volatile int*>::type is const volatile int*. —end example   editor    ACCEPTED  
JP 37 20.5.7 ¶ Table 41   Typo.

There isn't a period at the end of enable_if's comments.



If B is true, the member typedef type shall equal T; otherwise, there shall be no member typedef type



should be



If B is true, the member typedef type shall equal T; otherwise, there shall be no member typedef type.  
Add ”.”   editor    ACCEPTED  
US 70 20.5   Specifications now expressed via narrative text are more accurately and clearly expressed via executable code.   Wherever concepts are available that directly match this section’s type traits, express the traits in terms of the concepts instead of via narrative text. Where the type traits do not quite match the corresponding concepts, bring the two into alignment so as to avoid two nearly-identical notions.   LWG  1018  Section reference corrected from 20.6.  
US 71 20.6.7 ¶ Table 51, last row, column 3   The grammar is incorrect.   Change “conversion are” to “conversion is”.   editor    ACCEPTED with MODIFICATIONS

"conversions are" is correct.  
JP 38 20.6.12.1.3   add the move requirement for bind's return type.

For example, assume following th1 and th2,

void f(vector<int> v) { } vector<int> v{ ... }; thread th1([v]{ f(v); }); thread th2(bind(f, v)); When function object are set to thread, v is moved to th1's lambda expression in a Move Constructor of lambda expression becuase th1's lambda expression has a Move Constructor. But bind of th2's return type doesn't have the requirement of Move, so it may not moved but copied.

Add the requirement of move to get rid of this useless copy.

And also, add the MoveConstructible as well as CopyConstructible.  
Add the following requirements. "it has a public move constructor that performs a member-wise move."

Add the MoveConstructible.  
LWG  817   
JP 39 20.6.16.2   There are no requires corresponding to F of std::function.   Correct as follows.

template<class F, Allocator A> function(allocator_arg_t, const A&, F);
template<class F, Allocator A> function(allocator_arg_t, const A&, F&&);

should be

template<class F, Allocator A>
requires CopyConstructible<F> && Callable<F, ArgTypes...>
&& Convertible<Callable<F, ArgTypes...>::result_type, R>
function(allocator_arg_t, const A&, F);
template<class F, Allocator A>
requires CopyConstructible<F> && Callable<F, ArgTypes...>
&& Convertible<Callable<F, ArgTypes...>::result_type, R>
function(allocator_arg_t, const A&, F&&);  
LWG  1024  ACCEPTED with MODIFICATIONS  
JP 40 20.6.16.2   Thougn it's "Allocator Aloc" at other places, it's "Allocator A" only std::function constructor template parameter.   Correct as follows.

template<class F, Allocator A> function(allocator_arg_t, const A&, F);

template<class F, Allocator A> function(allocator_arg_t, const A&, F&&);



should be



template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc &, F);

template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc &, F&&);  
editor    ACCEPTED  
JP 41 20.6.16.2   There are no requires corresponding to R and Args of UsesAllocator.   Correct as follows.

template <class R, class... Args>
concept_map UsesAllocator<function<R(Args...)>, Alloc> {
typedef Alloc allocator_type;
}

should be

template <Returnable R, CopyConstructible... Args>
concept_map UsesAllocator<function<R(Args...)>, Alloc> {
typedef Alloc allocator_type;
}  
LWG    REJECTED

This change would be redundant because function<> is already sufficiently constrained. No actions necessary.  
JP 42 20.6.16.2   The requires are wrong.

R require Returnable, and ArgTypes requires CopyConstructible by a definition of function, then it's a mistake to designate followings by MoveConstructible.  
Correct as follows.

template <MoveConstructible R, MoveConstructible... ArgTypes>
bool operator==(const function<R(ArgTypes...)>&, nullptr_t);
template <MoveConstructible R, MoveConstructible... ArgTypes>
bool operator==(nullptr_t, const function<R(ArgTypes...)>&);
template <MoveConstructible R, MoveConstructible... ArgTypes>
bool operator!=(const function<R(ArgTypes...)>&, nullptr_t);
template <MoveConstructible R, MoveConstructible... ArgTypes>
bool operator!=(nullptr_t, const function<R(ArgTypes...)>&);
template <MoveConstructible R, MoveConstructible... ArgTypes>
void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);

should be

template <Returnable R, CopyConstructible... ArgTypes>
bool operator==(const function<R(ArgTypes...)>&, nullptr_t);
template <Returnable R, CopyConstructible... ArgTypes>
bool operator==(nullptr_t, const function<R(ArgTypes...)>&);
template <Returnable R, CopyConstructible... ArgTypes>
bool operator!=(const function<R(ArgTypes...)>&, nullptr_t);
template <Returnable R, CopyConstructible... ArgTypes>
bool operator!=(nullptr_t, const function<R(ArgTypes...)>&);
template <Returnable R, CopyConstructible... ArgTypes>
void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);  
editor    ACCEPTED  
UK 208
[338]
20.6.17 ¶ 1   std::hash should be implemented for much more of the standard library. In particular for pair, tuple and all the standard containers.   .   LWG    REJECTED

NAD. Consensus is that this is an expansion beyond the scope of C++0X.  
UK 209
[111]
20.7   Smart pointers cannot be used in constrained templates   Provide constraints for smart pointers   LWG  1026   
UK 213
[357]
20.7.6   std::allocator should be constrained to simplify its use on constrained contexts. This library component models allocation from free store via the new operator so choose constraints to match. The Allocator concept allows for a wider variety of allocators that users may choose to supply if their allocation model does not require operator new, without impacting the requirements of this template.   The primary allocator template should be constrained to require ObjectType<T> and FreeStoreAllocatable<T>. Further operations to be constrained as required.   LWG  1027  ACCEPTED  
UK 214
[125]
20.7.8   raw_storage_iterator needs constraining as an iterator adaptor to be safely used in constrained templates   Constrain the raw_storage_iterator template   LWG  1028   
UK 210
[124]
20.7.11   Specialized algorithms for memory managenment need requirements to be easily usable in constrained templates   Provide constraints for all algorithms in 20.7.11   LWG  1029   
DE 20 20.6.12   DE-20 The section heading and the first sentence use the term "template function", which is undefined.   Replace "template function" by "function template".   editor    ACCEPTED

Section reference corrected from 20.7.12.  
US 72 20.6.12.1.3 [func.bind.bind]   bind should support move-only functors and bound arguments.     LWG  817  Section reference corrected from 20.7.12.  
DE 21 20.6.12.1.3 [func.bind.bind]   DE-21 The specification for bind claims twice that "the values and types for the bound arguments v1, v2, ..., vN are determined as specified below". No such specification appears to exist.   Add the missing specification in the same section, or add a cross-reference indicating the section where the specification appears.   LWG  817  ACCEPTED

Section reference corrected from 20.7.12.1.3.  
UK 211
[428]
20.6.12.2.3 [unique.ptr.single.asgn] ¶ 11   The nullptr_t type was introduced to resolve the null pointer literal problem. It should be used for the assignemnt operator, as with the constructor and elsewhere through the library.   Change signature here and in the synopsis to: unique_ptr& operator=(nullptr_t); Strike the sentance an note before the Effects clause.   LWG  1021  ACCEPTED

Section reference corrected from 20.7.12.2.3.  
UK 212
[270]
20.6.13.7 [util.dynamic.safety]   The pointer-safety API is nothing to do with smart pointers, so does not belong in 20.7.13. In fact it is a set of language support features are really belongs in clause 18, with the contents declared in a header that deals with language-support of memory management.   Move this specification to 18.5. Move the declarations into the header <new>.   LWG    ACCEPTED with MODIFICATIONS

Section reference corrected from 20.7.13.7.  
DE 22 20.6.16.2 [func.wrap.func]   DE-22 The conditions for deriving from std::unary_function and std::binary_function are unclear: The condition would also be satisfied if ArgTypes were std::vector<T1>, because it (arguably) "contains" T1.   Consider stating the conditions in normative prose instead of in comments in the class definition. Use "consists of" instead of "contains". Consider using "if and only if" instead of "iff".   LWG  1023  ACCEPTED

Section reference corrected from 20.7.16.2.  
US 73 20.6.18   The std::reference_closure template is redundant with std::function and should be removed.



std::reference_closure is a premature optimization that provides a limited subset of the functionality of std::function intended to improve performance in a narrow use case. However, the “parallel application performance” benchmark used to motivate the inclusion of std::reference_closure was flawed in several ways:


  1. it failed to enable a common optimization in std::function (implemented by all vendors), exacting a large and unrealistic penalty for copying std::function instances, and


  2. it failed to account for parallel scheduler overhead or realistically-sized work units, both of which would dominate the costs measured by the benchmark in any realistic application.
 
Remove 20.7.18 [func.referenceclosure].



Remove 5.1.1 paragraph 12.  
CWG  750  ACCEPTED

Section reference corrected from 20.7.18.

See paper N2845 
US 74.1 20.8   Scoped allocators represent a poor trade-off for standardization, since (1) scoped-allocator--aware containers can be implemented outside the C++ standard library but used with its algorithms, (2) scoped allocators only benefit a tiny proportion of the C++ community (since few C++ programmers even use today’s allocators), and (3) all C++ users, especially the vast majority of the C++ community that won’t ever use scoped allocators are forced to cope with the interface complexity introduced by scoped allocators. In essence, the larger community will suffer to support a very small subset of the community who can already implement their own data structures outside of the standard library. Therefore, scoped allocators should be removed from the working paper.

Some evidence of the complexity introduced by scoped allocators:

20.3.3, 20.5: large increase in the number of pair and tuple constructors

23: confusing “AllocatableElement” requirements throughout.  
Remove support for scoped allocators from the working paper. This includes at least the following changes:



Remove 20.8.3 [allocator.element.concepts]



Remove 20.8.7 [allocator.adaptor]



Remove 20.8.10 [construct.element]



In Clause 23: replace requirements naming the AllocatableElement concept with requirements naming CopyConstructible, MoveConstructible, DefaultConstructible, or Constructible, as appropriate.  
LWG  1075  See paper N2840 
US 74.2 20.8.2.2 ¶ (a) synopsis (b) after ¶ 14   A concept name is twice misspelled.   Change “Hasconstructor” to “HasConstructor” (twice).   editor    ACCEPTED with MODIFICATIONS

The text in question is in 20.7.2.2, not 20.8.2.2.  
US 75 20.8.2.2   Allocator concepts are incomplete   See paper: http://www.halpernwightsoftware.com/WG21/n2810_allocator_defects.pdf   LWG    ACCEPTED with MODIFICATIONS

See paper N2840 
JP 43 20.8.3   Typo.

"alloc" should be "Alloc"  
Correct as follows.



auto concept UsesAllocator<typename T, typename Alloc> {

requires Allocator<alloc>;

typename allocator_type = T::allocator_type;



should be



auto concept UsesAllocator<typename T, typename Alloc> {

requires Allocator<Alloc>;

typename allocator_type = T::allocator_type;  
editor    ACCEPTED  
UK 215
[356]
20.8.3.3 ¶ 6,8   Extra pair of {}, presumably some formatting code gone awry : duration& operator-{-}();   Remove the {} or fix formatting   editor    ACCEPTED  
US 77 20.8.4   Allocator-specific move and copy behavior for containers (N2525) complicates a little-used and already-complicated portion of the standard library (allocators), and breaks the conceptual model of move-constructor and move-assignment operations on standard containers being efficient operations. The extensions for allocator-specific move and copy behavior should be removed from the working paper.

With the introduction of rvalue references, we are teaching programmers that moving from a standard container (e.g., a vector<string>) is an efficient, constant-time operation. The introduction of N2525 removed that guarantee; depending on the behavior of four different traits (20.8.4), the complexity of copy and move operations can be constant or linear time. This level of customization greatly increases the complexity of standard containers, and benefits only a tiny fraction of the C++ community.  
Remove 20.8.4.



Remove 20.8.5.



Remove all references to the facilities in 20.8.4 and 20.8.5 from clause 23.  
LWG     
US 78 20.8.12, 20.8.13.2   There is presently no way to convert directly from a shared_ptr to a unique_ptr.   Add an interface that performs the conversion. See the attached, Issues with the C++ Standard" paper under Chapter 20, "Conversion from shared_ptr to unique_ptr".   LWG  1031   
US 79 20.8.12.2.1   [unique.ptr.single.ctor]/5 no longer requires for D not to be a pointer type. This restriction needs to be put back in. Otherwise we have a run time failure that could have been caught at compile time:



unique_ptr<int, void(*)(void*)> p(malloc(sizeof(int))); // should not compile



unique_ptr<int, void(*)(void*)> p(malloc(sizeof(int)), free); // ok  
&