<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>

    C++ Standard Core Language
    
      Active Issues
     </TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Document number:
     </TD>
<TD>
        &#160;PL22.16/11-0006 = WG21 N3236</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2011-02-28</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Project:
     </TD>
<TD>
      &#160;Programming Language C++
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reference:
     </TD>
<TD>
      &#160;ISO/IEC IS 14882:2003
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reply to:
     </TD>
<TD>
      &#160;William M. Miller
     </TD>
</TR>
<TR>
<TD></TD>
<TD>
      &#160;Edison Design Group, Inc.
     </TD>
</TR>
<TR>
<TD></TD>
<TD>
      &#160;<A HREF="mailto://wmm@edg.com">wmm@edg.com</A></TD>
</TR>
</TABLE><BR CLEAR="ALL"><BR><CENTER>
<H2>

     C++ Standard Core Language
     
       Active Issues,
      

     Revision
     75</H2>
</CENTER><BR><P>
      This document contains the C++ core language issues on which the
      Committee (J16 + WG21) has not yet acted, that is, issues
      with status
      "<A HREF="#Ready Status">Ready</A>,"
      "<A HREF="#Tentatively Ready Status">Tentatively Ready</A>,"
      "<A HREF="#Review Status">Review</A>,"
      "<A HREF="#Drafting Status">Drafting</A>," and
      "<A HREF="#Open Status">Open</A>."
     </P>
<P>
    This document is part of a group of related documents that
    together describe the issues that have been raised regarding the
    C++ Standard.  The other documents in the group are:
   </P>
<UL>
<LI><A HREF="cwg_closed.html">Closed Issues List</A>, which contains
      the issues which the Committee has decided are not defects
      in the International Standard, including a brief rationale
      explaining the reason for the decision.
     </LI>
<LI><A HREF="cwg_defects.html">Defect Reports List</A>, which contains
      the issues that have been categorized by the Committee as Defect
      Reports, along with their proposed resolutions.
     </LI>
<LI><A HREF="cwg_toc.html">Table of Contents</A>, which contains a
     summary listing of all issues in numerical order.
    </LI>
<LI><A HREF="cwg_index.html">Index by Section</A>, which contains a
     summary listing of all issues arranged in the order of the
     sections of the Standard with which they deal most directly.
    </LI>
<LI><A HREF="cwg_status.html">Index by Status</A>, which contains a
     summary listing of all issues grouped by status.
    </LI>
</UL>
<P>
    Section references in this document reflect the section numbering
    of document
    <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3225.pdf">PL22.16/10-0215 = WG21 N3225</A>.
   </P>
<P>The purpose of these documents is to record the disposition of issues
that have come before the Core Language Working Group of the ANSI
(INCITS PL22.16) and ISO (WG21) C++ Standard Committee.</P>

<P>Some issues represent potential defects in the ISO/IEC IS 14882:2003
document and corrected defects in the earlier ISO/IEC 14882:1998 document;
others refer to text in the working draft for the next revision of the
C++ language, informally known as C++0x, and not to any Standard text.
Issues are not necessarily formal ISO Defect Reports (DRs).
While some issues will eventually be elevated to DR status, others
will be disposed of in other ways.  (See <A HREF="#Issue Status">Issue
Status</A> below.)</P>



<P>The most current public version of this document can be found at
<A HREF="http://www.open-std.org/jtc1/sc22/wg21">http://www.open-std.org/jtc1/sc22/wg21</A>. 
Requests for further information about these documents should include
the document number, reference ISO/IEC 14882:2003, and be
submitted to the InterNational Committee for Information Technology Standards
(INCITS),
1250&#160;Eye&#160;Street&#160;NW, Suite 200, Washington,&#160;DC&#160;20005,
USA.</P>

<P>Information regarding how to obtain a copy of the C++ Standard,
join the Standard Committee, or submit an issue
can be found in the C++ FAQ at
<A HREF="http://www.comeaucomputing.com/csc/faq.html">http://www.comeaucomputing.com/csc/faq.html</A>.
Public discussion of the C++ Standard and related issues occurs on
newsgroup <A HREF="news:comp.std.c++">comp.std.c++</A>.</P>

<BR>
<H3>Revision History</H3>

<UL>

<LI><B>Revision 75, 2011-02-28:</B>&gt;Reflected results of two
between-meetings teleconferences, including moving a number of issues
to "tentatively ready" status.  Added drafting for a number of issues
and moved them to "review" status.  Reopened <A HREF="
     cwg_active.html#109">issue 109</A> in light of recent discussion.  Moved <A HREF="
     cwg_active.html#1028">issue 1028</A> back to "open" status after further analysis.  Moved
issues <A HREF="
     cwg_defects.html#1109">1109</A> and <A HREF="
     cwg_defects.html#1127">1127</A>
to "DR" status, as they had been overlooked in the results of the
November, 2010 (Batavia) meeting.  Added new issues
<A HREF="
     cwg_active.html#1227">1227</A>,
<A HREF="
     cwg_active.html#1228">1228</A>,
<A HREF="
     cwg_active.html#1229">1229</A>,
<A HREF="
     cwg_active.html#1230">1230</A>,
<A HREF="
     cwg_active.html#1231">1231</A>,
<A HREF="
     cwg_active.html#1232">1232</A>,
<A HREF="
     cwg_active.html#1233">1233</A>,
<A HREF="
     cwg_active.html#1234">1234</A>,
<A HREF="
     cwg_active.html#1235">1235</A>,
<A HREF="
     cwg_active.html#1236">1236</A>,
<A HREF="
     cwg_active.html#1237">1237</A>,
<A HREF="
     cwg_active.html#1238">1238</A>,
<A HREF="
     cwg_active.html#1239">1239</A>,
<A HREF="
     cwg_active.html#1240">1240</A>,
<A HREF="
     cwg_active.html#1241">1241</A>,
<A HREF="
     cwg_active.html#1242">1242</A>,
<A HREF="
     cwg_active.html#1243">1243</A>,
<A HREF="
     cwg_active.html#1244">1244</A>,
<A HREF="
     cwg_active.html#1245">1245</A>, and
<A HREF="
     cwg_active.html#1246">1246</A>.
</LI>

<LI><B>Revision 74, 2010-11-29:</B> Reflected deliberations at the
November, 2010 (Batavia) meeting.  Added new issues
<A HREF="
     cwg_active.html#1211">1211</A>,
<A HREF="
     cwg_active.html#1212">1212</A>,
<A HREF="
     cwg_active.html#1213">1213</A>,
<A HREF="
     cwg_active.html#1214">1214</A>,
<A HREF="
     cwg_active.html#1215">1215</A>,
<A HREF="
     cwg_active.html#1216">1216</A>,
<A HREF="
     cwg_closed.html#1217">1217</A>,
<A HREF="
     cwg_active.html#1218">1218</A>,
<A HREF="
     cwg_active.html#1219">1219</A>,
<A HREF="
     cwg_active.html#1220">1220</A>,
<A HREF="
     cwg_active.html#1221">1221</A>,
<A HREF="
     cwg_active.html#1222">1222</A>,
<A HREF="
     cwg_active.html#1223">1223</A>,
<A HREF="
     cwg_active.html#1224">1224</A>,
<A HREF="
     cwg_active.html#1225">1225</A>, and
<A HREF="
     cwg_active.html#1226">1226</A>.
</LI>

<LI><B>Revision 73, 2010-10-18:</B> Moved issues
<A HREF="
     cwg_defects.html#994">994</A> and <A HREF="
     cwg_active.html#1058">1058</A>
back to "open" status for potential reconsideration. Added analysis to
<A HREF="
     cwg_active.html#1038">issue 1038</A>. Moved issues
<A HREF="
     cwg_defects.html#1125">1125</A> and <A HREF="
     cwg_defects.html#1127">1127</A>
back to "drafting" status after further discussion revealed problems
with the proposed resolution approved at the August, 2010 meeting.
Moved <A HREF="
     cwg_active.html#1167">issue 1167</A> to "review" status to
allow consideration of extending the resolution to cover a new but
related question. Reflected results of two between-meetings teleconferences,
including moving a number of issues to "tentatively ready" status.
Added new issues
<A HREF="
     cwg_active.html#1174">1174</A>,
<A HREF="
     cwg_active.html#1175">1175</A>,
<A HREF="
     cwg_active.html#1176">1176</A>,
<A HREF="
     cwg_active.html#1177">1177</A>,
<A HREF="
     cwg_active.html#1178">1178</A>,
<A HREF="
     cwg_closed.html#1179">1179</A>,
<A HREF="
     cwg_active.html#1180">1180</A>,
<A HREF="
     cwg_active.html#1181">1181</A>,
<A HREF="
     cwg_active.html#1182">1182</A>,
<A HREF="
     cwg_active.html#1183">1183</A>,
<A HREF="
     cwg_active.html#1184">1184</A>,
<A HREF="
     cwg_active.html#1185">1185</A>,
<A HREF="
     cwg_active.html#1186">1186</A>,
<A HREF="
     cwg_active.html#1187">1187</A>,
<A HREF="
     cwg_active.html#1188">1188</A>,
<A HREF="
     cwg_active.html#1189">1189</A>,
<A HREF="
     cwg_active.html#1190">1190</A>,
<A HREF="
     cwg_active.html#1191">1191</A>,
<A HREF="
     cwg_active.html#1192">1192</A>,
<A HREF="
     cwg_active.html#1193">1193</A>,
<A HREF="
     cwg_active.html#1194">1194</A>,
<A HREF="
     cwg_active.html#1195">1195</A>,
<A HREF="
     cwg_active.html#1196">1196</A>,
<A HREF="
     cwg_active.html#1197">1197</A>,
<A HREF="
     cwg_active.html#1198">1198</A>,
<A HREF="
     cwg_active.html#1199">1199</A>,
<A HREF="
     cwg_active.html#1200">1200</A>,
<A HREF="
     cwg_active.html#1201">1201</A>,
<A HREF="
     cwg_active.html#1202">1202</A>,
<A HREF="">1203</A>,
<A HREF="
     cwg_active.html#1204">1204</A>,
<A HREF="">1205</A>,
<A HREF="
     cwg_active.html#1206">1206</A>,
<A HREF="
     cwg_active.html#1207">1207</A>,
<A HREF="
     cwg_active.html#1208">1208</A>,
<A HREF="
     cwg_active.html#1209">1209</A>, and
<A HREF="
     cwg_active.html#1210">1210</A>,
</LI>

<LI><B>Revision 72, 2010-08-23:</B> Reflected deliberations at the
August, 2010 (Rapperswil) meeting. Added new issues
<A HREF="
     cwg_active.html#1091">1091</A>,
<A HREF="
     cwg_active.html#1092">1092</A>,
<A HREF="
     cwg_active.html#1093">1093</A>,
<A HREF="
     cwg_active.html#1094">1094</A>,
<A HREF="
     cwg_active.html#1095">1095</A>,
<A HREF="
     cwg_active.html#1096">1096</A>,
<A HREF="
     cwg_closed.html#1097">1097</A>,
<A HREF="
     cwg_active.html#1098">1098</A>,
<A HREF="
     cwg_active.html#1099">1099</A>,
<A HREF="
     cwg_active.html#1100">1100</A>,
<A HREF="
     cwg_active.html#1101">1101</A>,
<A HREF="
     cwg_defects.html#1102">1102</A>,
<A HREF="
     cwg_defects.html#1103">1103</A>,
<A HREF="
     cwg_defects.html#1104">1104</A>,
<A HREF="
     cwg_defects.html#1105">1105</A>,
<A HREF="
     cwg_defects.html#1106">1106</A>,
<A HREF="
     cwg_defects.html#1107">1107</A>,
<A HREF="
     cwg_active.html#1108">1108</A>,
<A HREF="
     cwg_defects.html#1109">1109</A>,
<A HREF="
     cwg_closed.html#1110">1110</A>,
<A HREF="
     cwg_active.html#1111">1111</A>,
<A HREF="
     cwg_defects.html#1112">1112</A>,
<A HREF="
     cwg_defects.html#1113">1113</A>,
<A HREF="
     cwg_defects.html#1114">1114</A>,
<A HREF="
     cwg_active.html#1115">1115</A>,
<A HREF="
     cwg_active.html#1116">1116</A>,
<A HREF="
     cwg_defects.html#1117">1117</A>,
<A HREF="
     cwg_closed.html#1118">1118</A>,
<A HREF="
     cwg_defects.html#1119">1119</A>,
<A HREF="
     cwg_active.html#1120">1120</A>,
<A HREF="
     cwg_defects.html#1121">1121</A>,
<A HREF="
     cwg_defects.html#1122">1122</A>,
<A HREF="
     cwg_defects.html#1123">1123</A>,
<A HREF="
     cwg_closed.html#1124">1124</A>,
<A HREF="
     cwg_defects.html#1125">1125</A>,
<A HREF="
     cwg_defects.html#1126">1126</A>,
<A HREF="
     cwg_defects.html#1127">1127</A>,
<A HREF="
     cwg_defects.html#1128">1128</A>,
<A HREF="
     cwg_defects.html#1129">1129</A>,
<A HREF="
     cwg_defects.html#1130">1130</A>,
<A HREF="
     cwg_defects.html#1131">1131</A>,
<A HREF="
     cwg_closed.html#1132">1132</A>,
<A HREF="
     cwg_active.html#1133">1133</A>,
<A HREF="
     cwg_defects.html#1134">1134</A>,
<A HREF="
     cwg_active.html#1135">1135</A>,
<A HREF="
     cwg_active.html#1136">1136</A>,
<A HREF="
     cwg_active.html#1137">1137</A>,
<A HREF="
     cwg_defects.html#1138">1138</A>,
<A HREF="
     cwg_defects.html#1139">1139</A>,
<A HREF="
     cwg_active.html#1140">1140</A>,
<A HREF="
     cwg_active.html#1141">1141</A>,
<A HREF="
     cwg_defects.html#1142">1142</A>,
<A HREF="
     cwg_active.html#1143">1143</A>,
<A HREF="
     cwg_defects.html#1144">1144</A>,
<A HREF="
     cwg_active.html#1145">1145</A>,
<A HREF="
     cwg_defects.html#1146">1146</A>,
<A HREF="
     cwg_defects.html#1147">1147</A>,
<A HREF="
     cwg_defects.html#1148">1148</A>,
<A HREF="
     cwg_active.html#1149">1149</A>,
<A HREF="
     cwg_active.html#1150">1150</A>,
<A HREF="
     cwg_active.html#1151">1151</A>,
<A HREF="
     cwg_defects.html#1152">1152</A>,
<A HREF="
     cwg_defects.html#1153">1153</A>,
<A HREF="
     cwg_defects.html#1154">1154</A>,
<A HREF="
     cwg_defects.html#1155">1155</A>,
<A HREF="
     cwg_defects.html#1156">1156</A>,
<A HREF="
     cwg_active.html#1157">1157</A>,
<A HREF="
     cwg_defects.html#1158">1158</A>,
<A HREF="
     cwg_defects.html#1159">1159</A>,
<A HREF="
     cwg_defects.html#1160">1160</A>,
<A HREF="
     cwg_defects.html#1161">1161</A>,
<A HREF="
     cwg_closed.html#1162">1162</A>,
<A HREF="
     cwg_closed.html#1163">1163</A>,
<A HREF="
     cwg_defects.html#1164">1164</A>,
<A HREF="
     cwg_defects.html#1165">1165</A>,
<A HREF="
     cwg_active.html#1166">1166</A>,
<A HREF="
     cwg_active.html#1167">1167</A>,
<A HREF="
     cwg_defects.html#1168">1168</A>,
<A HREF="
     cwg_defects.html#1169">1169</A>,
<A HREF="
     cwg_active.html#1170">1170</A>,
<A HREF="
     cwg_defects.html#1171">1171</A>,
<A HREF="
     cwg_active.html#1172">1172</A>, and
<A HREF="
     cwg_defects.html#1173">1173</A>.
</LI>

<LI><B>Revision 71, 2010-08-07:</B> Added new issues
<A HREF="
     cwg_defects.html#1069">1069</A>,
<A HREF="
     cwg_defects.html#1070">1070</A>,
<A HREF="
     cwg_active.html#1071">1071</A>,
<A HREF="
     cwg_defects.html#1072">1072</A>,
<A HREF="
     cwg_active.html#1073">1073</A>,
<A HREF="
     cwg_active.html#1074">1074</A>,
<A HREF="
     cwg_defects.html#1075">1075</A>,
<A HREF="
     cwg_active.html#1076">1076</A>,
<A HREF="
     cwg_closed.html#1077">1077</A>,
<A HREF="
     cwg_closed.html#1078">1078</A>,
<A HREF="
     cwg_active.html#1079">1079</A>,
<A HREF="
     cwg_active.html#1080">1080</A>,
<A HREF="
     cwg_active.html#1081">1081</A>,
<A HREF="
     cwg_active.html#1082">1082</A>,
<A HREF="
     cwg_defects.html#1083">1083</A>,
<A HREF="
     cwg_closed.html#1084">1084</A>,
<A HREF="
     cwg_closed.html#1085">1085</A>,
<A HREF="
     cwg_defects.html#1086">1086</A>,
<A HREF="
     cwg_defects.html#1087">1087</A>,
<A HREF="
     cwg_active.html#1088">1088</A>,
<A HREF="
     cwg_active.html#1089">1089</A>, and
<A HREF="
     cwg_active.html#1090">1090</A>.
</LI>

<LI><B>Revision 70, 2010-08-06:</B> Reflected results of between-meetings
teleconference, including moving a number of issues to "tentatively ready"
status, updating proposed resolutions, and moving issues
<A HREF="
     cwg_defects.html#341">341</A>,
<A HREF="
     cwg_active.html#355">355</A>,
<A HREF="
     cwg_active.html#472">472</A>, and
<A HREF="
     cwg_active.html#529">529</A> to "drafting" status for more work.
Changed <A HREF="
     cwg_defects.html#979">issue 979</A> to "CD2" status, which
was overlooked in the results of the March, 2010 meeting.  Closed issues
<A HREF="
     cwg_closed.html#1041">1041</A>, <A HREF="
     cwg_closed.html#1019">1019</A>, and
<A HREF="
     cwg_closed.html#507">507</A> as duplicates of issues
<A HREF="
     cwg_defects.html#924">924</A>, <A HREF="
     cwg_active.html#314">314</A>, and
<A HREF="
     cwg_active.html#260">260</A>, respectively.
</LI>

<LI><B>Revision 69, 2010-03-29:</B> Reflected deliberations at the March,
2010 (Pittsburgh, PA) meeting.  Placed all issues with "WP" status and
newly-approved "DR" issues into "CD2" status, to reflect advancing the
Final Committee Draft for balloting. Added new issues
<A HREF="
     cwg_closed.html#1001">1001</A>,
<A HREF="
     cwg_closed.html#1002">1002</A>,
<A HREF="
     cwg_active.html#1003">1003</A>,
<A HREF="
     cwg_active.html#1004">1004</A>,
<A HREF="
     cwg_active.html#1005">1005</A>,
<A HREF="
     cwg_defects.html#1006">1006</A>,
<A HREF="
     cwg_closed.html#1007">1007</A>,
<A HREF="
     cwg_closed.html#1008">1008</A>,
<A HREF="
     cwg_defects.html#1009">1009</A>,
<A HREF="
     cwg_defects.html#1010">1010</A>,
<A HREF="
     cwg_defects.html#1011">1011</A>,
<A HREF="
     cwg_defects.html#1012">1012</A>,
<A HREF="
     cwg_active.html#1013">1013</A>,
<A HREF="
     cwg_closed.html#1014">1014</A>,
<A HREF="
     cwg_active.html#1015">1015</A>,
<A HREF="
     cwg_defects.html#1016">1016</A>,
<A HREF="
     cwg_active.html#1017">1017</A>,
<A HREF="
     cwg_active.html#1018">1018</A>,
<A HREF="
     cwg_closed.html#1019">1019</A>,
<A HREF="
     cwg_defects.html#1020">1020</A>,
<A HREF="
     cwg_active.html#1021">1021</A>,
<A HREF="
     cwg_active.html#1022">1022</A>,
<A HREF="">1023</A>,
<A HREF="
     cwg_active.html#1024">1024</A>,
<A HREF="
     cwg_defects.html#1025">1025</A>,
<A HREF="
     cwg_closed.html#1026">1026</A>,
<A HREF="
     cwg_active.html#1027">1027</A>,
<A HREF="
     cwg_active.html#1028">1028</A>,
<A HREF="
     cwg_defects.html#1029">1029</A>,
<A HREF="
     cwg_active.html#1030">1030</A>,
<A HREF="
     cwg_active.html#1031">1031</A>,
<A HREF="
     cwg_active.html#1032">1032</A>,
<A HREF="
     cwg_active.html#1033">1033</A>,
<A HREF="
     cwg_defects.html#1034">1034</A>,
<A HREF="
     cwg_active.html#1035">1035</A>,
<A HREF="
     cwg_defects.html#1036">1036</A>,
<A HREF="
     cwg_defects.html#1037">1037</A>,
<A HREF="
     cwg_active.html#1038">1038</A>,
<A HREF="">1039</A>,
<A HREF="
     cwg_closed.html#1040">1040</A>,
<A HREF="
     cwg_closed.html#1041">1041</A>,
<A HREF="
     cwg_active.html#1042">1042</A>,
<A HREF="
     cwg_active.html#1043">1043</A>,
<A HREF="
     cwg_active.html#1044">1044</A>,
<A HREF="
     cwg_closed.html#1045">1045</A>,
<A HREF="
     cwg_active.html#1046">1046</A>,
<A HREF="
     cwg_defects.html#1047">1047</A>,
<A HREF="
     cwg_closed.html#1048">1048</A>,
<A HREF="
     cwg_active.html#1049">1049</A>,
<A HREF="
     cwg_closed.html#1050">1050</A>,
<A HREF="
     cwg_defects.html#1051">1051</A>,
<A HREF="">1052</A>,
<A HREF="
     cwg_closed.html#1053">1053</A>,
<A HREF="
     cwg_active.html#1054">1054</A>,
<A HREF="
     cwg_active.html#1055">1055</A>,
<A HREF="
     cwg_active.html#1056">1056</A>,
<A HREF="
     cwg_active.html#1057">1057</A>,
<A HREF="
     cwg_active.html#1058">1058</A>,
<A HREF="
     cwg_active.html#1059">1059</A>,
<A HREF="
     cwg_active.html#1060">1060</A>,
<A HREF="
     cwg_defects.html#1061">1061</A>,
<A HREF="
     cwg_defects.html#1062">1062</A>,
<A HREF="
     cwg_active.html#1063">1063</A>,
<A HREF="
     cwg_defects.html#1064">1064</A>,
<A HREF="
     cwg_defects.html#1065">1065</A>,
<A HREF="
     cwg_defects.html#1066">1066</A>,
<A HREF="
     cwg_closed.html#1067">1067</A>, and
<A HREF="
     cwg_active.html#1068">1068</A>.
</LI>

<LI><B>Revision 68, 2010-02-16:</B> Reflected results of between-meeting
teleconferences, including moving many issues to "tentatively ready" status
and incorporating draft proposed resolutions for many others.  Added
new issues <A HREF="
     cwg_defects.html#999">999</A> and <A HREF="
     cwg_defects.html#1000">1000</A>.
</LI>

<LI><B>Revision 67, 2009-11-08:</B> Reflected deliberations at the October,
2009 (Santa Cruz, CA) meeting. Added new issues
<A HREF="
     cwg_defects.html#972">972</A>,
<A HREF="
     cwg_defects.html#973">973</A>,
<A HREF="
     cwg_active.html#974">974</A>,
<A HREF="
     cwg_active.html#975">975</A>,
<A HREF="
     cwg_defects.html#976">976</A>,
<A HREF="
     cwg_active.html#977">977</A>,
<A HREF="
     cwg_defects.html#978">978</A>,
<A HREF="
     cwg_defects.html#979">979</A>,
<A HREF="
     cwg_defects.html#980">980</A>,
<A HREF="
     cwg_active.html#981">981</A>,
<A HREF="
     cwg_closed.html#982">982</A>,
<A HREF="
     cwg_defects.html#983">983</A>,
<A HREF="
     cwg_defects.html#984">984</A>,
<A HREF="
     cwg_active.html#985">985</A>,
<A HREF="
     cwg_defects.html#986">986</A>,
<A HREF="
     cwg_active.html#987">987</A>,
<A HREF="
     cwg_defects.html#988">988</A>,
<A HREF="
     cwg_defects.html#989">989</A>,
<A HREF="
     cwg_defects.html#990">990</A>,
<A HREF="
     cwg_defects.html#991">991</A>,
<A HREF="
     cwg_closed.html#992">992</A>,
<A HREF="
     cwg_active.html#993">993</A>,
<A HREF="
     cwg_defects.html#994">994</A>,
<A HREF="
     cwg_defects.html#995">995</A>,
<A HREF="
     cwg_active.html#996">996</A>,
<A HREF="
     cwg_active.html#997">997</A>, and
<A HREF="
     cwg_closed.html#998">998</A>.
</LI>

<LI><B>Revision 66, 2009-09-29:</B> Incorporated a new status,
"tentatively ready", for issues whose resolutions were reviewed and
approved by teleconference between meetings. Changed
<A HREF="
     cwg_defects.html#378">issue 378</A> to "CD1" status, as it was
resolved by the resolution of <A HREF="
     cwg_defects.html#276">issue 276</A>.
 Added new issues
<A HREF="
     cwg_active.html#949">949</A>,
<A HREF="
     cwg_defects.html#950">950</A>,
<A HREF="
     cwg_defects.html#951">951</A>,
<A HREF="
     cwg_active.html#952">952</A>,
<A HREF="
     cwg_defects.html#953">953</A>,
<A HREF="
     cwg_active.html#954">954</A>,
<A HREF="
     cwg_defects.html#955">955</A>,
<A HREF="
     cwg_defects.html#956">956</A>,
<A HREF="
     cwg_defects.html#957">957</A>,
<A HREF="
     cwg_closed.html#958">958</A>,
<A HREF="
     cwg_defects.html#959">959</A>,
<A HREF="
     cwg_defects.html#960">960</A>,
<A HREF="
     cwg_defects.html#961">961</A>,
<A HREF="
     cwg_defects.html#962">962</A>,
<A HREF="
     cwg_defects.html#963">963</A>,
<A HREF="
     cwg_defects.html#964">964</A>,
<A HREF="
     cwg_defects.html#965">965</A>,
<A HREF="
     cwg_defects.html#966">966</A>,
<A HREF="
     cwg_active.html#967">967</A>,
<A HREF="
     cwg_defects.html#968">968</A>,
<A HREF="
     cwg_defects.html#969">969</A>,
<A HREF="
     cwg_defects.html#970">970</A>, and
<A HREF="
     cwg_active.html#971">971</A>.
</LI>

<LI><B>Revision 65, 2009-08-03:</B> Reflected deliberations from the
Frankfurt, Germany (July, 2009) meeting.  Added a new status,
"concepts," for issues related to the concepts proposal that was
removed from the working document and moved all concepts-related
issues to that status, effectively closing them.
 Changed the presentation of proposed
resolutions to use background colors in addition to font effects to
identify changes (i.e., <SPAN style="font-weight:bold;background-color:#A0FFA0">inserted</SPAN> and <SPAN style="text-decoration:line-through;background-color:#FFA0A0">deleted</SPAN>
text). Added new issues
<A HREF="
     cwg_defects.html#922">922</A>,
<A HREF="
     cwg_defects.html#923">923</A>,
<A HREF="
     cwg_defects.html#924">924</A>,
<A HREF="
     cwg_active.html#925">925</A>,
<A HREF="
     cwg_defects.html#926">926</A>,
<A HREF="
     cwg_defects.html#927">927</A>,
<A HREF="
     cwg_defects.html#928">928</A>,
<A HREF="
     cwg_defects.html#929">929</A>,
<A HREF="
     cwg_defects.html#930">930</A>,
<A HREF="
     cwg_defects.html#931">931</A>,
<A HREF="
     cwg_defects.html#932">932</A>,
<A HREF="
     cwg_defects.html#933">933</A>,
<A HREF="
     cwg_defects.html#934">934</A>,
<A HREF="
     cwg_defects.html#935">935</A>,
<A HREF="
     cwg_defects.html#936">936</A>,
<A HREF="
     cwg_closed.html#937">937</A>,
<A HREF="
     cwg_active.html#938">938</A>,
<A HREF="
     cwg_defects.html#939">939</A>,
<A HREF="
     cwg_defects.html#940">940</A>,
<A HREF="
     cwg_defects.html#941">941</A>,
<A HREF="
     cwg_defects.html#942">942</A>,
<A HREF="
     cwg_active.html#943">943</A>,
<A HREF="
     cwg_active.html#944">944</A>,
<A HREF="
     cwg_active.html#945">945</A>,
<A HREF="
     cwg_defects.html#946">946</A>,
<A HREF="
     cwg_closed.html#947">947</A>, and
<A HREF="
     cwg_defects.html#948">948</A>.
</LI>

<LI><B>Revision 64, 2009-06-19:</B> Fixed incorrect cross-references in
issues <A HREF="
     cwg_closed.html#867">867</A> and <A HREF="
     cwg_closed.html#868">868</A>.
Added proposed resolutions for issues
<A HREF="
     cwg_defects.html#527">527</A>,
<A HREF="
     cwg_defects.html#587">587</A>,
<A HREF="
     cwg_defects.html#589">589</A>,
<A HREF="
     cwg_defects.html#604">604</A>,
<A HREF="
     cwg_defects.html#719">719</A>,
<A HREF="
     cwg_defects.html#732">732</A>, and
<A HREF="
     cwg_defects.html#770">770</A>
and moved them to "review" status.  Added discussion to issues
<A HREF="
     cwg_defects.html#721">721</A>,
<A HREF="
     cwg_defects.html#760">760</A>,
<A HREF="
     cwg_closed.html#802">802</A>, and
<A HREF="
     cwg_defects.html#872">872</A>.  Added new issues
<A HREF="
     cwg_closed.html#889">889</A>,
<A HREF="
     cwg_closed.html#890">890</A>,
<A HREF="
     cwg_defects.html#891">891</A>,
<A HREF="
     cwg_defects.html#892">892</A>,
<A HREF="
     cwg_closed.html#893">893</A>,
<A HREF="
     cwg_closed.html#894">894</A>,
<A HREF="
     cwg_closed.html#895">895</A>,
<A HREF="
     cwg_defects.html#896">896</A>,
<A HREF="
     cwg_active.html#897">897</A>,
<A HREF="
     cwg_closed.html#898">898</A>,
<A HREF="
     cwg_defects.html#899">899</A>,
<A HREF="
     cwg_closed.html#900">900</A>,
<A HREF="
     cwg_active.html#901">901</A>,
<A HREF="
     cwg_closed.html#902">902</A>,
<A HREF="
     cwg_active.html#903">903</A>,
<A HREF="
     cwg_defects.html#904">904</A>,
<A HREF="
     cwg_defects.html#905">905</A>,
<A HREF="
     cwg_defects.html#906">906</A>,
<A HREF="
     cwg_closed.html#907">907</A>,
<A HREF="
     cwg_defects.html#908">908</A>,
<A HREF="
     cwg_closed.html#909">909</A>,
<A HREF="
     cwg_defects.html#910">910</A>,
<A HREF="
     cwg_closed.html#911">911</A>,
<A HREF="
     cwg_active.html#912">912</A>,
<A HREF="
     cwg_defects.html#913">913</A>,
<A HREF="
     cwg_closed.html#914">914</A>,
<A HREF="">915</A>,
<A HREF="
     cwg_active.html#916">916</A>,
<A HREF="
     cwg_closed.html#917">917</A>,
<A HREF="
     cwg_closed.html#918">918</A>,
<A HREF="
     cwg_defects.html#919">919</A>,
<A HREF="
     cwg_defects.html#920">920</A>, and
<A HREF="
     cwg_defects.html#921">921</A>.
</LI>

<LI><B>Revision 63, 2009-05-06:</B> Closed <A HREF="
     cwg_closed.html#839">issue 839</A> as a duplicate of <A HREF="
     cwg_defects.html#803">issue 803</A>.
Added notes to the discussion of issues <A HREF="
     cwg_active.html#325">325</A>,
<A HREF="
     cwg_defects.html#626">626</A>, <A HREF="
     cwg_defects.html#667">667</A>
<A HREF="
     cwg_defects.html#690">690</A>, <A HREF="
     cwg_active.html#739">739</A>, and
<A HREF="
     cwg_closed.html#841">841</A>.  Moved <A HREF="
     cwg_closed.html#662">issue 662</A>
back to "open" status with additional discussion.  Added new issues
<A HREF="
     cwg_closed.html#843">843</A>,
<A HREF="
     cwg_closed.html#844">844</A>,
<A HREF="
     cwg_defects.html#845">845</A>,
<A HREF="
     cwg_defects.html#846">846</A>,
<A HREF="
     cwg_defects.html#847">847</A>,
<A HREF="
     cwg_closed.html#848">848</A>,
<A HREF="
     cwg_closed.html#849">849</A>,
<A HREF="
     cwg_defects.html#850">850</A>,
<A HREF="
     cwg_closed.html#851">851</A>,
<A HREF="
     cwg_active.html#852">852</A>,
<A HREF="
     cwg_defects.html#853">853</A>,
<A HREF="
     cwg_defects.html#854">854</A>,
<A HREF="
     cwg_defects.html#855">855</A>,
<A HREF="
     cwg_closed.html#856">856</A>,
<A HREF="
     cwg_closed.html#857">857</A>,
<A HREF="
     cwg_defects.html#858">858</A>,
<A HREF="
     cwg_closed.html#859">859</A>,
<A HREF="
     cwg_defects.html#860">860</A>,
<A HREF="
     cwg_defects.html#861">861</A>,
<A HREF="
     cwg_defects.html#862">862</A>,
<A HREF="
     cwg_defects.html#863">863</A>,
<A HREF="
     cwg_defects.html#864">864</A>,
<A HREF="
     cwg_defects.html#865">865</A>,
<A HREF="
     cwg_closed.html#866">866</A>,
<A HREF="
     cwg_closed.html#867">867</A>,
<A HREF="
     cwg_closed.html#868">868</A>,
<A HREF="
     cwg_defects.html#869">869</A>,
<A HREF="
     cwg_closed.html#870">870</A>,
<A HREF="
     cwg_closed.html#871">871</A>,
<A HREF="
     cwg_defects.html#872">872</A>,
<A HREF="
     cwg_defects.html#873">873</A>,
<A HREF="
     cwg_defects.html#874">874</A>,
<A HREF="
     cwg_closed.html#875">875</A>,
<A HREF="
     cwg_defects.html#876">876</A>,
<A HREF="
     cwg_defects.html#877">877</A>,
<A HREF="
     cwg_closed.html#878">878</A>,
<A HREF="
     cwg_defects.html#879">879</A>,
<A HREF="
     cwg_defects.html#880">880</A>,
<A HREF="
     cwg_closed.html#881">881</A>,
<A HREF="
     cwg_defects.html#882">882</A>,
<A HREF="
     cwg_defects.html#883">883</A>,
<A HREF="
     cwg_defects.html#884">884</A>,
<A HREF="
     cwg_closed.html#885">885</A>,
<A HREF="
     cwg_defects.html#886">886</A>,
<A HREF="
     cwg_defects.html#887">887</A>, and
<A HREF="
     cwg_defects.html#888">888</A>.
</LI>

<LI><B>Revision 62, 2009-03-23:</B> Reflected deliberations from the
Summit, NJ (March, 2009) meeting. Marked issues directly related to
National Body comments on the 2008-10 Committee Draft with a tag
identifying the relevant comment; the tag is both printed in the issue
body and reflected in the "Index by Status" document.  Added new
issues
<A HREF="
     cwg_defects.html#767">767</A>,
<A HREF="
     cwg_defects.html#768">768</A>,
<A HREF="
     cwg_defects.html#769">769</A>,
<A HREF="
     cwg_defects.html#770">770</A>,
<A HREF="
     cwg_defects.html#771">771</A>,
<A HREF="
     cwg_defects.html#772">772</A>,
<A HREF="
     cwg_defects.html#773">773</A>,
<A HREF="
     cwg_defects.html#774">774</A>,
<A HREF="
     cwg_defects.html#775">775</A>,
<A HREF="
     cwg_defects.html#776">776</A>,
<A HREF="
     cwg_defects.html#777">777</A>,
<A HREF="
     cwg_active.html#778">778</A>,
<A HREF="
     cwg_defects.html#779">779</A>,
<A HREF="
     cwg_closed.html#780">780</A>,
<A HREF="
     cwg_closed.html#781">781</A>,
<A HREF="
     cwg_defects.html#782">782</A>,
<A HREF="
     cwg_active.html#783">783</A>,
<A HREF="
     cwg_active.html#784">784</A>,
<A HREF="
     cwg_defects.html#785">785</A>,
<A HREF="
     cwg_defects.html#786">786</A>,
<A HREF="
     cwg_defects.html#787">787</A>,
<A HREF="
     cwg_defects.html#788">788</A>,
<A HREF="
     cwg_defects.html#789">789</A>,
<A HREF="
     cwg_defects.html#790">790</A>,
<A HREF="
     cwg_closed.html#791">791</A>,
<A HREF="
     cwg_defects.html#792">792</A>,
<A HREF="
     cwg_defects.html#793">793</A>,
<A HREF="
     cwg_closed.html#794">794</A>,
<A HREF="
     cwg_closed.html#795">795</A>,
<A HREF="
     cwg_defects.html#796">796</A>,
<A HREF="
     cwg_defects.html#797">797</A>,
<A HREF="
     cwg_active.html#798">798</A>,
<A HREF="
     cwg_defects.html#799">799</A>,
<A HREF="
     cwg_closed.html#800">800</A>,
<A HREF="
     cwg_defects.html#801">801</A>,
<A HREF="
     cwg_closed.html#802">802</A>,
<A HREF="
     cwg_defects.html#803">803</A>,
<A HREF="
     cwg_defects.html#804">804</A>,
<A HREF="
     cwg_defects.html#805">805</A>,
<A HREF="
     cwg_defects.html#806">806</A>,
<A HREF="
     cwg_closed.html#807">807</A>,
<A HREF="
     cwg_defects.html#808">808</A>,
<A HREF="
     cwg_defects.html#809">809</A>,
<A HREF="
     cwg_defects.html#810">810</A>,
<A HREF="
     cwg_defects.html#811">811</A>,
<A HREF="
     cwg_defects.html#812">812</A>,
<A HREF="
     cwg_active.html#813">813</A>,
<A HREF="
     cwg_defects.html#814">814</A>,
<A HREF="
     cwg_defects.html#815">815</A>,
<A HREF="
     cwg_defects.html#816">816</A>,
<A HREF="
     cwg_defects.html#817">817</A>,
<A HREF="
     cwg_defects.html#818">818</A>,
<A HREF="
     cwg_closed.html#819">819</A>,
<A HREF="
     cwg_defects.html#820">820</A>,
<A HREF="
     cwg_closed.html#821">821</A>,
<A HREF="
     cwg_closed.html#822">822</A>,
<A HREF="
     cwg_defects.html#823">823</A>,
<A HREF="
     cwg_closed.html#824">824</A>,
<A HREF="
     cwg_closed.html#825">825</A>,
<A HREF="
     cwg_closed.html#826">826</A>,
<A HREF="
     cwg_closed.html#827">827</A>,
<A HREF="
     cwg_defects.html#828">828</A>,
<A HREF="
     cwg_closed.html#829">829</A>,
<A HREF="
     cwg_defects.html#830">830</A>,
<A HREF="
     cwg_defects.html#831">831</A>,
<A HREF="
     cwg_defects.html#832">832</A>,
<A HREF="
     cwg_defects.html#833">833</A>,
<A HREF="
     cwg_defects.html#834">834</A>,
<A HREF="
     cwg_defects.html#835">835</A>,
<A HREF="
     cwg_closed.html#836">836</A>,
<A HREF="
     cwg_active.html#837">837</A>,
<A HREF="
     cwg_active.html#838">838</A>,
<A HREF="
     cwg_closed.html#839">839</A>,
<A HREF="
     cwg_defects.html#840">840</A>,
<A HREF="
     cwg_closed.html#841">841</A>, and
<A HREF="
     cwg_defects.html#842">842</A>.
</LI>

<LI><B>Revision 61, 2009-02-08:</B> Provided a reference to a paper
containing a proposed resolution for issues <A HREF="
     cwg_defects.html#695">695</A>
and <A HREF="
     cwg_defects.html#699">699</A> and moved them to "review" status.
Added new issues
<A HREF="
     cwg_defects.html#749">749</A>,
<A HREF="
     cwg_defects.html#750">750</A>,
<A HREF="
     cwg_defects.html#751">751</A>,
<A HREF="
     cwg_defects.html#752">752</A>,
<A HREF="
     cwg_defects.html#753">753</A>,
<A HREF="
     cwg_defects.html#754">754</A>,
<A HREF="
     cwg_closed.html#755">755</A>,
<A HREF="
     cwg_defects.html#756">756</A>,
<A HREF="
     cwg_defects.html#757">757</A>,
<A HREF="
     cwg_active.html#758">758</A>,
<A HREF="
     cwg_defects.html#759">759</A>,
<A HREF="
     cwg_defects.html#760">760</A>,
<A HREF="
     cwg_defects.html#761">761</A>,
<A HREF="
     cwg_defects.html#762">762</A>,
<A HREF="
     cwg_defects.html#763">763</A>,
<A HREF="
     cwg_defects.html#764">764</A>,
<A HREF="
     cwg_defects.html#765">765</A>, and
<A HREF="
     cwg_defects.html#766">766</A>.
</LI>

<LI><B>Revision 60, 2008-12-09:</B> Revised the resolution of
<A HREF="
     cwg_defects.html#653">issue 653</A> and moved to "review" status.
Added new issues
<A HREF="
     cwg_closed.html#724">724</A>,
<A HREF="
     cwg_closed.html#725">725</A>,
<A HREF="
     cwg_defects.html#726">726</A>,
<A HREF="
     cwg_closed.html#727">727</A>,
<A HREF="
     cwg_closed.html#728">728</A>,
<A HREF="
     cwg_active.html#729">729</A>,
<A HREF="
     cwg_defects.html#730">730</A>,
<A HREF="
     cwg_defects.html#731">731</A>,
<A HREF="
     cwg_defects.html#732">732</A>,
<A HREF="
     cwg_closed.html#733">733</A>,
<A HREF="
     cwg_defects.html#734">734</A>,
<A HREF="
     cwg_defects.html#735">735</A>,
<A HREF="
     cwg_closed.html#736">736</A>,
<A HREF="
     cwg_defects.html#737">737</A>,
<A HREF="
     cwg_defects.html#738">738</A>,
<A HREF="
     cwg_active.html#739">739</A>,
<A HREF="
     cwg_defects.html#740">740</A>,
<A HREF="
     cwg_defects.html#741">741</A>,
<A HREF="
     cwg_active.html#742">742</A>,
<A HREF="
     cwg_defects.html#743">743</A>,
<A HREF="
     cwg_defects.html#744">744</A>,
<A HREF="
     cwg_active.html#745">745</A>,
<A HREF="
     cwg_defects.html#746">746</A>,
<A HREF="
     cwg_active.html#747">747</A>, and
<A HREF="
     cwg_closed.html#748">748</A>.
</LI>

<LI><B>Revision 59, 2008-10-05:</B> Reflected deliberations from the
San Francisco (September, 2008) meeting. Placed all issues with
"WP" status and newly-approved "DR" issues into "CD1" status, to
reflect advancing the Committee Draft for balloting.  Added new
proposed resolutions to issues <A HREF="
     cwg_active.html#696">696</A>,
<A HREF="
     cwg_defects.html#704">704</A>, and <A HREF="
     cwg_defects.html#705">705</A>
and moved them to "review" status. Changed
<A HREF="
     cwg_closed.html#265">issue 265</A> to "dup" status in favor of
<A HREF="
     cwg_defects.html#353">issue 353</A>, which was approved in 2003.
Added new issues
<A HREF="
     cwg_defects.html#710">710</A>,
<A HREF="
     cwg_defects.html#711">711</A>,
<A HREF="
     cwg_active.html#712">712</A>,
<A HREF="
     cwg_defects.html#713">713</A>,
<A HREF="
     cwg_defects.html#714">714</A>,
<A HREF="
     cwg_defects.html#715">715</A>,
<A HREF="
     cwg_defects.html#716">716</A>,
<A HREF="
     cwg_defects.html#717">717</A>,
<A HREF="
     cwg_active.html#718">718</A>,
<A HREF="
     cwg_defects.html#719">719</A>,
<A HREF="
     cwg_defects.html#720">720</A>,
<A HREF="
     cwg_defects.html#721">721</A>,
<A HREF="
     cwg_defects.html#722">722</A>, and
<A HREF="
     cwg_closed.html#723">723</A>.
</LI>

<LI><B>Revision 58, 2008-08-25:</B> Fixed some incorrect section
references.  Fixed the title of <A HREF="
     cwg_active.html#692">issue 692</A>.
Changed the status of <A HREF="
     cwg_defects.html#603">issue 603</A> to "WP",
as the paper that resolved it was approved in April, 2007.  Moved
<A HREF="
     cwg_defects.html#657">issue 657</A> back to "review" status and
added proposed wording. Added discussion to issues
<A HREF="
     cwg_defects.html#693">693</A> and <A HREF="
     cwg_active.html#697">697</A>.
Added or revised resolutions for issues
<A HREF="
     cwg_defects.html#606">606</A>,
<A HREF="
     cwg_defects.html#614">614</A>,
<A HREF="
     cwg_defects.html#652">652</A>,
<A HREF="
     cwg_defects.html#685">685</A>, and
<A HREF="
     cwg_defects.html#694">694</A> and moved them to "review" status.
Added new issues
<A HREF="
     cwg_defects.html#704">704</A>,
<A HREF="
     cwg_defects.html#705">705</A>,
<A HREF="
     cwg_closed.html#706">706</A>,
<A HREF="
     cwg_defects.html#707">707</A>,
<A HREF="
     cwg_active.html#708">708</A>, and
<A HREF="
     cwg_defects.html#709">709</A>.
</LI>

<LI><B>Revision 57, 2008-07-27:</B>  Updated the status of issues
<A HREF="
     cwg_defects.html#222">222</A>, <A HREF="
     cwg_defects.html#309">309</A>, and
<A HREF="
     cwg_defects.html#632">632</A> to reflect actions at the June, 2008
meeting that were inadvertently omitted in the preceding revision.
Added proposed wording for
<A HREF="
     cwg_defects.html#683">issue 683</A> and moved it to "review" status.
Added new issues
<A HREF="
     cwg_active.html#697">697</A>,
<A HREF="
     cwg_active.html#698">698</A>,
<A HREF="
     cwg_defects.html#699">699</A>,
<A HREF="
     cwg_defects.html#700">700</A>,
<A HREF="
     cwg_defects.html#701">701</A>,
<A HREF="
     cwg_defects.html#702">702</A>, and
<A HREF="
     cwg_defects.html#703">703</A>.
</LI>

<LI><B>Revision 56, 2008-06-29:</B> Reflected deliberations from the
Sophia Antipolis (June, 2008) meeting.  Added discussion to issues
<A HREF="
     cwg_closed.html#507">507</A> and
<A HREF="
     cwg_defects.html#527">527</A>. Added proposed resolution for
<A HREF="
     cwg_defects.html#653">issue 653</A>.  Added new issues
<A HREF="
     cwg_defects.html#695">695</A> and <A HREF="
     cwg_active.html#696">696</A>.
</LI>

<LI><B>Revision 55, 2008-05-18:</B> Added proposed resolutions for
issues
<A HREF="
     cwg_defects.html#220">220</A>,
<A HREF="
     cwg_defects.html#257">257</A>,
<A HREF="
     cwg_active.html#292">292</A>,
<A HREF="
     cwg_defects.html#341">341</A>,
<A HREF="
     cwg_active.html#539">539</A>,
<A HREF="
     cwg_active.html#554">554</A>,
<A HREF="
     cwg_defects.html#570">570</A>,
<A HREF="
     cwg_defects.html#571">571</A>,
<A HREF="
     cwg_defects.html#576">576</A>,
<A HREF="
     cwg_active.html#597">597</A>,
<A HREF="
     cwg_defects.html#621">621</A>,
<A HREF="
     cwg_defects.html#624">624</A>,
<A HREF="
     cwg_defects.html#626">626</A>,
<A HREF="
     cwg_defects.html#633">633</A>,
<A HREF="
     cwg_defects.html#634">634</A>,
<A HREF="
     cwg_defects.html#639">639</A>, and
<A HREF="
     cwg_defects.html#642">642</A>,
and moved them to "review" status.
Moved <A HREF="
     cwg_closed.html#155">issue 155</A> to "dup" status in
favor of <A HREF="
     cwg_defects.html#632">issue 632</A>, which was changed
to "review" status in light of its connection with the
initializer-list proposal.  Moved issues <A HREF="
     cwg_defects.html#530">530</A>
and <A HREF="
     cwg_defects.html#551">551</A>
to "WP" status because they were resolved by the constexpr proposal.
Moved <A HREF="
     cwg_closed.html#646">issue 646</A> to "review" status because
it appears to be "NAD".  Changed <A HREF="
     cwg_active.html#240">issue 240</A>
to "review" status (from "ready") in light of input from WG14 regarding
a similar issue.  Added new issues
<A HREF="
     cwg_defects.html#685">685</A>,
<A HREF="
     cwg_defects.html#686">686</A>,
<A HREF="
     cwg_closed.html#687">687</A>,
<A HREF="
     cwg_defects.html#688">688</A>,
<A HREF="
     cwg_active.html#689">689</A>,
<A HREF="
     cwg_defects.html#690">690</A>,
<A HREF="
     cwg_defects.html#691">691</A>,
<A HREF="
     cwg_active.html#692">692</A>,
<A HREF="
     cwg_defects.html#693">693</A>, and
<A HREF="
     cwg_defects.html#694">694</A>.
</LI>

<LI><B>Revision 54, 2008-03-17:</B> Reflected deliberations from the
Bellevue (February, 2008) meeting.  Restructured references inside
&#8220;definitions&#8221; sections (1.3 [intro.defs],
17.3 [definitions]) because the individual definitions are not
sections.  Returned <A HREF="
     cwg_closed.html#646">issue 646</A> to "open"
status (it was previously erroneously in "drafting" status).  Moved
issues <A HREF="
     cwg_closed.html#347">347</A>, <A HREF="
     cwg_active.html#512">512</A>,
and <A HREF="
     cwg_active.html#236">236</A> to "review" status with a
recommendation to close them as "NAD."  Changed issues <A HREF="
     cwg_defects.html#220">220</A> and <A HREF="
     cwg_defects.html#256">256</A> back to "open"
status  and
annotated them to indicate that they have been accepted by EWG and
referred to CWG for action for C++0x.  Changed issues <A HREF="
     cwg_active.html#6">6</A> and <A HREF="
     cwg_active.html#150">150</A> back to "open"
status  and
annotated them to indicate that they have been accepted by EWG and
referred to CWG for action, but not for C++0x. Closed issues
<A HREF="
     cwg_closed.html#107">107</A>,
<A HREF="
     cwg_closed.html#168">168</A>,
<A HREF="
     cwg_closed.html#229">229</A>,
<A HREF="
     cwg_closed.html#294">294</A>, and
<A HREF="
     cwg_closed.html#359">359</A> as "NAD" to reflect the recommendation
of EWG.  Added new issues
<A HREF="
     cwg_closed.html#673">673</A>,
<A HREF="
     cwg_defects.html#674">674</A>,
<A HREF="
     cwg_active.html#675">675</A>,
<A HREF="
     cwg_defects.html#676">676</A>,
<A HREF="
     cwg_defects.html#677">677</A>,
<A HREF="
     cwg_defects.html#678">678</A>,
<A HREF="
     cwg_defects.html#679">679</A>,
<A HREF="
     cwg_defects.html#680">680</A>,
<A HREF="
     cwg_defects.html#681">681</A>,
<A HREF="
     cwg_active.html#682">682</A>,
<A HREF="
     cwg_defects.html#683">683</A>, and
<A HREF="
     cwg_defects.html#684">684</A>.
</LI>

<LI><B>Revision 53, 2008-02-03:</B>
Updated the proposed resolutions for issues <A HREF="
     cwg_defects.html#288">288</A>
and <A HREF="
     cwg_active.html#342">342</A>.  Updated the status of issues
<A HREF="
     cwg_defects.html#199">199</A> and <A HREF="
     cwg_defects.html#430">430</A> to reflect
actions at the Oxford (April, 2007) meeting.
Added proposed resolutions and
changed the status to "review" for issues
<A HREF="
     cwg_defects.html#28">28</A>,
<A HREF="
     cwg_active.html#111">111</A>,
<A HREF="
     cwg_defects.html#118">118</A>,
<A HREF="
     cwg_defects.html#141">141</A>,
<A HREF="
     cwg_active.html#240">240</A>,
<A HREF="
     cwg_defects.html#276">276</A>,
<A HREF="
     cwg_defects.html#309">309</A>,
<A HREF="
     cwg_active.html#355">355</A>,
<A HREF="
     cwg_defects.html#373">373</A>,
<A HREF="
     cwg_defects.html#378">378</A>,
<A HREF="
     cwg_active.html#462">462</A>,
<A HREF="
     cwg_defects.html#485">485</A>,
<A HREF="
     cwg_active.html#535">535</A>,
<A HREF="
     cwg_closed.html#574">574</A>,
<A HREF="
     cwg_defects.html#601">601</A>,
<A HREF="
     cwg_defects.html#608">608</A>,
<A HREF="
     cwg_defects.html#641">641</A>,
<A HREF="
     cwg_defects.html#645">645</A>, and
<A HREF="
     cwg_defects.html#651">651</A>.
Added new issues
<A HREF="
     cwg_defects.html#667">667</A>,
<A HREF="
     cwg_defects.html#668">668</A>,
<A HREF="
     cwg_closed.html#669">669</A>,
<A HREF="
     cwg_active.html#670">670</A>,
<A HREF="
     cwg_defects.html#671">671</A>, and
<A HREF="
     cwg_defects.html#672">672</A>.
</LI>

<LI><B>Revision 52, 2007-12-09:</B>
Updated the status of issues <A HREF="
     cwg_defects.html#568">568</A> and
<A HREF="
     cwg_defects.html#620">620</A> to reflect actions at the Toronto
(July, 2007) meeting. Fixed a typographical error in the example for
<A HREF="
     cwg_defects.html#606">issue 606</A>.
Added new issues
<A HREF="
     cwg_defects.html#654">654</A>,
<A HREF="
     cwg_defects.html#655">655</A>,
<A HREF="
     cwg_defects.html#656">656</A>,
<A HREF="
     cwg_defects.html#657">657</A>,
<A HREF="
     cwg_defects.html#658">658</A>,
<A HREF="
     cwg_defects.html#659">659</A>,
<A HREF="
     cwg_defects.html#660">660</A>,
<A HREF="
     cwg_defects.html#661">661</A>,
<A HREF="
     cwg_closed.html#662">662</A>,
<A HREF="
     cwg_defects.html#663">663</A>,
<A HREF="
     cwg_defects.html#664">664</A>,
<A HREF="
     cwg_defects.html#665">665</A>, and
<A HREF="
     cwg_defects.html#666">666</A>.
</LI>

<LI><B>Revision 51, 2007-10-09:</B> Reflected deliberations from the Kona
(October, 2007) meeting.  Added new issues
<A HREF="
     cwg_defects.html#652">652</A> and <A HREF="
     cwg_defects.html#653">653</A>.
</LI>

<LI><B>Revision 50, 2007-09-09:</B> Updated section reference numbers to use
the numbering of the most recent working draft and added text identifying
the document number of that draft at the beginning of each issues
list document.  Updated <A HREF="
     cwg_defects.html#475">issue 475</A>
with discussion regarding the point at which
<TT>std::uncaught_exception()</TT> becomes <TT>false</TT>.  Added new issues
<A HREF="
     cwg_defects.html#642">642</A>,
<A HREF="
     cwg_closed.html#643">643</A>,
<A HREF="
     cwg_defects.html#644">644</A>,
<A HREF="
     cwg_defects.html#645">645</A>,
<A HREF="
     cwg_closed.html#646">646</A>,
<A HREF="
     cwg_defects.html#647">647</A>,
<A HREF="
     cwg_defects.html#648">648</A>,
<A HREF="
     cwg_defects.html#649">649</A>,
<A HREF="
     cwg_defects.html#650">650</A>, and
<A HREF="
     cwg_defects.html#651">651</A>.
</LI>

<LI><B>Revision 49, 2007-08-05:</B> Reflected deliberations from the
Toronto (July, 2007) meeting.  Added additional discussion to issues
<A HREF="
     cwg_active.html#219">219</A> and <A HREF="
     cwg_defects.html#339">339</A>.
Added new issues
<A HREF="
     cwg_defects.html#637">637</A>,
<A HREF="
     cwg_defects.html#638">638</A>,
<A HREF="
     cwg_defects.html#639">639</A>,
<A HREF="
     cwg_active.html#640">640</A>, and
<A HREF="
     cwg_defects.html#641">641</A>.
</LI>

<LI><B>Revision 48, 2007-06-24:</B> Added new issues
<A HREF="
     cwg_defects.html#632">632</A>,
<A HREF="
     cwg_defects.html#633">633</A>,
<A HREF="
     cwg_defects.html#634">634</A>,
<A HREF="
     cwg_closed.html#635">635</A>, and
<A HREF="
     cwg_active.html#636">636</A>.
</LI>

<LI><B>Revision 47, 2007-05-06:</B> Reflected deliberations from the
Oxford (April, 2007) meeting.
Added new issues
<A HREF="
     cwg_defects.html#626">626</A>,
<A HREF="
     cwg_closed.html#627">627</A>,
<A HREF="
     cwg_defects.html#628">628</A>,
<A HREF="
     cwg_defects.html#629">629</A>,
<A HREF="
     cwg_defects.html#630">630</A>, and
<A HREF="
     cwg_active.html#631">631</A>.
</LI>

<LI><B>Revision 46, 2007-03-11:</B> Added proposed wording to
<A HREF="
     cwg_defects.html#495">issue 495</A> and moved it to
&#8220;review&#8221; status.  Added new issues
<A HREF="
     cwg_defects.html#612">612</A>,
<A HREF="
     cwg_defects.html#613">613</A>,
<A HREF="
     cwg_defects.html#614">614</A>,
<A HREF="
     cwg_defects.html#615">615</A>,
<A HREF="
     cwg_active.html#616">616</A>,
<A HREF="
     cwg_active.html#617">617</A>,
<A HREF="
     cwg_defects.html#618">618</A>,
<A HREF="
     cwg_defects.html#619">619</A>,
<A HREF="
     cwg_defects.html#620">620</A>,
<A HREF="
     cwg_defects.html#621">621</A>,
<A HREF="
     cwg_closed.html#622">622</A>,
<A HREF="
     cwg_closed.html#623">623</A>,
<A HREF="
     cwg_defects.html#624">624</A>, and
<A HREF="
     cwg_defects.html#625">625</A>.
</LI>

<LI><B>Revision 45, 2007-01-14:</B> Changed the status of
<A HREF="
     cwg_defects.html#78">issue 78</A> from TC1 to WP.
Added new issues
<A HREF="
     cwg_defects.html#603">603</A>,
<A HREF="
     cwg_defects.html#604">604</A>,
<A HREF="
     cwg_defects.html#605">605</A>,
<A HREF="
     cwg_defects.html#606">606</A>,
<A HREF="
     cwg_active.html#607">607</A>,
<A HREF="
     cwg_defects.html#608">608</A>,
<A HREF="
     cwg_active.html#609">609</A>,
<A HREF="
     cwg_closed.html#610">610</A>, and
<A HREF="
     cwg_active.html#611">611</A>.
</LI>

<LI><B>Revision 44, 2006-11-05:</B> Reflected deliberations from the
Portland (October, 2006) meeting.  Added proposed wording for issues
<A HREF="
     cwg_defects.html#288">288</A>,
<A HREF="
     cwg_active.html#342">342</A>, and
<A HREF="
     cwg_active.html#572">572</A>, and moved them to &#8220;review&#8221;
status.  Added new issues
<A HREF="
     cwg_active.html#596">596</A>,
<A HREF="
     cwg_active.html#597">597</A>,
<A HREF="
     cwg_defects.html#598">598</A>,
<A HREF="
     cwg_defects.html#599">599</A>,
<A HREF="
     cwg_active.html#600">600</A>,
<A HREF="
     cwg_defects.html#601">601</A>, and
<A HREF="
     cwg_active.html#602">602</A>.
</LI>

<LI><B>Revision 43, 2006-09-09:</B> Updated issues
<A HREF="
     cwg_defects.html#218">218</A>,
<A HREF="
     cwg_defects.html#357">357</A>, and
<A HREF="
     cwg_defects.html#537">537</A> with additional discussion and proposed
resolutions and moved them to &#8220;review&#8221; status; added issues
<A HREF="
     cwg_defects.html#589">589</A>,
<A HREF="
     cwg_active.html#590">590</A>,
<A HREF="
     cwg_active.html#591">591</A>,
<A HREF="
     cwg_defects.html#592">592</A>,
<A HREF="
     cwg_closed.html#593">593</A>,
<A HREF="
     cwg_defects.html#594">594</A>, and
<A HREF="
     cwg_active.html#595">595</A>.
</LI>

<LI><B>Revision 42, 2006-06-23:</B> Updated issues
<A HREF="
     cwg_defects.html#408">408</A> and <A HREF="
     cwg_defects.html#561">561</A> with
additional discussion; added a reference to a paper on the topic to
<A HREF="
     cwg_closed.html#567">issue 567</A>; and added issues
<A HREF="
     cwg_active.html#578">578</A>,
<A HREF="
     cwg_active.html#579">579</A>,
<A HREF="
     cwg_active.html#580">580</A>,
<A HREF="
     cwg_active.html#581">581</A>,
<A HREF="
     cwg_defects.html#582">582</A>,
<A HREF="
     cwg_active.html#583">583</A>,
<A HREF="
     cwg_closed.html#584">584</A>,
<A HREF="
     cwg_closed.html#585">585</A>,
<A HREF="
     cwg_closed.html#586">586</A>,
<A HREF="
     cwg_defects.html#587">587</A>, and
<A HREF="
     cwg_defects.html#588">588</A>.
</LI>

<LI><B>Revision 41, 2006-04-22:</B> Reflected deliberations from the
Berlin (April, 2006) meeting.  Added issues
<A HREF="
     cwg_active.html#562">562</A>,
<A HREF="
     cwg_active.html#563">563</A>,
<A HREF="
     cwg_defects.html#564">564</A>,
<A HREF="
     cwg_active.html#565">565</A>,
<A HREF="
     cwg_closed.html#566">566</A>,
<A HREF="
     cwg_closed.html#567">567</A>,
<A HREF="
     cwg_defects.html#568">568</A>,
<A HREF="
     cwg_defects.html#569">569</A>,
<A HREF="
     cwg_defects.html#570">570</A>,
<A HREF="
     cwg_defects.html#571">571</A>,
<A HREF="
     cwg_active.html#572">572</A>,
<A HREF="
     cwg_active.html#573">573</A>,
<A HREF="
     cwg_closed.html#574">574</A>,
<A HREF="
     cwg_defects.html#575">575</A>,
<A HREF="
     cwg_defects.html#576">576</A>, and
<A HREF="
     cwg_active.html#577">577</A>.
</LI>

<LI><B>Revision 40, 2006-02-24:</B> Updated
<A HREF="
     cwg_defects.html#540">issue 540</A> to refer to paper
J16/06-0022 = WG21 N1952 for its resolution.  Updated
<A HREF="
     cwg_active.html#453">issue 453</A> to note the need for additional
drafting.  Reopened <A HREF="
     cwg_active.html#504">issue 504</A> and broadened
its scope to include object declarations as well.  Updated
<A HREF="
     cwg_active.html#150">issue 150</A> (in &#8220;extension&#8221; status)
with additional commentary.
Added issues
<A HREF="
     cwg_closed.html#552">552</A>,
<A HREF="
     cwg_closed.html#553">553</A>,
<A HREF="
     cwg_active.html#554">554</A>,
<A HREF="
     cwg_active.html#555">555</A>,
<A HREF="
     cwg_defects.html#556">556</A>,
<A HREF="
     cwg_defects.html#557">557</A>,
<A HREF="
     cwg_defects.html#558">558</A>,
<A HREF="
     cwg_defects.html#559">559</A>,
<A HREF="
     cwg_active.html#560">560</A>, and
<A HREF="
     cwg_defects.html#561">561</A>.
</LI>

<LI><B>Revision 39, 2005-12-16:</B> Updated
<A HREF="
     cwg_defects.html#488">issue 488</A> with additional discussion.
Added issues
<A HREF="
     cwg_defects.html#538">538</A>,
<A HREF="
     cwg_active.html#539">539</A>,
<A HREF="
     cwg_defects.html#540">540</A>,
<A HREF="
     cwg_defects.html#541">541</A>,
<A HREF="
     cwg_defects.html#542">542</A>,
<A HREF="
     cwg_defects.html#543">543</A>,
<A HREF="
     cwg_closed.html#544">544</A>,
<A HREF="
     cwg_active.html#545">545</A>,
<A HREF="
     cwg_defects.html#546">546</A>,
<A HREF="
     cwg_active.html#547">547</A>,
<A HREF="
     cwg_closed.html#548">548</A>,
<A HREF="
     cwg_active.html#549">549</A>,
<A HREF="
     cwg_active.html#550">550</A>, and
<A HREF="
     cwg_defects.html#551">551</A>.
</LI>

<LI><B>Revision 38, 2005-10-22:</B> Reflected deliberations from the
Mont Tremblant (October, 2005) meeting.  Added isues
<A HREF="
     cwg_defects.html#530">530</A>,
<A HREF="
     cwg_active.html#531">531</A>,
<A HREF="
     cwg_defects.html#532">532</A>,
<A HREF="
     cwg_closed.html#533">533</A>,
<A HREF="
     cwg_defects.html#534">534</A>,
<A HREF="
     cwg_active.html#535">535</A>,
<A HREF="
     cwg_active.html#536">536</A>, and
<A HREF="
     cwg_defects.html#537">537</A>.
</LI>

<LI><B>Revision 37, 2005-08-27:</B> Added issues
<A HREF="
     cwg_active.html#523">523</A>,
<A HREF="
     cwg_defects.html#524">524</A>,
<A HREF="
     cwg_defects.html#525">525</A>,
<A HREF="
     cwg_defects.html#526">526</A>,
<A HREF="
     cwg_defects.html#527">527</A>,
<A HREF="
     cwg_active.html#528">528</A>, and
<A HREF="
     cwg_active.html#529">529</A>.
</LI>

<LI><B>Revision 36, 2005-06-27:</B> Reopened <A HREF="
     cwg_defects.html#484">issue 484</A> for additional discussion.
Added issues
<A HREF="
     cwg_defects.html#517">517</A>,
<A HREF="
     cwg_defects.html#518">518</A>,
<A HREF="
     cwg_defects.html#519">519</A>,
<A HREF="
     cwg_defects.html#520">520</A>,
<A HREF="
     cwg_defects.html#521">521</A>, and
<A HREF="
     cwg_defects.html#522">522</A>.
</LI>

<LI><B>Revision 35, 2005-05-01:</B> Reflected deliberations from
the Lillehammer (April, 2005) meeting.  Updated issues
<A HREF="
     cwg_active.html#189">189</A> and <A HREF="
     cwg_active.html#459">459</A> with additional
discussion.  Added new issues
<A HREF="
     cwg_active.html#504">504</A>,
<A HREF="
     cwg_defects.html#505">505</A>,
<A HREF="
     cwg_defects.html#506">506</A>,
<A HREF="
     cwg_closed.html#507">507</A>,
<A HREF="
     cwg_defects.html#508">508</A>,
<A HREF="
     cwg_defects.html#509">509</A>,
<A HREF="
     cwg_defects.html#510">510</A>,
<A HREF="
     cwg_active.html#511">511</A>,
<A HREF="
     cwg_active.html#512">512</A>,
<A HREF="
     cwg_defects.html#513">513</A>,
<A HREF="
     cwg_defects.html#514">514</A>,
<A HREF="
     cwg_defects.html#515">515</A>, and
<A HREF="
     cwg_defects.html#516">516</A>.
</LI>

<LI><B>Revision 34: 2005-03-06:</B> Closed <A HREF="
     cwg_closed.html#471">issue 471</A> as NAD; updated issues
<A HREF="
     cwg_defects.html#58">58</A>,
<A HREF="
     cwg_active.html#232">232</A>,
<A HREF="
     cwg_defects.html#339">339</A>,
<A HREF="
     cwg_active.html#407">407</A>, and
<A HREF="
     cwg_defects.html#494">494</A>
with additional discussion; and added new issues
<A HREF="
     cwg_active.html#498">498</A>,
<A HREF="
     cwg_defects.html#499">499</A>,
<A HREF="
     cwg_defects.html#500">500</A>,
<A HREF="
     cwg_closed.html#501">501</A>,
<A HREF="
     cwg_defects.html#502">502</A>, and
<A HREF="
     cwg_active.html#503">503</A>.
</LI>

<LI><B>Revision 33: 2005-01-14:</B> Updated <A HREF="
     cwg_active.html#36">issue 36</A> with additional discussion.  Added new
issues
<A HREF="
     cwg_defects.html#485">485</A>,
<A HREF="
     cwg_defects.html#486">486</A>,
<A HREF="
     cwg_closed.html#487">487</A>,
<A HREF="
     cwg_defects.html#488">488</A>,
<A HREF="
     cwg_closed.html#489">489</A>,
<A HREF="
     cwg_defects.html#490">490</A>,
<A HREF="
     cwg_defects.html#491">491</A>,
<A HREF="
     cwg_defects.html#492">492</A>,
<A HREF="
     cwg_defects.html#493">493</A>,
<A HREF="
     cwg_defects.html#494">494</A>,
<A HREF="
     cwg_defects.html#495">495</A>,
<A HREF="
     cwg_active.html#496">496</A>, and
<A HREF="
     cwg_defects.html#497">497</A>.
</LI>

<LI><B>Revision 32: 2004-11-07:</B> Reflected deliberations from
the Redmond (October, 2004) meeting.  Added new issues
<A HREF="
     cwg_defects.html#475">475</A>,
<A HREF="
     cwg_active.html#476">476</A>,
<A HREF="
     cwg_defects.html#477">477</A>,
<A HREF="
     cwg_closed.html#478">478</A>,
<A HREF="
     cwg_defects.html#479">479</A>,
<A HREF="
     cwg_defects.html#480">480</A>,
<A HREF="
     cwg_defects.html#481">481</A>,
<A HREF="
     cwg_active.html#482">482</A>,
<A HREF="
     cwg_active.html#483">483</A>, and
<A HREF="
     cwg_defects.html#484">484</A>.
</LI>

<LI>
<B>Revision 31: 2004-09-10:</B> Updated <A HREF="
     cwg_active.html#268">issue 268</A> with comments from WG14; added comments and changed
the status of <A HREF="
     cwg_defects.html#451">issue 451</A> back to
&#8220;open&#8221;; added discussion to issues
<A HREF="
     cwg_closed.html#334">334</A>,
<A HREF="
     cwg_defects.html#341">341</A>,
<A HREF="
     cwg_defects.html#385">385</A>,
<A HREF="
     cwg_active.html#399">399</A>, and
<A HREF="
     cwg_defects.html#430">430</A>;
and added new issues
<A HREF="
     cwg_defects.html#470">470</A>,
<A HREF="
     cwg_closed.html#471">471</A>,
<A HREF="
     cwg_active.html#472">472</A>,
<A HREF="
     cwg_active.html#473">473</A>, and
<A HREF="
     cwg_defects.html#474">474</A>.
</LI>

<LI>
<B>Revision 30: 2004-04-09:</B> Reflected deliberations from the
Sydney (March, 2004) meeting.  Added issues 461-469, updated issues
<A HREF="
     cwg_defects.html#39">39</A>,
<A HREF="
     cwg_defects.html#86">86</A>,
<A HREF="
     cwg_defects.html#257">257</A>,
<A HREF="
     cwg_defects.html#291">291</A>,
<A HREF="
     cwg_defects.html#391">391</A>,
<A HREF="
     cwg_defects.html#389">389</A>,
<A HREF="
     cwg_closed.html#435">435</A>,
<A HREF="
     cwg_defects.html#436">436</A>,
<A HREF="
     cwg_defects.html#437">437</A>,
<A HREF="
     cwg_defects.html#439">439</A>,
<A HREF="
     cwg_defects.html#441">441</A>,
<A HREF="
     cwg_defects.html#442">442</A>,
<A HREF="
     cwg_defects.html#446">446</A>,
<A HREF="
     cwg_defects.html#450">450</A>,
<A HREF="
     cwg_active.html#453">453</A>,
and
<A HREF="
     cwg_defects.html#458">458</A>.
</LI>

<LI>
<B>Revision 29: 2004-02-13:</B> Added issues 441-460, updated issues
<A HREF="
     cwg_defects.html#39">39</A>,
<A HREF="
     cwg_defects.html#291">291</A>,
<A HREF="
     cwg_defects.html#306">306</A>,
<A HREF="
     cwg_defects.html#319">319</A>,
<A HREF="
     cwg_defects.html#389">389</A>,
<A HREF="
     cwg_defects.html#394">394</A>,
<A HREF="
     cwg_defects.html#413">413</A>,
and
<A HREF="
     cwg_defects.html#417">417</A>.
</LI>

<LI>
<B>Revision 28: 2003-11-15:</B> Reflected deliberations from the
Kona (October, 2003) meeting.  Added issues 435-438.
</LI>

<LI>
<B>Revision 27: 2003-09-19:</B> Added new issues 412-434, updated
<A HREF="
     cwg_defects.html#54">issues 54</A>,
<A HREF="
     cwg_defects.html#301">301</A>,
<A HREF="
     cwg_defects.html#372">372</A>,
<A HREF="
     cwg_defects.html#382">382</A>,
<A HREF="
     cwg_defects.html#391">391</A>, and
<A HREF="
     cwg_active.html#399">399</A>.
</LI>

<LI>
<B>Revision 26: 2003-04-25:</B>  Reflected deliberations from
the Oxford (April, 2003) meeting.  Added new issues 402-411.
</LI>

<LI>
<B>Revision 25: 2003-03-03:</B> Added new issues 390-401, updated
<A HREF="
     cwg_defects.html#214">issue 214</A>.
</LI>
<LI>
<B>Revision 24: 2002-11-08:</B> Reflected deliberations from the
Santa Cruz (October, 2002) meeting.  Added new issues 379-389.
</LI>

<LI>
<B>Revision 23: 2002-09-10:</B> Added new issues 355-378, updated
<A HREF="
     cwg_defects.html#298">issue 298</A> and <A HREF="
     cwg_defects.html#214">issue 214</A>.
</LI>
<LI>
<B>Revision 22: 2002-05-10:</B> Reflected deliberations from the
Curacao (April, 2002) meeting.  Added issues 342-354.
</LI>
<LI>
<B>Revision 21: 2002-03-11:</B> Added new issues 314-341, updated issues
<A HREF="
     cwg_closed.html#132">132</A>,
<A HREF="
     cwg_defects.html#214">214</A>,
<A HREF="
     cwg_defects.html#244">244</A>,
<A HREF="
     cwg_defects.html#245">245</A>,
<A HREF="
     cwg_defects.html#254">254</A>,
<A HREF="
     cwg_active.html#255">255</A>,
<A HREF="
     cwg_defects.html#283">283</A>.
</LI>

<LI>
<B>Revision 20: 2001-11-09:</B> Reflected deliberations from the
Redmond (October, 2001) meeting.  Added issue <A HREF="
     cwg_closed.html#313">313</A>.
</LI>

<LI>
<B>Revision 19: 2001-09-12:</B> Added new issues 289-308, updated
issues <A HREF="
     cwg_defects.html#222">222</A>, <A HREF="
     cwg_defects.html#261">261</A>,
<A HREF="
     cwg_defects.html#270">270</A>.
</LI>

<LI>
<B>Revision 18: 2001-05-19:</B> Reflected deliberations from the
Copenhagen (April, 2001) meeting.  Added new issues 282-288.
</LI>

<LI>
<B>Revision 17: 2001-04-29:</B> Added new issues 276-81.
</LI>

<LI>
<B>Revision 16: 2001-03-27:</B> Updated <A HREF="
     cwg_active.html#138">issue 138</A> to discuss the interaction of <I>using-declaration</I>s
and "forward declarations."  Noted a problem with the proposed
resolution of <A HREF="
     cwg_defects.html#139">issue 139</A>.  Added some
new discussion to  <A HREF="
     cwg_defects.html#115">issue 115</A>.  Added
proposed resolution for <A HREF="
     cwg_defects.html#160">issue 160</A>.  Updated
address of C++ FAQ.  Added new issues 265-275.
</LI>

<LI>
<B>Revision 15: 2000-11-18:</B> Reflected deliberations from the
Toronto (October, 2000) meeting; moved the discussion of empty and
fully-initialized const objects from <A HREF="
     cwg_defects.html#78">issue 78</A> into <A HREF="
     cwg_active.html#253">new issue 253</A>;
added new issues 254-264.
</LI>

<LI>
<B>Revision 14: 2000-10-21:</B> Added issues 246-252; added an extra
question to <A HREF="
     cwg_defects.html#221">issue 221</A> and changed its
status back to "review."
</LI>

<LI>
<B>Revision 13: 2000-09-16:</B> Added issues 229-245; changed status
of <A HREF="
     cwg_defects.html#106">issue 106</A> to "review" because of problem
detected in proposal; added wording for issues <A HREF="
     cwg_defects.html#87">87</A> and <A HREF="
     cwg_defects.html#216">216</A> and moved to "review"
status; updated discussion of issues
<A HREF="
     cwg_defects.html#5">5</A>,
<A HREF="
     cwg_defects.html#78">78</A>,
<A HREF="
     cwg_defects.html#198">198</A>,
<A HREF="
     cwg_active.html#203">203</A>, and
<A HREF="
     cwg_defects.html#222">222</A>.
</LI>

<LI>
<B>Revision 12: 2000-05-21:</B> Reflected deliberations from the
Tokyo (April, 2000) meeting; added new issues 222-228.
</LI>

<LI>
<B>Revision 11, 2000-04-13:</B> Added proposed wording and moved
issues
<A HREF="
     cwg_defects.html#62">62</A>,
<A HREF="
     cwg_defects.html#73">73</A>,
<A HREF="
     cwg_defects.html#89">89</A>,
<A HREF="
     cwg_defects.html#94">94</A>,
<A HREF="
     cwg_defects.html#106">106</A>,
<A HREF="
     cwg_defects.html#121">121</A>,
<A HREF="
     cwg_defects.html#134">134</A>,
<A HREF="
     cwg_defects.html#142">142</A>, and
<A HREF="
     cwg_defects.html#145">145</A>
to "review" status.  Moved <A HREF="
     cwg_closed.html#13">issue 13</A>
from "extension" to "open" status because of recent additional
discussion.
Added new issues 217-221.
</LI>

<LI>
<B>Revision 10, 2000-03-21:</B> Split the issues list and indices into
multiple documents.  Added further discussion to issues
<A HREF="
     cwg_defects.html#84">84</A> and <A HREF="
     cwg_defects.html#87">87</A>.
Added proposed wording and moved issues
<A HREF="
     cwg_defects.html#1">1</A>,
<A HREF="
     cwg_defects.html#69">69</A>,
<A HREF="
     cwg_defects.html#85">85</A>,
<A HREF="
     cwg_defects.html#98">98</A>,
<A HREF="
     cwg_defects.html#105">105</A>,
<A HREF="
     cwg_defects.html#113">113</A>,
<A HREF="
     cwg_closed.html#132">132</A>, and
<A HREF="
     cwg_defects.html#178">178</A>
to "review" status.
Added new issues 207-216.
</LI>

<LI><B>Revision 9, 2000-02-23:</B> Incorporated decisions from the
October, 1999 meeting of the Committee;

added issues 174 through 206.</LI>

<LI><B>Revision 8, 1999-10-13:</B> Minor editorial changes to issues
<A HREF="
     cwg_defects.html#90">90</A> and
<A HREF="
     cwg_defects.html#24">24</A>; updated issue
<A HREF="
     cwg_defects.html#89">89</A> to include a related question;
added issues
<A HREF="
     cwg_closed.html#169">169</A>,
<A HREF="
     cwg_active.html#170">170</A>,
<A HREF="
     cwg_defects.html#171">171</A>,
<A HREF="
     cwg_defects.html#172">172</A>, and
<A HREF="
     cwg_defects.html#173">173</A>.</LI>

<LI><B>Revision 7, 1999-09-14:</B> Removed unneeded change to
14.7.3 [temp.expl.spec] paragraph 9 from
<A HREF="
     cwg_defects.html#24">issue 24</A>; changed
<A HREF="
     cwg_defects.html#85">issue 85</A> to refer to
3.4.4 [basic.lookup.elab];
added issues
<A HREF="
     cwg_defects.html#122">122</A>,
<A HREF="
     cwg_defects.html#123">123</A>,
<A HREF="
     cwg_defects.html#124">124</A>,
<A HREF="
     cwg_defects.html#125">125</A>,
<A HREF="
     cwg_defects.html#126">126</A>,
<A HREF="
     cwg_defects.html#127">127</A>,
<A HREF="
     cwg_defects.html#128">128</A>,
<A HREF="
     cwg_active.html#129">129</A>,
<A HREF="
     cwg_closed.html#130">130</A>,
<A HREF="
     cwg_defects.html#131">131</A>,
<A HREF="
     cwg_closed.html#132">132</A>,
<A HREF="
     cwg_closed.html#133">133</A>,
<A HREF="
     cwg_defects.html#134">134</A>,
<A HREF="
     cwg_defects.html#135">135</A>,
<A HREF="
     cwg_defects.html#136">136</A>,
<A HREF="
     cwg_defects.html#137">137</A>,
<A HREF="
     cwg_active.html#138">138</A>,
<A HREF="
     cwg_defects.html#139">139</A>,
<A HREF="
     cwg_defects.html#140">140</A>,
<A HREF="
     cwg_defects.html#141">141</A>,
<A HREF="
     cwg_defects.html#142">142</A>,
<A HREF="
     cwg_defects.html#143">143</A>,
<A HREF="
     cwg_active.html#144">144</A>,
<A HREF="
     cwg_defects.html#145">145</A>,
<A HREF="
     cwg_active.html#146">146</A>,
<A HREF="
     cwg_defects.html#147">147</A>,
<A HREF="
     cwg_defects.html#148">148</A>,
<A HREF="
     cwg_defects.html#149">149</A>,
<A HREF="
     cwg_active.html#150">150</A>,
<A HREF="
     cwg_defects.html#151">151</A>,
<A HREF="
     cwg_defects.html#152">152</A>,
<A HREF="
     cwg_defects.html#153">153</A>,
<A HREF="
     cwg_closed.html#154">154</A>,
<A HREF="
     cwg_closed.html#155">155</A>,
<A HREF="
     cwg_active.html#156">156</A>,
<A HREF="
     cwg_active.html#157">157</A>,
<A HREF="
     cwg_defects.html#158">158</A>,
<A HREF="
     cwg_defects.html#159">159</A>,
<A HREF="
     cwg_defects.html#160">160</A>,
<A HREF="
     cwg_defects.html#161">161</A>,
<A HREF="
     cwg_defects.html#162">162</A>,
<A HREF="
     cwg_defects.html#163">163</A>,
<A HREF="
     cwg_defects.html#164">164</A>,
<A HREF="
     cwg_closed.html#165">165</A>,
<A HREF="
     cwg_defects.html#166">166</A>,
<A HREF="
     cwg_closed.html#167">167</A>, and
<A HREF="
     cwg_closed.html#168">168</A>.</LI>

<LI><B>Revision 6, 1999-05-31:</B> Moved
<A HREF="
     cwg_closed.html#72">issue 72</A> to "dup" status; added
proposed wording and moved <A HREF="
     cwg_defects.html#90">issue 90</A>
to "review" status; updated <A HREF="
     cwg_defects.html#98">issue 98</A>
with additional question; added issues
<A HREF="
     cwg_active.html#110">110</A>,
<A HREF="
     cwg_active.html#111">111</A>,
<A HREF="
     cwg_defects.html#112">112</A>,
<A HREF="
     cwg_defects.html#113">113</A>,
<A HREF="
     cwg_closed.html#114">114</A>,
<A HREF="
     cwg_defects.html#115">115</A>,
<A HREF="
     cwg_defects.html#116">116</A>,
<A HREF="
     cwg_closed.html#117">117</A>,
<A HREF="
     cwg_defects.html#118">118</A>,
<A HREF="
     cwg_defects.html#119">119</A>,
<A HREF="
     cwg_defects.html#120">120</A>, and
<A HREF="
     cwg_defects.html#121">121</A>.</LI>

<LI><B>Revision 5, 1999-05-24:</B> Reordered issues by status; added revision
history; first public version.</LI>
</UL>

<A NAME="Issue Status"></A>
<H3>Issue status</H3>

<P>Issues progress through various statuses as the Core Language
Working Group and, ultimately, the full PL22.16 and WG21 committees
deliberate and act.  For ease of reference, issues are grouped in these
documents by their status.  Issues have one of the following statuses:</P>

<P><B>Open:</B> The issue is new or the working group has not yet
formed an opinion on the issue.  If a <I>Suggested Resolution</I> is
given, it reflects the opinion of the issue's submitter, not
necessarily that of the working group or the Committee as a whole.</P>

<P><B>Drafting:</B> Informal consensus has been reached in the
working group and is described in rough terms in a <I>Tentative
Resolution</I>, although precise wording for the change is not yet
available.</P>

<P><B>Review:</B> Exact wording of a <I>Proposed Resolution</I> is now
available for an issue on which the working group previously reached
informal consensus.</P>

<P><B>Ready:</B> The working group has reached consensus that the
issue is a defect in the Standard, the <I>Proposed Resolution</I> is
correct, and the issue is ready to forward to the full Committee for
ratification as a proposed defect report.</P>

<P><B>Tentatively Ready:</B> Like "ready" except that the resolution
was produced and approved by a subset of the working group membership
between meetings.  Persons not participating in these betwee-meeting
activities are encouraged to review such resolutions carefully and to
alert the working group with any problems that may be found.</P>

<P><B>DR:</B> The full Committee has approved the item as a proposed
defect report.  The <I>Proposed Resolution</I> in an issue with this
status reflects the best judgment of the Committee at this time
regarding the action that will be taken to remedy the defect; however,
the current wording of the Standard remains in effect until such time
as a <I>Technical Corrigendum</I> or a revision of the Standard is
issued by ISO.</P>

<P><B>TC1:</B> A DR issue included in Technical Corrigendum 1.
TC1 is a revision of the Standard issued in 2003.</P>

<P><B>CD1:</B> A DR issue not resolved in TC1 but included in
Committee Draft 1.  CD1 was advanced for balloting at the
September, 2008 WG21 meeting.</P>

<P><B>CD2:</B> A DR issue not resolved in CD1 but included in
the Final Committee Draft advanced for balloting at the
March, 2010 WG21 meeting.</P>

<P><B>WP:</B> A DR issue whose resolution is reflected in
the current Working Paper.  The Working Paper is a draft for a
future version of the Standard.</P>

<P><B>Dup:</B> The issue is identical to or a subset of another issue,
identified in a <I>Rationale</I> statement.</P>

<P><B>NAD:</B> The working group has reached consensus that the issue
is not a defect in the Standard. A <I>Rationale</I> statement
describes the working group's reasoning.</P>

<P><B>Extension:</B> The working group has reached consensus that the
issue is not a defect in the Standard but is a request for an
extension to the language.  The working group
expresses no opinion on the merits of an issue with this status;
however, the issue will be maintained on the list for possible future
consideration as an extension proposal.</P>

<P><B>Concepts:</B> The issue relates to the &#8220;Concepts&#8221;
proposal that was removed from the working paper at the Frankfurt (July,
2009) meeting and hence is no longer under consideration.
</P>
<HR><A NAME="Ready Status"></A><H3>Issues with "Ready" Status</H3>
<HR><A NAME="1111"></A><H4>1111.
  
Remove dual-scope lookup of member template names
</H4><B>Section: </B>3.4.5&#160; [basic.lookup.classref]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US23">N3092 comment
  US&#160;23<BR></A>

<P>According to 3.4.5 [basic.lookup.classref] paragraph 1,</P>

<BLOCKQUOTE>

<P>In a class member access expression (5.2.5 [expr.ref]), if the <TT>.</TT> or <TT>-&gt;</TT> token is
immediately followed by an identifier followed by a
<TT>&lt;</TT>, the identifier must be looked up to determine
whether the <TT>&lt;</TT> is the beginning of a template
argument list (14.2 [temp.names]) or a less-than
operator.  The identifier is first looked up in the class of
the object expression.  If the identifier is not found, it
is then looked up in the context of the entire
<I>postfix-expression</I> and shall name a class template.
If the lookup in the class of the object expression finds a
template, the name is also looked up in the context of the
entire <I>postfix-expression</I> and</P>

<UL><LI><P>if the name is not found, the name found in the
class of the object expression is used, otherwise</P></LI>

<LI><P>if the name is found in the context of the entire
<I>postfix-expression</I> and does not name a class
template, the name found in the class of the object
expression is used, otherwise</P></LI>

<LI><P>if the name found is a class template, it shall refer to
the same entity as the one found in the class of the object
expression, otherwise the program is ill-formed.</P></LI></UL>

</BLOCKQUOTE>

<P>This makes the following ill-formed:</P>

<PRE>
    #include &lt;set&gt;
    using std::set;
    struct X {
      template &lt;typename T&gt; void set(const T&amp; value);
    };
    void foo() {
      X x;
      x.set&lt;double&gt;(3.2);
    }
</PRE>

<P>That's confusing and unnecessary.  The compiler has already done
the lookup in <TT>X</TT>'s scope, and the obviously-correct
resolution is that one, not the identifier from the
<I>postfix-expression</I>'s scope.  <A HREF="
     cwg_defects.html#305">Issue 305</A>
fixed a similar issue for destructor names but missed member functions.</P>

<P><U>Suggested resolution</U>: Delete the end of paragraph 1, starting
with &#8220;If the lookup in the class...&#8221; and including all
three bullets.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Change 3.4.3.1 [class.qual] paragraph 1 bullet 2 as
follows:</P></LI>

<UL><LI><P>a <I>conversion-type-id</I> of a<SPAN style="text-decoration:line-through;background-color:#FFA0A0">n</SPAN>
<I>conversion-function-id</I> is looked up <SPAN style="text-decoration:line-through;background-color:#FFA0A0">both in the scope of
the class and in the context in which the entire
<I>postfix-expression</I> occurs and shall refer to the same type in
both contexts</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">in the same manner as a
<I>conversion-type-id</I> in a class member access (see 3.4.5 [basic.lookup.classref])</SPAN>;</P></LI></UL>

<LI><P>Change 3.4.5 [basic.lookup.classref] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>In a class member access expression (5.2.5 [expr.ref]),
if the <TT>.</TT> or <TT>-&gt;</TT> token is immediately followed by
an <I>identifier</I> followed by a <TT>&lt;</TT>, the identifier must
be looked up to determine whether the <TT>&lt;</TT> is the beginning
of a template argument list (14.2 [temp.names]) or a less-than
operator.  The identifier is first looked up in the class of the
object expression.  If the identifier is not found, it is then looked
up in the context of the entire <I>postfix-expression</I> and shall
name a class template.  <SPAN style="text-decoration:line-through;background-color:#FFA0A0">If the lookup in the class of the object
expression finds a template, the name is also looked up in the context
of the entire <I>postfix-expression</I> and</SPAN></P>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">if the name is not found, the name found in the class
of the object expression is used, otherwise</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">if the name is found in the context of the entire
<I>postfix-expression</I> and does not name a class template, the name
found in the class of the object expression is used,
otherwise</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">if the name found is a class template, it shall refer to
the same entity as the one found in the class of the object
expression, otherwise the program is ill-formed.</SPAN></P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 3.4.5 [basic.lookup.classref] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

<P>If the <I>id-expression</I> in a class member access is a
<I>qualified-id</I> of the form</P>

<PRE>
    class-name-or-namespace-name::...
</PRE>

<P>the <I>class-name-or-namespace-name</I> following the <TT>.</TT> or
<TT>-&gt;</TT> operator is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">looked up both in the context of the entire
<I>postfix-expression</I> and in the scope of the class of the object
expression. If the name is found only in the scope of the class of the
object expression, the name shall refer to a <I>class-name</I>.  If
the name is found only in the context of the entire
<I>postfix-expression</I>, the name shall refer to a <I>class-name</I>
or <I>namespace-name</I>.  If the name is found in both contexts, the
<I>class-name-or-namespace-name</I> shall refer to the same
entity.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">first looked up in the class of the object
expression and the name, if found, is used. Otherwise it is looked up
in the context of the entire <I>postfix-expression</I>. [<I>Note:</I>
See 3.4.3 [basic.lookup.qual], which describes the lookup of a name
before <TT>::</TT>, which will only find a type or namespace
name. &#8212;<I>end note</I>]</SPAN></P>

</BLOCKQUOTE>

<LI><P>Change 3.4.5 [basic.lookup.classref] paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

<P>If the <I>id-expression</I> is a <I>conversion-function-id</I>, its
<I>conversion-type-id</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall denote the same type in both the
context in which the entire <I>postfix-expression</I> occurs and in
the context of the class of the object expression (or the class
pointed to by the pointer expression).</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is first looked up in
the class of the object expression and the name, if found and denotes
a type, is used. Otherwise it is looked up in the context of the
entire <I>postfix-expression</I> and the name shall denote a type.
[<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  struct A { };
  namespace N {
    struct A {
      void g() { }
      template &lt;class T&gt; operator T();
    };
  }

  int main() {
    N::A a;
    a.operator A();    //<SPAN style="font-family:Times;font-style:italic"> calls </SPAN>N::A::operator N::A
  }</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1187"></A><H4>1187.
  
Problems in initialization example
</H4><B>Section: </B>3.6.2&#160; [basic.start.init]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-31<BR>




<P>The note in 3.6.2 [basic.start.init] paragraph 3 contains the
following example:</P>

<PRE>
  inline double fd() { return 1.0; }
  extern double d1;
  double d2 = d1;     //<SPAN style="font-family:Times;font-style:italic"> unspecified:</SPAN>
                      //<SPAN style="font-family:Times;font-style:italic"> may be statically initialized to </SPAN>0.0<SPAN style="font-family:Times;font-style:italic"> or</SPAN>
                      //<SPAN style="font-family:Times;font-style:italic"> dynamically initialized to </SPAN>1.0
  double d1 = fd();   //<SPAN style="font-family:Times;font-style:italic"> may be initialized statically to </SPAN>1.0
</PRE>

<P>The comment for <TT>d2</TT> overlooks the third possibility: if
both <TT>d1</TT> and <TT>d2</TT> are dynamically initialized, <TT>d2</TT>
will be initialized to <TT>0</TT>.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change the comments in the example in 3.6.2 [basic.start.init]
paragraph 3 as follows:</P>

<PRE>
  inline double fd() { return 1.0; }
  extern double d1;
  double d2 = d1;     //<SPAN style="font-family:Times;font-style:italic"> unspecified:</SPAN>
                      //<SPAN style="font-family:Times;font-style:italic"> may be statically initialized to </SPAN>0.0<SPAN style="font-family:Times;font-style:italic"> or</SPAN>
                      //<SPAN style="font-family:Times;font-style:italic"> dynamically initialized <SPAN style="text-decoration:line-through;background-color:#FFA0A0">to </SPAN></SPAN><SPAN style="text-decoration:line-through;background-color:#FFA0A0">1.0</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><SPAN style="font-family:Times;font-style:italic">to </SPAN>0.0<SPAN style="font-family:Times;font-style:italic"> if </SPAN>d1<SPAN style="font-family:Times;font-style:italic"> is dynamically initialized, or </SPAN>1.0<SPAN style="font-family:Times;font-style:italic"> otherwise</SPAN></SPAN>
  double d1 = fd();   //<SPAN style="font-family:Times;font-style:italic"> may be initialized statically <SPAN style="font-weight:bold;background-color:#A0FFA0">or dynamically</SPAN> to </SPAN>1.0
</PRE>

<P>(The note should also be in running text following the bulleted list
instead of appearing as a bulleted item, as well.)</P>

<BR><BR><HR><A NAME="981"></A><H4>981.
  
Constexpr constructor templates and literal types
</H4><B>Section: </B>3.9&#160; [basic.types]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>16 October, 2009<BR>




<P>3.9 [basic.types] paragraph 10 requires that a class have at
least one constexpr constructor other than the copy constructor in
order to be considered a literal type.  However, a constexpr
constructor template might be instantiated in such a way that the
<TT>constexpr</TT> specifier is ignored (7.1.5 [dcl.constexpr]
paragraph 5).  It is therefore not known whether a class with a
constexpr constructor template is a literal type or not until the
constructor template is specialized, which could mean that an example
like</P>

<PRE>
    struct IntValue {
      template&lt;typename T&gt;
        constexpr IntValue(T t) : val(t) { }

      constexpr intmax_t get_value() { return val; }
     
     private:
       intmax_t val;
    };
</PRE>

<P>is ill-formed, because it is an error to declare a member function
(like <TT>get_value()</TT>) of a non-literal class to be constexpr
(7.1.5 [dcl.constexpr] paragraph 6).</P>

<P>3.9 [basic.types] paragraph 10 should be revised so that
either a constexpr constructor or constexpr constructor template
allows a class to be a literal type.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 3.9 [basic.types] paragraph 10 as follows:</P>

<BLOCKQUOTE>

<P>A type is a <I>literal type</I> if it is:</P>

<UL><LI><P>a scalar type; or</P></LI>

<LI><P>a class type (Clause 9 [class]) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">with</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">that</SPAN></P></LI>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a trivial copy constructor,</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">no non-trivial move constructor,</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">has</SPAN> a trivial destructor,</P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a trivial default constructor or</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is an aggregate
type (8.5.1 [dcl.init.aggr]) or has</SPAN> at least one constexpr
constructor <SPAN style="text-decoration:line-through;background-color:#FFA0A0">other than the</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">or constructor template that
is not a</SPAN> copy or move constructor, and</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">has</SPAN> all non-static data members and base classes of
literal types; or</P></LI>

</UL>

<LI><P>an array of literal type.</P></LI>

</UL>

</BLOCKQUOTE>

<P>This resolution also resolves issues <A HREF="
     cwg_active.html#1071">1071</A>
and <A HREF="
     cwg_active.html#1198">1198</A>.</P>

<BR><BR><HR><A NAME="1071"></A><H4>1071.
  
Literal class types and trivial default constructors
</H4><B>Section: </B>3.9&#160; [basic.types]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-02<BR>




<P>According to 3.9 [basic.types] paragraph 10, one of the
requirements for a literal class type is</P>

<UL><LI><P>a trivial default constructor or at least one constexpr
constructor other than the copy or move constructor</P></LI></UL>

<P>This rule has unfortunate consequences.  For example, in</P>

<PRE>
    struct A { int x; };
    struct B: A { int y; };
</PRE>

<P><TT>B</TT> is a literal type, even though it is impossible to
initialize a constant of that type.  Conversely, in</P>

<PRE>
    struct C {
        int a, b;
        constexpr C(int x, int y): a(x), b(y) { }
    };
    struct D {
        int x;
        C c;
    };
</PRE>

<P><TT>D</TT> is not a literal type, even though it could be
initialized as an aggregate.</P>

<P>It would be an improvement to replace the requirement for a
trivial default constructor with a requirement that the class be
an aggregate.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#981">issue 981</A>.</P>

<BR><BR><HR><A NAME="1198"></A><H4>1198.
  
Literal types and copy constructors
</H4><B>Section: </B>3.9&#160; [basic.types]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-16<BR>




<P>According to 3.9 [basic.types] paragraph 10, a literal
class type has</P>

<UL><LI><P>a trivial copy constructor,</P></LI>

<LI><P>no non-trivial move constructor,</P></LI>

<LI><P>...</P></LI>

</UL>

<P>Is this intended to mean that</P>

<PRE>
    struct A {
       A(const A&amp;) = default;
       A(A&amp;);
    };
</PRE>

<P>is a literal class because it does have a trivial copy constructor
even though it also has a non-trivial one?  That seems inconsistent
with the prohibition of non-trivial move constructors.</P>

<P>My preference would be to resolve this inconsistency by dropping
the restriction on non-trivial move constructors.  It seems to me that
having a trivial copy or move constructor is sufficient, we don't need
to prohibit additional non-trivial ones.  Actually, it's not clear to
me that we need the first condition either; a literal type could be
used for singleton variables even if it can't be copied.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#981">issue 981</A>.</P>

<BR><BR><HR><A NAME="1094"></A><H4>1094.
  
Converting floating-point values to scoped enumeration types
</H4><B>Section: </B>5.2.9&#160; [expr.static.cast]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-07-17<BR>




<P>According to 7.2 [dcl.enum] paragraph 10,</P>

<BLOCKQUOTE>

An expression of arithmetic or enumeration type can be
converted to an enumeration type explicitly.

</BLOCKQUOTE>

<P>However, 5.2.9 [expr.static.cast] paragraph 10 says only,</P>

<BLOCKQUOTE>

A value of integral or enumeration type can be explicitly
converted to an enumeration type.

</BLOCKQUOTE>

<P>This omits floating-point values.  Presumably unscoped
enumeration types are covered by paragraph 7,</P>

<BLOCKQUOTE>

The inverse of any standard conversion sequence (Clause
4 [conv]), other than the lvalue-to-rvalue
(4.1 [conv.lval]), array-to- pointer (4.2 [conv.array]), function-to-pointer (4.3 [conv.func]), and boolean (4.12 [conv.bool])
conversions, can be performed explicitly using
<TT>static_cast</TT>.

</BLOCKQUOTE>

<P>because 4.9 [conv.fpint] paragraph 2 allows an
unscoped enumeration value to be implicitly converted to a
floating point type.  (Although that also covers the integral
types, so it's not clear why they would be mentioned
specifically in 5.2.9 [expr.static.cast] paragraph 10.)
However, this should presumably say &#8220;arithmetic&#8221;
instead of &#8220;integral&#8221; to match the statement in
7.2 [dcl.enum] paragraph 10.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Change 5.2.9 [expr.static.cast] paragraph 10 as follows:</P></LI>

<BLOCKQUOTE>

A value of integral or enumeration type can be explicitly converted to
an enumeration type.  The value is unchanged if the original value is
within the range of the enumeration values (7.2 [dcl.enum]). Otherwise, the resulting <SPAN style="text-decoration:line-through;background-color:#FFA0A0">enumeration</SPAN> value is
unspecified <SPAN style="font-weight:bold;background-color:#A0FFA0">(and might not be in that range). A value of
floating-point type can also be converted to an enumeration type. The
resulting value is the same as converting the original value to the
underlying type of the enumeration (4.9 [conv.fpint]), and
subsequently to the enumeration type</SPAN>.

</BLOCKQUOTE>

<LI><P>Add the following footnote to the end of 7.2 [dcl.enum]
paragraph 7:</P></LI>

<BLOCKQUOTE>

...If the <I>enumerator-list</I> is empty, the values of the
enumeration are as if the enumeration had a single enumerator with
value 0. <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Footnote:</I> This set of values is used to define
promotion and conversion semantics for the enumeration type; it does
not exclude an expression of enumeration type from having a value that
falls outside this range. &#8212;<I>end footnote</I>]</SPAN>

</BLOCKQUOTE>

<LI><P>Delete 7.2 [dcl.enum] paragraph 10:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">An expression of arithmetic or enumeration type can be converted
to an enumeration type explicitly.  The value is unchanged if it is in
the range of enumeration values of the enumeration type; otherwise the
resulting enumeration value is unspecified.</SPAN>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="573"></A><H4>573.
  
Conversions between function pointers and <TT>void*</TT>
</H4><B>Section: </B>5.2.10&#160; [expr.reinterpret.cast]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>13 April 2006<BR>


<P>The resolution to <A HREF="
     cwg_defects.html#195">issue 195</A> makes
&#8220;converting a pointer to a function into a pointer to an object
type or vice versa&#8221; conditionally-supported behavior.  In doing
so, however, it overlooked the fact that <TT>void</TT> is not an
&#8220;object type&#8221; (3.9 [basic.types] paragraph 9).
The wording should be amended to allow conversion to and
from <TT>void*</TT> types.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Change 3.7.4.3 [basic.stc.dynamic.safety] paragraphs 1-2 as
follows:</P></LI>

<BLOCKQUOTE>

<P>A <I>traceable pointer object</I> is</P>

<UL><LI><P>an object of <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>pointer-to-object</I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">an
object pointer</SPAN> type <SPAN style="font-weight:bold;background-color:#A0FFA0">(3.9.2 [basic.compound])</SPAN>,
or</P></LI>

<LI><P>an object of an integral type that is at least as large as
<TT>std::intptr_t</TT>, or</P></LI>

<LI><P>a sequence of elements in an array of character type, where the
size and alignment of the sequence match <SPAN style="text-decoration:line-through;background-color:#FFA0A0">that</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">those</SPAN> of some <SPAN style="text-decoration:line-through;background-color:#FFA0A0">pointer-to-object</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">object
pointer</SPAN> type.</P></LI>

</UL>

<P>A pointer value is a <I>safely-derived pointer</I> to a dynamic
object only if it has <SPAN style="text-decoration:line-through;background-color:#FFA0A0">pointer-to-object</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">an object
pointer</SPAN> type and it is...</P>

</BLOCKQUOTE>

<LI><P>Change 3.9.2 [basic.compound] paragraphs 3-4 as follows:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">The type of a pointer to <TT>void</TT> or a pointer to an
object type is called an <I>object pointer type</I>. [<I>Note:</I> A
pointer to <TT>void</TT> does not have a pointer-to-object type,
however, because <TT>void</TT> is not an object type. &#8212;<I>end
note</I>] The type of a pointer that can designate a function is
called a <I>function pointer type</I>.</SPAN> A pointer to objects of
type <TT>T</TT> is referred to as a &#8220;pointer to
<TT>T</TT>.&#8221; [<I>Example:</I>...</P>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">Objects of cv-qualified (3.9.3 [basic.type.qualifier]) or
cv-unqualified type <TT>void*</TT> (pointer to void),</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A
pointer to cv-qualified (3.9.3 [basic.type.qualifier]) or cv-unqualified
<TT>void</TT></SPAN> can be used to point to objects of unknown
type. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">A <TT>void*</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Such a pointer</SPAN> shall be
able to hold any object pointer. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">A cv-qualified or cv-unqualified
(3.9.3 [basic.type.qualifier])</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">An object of type
<I>cv</I></SPAN> <TT>void*</TT> shall have the same representation and
alignment requirements as <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a cv-qualified or cv-unqualified</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I></SPAN> <TT>char*</TT>.</P>

</BLOCKQUOTE>

<LI><P>Change 4.10 [conv.ptr] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...A null pointer constant can be converted to a pointer type; the
result is the <I>null pointer value</I> of that type and is
distinguishable from every other value of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">pointer to object or
pointer to function</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">object pointer or function
pointer</SPAN> type...

</BLOCKQUOTE>

<LI><P>Change 4.11 [conv.mem] paragraph 2 footnote 58 as
follows:</P></LI>

<BLOCKQUOTE>

...Note that a pointer to member is not <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a pointer to object or a
pointer to function</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">an object pointer or a function
pointer</SPAN> and...

</BLOCKQUOTE>

<LI><P>Change 5.2.10 [expr.reinterpret.cast] paragraphs 6-8 as
follows:</P></LI>

<BLOCKQUOTE>

<P>A <SPAN style="text-decoration:line-through;background-color:#FFA0A0">pointer to a</SPAN> function <SPAN style="font-weight:bold;background-color:#A0FFA0">pointer</SPAN> can be
explicitly converted to a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">pointer to a</SPAN> function
<SPAN style="font-weight:bold;background-color:#A0FFA0">pointer</SPAN> of a different type...</P>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A pointer to an</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">An</SPAN> object <SPAN style="font-weight:bold;background-color:#A0FFA0">pointer</SPAN>
can be explicitly converted to <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a pointer to a different object
type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">an object pointer of a different type</SPAN>...</P>

<P>Converting a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">pointer to a function into a pointer to an
object</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">function pointer to an object pointer</SPAN> type or
vice versa is conditionally-supported...</P>

</BLOCKQUOTE>

<LI><P>Change the note in 8.3.5 [dcl.fct] paragraph 6 as
follows:</P></LI>

<BLOCKQUOTE>

[<I>Note:</I> function types are checked during the assignments and
initializations of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">pointer-to-functions, reference-to-functions,
and pointer-to-member-functions</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">pointers to functions,
references to functions, and pointers to member
functions</SPAN>. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>In the &#8220;Index of Implementation-defined Behavior,&#8221;
change the following item as indicated:</P></LI>

<BLOCKQUOTE>

converting <SPAN style="text-decoration:line-through;background-color:#FFA0A0">pointer to function into pointer to object</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">function pointer to object pointer</SPAN> and vice versa

</BLOCKQUOTE>

</OL>

<P><I>[Drafting note: 5.3.5 [expr.delete] paragraph 1 was not
changed, so the operand of <TT>delete</TT> still cannot be a
<TT>void*</TT>.  13.6 [over.built] paragraph 14 was not
changed, so <TT>void*</TT> pointers still do not get overloads for
<TT>operator-</TT>.  14.1 [temp.param] paragraph 4 was not
changed and thus continues to allow only pointers to objects, not
object pointers, as non-type template parameters.]</I></P>

<P>(See also <A HREF="
     cwg_active.html#1120">issue 1120</A>.)</P>

<BR><BR><HR><A NAME="1120"></A><H4>1120.
  
<TT>reinterpret_cast</TT> and <TT>void*</TT>
</H4><B>Section: </B>5.2.10&#160; [expr.reinterpret.cast]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>GB
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#GB22">N3092 comment
  GB&#160;22<BR></A>

<P>It is not permitted to use <TT>reinterpret_cast</TT> to convert
between pointers to object type and pointers to <TT>void</TT>.</P>

<P>See also <A HREF="
     cwg_active.html#573">issue 573</A>.</P>

<P><B>Proposed resolution (August, 2010):</B></P>

<P>Change 5.2.10 [expr.reinterpret.cast] paragraph 7 as follows:</P>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">A pointer to an object</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">An object
pointer</SPAN> can be explicitly converted to <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a pointer
to a different object type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">an object pointer of a
different type</SPAN>.<SUP>70</SUP> When a prvalue <TT>v</TT>
of type &#8220;pointer to <TT>T1</TT>&#8221; is converted to
the type &#8220;pointer to
<I>cv</I> <TT>T2</TT>&#8221;, the result is
<TT>static_cast&lt;</TT><I>cv</I>
<TT>T2*&gt;(static_cast&lt;</TT><I>cv</I>
<TT>void*&gt;(v))</TT> if both <TT>T1</TT> and <TT>T2</TT>
are standard-layout types (3.9 [basic.types]) and the
alignment requirements of <TT>T2</TT> are no stricter than
those of <TT>T1</TT><SPAN style="font-weight:bold;background-color:#A0FFA0">, or if either type is
<TT>void</TT></SPAN>.  Converting a prvalue of type
&#8220;pointer to <TT>T1</TT>&#8221; to the type
&#8220;pointer to <TT>T2</TT>&#8221; (where <TT>T1</TT> and
<TT>T2</TT> are object types and where the alignment
requirements of <TT>T2</TT> are no stricter than those of
<TT>T1</TT>) and back to its original type yields the
original pointer value.  The result of any other such
pointer conversion is unspecified.

</BLOCKQUOTE>

<P>(Note: this resolution depends on that of <A HREF="
     cwg_active.html#573">issue 573</A>.)</P>

<BR><BR><HR><A NAME="1193"></A><H4>1193.
  
Use of address-constant pointers in constant expressions
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-02<BR>




<P>It's not clear whether the current rules for constant expressions
allow indirect calls of constexpr functions and constexpr member
functions; for example,</P>

<PRE>
    constexpr bool is_negative(int x) { return x &lt; 0; }
    constexpr bool check(int x, bool (*p)(int)) { return p(x); }
    static_assert(check(-2, is_negative), "Error");
</PRE>

<P>If this is to be permitted, there does not seem to be a reason to
prohibit equality comparison of pointers to functions or pointers to
objects of static storage duration -- these can be tracked as is
already done for non-type template parameters.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 5.19 [expr.const] paragraph 2 bullet 19 as follows:</P>

<UL><LI><P>a relational (5.9 [expr.rel]) or equality
(5.10 [expr.eq]) operator where <SPAN style="text-decoration:line-through;background-color:#FFA0A0">at least one of the
operands is a pointer</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the result is
unspecified</SPAN>;</P></LI></UL>

<BR><BR><HR><A NAME="1022"></A><H4>1022.
  
Can an enumeration variable have values outside the values of the enumeration?
</H4><B>Section: </B>7.2&#160; [dcl.enum]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-01-22<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US31">N3092 comment
  US&#160;31<BR></A>



<P>According to 7.2 [dcl.enum] paragraph 10,</P>

<BLOCKQUOTE>

An expression of arithmetic or enumeration type can be converted
to an enumeration type explicitly.  The value is unchanged if it
is in the range of enumeration values of the enumeration type;
otherwise the resulting enumeration value is unspecified.

</BLOCKQUOTE>

<P>(There is similar wording in 5.2.9 [expr.static.cast].)
Does the phrase &#8220;resulting enumeration value&#8221; mean
that the result, although unspecified, must lie within the range
of enumeration values of the enumeration type?  Existing practice
seems to allow out-of-range values to be preserved if the
underlying type is large enough to represent the value.  This
freedom is important both for efficiency (to avoid having to mask
values while storing and/or fetching) and to prevent optimizers
from removing code that tests for out-of-range values.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1094">issue 1094</A>.</P>

<BR><BR><HR><A NAME="1135"></A><H4>1135.
  
Explicitly-defaulted non-public special member functions
</H4><B>Section: </B>8.4.2&#160; [dcl.fct.def.default]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>FI
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#FI1">N3092 comment
  FI&#160;1<BR></A>

<P>It should be allowed to explicitly default a non-public
special member function on its first declaration. It is very
likely that users will want to default protected/private
constructors and copy constructors without having to write
such defaulting outside the class.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Change 8.4.2 [dcl.fct.def.default] paragraphs 1-5 as
follows:</P></LI>

<BLOCKQUOTE>

<P>A function definition of the form:</P>

<UL><I>attribute-specifier<SUB>opt</SUB> decl-specifier-seq<SUB>opt</SUB> declarator </I> <TT>= default ;</TT></UL>

<P>is called an <I>explicitly-defaulted</I> definition. A function
that is explicitly defaulted shall</P>

<UL><LI><P>be a special member function,</P></LI>

<LI><P>have the same declared function type (except for possibly
differing <I>ref-qualifier</I>s and except that in the case of a copy
constructor or copy assignment operator, the parameter type may be
&#8220;reference to non-const <TT>T</TT>&#8221;, where <TT>T</TT> is
the name of the member function's class) as if it had been
implicitly declared, <SPAN style="font-weight:bold;background-color:#A0FFA0">and</SPAN></P></LI>

<LI><P>not have default arguments<SPAN style="text-decoration:line-through;background-color:#FFA0A0">, and</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">.</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">not have an <I>exception-specification</I>.</SPAN></P></LI>

</UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">[<I>Note:</I> This implies that parameter types, return type, and
cv-qualifiers must match the hypothetical implicit declaration.
&#8212;<I>end note</I>]</SPAN></P>

<P>An explicitly-defaulted function may be declared <TT>constexpr</TT>
only if it would have been implicitly declared as
<TT>constexpr</TT><SPAN style="font-weight:bold;background-color:#A0FFA0">, and may have an explicit
<I>exception-specification</I> only if it is compatible (15.4 [except.spec]) with the <I>exception-specification</I> on the implicit
declaration</SPAN>. If <SPAN style="text-decoration:line-through;background-color:#FFA0A0">it</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a function</SPAN> is
explicitly defaulted on its first declaration,</P>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">it shall be public,</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">it shall not be explicit,</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">it shall not be virtual,</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">it is implicitly considered to be <TT>constexpr</TT>
if the implicit declaration would be,</SPAN></P></LI>

<LI><P>it is implicitly considered to have the same
<I>exception-specification</I> as if it had been implicitly declared
(15.4 [except.spec]), and</P></LI>

<LI><P>in the case of a copy constructor, move constructor, copy
assignment operator, or move assignment operator, it shall have the
same parameter type as if it had been implicitly declared.</P></LI>

</UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">[<I>Note:</I> Such a special member function may be trivial, and
thus its accessibility and explicitness should match the hypothetical
implicit definition; see below. &#8212;<I>end note</I>]</SPAN>
[<I>Example:</I></P>

<PRE>
  struct S {
<SPAN style="font-weight:bold;background-color:#A0FFA0">    constexpr S() = default;                 //<SPAN style="font-family:Times;font-style:italic">ill-formed: implicit </SPAN>S()<SPAN style="font-family:Times;font-style:italic"> is not </SPAN>constexpr</SPAN>
    S(int a = 0) = default;                  //<SPAN style="font-family:Times;font-style:italic"> ill-formed: default argument</SPAN>
    void operator=(const S&amp;) = default;      //<SPAN style="font-family:Times;font-style:italic"> ill-formed: non-matching return type</SPAN>
    ~S() throw(<SPAN style="font-weight:bold;background-color:#A0FFA0">int</SPAN>) = default;               //<SPAN style="font-family:Times;font-style:italic"> ill-formed: exception specification <SPAN style="font-weight:bold;background-color:#A0FFA0">doesn't match</SPAN></SPAN>
  private:
<SPAN style="font-weight:bold;background-color:#A0FFA0">    int i;</SPAN>
    S(S&amp;);                                   //<SPAN style="font-family:Times;font-style:italic"> OK: private copy constructor</SPAN>
  };
  S::S(S&amp;) = default;                        //<SPAN style="font-family:Times;font-style:italic"> OK: defines copy constructor</SPAN>
</PRE>

<P>&#8212;<I>end example</I>]</P>

<P>Explicitly-defaulted functions and implicitly-declared functions
are collectively called <I>defaulted</I> functions, and the implementation
shall provide implicit definitions for them (12.1 [class.ctor]
12.4 [class.dtor], 12.8 [class.copy]), which
might mean defining them as deleted. A special member function is
<I>user-provided</I> if it is user-declared and not explicitly
defaulted <SPAN style="font-weight:bold;background-color:#A0FFA0">or deleted</SPAN> on its first declaration. A
user-provided explicitly-defaulted function <SPAN style="font-weight:bold;background-color:#A0FFA0">(i.e., explicitly
defaulted after its first declaration)</SPAN> is defined at the point
where it is explicitly defaulted; if such a function is implicitly
defined as deleted, the program is ill-formed. [<I>Note:</I>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">while an implicitly-declared special member function is inline
(Clause 12 [special]), an explicitly-defaulted definition
may be non-inline.  Non-inline definitions are user-provided, and
hence non-trivial (12.1 [class.ctor], 12.4 [class.dtor], 12.8 [class.copy]).  This rule enables</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">Declaring a function as defaulted after its first declaration can
provide</SPAN> efficient execution and concise definition while
enabling a stable binary interface to an evolving code
base. &#8212;<I>end note</I>]</P>

<P>[<I>Example:</I></P>

<PRE>
  struct trivial {
    trivial() = default;
    trivial(const trivial&amp;) = default;
    trivial(trivial&amp;&amp;) = default;
    trivial&amp; operator=(const trivial&amp;) = default;
    trivial&amp; operator=(trivial&amp;&amp;) = default;
    ~trivial() = default;
  };

  struct nontrivial1 {
    nontrivial1();
  };

  nontrivial1::nontrivial1() = default;           //<SPAN style="font-family:Times;font-style:italic"> not <SPAN style="text-decoration:line-through;background-color:#FFA0A0">inline</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">first declaration</SPAN></SPAN>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">  struct nontrivial2 {
    nontrivial2();
  };
  inline nontrivial2::nontrivial2() = default;    //<SPAN style="font-family:Times;font-style:italic"> not first declaration</SPAN>

  struct nontrivial3 {
    virtual ~nontrivial3() = 0;                   //<SPAN style="font-family:Times;font-style:italic"> virtual</SPAN>
  };
  inline nontrivial3::~nontrivial3() = default;   //<SPAN style="font-family:Times;font-style:italic"> not first declaration</SPAN></SPAN>
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<LI><P>Change 12.1 [class.ctor] paragraph 5 as follows:</P></LI>

<BLOCKUOTE>

...A default constructor is trivial if it is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">neither</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">not</SPAN> user-provided <SPAN style="text-decoration:line-through;background-color:#FFA0A0">nor deleted</SPAN> and...

</BLOCKUOTE>

<LI><P>Change 12.4 [class.dtor] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

...A destructor is trivial if it is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">neither</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">not</SPAN>
user-provided <SPAN style="text-decoration:line-through;background-color:#FFA0A0">nor deleted</SPAN> and...

</BLOCKQUOTE>

<LI><P>Change 12.8 [class.copy] paragraph 13 as follows:</P></LI>

<BLOCKQUOTE>

A copy/move constructor for class X is trivial if it is
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">neither</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">not</SPAN> user-provided <SPAN style="text-decoration:line-through;background-color:#FFA0A0">nor deleted</SPAN>
and...

</BLOCKQUOTE>

<LI><P>Change 12.8 [class.copy] paragraph 27 as follows:</P></LI>

<BLOCKQUOTE>

A copy/move assignment operator for class <TT>X</TT> is
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>trivial</I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">trivial</SPAN> if it is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">neither</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">not</SPAN> user-provided <SPAN style="text-decoration:line-through;background-color:#FFA0A0">nor deleted</SPAN> and...

</BLOCKQUOTE>

</OL>

<P>This resolution also resolves issues <A HREF="
     cwg_active.html#1136">1136</A>,
<A HREF="
     cwg_active.html#1137">1137</A>, <A HREF="
     cwg_active.html#1140">1140</A>,
<A HREF="
     cwg_active.html#1145">1145</A>, <A HREF="
     cwg_active.html#1149">1149</A>, and
<A HREF="
     cwg_active.html#1208">1208</A>.</P>

<BR><BR><HR><A NAME="1136"></A><H4>1136.
  
Explicitly-defaulted explicit constructors
</H4><B>Section: </B>8.4.2&#160; [dcl.fct.def.default]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>FI
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#FI2">N3092 comment
  FI&#160;2<BR></A>

<P>It should be allowed to explicitly default an explicit
special member function on its first declaration. It is very
likely that users will want to default explicit copy
constructors without having to write such defaulting outside
of the class.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of <A HREF="
     cwg_active.html#1135">issue 1135</A>.</P>

<BR><BR><HR><A NAME="1137"></A><H4>1137.
  
Explicitly-defaulted virtual special member functions
</H4><B>Section: </B>8.4.2&#160; [dcl.fct.def.default]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>FI
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#FI3">N3092 comment
  FI&#160;3<BR></A>

<P>It should be allowed to explicitly default a virtual
special member function on its first declaration. It is very
likely that users will want to default virtual copy
assignment operators and destructors without having to write
such defaulting outside of the class.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of <A HREF="
     cwg_active.html#1135">issue 1135</A>.</P>

<BR><BR><HR><A NAME="1140"></A><H4>1140.
  
Incorrect redefinition of POD class
</H4><B>Section: </B>9&#160; [class]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US50">N3092 comment
  US&#160;50<BR></A>

<P>The class</P>

<PRE>
    struct A { const int i; };
</PRE>

<P>was a POD in C++98, but is not a POD under the FCD rules
because it does not have a trivial default constructor.
C++0x POD was intended to be a superset of C++98 POD.</P>

<P><U>Suggested resolution</U>: Change POD to be standard
layout and trivially copyable.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of <A HREF="
     cwg_active.html#1135">issue 1135</A>.</P>

<BR><BR><HR><A NAME="1208"></A><H4>1208.
  
Explicit <TT>noexcept</TT> in defaulted definition
</H4><B>Section: </B>9.3.1&#160; [class.mfct.non-static]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-07<BR>




<P>It is currently not permitted to specify an
<I>exception-specification</I> in a defaulted definition.  It
would be nice to be able to do so (providing the explicit
specification matches the one that would be implicitly supplied)
for documentation purposes.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of <A HREF="
     cwg_active.html#1135">issue 1135</A>.</P>

<BR><BR><HR><A NAME="1145"></A><H4>1145.
  
Defaulting and triviality
</H4><B>Section: </B>12.1&#160; [class.ctor]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>FI
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-03<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#FI4">N3092 comment
  FI&#160;4<BR></A>

<P>What effect does defaulting have on triviality? Related
to <A HREF="
     cwg_active.html#1135">issue 1135</A>, non-public special
members defaulted on their first declaration should retain
triviality, because they shouldn't be considered
user-provided. Related to <A HREF="
     cwg_active.html#1137">issue 1137</A>, defaulted member functions that are virtual
should not be considered trivial, but there's no reason why
non-virtuals could not be.</P>

<P>Furthermore, a class with a non-public explicitly-defaulted
constructor isn't ever trivially constructible under the
current rules. If such a class is used as a subobject, the
constructor of the aggregating class should be trivial if it
can access the non-public explicitly defaulted constructor
of a subobject.</P>

<P><U>Suggested resolution</U>: Change the triviality rules
so that a class can have a trivial default constructor if
the class has access to the default constructors of its
subobjects and the default constructors of the subobjects
are explicitly defaulted on first declaration, even if said
defaulted constructors are non-public.</P>

<P>See also <A HREF="
     cwg_active.html#1149">issue 1149</A>.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>The consensus of the CWG was that this change should not be
made at this point in the standardization process, but that it
might be considered at a later date.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of <A HREF="
     cwg_active.html#1135">issue 1135</A>.</P>

<BR><BR><HR><A NAME="1081"></A><H4>1081.
  
Defaulted destructor and unusable operator delete
</H4><B>Section: </B>12.4&#160; [class.dtor]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-22<BR>




<P>A defaulted destructor should be implicitly defined as deleted
if <TT>operator delete</TT> is deleted or inaccessible.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 12.4 [class.dtor] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<P>...A defaulted destructor for a class <TT>X</TT> is defined as
deleted if:</P>

<UL><LI><P><TT>X</TT> is a union-like class that has a variant member
with a non-trivial destructor,</P></LI>

<LI><P>any of the non-static data members has class type <TT>M</TT>
(or array thereof) and <TT>M</TT> has a deleted destructor or a
destructor that is inaccessible from the defaulted destructor,
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">or</SPAN></P></LI>

<LI><P>any direct or virtual base class has a deleted destructor or a
destructor that is inaccessible from the defaulted
destructor<SPAN style="text-decoration:line-through;background-color:#FFA0A0">.</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">,</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">or, for a virtual destructor, lookup of the non-array
deallocation function results in an ambiguity or in a function that is
deleted or inaccessible from the defaulted destructor.</SPAN></P></LI>

</UL>

<P>A destructor is trivial if...</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1080"></A><H4>1080.
  
Confusing relationship between templates and copy constructors
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-19<BR>




<P>12.8 [class.copy] paragraphs 6-7 currently read,</P>

<BLOCKQUOTE>

<P>A declaration of a constructor for a class <TT>X</TT> is ill-formed
if its first parameter is of type (optionally cv-qualified) <TT>X</TT>
and either there are no other parameters or else all other parameters
have default arguments.</P>

<P> A member function template is never instantiated to perform the
copy of a class object to an object of its class
type. [<I>Example:</I></P>

<PRE>
    struct S {
        template&lt;typename T&gt; S(T);
        template&lt;typename T&gt; S(T&amp;&amp;);
        S();
    };

    S f();
    const S g;

    void h() {
        S a( f() ); //<SPAN style="font-family:Times;font-style:italic"> does not instantiate member template;</SPAN>
                    //<SPAN style="font-family:Times;font-style:italic"> uses the implicitly generated move constructor</SPAN>
        S a(g);     //<SPAN style="font-family:Times;font-style:italic"> does not instantiate the member template;</SPAN>
                    //<SPAN style="font-family:Times;font-style:italic"> uses the implicitly generated copy constructor</SPAN>
    }
</PRE>

</BLOCKQUOTE>

<P>These paragraphs were previously a single paragraph, and the second
sentence was intended to mean that</P>

<PRE>
    template &lt;class T&gt; A(T):
</PRE>

<P>will never be instantiated to produce <TT>A(A)</TT>.  It should
not have been split and the example should not have been amended to
include move construction.</P>

<P><U>Lawrence Crowl</U>: I suggest something along the lines of</P>

<BLOCKQUOTE>

A member function template is never instantiated to match the
signature of an ill-formed constructor.

</BLOCKQUOTE>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Merge 12.8 [class.copy] paragraphs 6 and 7 and change the
text as follows:</P>

<BLOCKQUOTE>

<P>A declaration of a constructor for a class <TT>X</TT> is ill-formed
if its first parameter is of type (optionally cv-qualified) <TT>X</TT>
and either there are no other parameters or else all other parameters
have default arguments.  A member function template is never
instantiated to <SPAN style="text-decoration:line-through;background-color:#FFA0A0">perform the copy of a class object to an object
of its class type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">produce such a constructor
signature</SPAN>. [<I>Example:</I></P>

<PRE>
  struct S {
    template&lt;typename T&gt; S(T);
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">    template&lt;typename T&gt; S(T&amp;&amp;);</SPAN>
    S();
  };

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">  S f();</SPAN>
  <SPAN style="text-decoration:line-through;background-color:#FFA0A0">const</SPAN> S g;

  void h() {
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">    S a( f() ); //<SPAN style="font-family:Times;font-style:italic"> does not instantiate member template;</SPAN>
                //<SPAN style="font-family:Times;font-style:italic"> uses the implicitly generated move constructor</SPAN></SPAN>
    S a(g);     //<SPAN style="font-family:Times;font-style:italic"> does not instantiate the member template <SPAN style="font-weight:bold;background-color:#A0FFA0">to produce </SPAN></SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">S::S&lt;S&gt;(S)</SPAN><SPAN style="font-family:Times;font-style:italic">;</SPAN>
                //<SPAN style="font-family:Times;font-style:italic"> uses the implicitly <SPAN style="text-decoration:line-through;background-color:#FFA0A0">generated</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">declared</SPAN> copy constructor</SPAN>
}
</PRE>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1149"></A><H4>1149.
  
Trivial non-public copy operators in subobjects
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>FI
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-03<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#FI5">N3092 comment
  FI&#160;5<BR></A>

<P>A class with a non-public explicitly-defaulted copy
constructor isn't ever trivially copyable under the current
rules. If such a class is used as a subobject, the copy
constructor of the aggregating class should be trivial if it
can access the non-public explicitly defaulted copy
constructor of a subobject.</P>

<P>See also <A HREF="
     cwg_active.html#1145">issue 1145</A>.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>The consensus of the CWG was that this change should not be
made at this point in the standardization process, but that it
might be considered at a later date.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of <A HREF="
     cwg_active.html#1135">issue 1135</A>.</P>

<BR><BR><HR><A NAME="1151"></A><H4>1151.
  
Overload resolution with initializer-list and non-list constructors
</H4><B>Section: </B>13.3.1.7&#160; [over.match.list]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-03<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US66">N3092 comment
  US&#160;66<BR></A>

<P>Overload resolution should first look for a viable list
constructor, then look for a non-list constructor if no list
constructor is viable.</P>

<P><B>Proposed resolution (August, 2010):</B></P>

<OL><LI><P>Change 8.5.4 [dcl.init.list] paragraph 3 bullet 5
as follows:</P></LI>

<UL><LI><P>Otherwise, if <TT>T</TT> is a class type,
constructors are considered. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">If <TT>T</TT> has an
initializer-list constructor, the argument list consists of
the initializer list as a single argument; otherwise, the
argument list consists of the elements of the initializer
list.</SPAN> The applicable constructors are enumerated
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">(13.3.1.7 [over.match.list])</SPAN> and the best one
is chosen through overload resolution (<SPAN style="font-weight:bold;background-color:#A0FFA0">13.3.1.7 [over.match.list],</SPAN> 13.3 [over.match]). If a
narrowing conversion (see below) is required to convert any
of the arguments, the program is ill-formed.
[<I>Example:</I>...</P></LI></UL>

<LI><P>Change 13.3.1.7 [over.match.list] as follows:</P></LI>

<BLOCKQUOTE>

<P>When objects of non-aggregate class type
<SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>T</TT></SPAN> are list-initialized (8.5.4 [dcl.init.list]), overload resolution selects the constructor
<SPAN style="font-weight:bold;background-color:#A0FFA0">in two phases</SPAN>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">as follows, where <TT>T</TT> is the cv-unqualified class
type of the object being initialized</SPAN>:</P>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">If <TT>T</TT> has an initializer-list
constructor (8.5.4 [dcl.init.list]),</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">Initially, the candidate functions are the
initializer-list constructors (8.5.4 [dcl.init.list])
of the class <TT>T</TT> and</SPAN> the argument list consists
of the initializer list as a single argument<SPAN style="font-weight:bold;background-color:#A0FFA0">.</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">; otherwise,</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">If no viable
initializer-list constructor is found, overload resolution is
performed again, where the candidate functions are all the
constructors of the class <TT>T</TT> and</SPAN> the
argument list consists of the elements of the initializer
list.</P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">For direct-list-initialization, the candidate
functions are all the constructors of the class
<TT>T</TT>.</SPAN></P></LI>

</UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">For</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">In</SPAN>
copy-list-initialization, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the candidate functions are
all the constructors of <TT>T</TT>.  However,</SPAN> if an
<TT>explicit</TT> constructor is chosen, the initialization
is ill-formed. [<I>Note:</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">This differs from other
situations (13.3.1.3 [over.match.ctor], 13.3.1.4 [over.match.copy]), where only converting constructors are
considered for copy-initialization.</SPAN> This restriction
only applies if this initialization is part of the final
result of overload resolution<SPAN style="font-weight:bold;background-color:#A0FFA0">.</SPAN> &#8212;<I>end
note</I>]</P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1073"></A><H4>1073.
  
Merging <I>dynamic-exception-specification</I>s and <I>noexcept-specification</I>s
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-02<BR>




<P>It is not clear how to handle compatible
<I>dynamic-exception-specification</I>s and
<I>noexcept-specification</I>s.  For example, given</P>

<PRE>
    void f() throw();
    void f() noexcept {
       throw 1;
    }
</PRE>

<P>should we call <TT>terminate()</TT> or <TT>unexpected()</TT>?  And
for</P>

<PRE>
    void g() throw (int);
    void g() noexcept (false) {
       throw 1.0;
    }
</PRE>

<P>should this call <TT>unexpected</TT> or propagate the exception?
Does the order of the declarations (and which is the definition)
matter?</P>

<P><U>Alisdair Meredith</U>:</P>

<P>And what about something like</P>

<PRE>
    struct A { ~A() throw() { } };
    struct B { ~B() noexcept { } };
    struct C: A, B { };
</PRE>

<P>What is the exception specification for <TT>C</TT>'s destructor?</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Change 15.4 [except.spec] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

<P>Two <I>exception-specification</I>s are <I>compatible</I> if:</P>

<UL><LI><P>both are non-throwing (see below), regardless of their
form,</P></LI>

<LI><P>both have the form
<TT>noexcept(</TT><I>constant-expression</I><TT>)</TT> and the
<I>constant-expression</I>s are equivalent, <SPAN style="font-weight:bold;background-color:#A0FFA0">or</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">one <I>exception-specification</I> is a
<I>noexcept-specification</I> allowing all exceptions and the other is
of the form <TT>throw(</TT><I>type-id-list</I><TT>)</TT>,
or</SPAN></P></LI>

<LI><P>both are <I>dynamic-exception-specification</I>s that have the
same set of adjusted types.</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Add the following note to the end of 15.4 [except.spec]
paragraph 9:</P></LI>

<BLOCKQUOTE>

<P>Whenever an exception is thrown and the search...</P>

<P>&#8212;<I>end example</I>]</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> A function can have multiple declarations with
different non-throwing <I>exception-specification</I>s; for this
purpose, the one on the function definition is used. &#8212;<I>end
note</I>]</SPAN></P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1167"></A><H4>1167.
  
<I>function-try-block</I>s for destructors
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>GB
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-03<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#GB46">N3092 comment
  GB&#160;46<BR></A>

<P>It is not entirely clear that a <I>function-try-block</I>
on a destructor will catch exceptions from a base or member
destructor; whether such exceptions might be swallowed with
a simple <TT>return</TT> statement rather than being
rethrown; and whether such a clause might be entered
multiple times if multiple bases/members throw, or if that
is an automatic terminate call.</P>

<P><B>Proposed resolution (August, 2010):</B></P>

<P>Change 15 [except] paragraph 4 as follows:</P>

<BLOCKQUOTE>

...An exception thrown during the execution of the
initializer expressions in the <I>ctor-initializer</I> or
during the execution of the <I>compound-statement</I><SPAN style="font-weight:bold;background-color:#A0FFA0">,
or &#8212; in the case of a destructor &#8212; during the
destruction of a subobject,</SPAN> transfers control to a
handler in a <I>function-try-block</I> in the same way as an
exception thrown during the execution of a <I>try-block</I>
transfers control to other handlers. [<I>Example:</I>...

</BLOCKQUOTE>

<P><B>Additional note (October, 2010):</B></P>



<P>There is a related problem with this wording: it covers only
&#8220;the execution of the initializer expressions in the
<I>ctor-initializer</I>,&#8221; when it should also cover execution
of base and member constructors, regardless of whether they have
initializer expressions in the <I>ctor-initializer</I> or not.</P>

<P>The issue has been moved back to "review" status to allow
consideration of amending the proposed resolution to something
like</P>

<BLOCKQUOTE>

...during the execution of the <I>compound-statement</I> or, if the
function is a constructor or destructor, during the initialization
or destruction of the class's subobjects, transfers control...

</BLOCKQUOTE>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 15 [except] paragraph 4 as follows:</P>

<BLOCKQUOTE>

A <I>function-try-block</I> associates a <I>handler-seq</I> with the
<I>ctor-initializer</I>, if present, and the
<I>compound-statement</I>.  An exception thrown during the execution
of the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">initializer expressions in the <I>ctor-initializer</I> or
during the execution of the</SPAN> <I>compound-statement</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">or,
for constructors and destructors, during the initialization or
destruction, respectively, of the class's subobjects,</SPAN> transfers
control to a handler in a <I>function-try-block</I> in the same way as
an exception thrown during the execution of a <I>try-block</I>
transfers control to other handlers.

</BLOCKQUOTE>

<BR><BR><BR><BR><HR><A NAME="Tentatively Ready Status"></A><H3>Issues with "Tentatively Ready" Status</H3>
<HR><A NAME="1201"></A><H4>1201.
  
Are deleted and defaulted functions definitions?
</H4><B>Section: </B>3.1&#160; [basic.def]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-20<BR>




<P>According to 3.2 [basic.def.odr] paragraph 2,</P>

<BLOCKQUOTE>

A declaration is a <I>definition</I> unless it declares a function
without specifying the function's body (8.4 [dcl.fct.def]), it
contains the <TT>extern</TT> specifier (7.1.1 [dcl.stc]) or a
<I>linkage-specification</I><SUP>25</SUP> (7.5 [dcl.link])
and neither an <I>initializer</I> nor a <I>function-body</I>...

</BLOCKQUOTE>

<P>Because <TT>= delete</TT> and <TT>= default</TT> are not forms
of <I>function-body</I>, this description does not cover defaulted
and deleted functions, even though these declarations are elsewhere
referred to as being definitions.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<P>Change the grammar in 8.4.1 [dcl.fct.def.general] paragraph 1
as follows:</P>

<UL><I>function-definition:</I>
<UL><I>attribute-specifier-seq<SUB>opt</SUB> decl-specifier-seq<SU>opt</SU> declarator function-body</I></UL>
<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>attribute-specifier-seq<SUB>opt</SUB> decl-specifier-seq<SU>opt</SU> declarator </I><TT>= default ;</TT></SPAN></UL>
<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>attribute-specifier-seq<SUB>opt</SUB> decl-specifier-seq<SU>opt</SU> declarator </I><TT>= delete ;</TT></SPAN></UL>

</UL>

<UL><I>function-body:</I>
<UL><I>ctor-initializer<SUB>opt</SUB> compound-statement</I></UL>
<UL><I>function-try-block</I></UL>
<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>= default ;</TT></SPAN></UL>
<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>= delete ;</TT></SPAN></UL>

</UL>

<BR><BR><HR><A NAME="1044"></A><H4>1044.
  
Point of declaration for an <I>alias-declaration</I>
</H4><B>Section: </B>3.3.2&#160; [basic.scope.pdecl]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-05<BR>


<P>The current wording of 3.3.2 [basic.scope.pdecl] does not specify
the point of declaration for an <I>alias-declaration</I> (although it
does do so in paragraph 3 for a template alias: &#8220;The point of
declaration of a template alias immediately follows the identifier
for the alias being declared&#8221;).  One might assume that an
<I>alias-declaration</I> would be the same, but it's not clear that
that is the right resolution (for either declaration, but especially
for the <I>alias-declaration</I>).</P>

<P>An <I>alias-declaration</I> is intended to be essentially a
different syntactic form of a <TT>typedef</TT> declaration
(7.1.3 [dcl.typedef] paragraph 2).  Placing the point of
declaration at the trailing semicolon instead of following the name
of the alias would allow more compatibility with the capabilities of
<TT>typedef</TT>s, for instance:</P>

<PRE>
    struct S { };
    namespace N {
        using S = S;
    }
</PRE>



<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The CWG agreed that the point of declaration for both template
and non-template cases should be at the semicolon.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<P>Change 3.3.2 [basic.scope.pdecl] paragraph 3 as follows:</P>

<BLOCKQUOTE>

...The point of declaration of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a template</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">an</SPAN>
alias <SPAN style="font-weight:bold;background-color:#A0FFA0">or alias template</SPAN> immediately follows <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the
identifier for the alias being declared</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the <I>type-id</I>
to which the alias refers</SPAN>.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1181"></A><H4>1181.
  
What is a &#8220;built-in type?&#8221;
</H4><B>Section: </B>3.9&#160; [basic.types]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Barry Hedquist
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-26<BR>


<P>The current draft uses the term &#8220;built-in type&#8221; several
times, but it is not defined anywhere. The Index appears to make it
synonymous with &#8220;fundamental type,&#8221; but the implication of
4 [conv] paragraph 1 is that compound types like pointers
should also be considered as &#8220;built-in.&#8221;</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<OL><LI><P>Change 1.8 [intro.object] paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

[<I>Note:</I> C++ provides a variety of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">built-in</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">fundamental</SPAN> types and several ways of composing new types
from existing types (3.9 [basic.types]). &#8212;<I>end
note</I>]

</BLOCKQUOTE>

<LI><P>Change 2.5 [lex.pptoken] as follows:</P></LI>

<BLOCKQUOTE>

[<I>Example:</I> The program fragment <TT>x+++++y</TT> is parsed as
<TT>x ++ ++ + y</TT>, which, if <TT>x</TT> and <TT>y</TT> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">are of
built-in</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">have integral</SPAN> types, violates a constraint
on increment operators, even though the parse <TT>x ++ + ++ y</TT>
might yield a correct expression.  &#8212;<I>end example</I>]

</BLOCKQUOTE>

<LI><P>Change 18.3.1.2 [numeric.limits.members] paragraph 58 as follows:</P></LI>

<BLOCKQUOTE>

True if the set of values representable by the type is
finite.<SUP>220</SUP> [<I>Note:</I> All <SPAN style="text-decoration:line-through;background-color:#FFA0A0">built-in</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">fundamental</SPAN> types <SPAN style="font-weight:bold;background-color:#A0FFA0">(3.9.1 [basic.fundamental])</SPAN>
are bounded.  This member would be false for arbitrary precision
types. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 24.2.1 [iterator.requirements.general] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...All input iterators <TT>i</TT> support the expression <TT>*i</TT>,
resulting in a value of some <SPAN style="text-decoration:line-through;background-color:#FFA0A0">class, enumeration, or
built-in</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">object</SPAN> type <TT>T</TT>, called the <I>value
type</I> of the iterator...

</BLOCKQUOTE>

<LI><P>Change 24.2.3 [input.iterators] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

A class or a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">built-in</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">pointer</SPAN> type <TT>X</TT>
satisfies the requirements of an input iterator for the value type
<TT>T</TT> if <TT>X</TT> satisfies the <TT>Iterator</TT> (24.2.2 [iterator.iterators]) and <TT>EqualityComparable</TT> (Table 33)
requirements and the expressions in Table 107 are valid and have the
indicated semantics.

</BLOCKQUOTE>

<LI><P>Change 24.2.4 [output.iterators] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

A class or a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">built-in</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">pointer</SPAN> type <TT>X</TT>
satisfies the requirements of an output iterator <SPAN style="text-decoration:line-through;background-color:#FFA0A0">if
<TT>X</TT></SPAN> if <TT>X</TT> satisfies the <TT>Iterator</TT>
requirements (24.2.2 [iterator.iterators]) and the expressions in
Table 108 are valid and have the indicated semantics.

</BLOCKQUOTE>

<LI><P>Change 24.2.5 [forward.iterators] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

A class or a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">built-in</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">pointer</SPAN> type <TT>X</TT>
satisfies the requirements of a forward iterator if...

</BLOCKQUOTE>

<LI><P>Change 24.2.6 [bidirectional.iterators] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

A class or a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">built-in</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">pointer</SPAN> type <TT>X</TT>
satisfies the requirements of a bidirectional iterator if, in addition
to satisfying the requirements for forward iterators, the following
expressions are valid as shown in Table 110.

</BLOCKQUOTE>

<LI><P>Change 24.2.7 [random.access.iterators] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

A class or a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">built-in</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">pointer</SPAN> type <TT>X</TT>
satisfies the requirements of a random access iterator if, in addition
to satisfying the requirements for bidirectional iterators, the
following expressions are valid as shown in Table 111.

</BLOCKQUOTE>

<LI><P>Change C.1.2 [diff.basic] section 3.1 as follows:</P></LI>

<BLOCKQUOTE>

<B>Rationale</B>: This avoids having different initialization rules
for <SPAN style="text-decoration:line-through;background-color:#FFA0A0">built-in</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">fundamental</SPAN> types and user-defined
types.

</BLOCKQUOTE>

<LI><P>Change C.1.7 [diff.class] section 9.1 as follows:</P></LI>

<BLOCKQUOTE>

...This new name space definition provides important notational
conveniences to C++ programmers and helps making the use of the
user-defined types as similar as possible to the use of
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">built-in</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">fundamental</SPAN> types...

</BLOCKQUOTE>

<LI><P>Delete the index entry, &#8220;built-in type; see fundamental
type</P>.&#8221;</LI>

</OL>

<P>(Note: This resolution assumes that the resolution for
<A HREF="
     cwg_active.html#572">issue 572</A> has been applied, removing
&#8220;built-in type&#8221; from 4 [conv] paragraph 1.)</P>

<BR><BR><HR><A NAME="572"></A><H4>572.
  
Standard conversions for non-built-in types
</H4><B>Section: </B>4&#160; [conv]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jens Maurer
 &#160;&#160;&#160;

 <B>Date: </B>6 April 2006<BR>


<P>4 [conv] paragraph 1 says,</P>

<BLOCKQUOTE>

Standard conversions are implicit conversions defined for built-in types.

</BLOCKQUOTE>

<P>However, enumeration types (which take part in the integral
promotions) and class types (which take part in the lvalue-to-rvalue
conversion) are not &#8220;built-in&#8221; types, so the definition of
&#8220;standard conversions&#8221; is wrong.</P>

<P><B>Proposed resolution (October, 2006):</B></P>

<P>Change 4 [conv] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Standard conversions are implicit conversions <SPAN style="text-decoration:line-through;background-color:#FFA0A0">defined for built-in types</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">with built-in meaning</SPAN>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1091"></A><H4>1091.
  
Inconsistent use of the term &#8220;object expression&#8221;
</H4><B>Section: </B>5.5&#160; [expr.mptr.oper]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Tom Plum
 &#160;&#160;&#160;

 <B>Date: </B>2010-07-10<BR>


<P>The description of class member access expressions in
5.2.5 [expr.ref] paragraph 2 defines the terms
&#8220;object expression&#8221; and &#8220;pointer
expression:&#8221;</P>

<BLOCKQUOTE>

For the first option (dot) the type of the first expression
(the <I>object expression</I>) shall be &#8220;class object&#8221;
(of a complete type). For the second option (arrow) the type
of the first expression (the <I>pointer expression</I>) shall be
&#8220;pointer to class object&#8221; (of a complete type).

</BLOCKQUOTE>

<P>(Note in passing that the phrase &#8220;class
object&#8221; seems very odd when describing a type.)  The
rest of that section is based on the equivalence of the
expression <TT>E1-&gt;E2</TT> to <TT>(*(E1)).E2</TT> and
thus is phrased only in terms of &#8220;object
expression.&#8221; This terminology appears to have been
misapplied in other parts of the Standard, using the term
&#8220;object expression&#8221; to refer both to class types
and pointers to class types.  The most egregious of these is
5.5 [expr.mptr.oper] paragraph 4, describing the
operands of a pointer-to-member expression:</P>

<BLOCKQUOTE>

The first operand is called the <I>object expression</I>.
If the dynamic type of the object expression does not
contain the member to which the pointer refers, the behavior
is undefined.

</BLOCKQUOTE>

<P>The dynamic type of the first operand in the
<TT>-&gt;*</TT> case is a pointer type, not a class type, so
it cannot &#8220;contain the member to which the pointer
refers.&#8221;  Another example is 3.4.5 [basic.lookup.classref],
describing the lookup in a class member access expression.  The
first paragraph uses the term consistently with its use in
5.2.5 [expr.ref], but paragraph 2 reads:</P>

<BLOCKQUOTE>

If the <I>id-expression</I> in a class member access
(5.2.5 [expr.ref]) is an <I>unqualified-id</I>, and the
type of the object expression is of a class type <TT>C</TT>, the
<I>unqualified-id</I> is looked up in the scope of class
<TT>C</TT>. If the type of the object expression is of
pointer to scalar type, the <I>unqualified-id</I> is looked
up in the context of the complete <I>postfix-expression</I>.

</BLOCKQUOTE>

<P>Paragraph 7 gets it right:</P>

<BLOCKQUOTE>

...in the context of the class of the object expression
(or the class pointed to by the pointer expression).

</BLOCKQUOTE>

<P>Another misapplication of the term occurs in 5.2.2 [expr.call]
paragraph 1:</P>

<BLOCKQUOTE>

...the call is as a member of the object pointed to or
referred to by the object expression (5.2.5 [expr.ref], 5.5 [expr.mptr.oper])... its final
overrider (10.3 [class.virtual]) in the dynamic type of
the object expression is called.  [<I>Note:</I> the dynamic
type is the type of the object pointed or referred to by the
current value of the object expression...

</BLOCKQUOTE>

<P>Here again we have the idea that an object expression can
&#8220;point to&#8221; an object.</P>

<P>Another minor complication is that 5 [expr]
paragraph 7 has a separate definition for the (hyphenated) term
&#8220;object-expression:&#8221;</P>

<BLOCKQUOTE>

An expression designating an object is called an <I>object-expression</I>.

</BLOCKQUOTE>

<P>This term is used several times in the Standard,
apparently interchangeably with the non-hyphenated version
defined in 5.2.5 [expr.ref]; for example,
5.1.1 [expr.prim.general] paragraph 10 bullet 1
mentions</P>

<BLOCKQUOTE>

a class member access (5.2.5 [expr.ref]) in which
the object-expression refers to the member's class

</BLOCKQUOTE>

<P>using the term defined in 5 [expr] paragraph 7 but
linking it with 5.2.5 [expr.ref].</P>

<P>These uses of &#8220;object expression&#8221; and
&#8220;object-expression&#8221; need to be made consistent,
especially the reference in 5.5 [expr.mptr.oper] that
implies that the dynamic type of a pointer is that of the
complete object to which it points.</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<OL><LI><P>Change 3.4.5 [basic.lookup.classref] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

...<SPAN style="text-decoration:line-through;background-color:#FFA0A0">If the type of the object expression is of pointer to scalar
type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">For a pseudo-destructor call (5.2.4 [expr.pseudo])</SPAN>, the <I>unqualified-id</I> is looked up in the
context of the complete <I>postfix-expression</I>.

</BLOCKQUOTE>

<LI><P>Delete 5 [expr] paragraph 7</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">An expression designating an object is called an
object-expression.</SPAN>

</BLOCKQUOTE>

<LI><P>Change 5.1.1 [expr.prim.general] paragraph 10 as follows:</P></LI>

<BLOCKQUOTE>

<P>An <I>id-expression</I> that denotes a non-static data member or
non-static member function of a class can only be used:</P>

<UL><LI><P>as part of a class member access (5.2.5 [expr.ref]) in which the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">object-expression</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">object
expression</SPAN> refers to the member's class or a class derived from
that class, or</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 5.2.2 [expr.call] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...For a member function call, the postfix expression shall be an
implicit (9.3.1 [class.mfct.non-static], 9.4 [class.static]) or
explicit class member access (5.2.5 [expr.ref]) whose
<I>id-expression</I> is a function member name, or a pointer-to-member
expression (5.5 [expr.mptr.oper]) selecting a function member; the
call is as a member of the <SPAN style="font-weight:bold;background-color:#A0FFA0">class</SPAN> object <SPAN style="text-decoration:line-through;background-color:#FFA0A0">pointed to
or</SPAN> referred to by the object expression <SPAN style="text-decoration:line-through;background-color:#FFA0A0">(5.2.5 [expr.ref], 5.5 [expr.mptr.oper])</SPAN>... [<I>Note:</I> the
dynamic type is the type of the object <SPAN style="text-decoration:line-through;background-color:#FFA0A0">pointed or</SPAN> referred
to by the current value of the object expression. 12.7 [class.cdtor] describes the behavior of virtual function calls when the
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">object-expression</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">object expression</SPAN> refers to an
object under construction or destruction. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 5.2.5 [expr.ref] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

For the first option (dot) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the type of</SPAN> the first expression <SPAN style="text-decoration:line-through;background-color:#FFA0A0">(the
<I>object expression</I>)</SPAN> shall <SPAN style="text-decoration:line-through;background-color:#FFA0A0">be &#8220;class
object&#8221; (of a complete type)</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">have complete class
type</SPAN>. For the second option (arrow) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the type of</SPAN> the
first expression <SPAN style="text-decoration:line-through;background-color:#FFA0A0">(the <I>pointer expression</I>)</SPAN> shall
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">be &#8220;pointer to class object&#8221; (of a complete
type)</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">have pointer to complete class type. The expression
<TT>E1-&gt;E2</TT> is converted to the equivalent form
<TT>(*(E1)).E2</TT>; the remainder of 5.2.5 [expr.ref] will
address only the first option (dot) [<I>Footnote:</I> Note that
<TT>(*(E1))</TT> is an lvalue. &#8212;<I>end footnote</I>]</SPAN>.  In
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">these cases</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">either case</SPAN>, the
<I>id-expression</I> shall name a member of the class or of one of its
base classes...

</BLOCKQUOTE>

<LI><P>Change 5.2.5 [expr.ref] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">If <TT>E1</TT> has the type &#8220;pointer to class <TT>X</TT>,&#8221;
then the expression <TT>E1-&gt;E2</TT> is converted to the equivalent
form <TT>(*(E1)).E2</TT>; the remainder of 5.2.5 [expr.ref]
will address only the first option (dot)<SUP>66</SUP>.</SPAN> Abbreviating
<I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">object-expression</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">postfix-expression</SPAN>.id-expression</I>
as <TT>E1.E2</TT>, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">then the</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>E1</TT> is called the
<I>object expression</I>.  The</SPAN> type and value category of
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">this expression</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>E1.E2</TT></SPAN> are determined as
follows...

</BLOCKQUOTE>

<LI><P>Change 5.5 [expr.mptr.oper] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

...<SPAN style="text-decoration:line-through;background-color:#FFA0A0">The result is an object or a function of the
type specified by the second operand.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The expression
<TT>E1-&gt;*E2</TT> is converted into the equivalent form
<TT>(*(E1)).*E2.</TT></SPAN>

</BLOCKQUOTE>

<LI><P>Change 5.5 [expr.mptr.oper] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">The first operand</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Abbreviating
<I>pm-expression</I><TT>.*</TT><I>cast-expression</I> as
<TT>E1.*E2</TT>, <TT>E1</TT></SPAN> is called the <I>object
expression</I>.  If the dynamic type of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the object
expression</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>E1</TT></SPAN> does not contain the member to
which <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the pointer</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>E2</TT></SPAN> refers, the
behavior is undefined.

</BLOCKQUOTE>

<LI><P>Change 5.5 [expr.mptr.oper] paragraph 6 as follows:</P></LI>

<BLOCKQUOTE>

...In a <TT>.*</TT> expression whose object expression is an rvalue,
the program is ill-formed if the second operand is a pointer to member
function with <I>ref-qualifier</I> <TT>&amp;</TT>.  In a
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>-&gt;*</TT> expression or in a</SPAN> <TT>.*</TT> expression
whose object expression is an lvalue, the program is ill-formed if the
second operand is a pointer to member function with
<I>ref-qualifier</I> <TT>&amp;&amp;</TT>.  The result of a <TT>.*</TT>
expression whose second operand is a pointer to a data member is of
the same value category (3.10 [basic.lval]) as its first
operand. The result of a <TT>.*</TT> expression whose second operand
is a pointer to a member function is a prvalue.  <SPAN style="text-decoration:line-through;background-color:#FFA0A0">The result of an
<TT>-&gt;*</TT> expression is an lvalue if its second operand is a
pointer to data member and a prvalue otherwise.</SPAN> If the second
operand is the null pointer to member value (4.11 [conv.mem]), the behavior is undefined.

</BLOCKQUOTE>

<LI><P>Change 9.4 [class.static] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

...A <TT>static</TT> member may be referred to using the class member
access syntax, in which case the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">object-expression</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">object expression</SPAN> is evaluated...

</BLOCKQUOTE>

<LI><P>Change 12.7 [class.cdtor] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

...If the virtual function call uses an explicit class member access
(5.2.5) and the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">object-expression</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">object
expression</SPAN> refers to the object under construction...

</BLOCKQUOTE>

<LI><P>Change 14.2 [temp.names] paragraph 4 as
follows:</P></LI>

<BLOCKQUOTE>

When the name of a member template specialization appears after
<TT>.</TT> or <TT>-&gt;</TT> in a <I>postfix-expression</I> or after a
<I>nested-name-specifier</I> in a <I>qualified-id</I>, and the object
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">or pointer</SPAN> expression of the <I>postfix-expression</I> or...

</BLOCKQUOTE>

</OL>

<P><I>[Note: although the current text of 3.4.5 [basic.lookup.classref]
paragraph 7 mentions the phrase &#8220;pointer expression,&#8221;
that wording will be replaced by <A HREF="
     cwg_active.html#1111">issue 1111</A>
or <A HREF="
     cwg_active.html#1220">issue 1220</A> and is thus not addressed
here.]</I></P>

<BR><BR><HR><A NAME="1060"></A><H4>1060.
  
Scoped enumerators in integral constant expressions
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jonathan Caves
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-21<BR>




<P>According to 5.19 [expr.const] paragraph 3,</P>

<BLOCKQUOTE>

A constant expression is an <I>integral constant expression</I>
if it is of integral or enumeration type. [<I>Note:</I> such
expressions may be used as array bounds (8.3.4 [dcl.array], 5.3.4 [expr.new]), as case expressions
(6.4.2 [stmt.switch]), as bit-field lengths (9.6 [class.bit]), as enumerator initializers (7.2 [dcl.enum]), and as integral or enumeration non-type template
arguments (14.3 [temp.arg]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>Although there is conceptually a conversion from enumeration
type to integral type involved in using an enumerator as an array
bound or bit-field length, the normative wording for those uses
does not explicitly mention it and simply requires an integral
constant expression.  Consequently, the current wording permits
uses like the following:</P>

<PRE>
    enum class E { e = 10; };
    struct S {
        int arr[E::e];
        int i: E::e;
    };
</PRE>

<P>This seems surprising.</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1197">issue 1197</A>.</P>

<BR><BR><HR><A NAME="1099"></A><H4>1099.
  
Infinite recursion in <TT>constexpr</TT> functions
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-01<BR>




<P>It is not clear what happens when a program violates the limits on
constexpr function recursion in a context that does not require a
constant expression.  For example,</P>

<PRE>
  constexpr int f(int i) { return f(i); }
  const int i = f(1);   //<SPAN style="font-family:Times;font-style:italic"> error, undefined behavior, or dynamic initialization?</SPAN>
</PRE>

<P>(Presumably the &#8220;within its resource limits&#8221; caveat of
1.4 [intro.compliance] paragraph 2 would effectively result in
undefined behavior in a context that required a constant expression.)</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The CWG was of mixed opinion as to whether an infinite recursion
in a constexpr function should be ill-formed or simply render an
expression non-constant.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<P>Add the following bullet in 5.19 [expr.const] paragraph 2:</P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">an invocation of a <TT>constexpr</TT> function or a
<TT>constexpr</TT> constructor that would exceed the
implementation-defined recursion limit (see annex B [implimits]);</SPAN></P></LI></UL>

<BR><BR><HR><A NAME="1100"></A><H4>1100.
  
<TT>constexpr</TT> conversion functions and non-type template arguments
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-01<BR>




<P>According to 14.3.2 [temp.arg.nontype] paragraph 1, one of the
possibilities for a <I>template-argument</I> for a non-type,
non-template <I>template-parameter</I> is</P>

<UL><LI><P>an integral constant expression (including a
constant expression of literal class type that can be used
as an integral constant expression as described in
5.19 [expr.const])</P></LI></UL>

<P>However, the requirement for such a literal class type is
(5.19 [expr.const] paragraph 5):</P>

<BLOCKQUOTE>

...that class type shall have a single non-explicit conversion
function to an integral or enumeration type and that
conversion function shall be constexpr.

</BLOCKQUOTE>

<P>Note that this normative requirement for a single
conversion function is contradicted by the example in that
paragraph, which reads in significant part,</P>

<PRE>
    struct A {
      constexpr A(int i) : val(i) { }
      constexpr operator int() { return val; }
      constexpr operator long() { return 43; }
    private:
      int val;
    };
    template&lt;int&gt; struct X { };
    constexpr A a = 42;
    X&lt;a&gt; x; //<SPAN style="font-family:Times;font-style:italic"> OK: unique conversion to </SPAN>int
</PRE>

<P><B>Proposed resolution (February, 2011):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1197">issue 1197</A>.</P>

<BR><BR><HR><A NAME="1197"></A><H4>1197.
  
Constexpr arrays
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-08<BR>




<P>The requirement in 5.19 [expr.const] that a constant
expression cannot contain</P>

<UL><LI><P>an array-to-pointer conversion (4.2 [conv.array])
that is applied to a glvalue that does not designate an object with
static storage duration</P></LI></UL>

<P>effectively eliminates the use of automatic constexpr arrays such
as</P>

<PRE>
    void f() {
       constexpr int ar[] = { 1, 2 };
       constexpr int i = ar[1];
    }
</PRE>

<P>There does not seem to be a problem with this kind of usage.</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<P>The proposed resolution will be submitted as a separate document.</P>

<BR><BR><HR><A NAME="1054"></A><H4>1054.
  
Lvalue-to-rvalue conversions in expression statements
</H4><B>Section: </B>6.2&#160; [stmt.expr]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Hans Boehm
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-16<BR>


<P>C and C++ differ in the treatment of an expression statement, in
particular with regard to whether a volatile lvalue is fetched.  For
example,</P>

<PRE>
    volatile int x;
    void f() {
        x;    // Fetches x in C, not in C++
    }
</PRE>

<P>The reason C++ is different in this regard is principally due to
the fact that an assignment expression is an lvalue in C++ but not
in C.  If the lvalue-to-rvalue conversion were applied to expression
statements, a statement like</P>

<PRE>
    x = 5;
</PRE>

<P>would write to x and then immediately read it.</P>

<P>It is not clear that the current approach to dealing with the
difference in assignment expressions is the only or best approach;
it might be possible to avoid the unwanted fetch on the result of
an assignment statement without giving up the fetch for a variable
appearing by itself in an expression statement.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<OL><LI><P>Add a new paragraph after 5 [expr] paragraph
10:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">In some contexts, an expression only appears for its
side-effects. Such an expression is called a <I>discarded-value
expression</I>. The expression is evaluated and its value is
discarded. The array-to-pointer (4.2 [conv.array]) and
function-to-pointer (4.3 [conv.func]) standard conversions
are not applied. The lvalue-to-rvalue conversion (4.1 [conv.lval]) is applied only if the expression is an lvalue of
volatile-qualified type and it has one of the following
forms:</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>id-expression</I> (5.1.1 [expr.prim.general]),</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">subscripting (5.2.1 [expr.sub]),</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">class member access (5.2.5 [expr.ref]),</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">indirection (5.3.1 [expr.unary.op]),</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">pointer-to-member operation (5.5 [expr.mptr.oper]),</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">conditional expression (5.16 [expr.cond]) where both
the second and the third operand are one of the above, or</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">comma expression (5.18 [expr.comma]) where the right
operand is one of the above.</SPAN></P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 5.2.9 [expr.static.cast] paragraph 6 as follows:</P></LI>

<BLOCKQUOTE>

Any expression can be explicitly converted to type <I>cv</I>
<TT>void</TT><SPAN style="font-weight:bold;background-color:#A0FFA0">, in which case it becomes a discarded-value
expression (Clause 5 [expr])</SPAN>.  <SPAN style="text-decoration:line-through;background-color:#FFA0A0">The expression
value is discarded.</SPAN> [<I>Note:</I> however, if the value is in a
temporary object (12.2 [class.temporary]), the destructor for that
object is not executed until the usual time, and the value of the
object is preserved for the purpose of executing the destructor.
&#8212;<I>end note</I>] <SPAN style="text-decoration:line-through;background-color:#FFA0A0">The lvalue-to-rvalue (4.1 [conv.lval]), array-to-pointer (4.2 [conv.array]), and
function-to-pointer (4.3 [conv.func]) standard conversions
are not applied to the expression.</SPAN>

</BLOCKQUOTE>

<LI><P>Change 5.18 [expr.comma] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...A pair of expressions separated by a comma is evaluated
left-to-right<SPAN style="font-weight:bold;background-color:#A0FFA0">;</SPAN> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and the value of</SPAN> the left
expression is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">discarded</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a discarded-value expression
(Clause 5 [expr])</SPAN>.<SUP>83</SUP> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">The
lvalue-to-rvalue (4.1 [conv.lval]), array-to-pointer
(4.2 [conv.array]), and function-to-pointer (4.3 [conv.func]) standard conversions are not applied to the left
expression.</SPAN> Every value computation...

</BLOCKQUOTE>

<LI><P>Change 6.2 [stmt.expr] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...The expression is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">evaluated and its value is discarded</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">a discarded-value expression (clause 5 [expr])</SPAN>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">The lvalue-to-rvalue (4.1 [conv.lval]),
array-to-pointer (4.2 [conv.array]), and function-to-pointer
(4.3 [conv.func]) standard conversions are not applied to the
expression.</SPAN>  All side effects...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="407"></A><H4>407.
  
Named class with associated typedef: two names or one?
</H4><B>Section: </B>7.1.3&#160; [dcl.typedef]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Clark Nelson
 &#160;&#160;&#160;

 <B>Date: </B>31 March 2003<BR>


<P>Here's an example:</P>
<PRE>
  typedef struct S { ... } S;
  void fs(S *x) { ... }
</PRE>
<P>The big question is, to what declaration does the reference to identifier S
actually refer? Is it the S that's declared as a typedef name, or the S
that's declared as a class name (or in C terms, as a struct tag)? (In either
case, there's clearly only one type to which it could refer, since a typedef
declaration does not introduce a new type. But the debugger apparently cares
about more than just the identity of the type.)</P>

<P>Here's a classical, closely related example:</P>
<PRE>
  struct stat { ... };
  int stat();
  ... stat( ... ) ...
</PRE>
<P>Does the identifier stat refer to the class or the function? Obviously, in
C, you can't refer to the struct tag without using the struct keyword,
because it is in a different name space, so the reference must be to the
function. In C++, the reference is also to the function, but for a
completely different reason.</P>

<P>Now in C, typedef names and function names are in the same name space, so
the natural extrapolation would be that, in the first example, S refers to
the typedef declaration, as it would in C. But C++ is not C. For the
purposes of this discussion, there are two important differences between C
and C++</P>

<P>The first difference is that, in C++, typedef names and class names are not
in separate name spaces. On the other hand, according to section
3.3.10 [basic.scope.hiding] (Name hiding), paragraph 2:</P>
<BLOCKQUOTE>
A class name (9.1) or enumeration name (7.2) can be hidden by <SPAN style="font-weight:bold;background-color:#A0FFA0">the name of
an object, function, or enumerator</SPAN> declared in the same scope. If a class
or enumeration name and an object, function, or enumerator are declared in
the same scope (in any order) with the same name, the class or enumeration
name is hidden wherever the object, function, or enumerator name is
visible.
</BLOCKQUOTE>

<P>Please consider carefully the phrase I have highlighted, and the fact that a
typedef name is not the name of an object, function or enumerator. As a
result, this example:</P>
<PRE>
  struct stat { ... };
  typedef int stat;
</PRE>
<P>Which would be perfectly legal in C, is disallowed in C++, both implicitly
(see the above quote) and explicitly (see section
7.1.3 [dcl.typedef] (The typedef
specifier), paragraph 3):</P>
<BLOCKQUOTE>
In a given scope, a typedef specifier shall not be used to redefine the
name of any type declared in that scope to refer to a different type.
Similarly, in a given scope, a class or enumeration shall not be declared
with the same name as a typedef-name that is declared in that scope and
refers to a type other than the class or enumeration itself.
</BLOCKQUOTE>

<P>From which we can conclude that in C++ typedef names do not hide class names
declared in the same scope. If they did, the above example would be legal.</P>

<P>The second difference is that, in C++, a typedef name that refers to a class
is a class-name; see 7.1.3 [dcl.typedef] paragraph 4:</P>
<BLOCKQUOTE>
A typedef-name that names a class is a class-name(9.1). If a typedef-name
is used following the class-key in an elaborated-type-specifier (7.1.5.3) or
in the class-head of a class declaration (9), or is used as the identifier
in the declarator for a constructor or destructor declaration (12.1, 12.4),
the program is ill-formed.
</BLOCKQUOTE>

<P>This implies, for instance, that a typedef-name referring to a class can be
used in a nested-name-specifier (i.e. before :: in a qualified name) or
following ~ to refer to a destructor. Note that using a typedef-name as a
class-name in an elaborated-type-specifier is not allowed. For example:</P>
<PRE>
  struct X { };
  typedef struct X X2;
  X x; // legal
  X2 x2; // legal
  struct X sx; // legal
  struct X2 sx2; // illegal
</PRE>

<P>The final relevant piece of the standard is
7.1.3 [dcl.typedef] paragraph 2:</P>
<BLOCKQUOTE>
In a given scope, a typedef specifier can be used to redefine the name of
any type declared in that scope to refer to the type to which it already
refers.
</BLOCKQUOTE>

<P>This of course is what allows the original example, to which let us now
return:</P>
<PRE>
  typedef struct S { ... } S;
  void fs(S *x) { ... }
</PRE>
<P>The question, again is, to which declaration of S does the reference
actually refer? In C, it would clearly be to the second, since the first
would be accessible only by using the struct keyword. In C++, if typedef
names hid class names declared in the same scope, the answer would be the
same. But we've already seen that typedef names do not hide class names
declared in the same scope.</P>

<P>So to which declaration does the reference to S refer? The answer is that it
doesn't matter. The second declaration of S, which appears to be a
declaration of a typedef name, is actually a declaration of a class name
(7.1.3 [dcl.typedef] paragraph 4), and as such is simply a
redeclaration. Consider the following example:</P>
<PRE>
  typedef int I, I;
  extern int x, x;
  void f(), f();
</PRE>
<P>To which declaration would a reference to I, x or f refer? It doesn't
matter, because the second declaration of each is really just a
redeclaration of the thing declared in the first declaration. So to save
time, effort and complexity, the second declaration of each doesn't add any
entry to the compiler's symbol table.</P>

<P><B>Note (March, 2005):</B></P>



<P><U>Matt Austern</U>: Is this legal?</P>

<PRE>
    struct A { };
    typedef struct A A;
    struct A* p;
</PRE>

<P>Am I right in reading the standard [to say that this is
ill-formed]?  On the one hand it's a nice uniform rule.  On the other
hand, it seems likely to confuse users.  Most people are probably used
to thinking that 'typedef struct A A' is a null operation, and, if
this code really is illegal, it would seem to be a gratuitous C/C++
incompatibility.</P>

<P><U>Mike Miller</U>: I think you're right.  7.1.3 [dcl.typedef] paragraph 1:</P>

<BLOCKQUOTE>

A name declared with the <TT>typedef</TT> specifier becomes a
<I>typedef-name</I>.

</BLOCKQUOTE>

<P>7.1.3 [dcl.typedef] paragraph 2:</P>

<BLOCKQUOTE>

In a given non-class scope, a <TT>typedef</TT> specifier can be used
to redefine the name of any type declared in that scope
to refer to the type to which it already refers.

</BLOCKQUOTE>

<P>After the <TT>typedef</TT> declaration in the example, the name
<TT>X</TT> has been &#8220;redefined&#8221; &#8212; it is no longer
just a <I>class-name</I>, it has been &#8220;redefined&#8221; to be a
<I>typedef-name</I> (that, by virtue of the fact that it refers to a
class type, is also a <I>class-name</I>).</P>

<P><U>John Spicer</U>: In C, and originally in C++, an
<I>elaborated-type-specifier</I> did not consider typedef names, so
&#8220;<TT>struct X* x</TT>&#8221; would find the class and not the
typedef.</P>

<P>When C++ was changed to make typedefs visible to
<I>elaborated-type-specifier</I> lookups, I believe this issue was
overlooked and inadvertantly made ill-formed.
</P>

<P>I suspect we need add text saying that if a given scope contains
both a class/enum and a typedef, that an elaborated type specifier
lookup finds the class/enum.
</P>

<P><U>Mike Miller</U>: I'm a little uncomfortable with this approach.
The model we have for declaring a typedef in the same scope as a
class/enum is redefinition, not hiding (like the &#8220;<TT>struct
stat</TT>&#8221; hack).  This approach seems to assume that the
typedef hides the class/enum, which can then be found by an
<I>elaborated-type-specifier</I>, just as if it were hidden by a
variable, function, or enumerator.
</P>

<P>Also, this approach reduces but doesn't eliminate the
incompatibility with C.  For example:
</P>

<PRE>
    struct S { };
    {
        typedef struct S S;
        struct S* p;        // still ill-formed
    }
</PRE>

<P>My preference would be for something following the basic principle
that declaring a <I>typedef-name</I> <TT>T</TT> in a scope where
<TT>T</TT> already names the type designated by the typedef should
have no effect on whether an <I>elaborated-type-specifier</I> in that
or a nested scope is well-formed or not.  Another way of saying that
is that a <I>typedef-name</I> that designates a same-named class or
enumeration in the same or a containing scope is transparent with
respect to <I>elaborated-type-specifier</I>s.</P>

<P><U>John Spicer</U>: This strikes me as being a rather complicated
solution. When we made the change to make typedefs visible to
<I>elaborated-type-specifier</I>s we did so knowing it would make some
C cases ill-formed, so this does not bother me.  We've lived with the
C incompatibility for many years now, so I don't personally feel a
need to undo it.  I also don't like the fact that you have to
essentially do the old-style <I>elaborated-type-specifier</I> lookup
to check the result of the lookup that found the typedef.
</P>

<P>I continue to prefer the direction I described earlier where if a
given scope contains both a class/enum and a typedef, that an
<I>elaborated-type-specifier</I> lookup finds the class/enum.
</P>

<P><B>Notes from the April, 2005 meeting:</B></P>

<P>The CWG agreed with John Spicer's approach, i.e., permitting
a <I>typedef-name</I> to be used in an
<I>elaborated-type-specifier</I> only if it is declared in the same
scope as the class or enumeration it names.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<P>Add the following new paragraph after 7.1.3 [dcl.typedef]
paragraph 4:</P>

<BLOCKQUOTE>

<P>If a <TT>typedef</TT> specifier is used to redefine in a given
scope an entity that can be referenced using an
<I>elaborated-type-specifier</I>, the entity can continue to be
referenced by an <I>elaborated-type-specifier</I> or as an enumeration or
class name in an enumeration or class definition respectively.
[<I>Example:</I></P>

<PRE>
  struct S;
  typedef struct S S;
  int main() {
    struct S* p; //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
  }
  struct S {};   //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1199"></A><H4>1199.
  
Deleted constexpr functions
</H4><B>Section: </B>7.1.5&#160; [dcl.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-17<BR>




<P>The current requirements for constexpr functions do not permit a
deleted constexpr function because the definition does not consist of
a <I>compound-statement</I> containing just a <TT>return</TT>
statement.  However, it could be useful to allow this form in a
case where a single piece of code is used in multiple configurations,
in some of which the function is constexpr and others deleted;
having to update all declarations of the function to remove the
<TT>constexpr</TT> specifier is unnecessarily onerous.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<OL><LI><P>Change 7.1.5 [dcl.constexpr] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

<UL><LI><P>...</P></LI>

<LI><P>its <I>function-body</I> shall be <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>= delete</TT>
or</SPAN> a <I>compound-statement</I> of the form</P>

<PRE>
  { return <I>expression</I> ; }
</PRE>

</LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 7.1.5 [dcl.constexpr] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">The definition of a <TT>constexpr</TT> constructor</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">In the definition of a <TT>constexpr</TT> constructor, each of
the parameter types shall be a literal type or a reference to a
literal type.  In addition, either its <I>function-body</I> shall be
<TT>= delete</TT> or it</SPAN> shall satisfy the following
constraints:</P>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">each of its parameter types shall be a literal type or
a reference to literal type;</SPAN></P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1240"></A><H4>1240.
  
<TT>constexpr</TT> defaulted constructors
</H4><B>Section: </B>8.1&#160; [dcl.name]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jens Maurer
 &#160;&#160;&#160;

 <B>Date: </B>2011-02-02<BR>


<P><A HREF="
     cwg_active.html#1199">Issue 1199</A> proposes to add the capability
of defining a <TT>constexpr</TT> special function as deleted.  It
would be similarly useful to be able to mark a defaulted constructor
as <TT>constexpr</TT>.  (It should be noted that the existing text of
12.1 [class.ctor] and the proposed resolution of
<A HREF="
     cwg_active.html#1224">issue 1224</A> already allow for implicitly-defined
constructors to be implicitly <TT>constexpr</TT>; this issue simply
proposes allowing the explicit use of the <TT>constexpr</TT>
specifier.)</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<OL><LI><P>Change 7.1.5 [dcl.constexpr] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

<UL><LI><P>...</P></LI>

<LI><P>its <I>function-body</I> shall be <TT>= delete</TT><SPAN style="font-weight:bold;background-color:#A0FFA0">, <TT>=
default</TT>,</SPAN> or a <I>compound-statement</I> of the form</P>

<PRE>
  { return <I>expression</I> ; }
</PRE>

</LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 7.1.5 [dcl.constexpr] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

<P>In the definition of a <TT>constexpr</TT> constructor, each of the
parameter types shall be a literal type or a reference to a literal
type.  In addition, either its <I>function-body</I> shall be <TT>=
delete</TT> <SPAN style="font-weight:bold;background-color:#A0FFA0">or <TT>= default</TT></SPAN> or it shall satisfy the
following constraints:</P>

<UL><LI><P>...</P></LI>

</UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A trivial copy/move constructor is also a <TT>constexpr</TT>
constructor.</SPAN></P>

</BLOCKQUOTE>

</OL>

<I>[Note: this resolution assumes that the changes for
<A HREF="
     cwg_active.html#1199">issue 1199</A> have been applied.]</I>

<BR><BR><HR><A NAME="938"></A><H4>938.
  
Initializer lists and array new
</H4><B>Section: </B>8.5.1&#160; [dcl.init.aggr]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>12 July, 2009<BR>




<P>8.5.1 [dcl.init.aggr] paragraph 4 says,</P>

<BLOCKQUOTE>

An <I>initializer-list</I> is ill-formed if the number of
<I>initializer-clause</I>s exceeds the number of members or elements
to initialize.

</BLOCKQUOTE>

<P>However, in a <I>new-expression</I>, the number of elements to be
initialized is potentially unknown at compile time. How should an
overly-long <I>initializer-list</I> in a <I>new-expression</I> be treated?</P>

<P><B>Notes from the August, 2010 meeting:</B></P>

<P>The consensus of the CWG was that this case should throw an exception
at runtime.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<P>Change 5.3.4 [expr.new] paragraph 7 as follows:</P>

<BLOCKQUOTE>

When the value of the <I>expression</I> in a
<I>noptr-new-declarator</I> is zero, the allocation function is called
to allocate an array with no elements.  If the value of that
<I>expression</I> is less than zero or such that the size of the
allocated object would exceed the implementation-defined limit,
<SPAN style="font-weight:bold;background-color:#A0FFA0">or if the <I>new-initializer</I> is a <I>braced-init-list</I> for
which the number of <I>initializer-clause</I>s exceeds the number of
elements to initialize,</SPAN> no storage is obtained and the
<I>new-expression</I> terminates by throwing an exception of a type
that would match a handler (15.3 [except.handle]) of type
<TT>std::bad_array_new_length</TT> (18.6.2.2 [new.badlength]).

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1030"></A><H4>1030.
  
Evaluation order in <I>initializer-list</I>s used in aggregate initialization
</H4><B>Section: </B>8.5.1&#160; [dcl.init.aggr]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Scott Meyers
 &#160;&#160;&#160;

 <B>Date: </B>2010-02-09<BR>




<P>The ordering imposed by 8.5.1 [dcl.init.aggr] paragraph
17 applies only to &#8220;the full-expressions in an
<I>initializer-clause</I>&#8221; (i.e., what follows an
<TT>=</TT> in an aggregate initializer); this leaves unspecified
the order in which the expressions in an <I>initializer-list</I>
(the term used by the <I>braced-init-list</I> form of
initializer, with no <TT>=</TT>) are evaluated.</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The CWG favored guaranteeing the order of evaluation of
<I>initializer-clause</I>s appearing in a <I>braced-init-list</I>,
regardless of whether the <I>braced-init-list</I> is an aggregate
initialization or constructor call.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<OL><LI><P>Delete 8.5.1 [dcl.init.aggr] paragraph 17:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">The full-expressions in an <I>initializer-clause</I> are
evaluated in the order in which they appear.</SPAN>

</BLOCKQUOTE>

<LI><P>Insert the following as a new paragraph between paragraphs
3 and 4 of 8.5.4 [dcl.init.list]</P></LI>

<BLOCKQUOTE>

<SPAN style="font-weight:bold;background-color:#A0FFA0">Within the <I>initializer-list</I> of a <I>braced-init-list</I>,
the <I>initializer-clause</I>s, including any that result from pack
expansions (14.5.3 [temp.variadic]), are evaluated in the order
in which they appear. That is, every value computation and side effect
associated with a given <I>initializer-clause</I> is sequenced before
every value computation and side effect associated with any
<I>initializer-clause</I> that follows it in the comma-separated list
of the <I>initializer-list</I>. [<I>Note:</I> This evaluation ordering
holds regardless of the semantics of the initialization; for example,
it applies when the elements of the <I>initializer-list</I> are
interpreted as arguments of a constructor call, even though ordinarily
there are no sequencing constraints on the arguments of a call.
&#8212;<I>end note</I>]</SPAN>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="355"></A><H4>355.
  
Global-scope <TT>::</TT> in <I>nested-name-specifier</I>
</H4><B>Section: </B>9&#160; [class]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Clark Nelson
 &#160;&#160;&#160;

 <B>Date: </B>16 May 2002<BR>




<P>
In looking at a large handful of core issues related to
<I>elaborated-type-specifier</I>s and the naming of classes in general, I
discovered an odd fact. It turns out that there is exactly one place in the
grammar where <I>nested-name-specifier</I>
is not immediately preceded by "<TT>::</TT><SUB><I>opt</I></SUB>":
in <I>class-head</I>, which is used only for class definitions. So technically,
this example is ill-formed, and should evoke a syntax error:
</P>
<PRE>
  struct A;
  struct ::A { };
</PRE>
<P>
However, all of EDG, GCC and Microsoft's compiler accept it without a qualm.
In fact, I couldn't get any of them to even warn about it.</P>

<P><B>Suggested resolution:</B></P>

<P>It would simplify the grammar, and apparently better reflect existing
practice, to factor the global-scope operator into the rule for
<I>nested-name-specifier</I>.</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<P>The proposed resolution will be submitted as a separate document.</P>

<BR><BR><HR><A NAME="1207"></A><H4>1207.
  
Type of class member in <I>trailing-return-type</I>
</H4><B>Section: </B>9.3.1&#160; [class.mfct.non-static]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-06<BR>




<P>Consider the following example:</P>

<PRE>
    struct vector {
        struct iterator { };
        struct const_iterator { };
        iterator begin();
        const_iterator begin() const;
    };
    class block {
        vector v;
        auto end() const -&gt; decltype(v.begin()) { return v.begin(); }
    };
</PRE>

<P>Because the transformation of a member name into a class member
access expression (9.3.1 [class.mfct.non-static] paragraph 3) only
occurs inside the body of a non-static member function, the type
of <TT>v</TT> in the <I>trailing-return-type</I> is non-const but
is const in the return expression, resulting in a type mismatch
between the return expression and the return type of the function.</P>

<P>One possibility would be to include the <I>trailing-return-type</I>
as being subject to the transformation in 9.3.1 [class.mfct.non-static].
Note, however, that <TT>this</TT> is currently not in scope at that
point (see <A HREF="
     cwg_active.html#945">issue 945</A>).</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The CWG felt that, because <TT>this</TT> is effectively an
implicit parameter, the best approach would be to model its usability
on the visibility of parameters: it could be named wherever a
parameter of the function is in scope.</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<OL><LI><P>Change 5.1.1 [expr.prim.general] paragraph 2 as follows,
adding three new paragraphs:</P></LI>

<BLOCKQUOTE>

<P>The keyword <TT>this</TT> names a pointer to the object for which a
non-static member function (9.3.2 [class.this]) is invoked or
a non-static data member's initializer (9.2 [class.mem]) is
evaluated. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">The keyword <TT>this</TT> shall be used only inside the
body of a non-static member function (9.3 [class.mfct]) of the
nearest enclosing class or in a <I>brace-or-equal-initializer</I> for
a non-static data member (9.2 [class.mem]).  The type of the
expression is a pointer to the class of the function or non-static
data member, possibly with cv-qualifiers on the class type. The
expression is a prvalue.</SPAN></P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">If a <I>function-definition</I> or <I>member-declarator</I>
declares a member function of a class <TT>X</TT>, the expression
<TT>this</TT> is a prvalue of type &#8220;pointer to
<I>cv-qualifier-seq</I> <TT>X</TT>&#8221; between the optional
<I>cv-qualifier-seq</I> and the end of the <I>function-definition</I>
or <I>member-declarator</I>. It shall not appear before the optional
<I>cv-qualifier-seq</I> and it shall not appear within the declaration
of a static member function (although its type and value category is
defined within a static member function as it is within a non-static
member function). [<I>Note:</I> the type and value category is defined
even for the case of a static member function because declaration
matching does not occur until the complete declarator is known, and
<TT>this</TT> may be used in the <I>trailing-return-type</I> of the
declarator. &#8212;<I>end note</I>]</SPAN></P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">Otherwise, if a <I>member-declarator</I> declares a
non-static data member (9.2 [class.mem]) of a class <TT>X</TT>,
the expression <TT>this</TT> is a prvalue of type &#8220;pointer to
<TT>X</TT>&#8221; within the optional <I>brace-or-equal-initializer</I>.
It shall not appear elsewhere in the <I>member-declarator</I>.</SPAN></P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">The expression <TT>this</TT> shall not appear in any other
context.</SPAN></P>

<P>[<I>Example:</I>...</P>

</BLOCKQUOTE>

<LI><P>Change 5.1.1 [expr.prim.general] paragraph 10 as follows:</P></LI>

<BLOCKQUOTE>

<P>An <I>id-expression</I> that denotes a non-static data member or
non-static member function of a class can only be used:</P>

<UL><LI><P>...</P></LI>

<LI><SPAN style="text-decoration:line-through;background-color:#FFA0A0">in the body of</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">beyond the optional
<I>cv-qualifier-seq</I> in the <I>member-declarator</I> or
<I>function-definition</I> that declares</SPAN> a non-static member
function of that class or of a class derived from that class
(9.3.1 [class.mfct.non-static]), or</LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 9.3.1 [class.mfct.non-static] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

When an <I>id-expression</I> (5.1 [expr.prim]) that is not
part of a class member access syntax (5.2.5 [expr.ref]) and
not used to form a pointer to member (5.3.1 [expr.unary.op]) is
used in the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">body</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">declaration</SPAN> of a
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">non-static</SPAN> member function of class <TT>X</TT>, if name
lookup (3.4 [basic.lookup]) resolves the name...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="696"></A><H4>696.
  
Use of block-scope constants in local classes
</H4><B>Section: </B>9.8&#160; [class.local]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>29 May, 2008<BR>


<P>According to 9.8 [class.local] paragraph 1,</P>

<BLOCKQUOTE>

Declarations in a local class can use only type names, static variables,
extern variables and functions, and enumerators from the enclosing scope.

</BLOCKQUOTE>

<P>This would presumably make both of the members of <TT>S2</TT> below
ill-formed:</P>

<PRE>
    void test () {
      const int local_const = 7;
      struct S2 {
        int member:local_const;
        void f() { int j = local_const; }
      };
    }
</PRE>

<P>Should there be an exception to this rule for constant values?
Current implementations seem to accept the reference to
<TT>local_const</TT> in the bit-field declaration but not in the
member function definition.  Should they be the same or different?</P>

<P><B>Notes from the September, 2008 meeting:</B></P>

<P>The CWG agreed that both uses of <TT>local_const</TT> in the
example above should be accepted.  The intent of the restriction
was to avoid the need to pass a frame pointer into local class
member functions, so uses of local const variables as values
should be permitted.</P>

<P><B>Notes from the October, 2009 meeting:</B></P>

<P>There was interest in an approach that would allow
explicitly-captured constants to appear in constant expressions
but also to be &#8220;used.&#8221; Another suggestion was to have
variables captured if they appear in either &#8220;use&#8221; or
&#8220;non-use&#8221; contexts.</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<OL><LI><P>Change 5.1.2 [expr.prim.lambda] paragraph 17 as
follows:</P></LI>

<BLOCKQUOTE>

<P>Every <I>id-expression</I> that is an odr-use (3.2 [basic.def.odr]) of an entity captured by copy is transformed into an
access to the corresponding unnamed data member of the closure
type. <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> an <I>id-expression</I> that is not an
odr-use refers to the original entity, never to a member of the
closure type. Furthermore, such an <I>id-expression</I> does not cause
the implicit capture of the entity. &#8212;<I>end note</I>]</SPAN> If
<TT>this</TT> is captured, each odr-use of <TT>this</TT> is
transformed into an access to the corresponding unnamed data member of
the closure type, cast (5.4 [expr.cast]) to the type of
<TT>this</TT>. [<I>Note:</I> the cast ensures that the transformed
expression is a prvalue. &#8212;<I>end note</I>]
<SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  void f(const int*);
  void g() {
    const int N = 10;
    [=] {
      int arr[N];    //<SPAN style="font-family:Times;font-style:italic"> OK: not an odr-use, refers to automatic variable</SPAN>
      f(&amp;N);         //<SPAN style="font-family:Times;font-style:italic"> OK: causes </SPAN>N<SPAN style="font-family:Times;font-style:italic"> to be captured; </SPAN>&amp;N<SPAN style="font-family:Times;font-style:italic"> points to the</SPAN>
                     //<SPAN style="font-family:Times;font-style:italic"> corresponding member of the closure type</SPAN>
    }
  }</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

<LI>Change 9.8 [class.local] paragraph 1 as follows:</LI>

<BLOCKQUOTE>

<P>...Declarations in a local class <SPAN style="text-decoration:line-through;background-color:#FFA0A0">can use only type names,
static variables, extern variables and functions, and enumerators from
the</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">shall not odr-use (3.2 [basic.def.odr]) a variable
with automatic storage duration from an</SPAN> enclosing
scope. [<I>Example:</I></P>

<PRE>
  int x;
  void f() {
    static int s ;
    int x;
<SPAN style="font-weight:bold;background-color:#A0FFA0">    const int N = 5;</SPAN>
    extern int <SPAN style="text-decoration:line-through;background-color:#FFA0A0">g</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">q</SPAN>();

    struct local {
      int g() { return x; }     //<SPAN style="font-family:Times;font-style:italic"> error: <SPAN style="font-weight:bold;background-color:#A0FFA0">odr-use of automatic variable</SPAN> </SPAN>x<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><SPAN style="font-family:Times;font-style:italic"> has automatic storage duration</SPAN></SPAN>
      int h() { return s; }     //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
      int k() { return ::x; }   //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
      int l() { return <SPAN style="text-decoration:line-through;background-color:#FFA0A0">g</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">q</SPAN>(); } //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">      int m() { return N; }     //<SPAN style="font-family:Times;font-style:italic"> OK: not an odr-use</SPAN>
      int* n() { return &amp;N; }   //<SPAN style="font-family:Times;font-style:italic"> error: odr-use of automatic variable </SPAN>N</SPAN>
    };
  }

  local* p = 0;                 //<SPAN style="font-family:Times;font-style:italic"> error: </SPAN>local<SPAN style="font-family:Times;font-style:italic"> not in scope</SPAN>
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1191"></A><H4>1191.
  
Deleted subobject destructors and implicitly-defined constructors
</H4><B>Section: </B>12.1&#160; [class.ctor]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-02<BR>




<P>Consider the following example:</P>

<PRE>
    struct A {
       A();
       ~A() = delete;
    };

    struct B: A { };
    B* b = new B;
</PRE>

<P>Under the current rules, <TT>B()</TT> is not deleted, but is
ill-formed because it calls the deleted <TT>~A::A()</TT> if it exits
via an exception after the completion of the construction of
<TT>A</TT>. A deleted subobject destructor should be added to the list
of reasons for implicit deletion in 12.1 [class.ctor] and
12.8 [class.copy].</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The CWG agreed that a change was needed, but only if one or more
base and/or member constructors are non-trivial.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<OL><LI><P>Add a new bullet to 12.1 [class.ctor] paragraph 5 as
follows:</P></LI>

<BLOCKQUOTE>

<P>...A defaulted default constructor for class <TT>X</TT> is defined
as deleted if:</P>

<UL><LI><P>...</P></LI>

<LI><P><TT>X</TT> is a non-union class and all members of any
anonymous union member are of const-qualified type (or array thereof),
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">or</SPAN></P></LI>

<LI><P>any direct or virtual base class, or non-static data member
with no <I>brace-or-equal-initializer</I>, has class type <TT>M</TT>
(or array thereof) and either <TT>M</TT> has no default constructor or
overload resolution (13.3 [over.match]) as applied to
<TT>M</TT>'s default constructor results in an ambiguity or in a
function that is deleted or inaccessible from the defaulted default
constructor<SPAN style="text-decoration:line-through;background-color:#FFA0A0">.</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">, or</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">any direct or virtual base class or non-static data member
has a type with a destructor that is deleted or inaccessible from the
defaulted default constructor.</SPAN></P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Add a new bullet to 12.8 [class.copy] paragraph 12 as
follows:</P></LI>

<BLOCKQUOTE>

<P>...A defaulted copy/move constructor for a class <TT>X</TT> is
defined as deleted (8.4.3 [dcl.fct.def.delete]) if X has:</P>

<UL><LI><P>a variant member with a non-trivial corresponding
constructor and <TT>X</TT> is a union-like class,</P></LI>

<LI><P>a non-static data member of class type <TT>M</TT> (or array
thereof) that cannot be copied/moved because overload resolution
(13.3 [over.match]), as applied to <TT>M</TT>'s corresponding
constructor, results in an ambiguity or a function that is deleted or
inaccessible from the defaulted constructor, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or</SPAN></P></LI>

<LI><P>a direct or virtual base class <TT>B</TT> that cannot be
copied/moved because overload resolution (13.3 [over.match]),
as applied to <TT>B</TT>'s corresponding constructor, results in an
ambiguity or a function that is deleted or inaccessible from the
defaulted constructor, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">any direct or virtual base class or non-static data member
of a type with a destructor that is deleted or inaccessible from the
defaulted constructor,</SPAN></P></LI>

<LI><P>for the copy constructor, a non-static data member of rvalue
reference type, or</P></LI>

<LI><P>for the move constructor, a non-static data member or direct or
virtual base class with a type that does not have a move constructor
and is not trivially copyable.</P></LI>

</UL>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1096"></A><H4>1096.
  
Missing requirement for template definitions
</H4><B>Section: </B>14&#160; [temp]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-07-28<BR>




<P>The removal of the <TT>export</TT> keyword inadvertently deleted
the text (previously found in 14 [temp] paragraph 8 of
the 2003 Standard),</P>

<BLOCKQUOTE>

A non-exported template must be defined in every
translation unit in which it is implicitly instantiated
(14.7.1 [temp.inst]), unless the corresponding
specialization is explicitly instantiated (14.7.2 [temp.explicit]) in some translation unit; no diagnostic is
required.

</BLOCKQUOTE>

<P>This requirement must be reinstated.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<P>Add the following as a new paragraph following 14 [temp]
paragraph 5:</P>

<BLOCKQUOTE>

<SPAN style="font-weight:bold;background-color:#A0FFA0">A function template, member function of a class template, or
static data member of a class template shall be defined in every
translation unit in which it is implicitly instantiated (14.7.1 [temp.inst]), unless the corresponding specialization is explicitly
instantiated (14.7.2 [temp.explicit]) in some translation unit;
no diagnostic is required.</SPAN>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1068"></A><H4>1068.
  
Template aliases with default arguments and template parameter packs
</H4><B>Section: </B>14.1&#160; [temp.param]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-27<BR>


<P>Since there appear to be no restrictions against it, it would
appear that default arguments and template parameter packs can be
used with template aliases just as with other templates.  If that
is the case, then, the current wording in 14.1 [temp.param]
paragraph 11 requires adjustment:</P>

<BLOCKQUOTE>

If a <I>template-parameter</I> of a class template has a default
<I>template-argument</I>, each subsequent
<I>template-parameter</I> shall either have a default
<I>template-argument</I> supplied or be a template parameter
pack.  If a <I>template-parameter</I> of a class template is a
template parameter pack, it shall be the last
<I>template-parameter</I>.

</BLOCKQUOTE>

<P>Presumably these restrictions should also apply to template
aliases, but as written, they only apply to class templates.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<P>Change 14.1 [temp.param] paragraph 11 as follows:</P>

<BLOCKQUOTE>

If a <I>template-parameter</I> of a class template <SPAN style="font-weight:bold;background-color:#A0FFA0">or alias
template</SPAN> has a default <I>template-argument</I>, each subsequent
<I>template-parameter</I> shall either have a default
<I>template-argument</I> supplied or be a template parameter pack.  If
a <I>template-parameter</I> of a primary class template <SPAN style="font-weight:bold;background-color:#A0FFA0">or alias
template</SPAN> is a template parameter pack, it shall be the last
<I>template-parameter</I>.  [<I>Note:</I>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="993"></A><H4>993.
  
Freedom to perform instantiation at the end of the translation unit
</H4><B>Section: </B>14.6.4.1&#160; [temp.point]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>6 March, 2009<BR>


<P>The intent is that it is a permissible implementation technique to
do template instantiation at the end of a translation unit rather than
at an actual point of instantiation.  This idea is not reflected in the
current rules, however.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<P>Change 14.6.4.1 [temp.point] paragraph 7 as follows:</P>

<BLOCKQUOTE>

A specialization for a function template, a member function template,
or of a member function or static data member of a class template may
have multiple points of instantiations within a translation unit<SPAN style="font-weight:bold;background-color:#A0FFA0">,
and in addition to the points of instantiation described above, for
any such specialization that has a point of instantiation within the
translation unit, the end of the translation unit is also considered a
point of instantiation</SPAN>.  A specialization for a class
template...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1170"></A><H4>1170.
  
Access checking during template argument deduction
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-03<BR>


<P>According to 14.8.2 [temp.deduct] paragraph 8,</P>

<BLOCKQUOTE>

Access checking is not done as part of the substitution
process.  Consequently, when deduction succeeds, an access
error could still result when the function is instantiated.

</BLOCKQUOTE>

<P>This mimics the way access checking is done in overload
resolution.  However, experience has shown that this exemption
of access errors from deduction failure significantly complicates
the Standard library, so this rule should be changed.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<P>Change 14.8.2 [temp.deduct] paragraph 8 as follows:</P>

<BLOCKQUOTE>

If a substitution results in an invalid type or expression, type
deduction fails. An invalid type or expression is one that would be
ill-formed if written using the substituted arguments.
<SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I></SPAN> Access checking is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">not</SPAN> done as
part of the substitution process.  <SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end note</I>]</SPAN>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">Consequently, when deduction succeeds, an access error could still
result when the function is instantiated.</SPAN>  Only invalid types...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1218"></A><H4>1218.
  
What is the &#8220;currently-handled exception&#8221; in a multi-threaded program?
</H4><B>Section: </B>15.3&#160; [except.handle]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>CA
 &#160;&#160;&#160;

 <B>Date: </B>2010-11-12<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#CA5">N3092 comment
  CA&#160;5<BR></A>

<P>15.3 [except.handle] paragraph 8 defines the &#8220;currently
handled exception&#8221; as</P>

<BLOCKQUOTE>

The exception with the most recently activated handler that is still active

</BLOCKQUOTE>

<P>This definition ignores the possibility that an exception might be
thrown and caught in another thread during the execution of a handler.
Since <TT>throw;</TT> rethrows the &#8220;currently handled
exception,&#8221; one might conclude that it would be the other
thread's exception that would be rethrown instead of the one that
activated that handler.</P>

<P><B>Proposed resolution (January, 2011):</B></P>

<OL><LI><P>Change 15 [except] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

Exception handling provides a way of transferring control and
information from a point in the execution of a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">program</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">thread</SPAN> to an exception handler associated with a point
previously passed by the execution...

</BLOCKQUOTE>

<LI><P>Change 15.1 [except.throw] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

...The implementation may then deallocate the memory for the exception
object; any such deallocation is done in an unspecified way. <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I>
An exception thrown by a <I>throw-expression</I> does not propagate to other
threads unless caught, stored, and rethrown using appropriate library
functions; see 18.8.5 [propagation] and 30.6 [futures].
&#8212;<I>end note</I>]</SPAN>

</BLOCKQUOTE>

<LI><P>Change 15.3 [except.handle] paragraph 6 as follows:</P></LI>

If no match is found among the handlers for a try block, the search
for a matching handler continues in a dynamically surrounding try
block <SPAN style="font-weight:bold;background-color:#A0FFA0">of the same thread</SPAN>.

</OL>



<BR><BR><BR><BR><HR><A NAME="Review Status"></A><H3>Issues with "Review" Status</H3>
<HR><A NAME="1189"></A><H4>1189.
  
Address of distinct base class subobjects
</H4><B>Section: </B>1.8&#160; [intro.object]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-31<BR>




<P>1.8 [intro.object] paragraph 6 says,</P>

<BLOCKQUOTE>

Two distinct objects that are neither bit-fields nor base class
subobjects of zero size shall have distinct addresses.

</BLOCKQUOTE>

<P>This formulation leaves open the possibility that two base
class subobjects of the same type could have the same address
(because one or both might be zero-length base class
subobjects).</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 1.8 [intro.object] paragraph 6 as follows:</P>

<BLOCKQUOTE>

Unless an object is a bit-field or a base class subobject of zero
size, the address of that object is the address of the first byte it
occupies. Two distinct objects that are <SPAN style="text-decoration:line-through;background-color:#FFA0A0">neither</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">not</SPAN> bit-fields <SPAN style="text-decoration:line-through;background-color:#FFA0A0">nor base class subobjects of zero
size</SPAN> shall have distinct addresses<SPAN style="font-weight:bold;background-color:#A0FFA0">, if both have the same
type or if not both are base class subobjects of zero size</SPAN>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1176"></A><H4>1176.
  
Definition of release sequence
</H4><B>Section: </B>1.10&#160; [intro.multithread]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>CA, GB
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-10<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#CA12">N3092 comment
  CA&#160;12<BR></A>
<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#GB9">N3092 comment
  GB&#160;9<BR></A>

<P>The current wording of the standard suggests
that release sequences are maximal with respect to
sequence inclusion, i.e. that if there are two release
operations in the modification order,</P>

<PRE>
mod       mod
rel1-----&gt;rel2-----&gt;w
</PRE>

<P>then <TT>[rel1;rel2;w]</TT> is the only release sequence, as the
other candidate <TT>[rel2;w]</TT> is included in it. This
interpretation precludes synchronizing with releases which have other
releases sequenced-before them. We believe that the intention is
actually to define the maximal release sequence from a particular
release operation, which would admit both <TT>[rel1;rel2;w]</TT> and
<TT>[rel2;w]</TT>.</P>

<P><B>Proposed resolution (August, 2010):</B></P>

<P>Change 1.10 [intro.multithread] paragraph 6 as follows:</P>

<BLOCKQUOTE>

<P>A <I>release sequence</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">from a release operation
<I>A</I></SPAN> on an atomic object <I>M</I> is a maximal contiguous
sub-sequence of side effects in the modification order of
<I>M</I>, where the first operation is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a release</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>A</I></SPAN>, and every subsequent operation</P>

<UL><LI><P>is performed by the same thread that performed the release,
or</P></LI>

<LI><P>is an atomic read-modify-write operation.</P></LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1177"></A><H4>1177.
  
Intra-thread dependency-ordered-before
</H4><B>Section: </B>1.10&#160; [intro.multithread]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>CA
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-10<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#CA15">N3092 comment
  CA&#160;15<BR></A>

<P>The current draft has release/acquire synchronize-with
edges only between a release on one thread and an
acquire on a <I>different</I> thread, whereas the definition of
dependency-ordered-before permits the release and
consume to be on the same thread; it seems odd to permit
the latter. (At the moment function arguments can't race or
sync with each other, but they can be dependency
ordered before each other.)</P>

<P>We don't currently have an example in which this makes a real
difference, but for symmetry could suggest changing the definition of
dependency-ordered-before in 1.10 [intro.multithread].</P>

<P><B>Proposed resolution (August, 2010):</B></P>

<P>Change 1.10 [intro.multithread] paragraph 9 as follows:</P>

<BLOCKQUOTE>

<P>An evaluation <I>A</I> is <I>dependency-ordered before</I> an
evaluation <I>B</I> if</P>

<UL><LI><P><I>A</I> performs a release operation on an atomic object
<I>M</I>, and<SPAN style="font-weight:bold;background-color:#A0FFA0">, on another thread,</SPAN> <I>B</I> performs a
consume operation on <I>M</I> and reads a value written by any side
effect in the release sequence headed by <I>A</I>, or</P></LI>

<LI><P>for some evaluation <I>X</I>, <I>A</I> is dependency-ordered
before <I>X</I> and <I>X</I> carries a dependency to
<I>B</I>.</P></LI>

</UL>

<P>[<I>Note:</I>...</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1175"></A><H4>1175.
  
Disambiguating user-defined literals
</H4><B>Section: </B>2.14.8&#160; [lex.ext]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Sebastian Gesemann
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-10<BR>


<P>A user-defined literal like <TT>0x123DZ</TT> could be
parsed either as a <I>hexadecimal-literal</I> of <TT>0x123</TT> and a
<I>ud-suffix</I> of <TT>DZ</TT> or as a <I>hexadecimal-literal</I> of
<TT>0x123D</TT> and a <I>ud-suffix</I> of <TT>Z</TT>.  There does not
appear to be a rule that disambiguates the two possible parses.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 2.14.8 [lex.ext] paragraph 1 as follows:</P>

<BLOCKQUOTE>

If a token matches both <I>user-defined-literal</I> and another
literal kind, it is treated as the latter.  [<I>Example:</I>
<TT>123_km</TT>, <TT>1.2LL</TT>, <TT>"Hello"s</TT> are all
<I>user-defined-literal</I>s, but <TT>12LL</TT> is an
<I>integer-literal</I>.  &#8212;<I>end example</I>] <SPAN style="font-weight:bold;background-color:#A0FFA0">The syntactic
nonterminal preceding the <I>ud-suffix</I> in a
<I>user-defined-literal</I> is taken to be the longest sequence of
characters that could match that nonterminal. [<I>Example:</I> The
<I>ud-suffix</I> in <TT>1.0e0X</TT> is <TT>X</TT>, not <TT>e0X</TT>;
in <TT>0x1DZ</TT>, the <I>ud-suffix</I> is <TT>Z</TT>, not
<TT>DZ</TT>. &#8212;<I>end example</I>]</SPAN>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="758"></A><H4>758.
  
Missing cases of declarations that are not definitions
</H4><B>Section: </B>3.1&#160; [basic.def]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Bjarne Stroustrup
 &#160;&#160;&#160;

 <B>Date: </B>22 January, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK23">N2800 comment
  UK&#160;23<BR></A>
<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK24">N2800 comment
  UK&#160;24<BR></A>



<P>The list of declarations that are not definitions given in
3.1 [basic.def] paragraph 2 does not mention several plausible
candidates: parameter declarations in non-defining function declarations,
non-static data members, and template parameters.  It might be argued
that none of these are <I>declaration</I>s (paragraph 1 does not use the
syntactic non-terminal <I>declaration</I> but does explicitly refer to
clause 7 [dcl.dcl], where that non-terminal is defined).
However, the list in paragraph 2 does mention static member declarations,
which also are not <I>declaration</I>s, so the intent is not clear.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 3.1 [basic.def] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A declaration is a <I>definition</I> unless it declares a function
without specifying the function's body (8.4 [dcl.fct.def]), it
contains the <TT>extern</TT> specifier (7.1.1 [dcl.stc]) or
a <I>linkage-specification</I><SUP>25</SUP> (7.5 [dcl.link])
and neither an <I>initializer</I> nor a <I>function-body</I>, it
declares a static data member in a class definition (<SPAN style="font-weight:bold;background-color:#A0FFA0">9.2 [class.mem],</SPAN> 9.4 [class.static]), it is a class name
declaration (9.1 [class.name]), it is an
<I>opaque-enum-declaration</I> (7.2 [dcl.enum]), <SPAN style="font-weight:bold;background-color:#A0FFA0">it
is a <I>template-parameter</I> (14.1 [temp.param]), it is a
<I>parameter-declaration</I> (8.3.5 [dcl.fct]) in a
function declaration that is not a definition,</SPAN> or it is a
<TT>typedef</TT> declaration (7.1.3 [dcl.typedef]), <SPAN style="font-weight:bold;background-color:#A0FFA0">an
<I>alias-declaration (7.1.3 [dcl.typedef]),</I></SPAN> a
<I>using-declaration</I> (7.3.3 [namespace.udecl]), a
<I>static_assert-declaration</I> (Clause 7 [dcl.dcl]), an
<I>attribute-declaration</I> (Clause 7 [dcl.dcl]), an
<I>empty-declaration</I> (Clause 7 [dcl.dcl]), or a
<I>using-directive</I> (7.3.4 [namespace.udir]).

</BLOCKQUOTE>

<BR><BR><HR><A NAME="712"></A><H4>712.
  
Are integer constant operands of a <I>conditional-expression</I> &#8220;used?&#8221;
</H4><B>Section: </B>3.2&#160; [basic.def.odr]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>9 September, 2008<BR>


<P>In describing static data members initialized inside the class
definition, 9.4.2 [class.static.data] paragraph 3 says,</P>

<BLOCKQUOTE>

The member shall still be defined in a namespace scope if it is
used in the program...

</BLOCKQUOTE>

<P>The definition of &#8220;used&#8221; is in 3.2 [basic.def.odr]
paragraph 1:</P>

<BLOCKQUOTE>

An object or non-overloaded function whose name appears as a
potentially-evaluated expression is <I>used</I> unless it is an
object that satisfies the requirements for appearing in a
constant expression (5.19 [expr.const]) and the
lvalue-to-rvalue conversion (4.1 [conv.lval]) is
immediately applied.

</BLOCKQUOTE>

<P>Now consider the following example:</P>

<PRE>
    struct S {
      static const int a = 1;
      static const int b = 2;
    };
    int f(bool x) {
      return x ? S::a : S::b;
    }
</PRE>

<P>According to the current wording of the Standard, this example
requires that <TT>S::a</TT> and <TT>S::b</TT> be defined in a
namespace scope.  The reason for this is that, according to
5.16 [expr.cond] paragraph 4, the result of this
<I>conditional-expression</I> is an lvalue and the
lvalue-to-rvalue conversion is applied to that, not directly
to the object, so this fails the &#8220;immediately applied&#8221;
requirement.  This is surprising and unfortunate, since only the
values and not the addresses of the static data members are used.
(This problem also applies to the proposed resolution of
<A HREF="
     cwg_active.html#696">issue 696</A>.)</P>

<P><B>Proposed resolution (November, 2009):</B></P>

<P>Change 3.2 [basic.def.odr] paragraph 1 as follows:</P>

<BLOCKQUOTE>

...An object or non-overloaded function whose name appears as a
potentially-evaluated expression <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>x</TT></SPAN> is used
unless it is an object that satisfies the requirements for
appearing in a constant expression (5.19 [expr.const])
and the lvalue-to-rvalue conversion (4.1 [conv.lval]) is
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">immediately applied</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">eventually applied to all
lvalue expressions <TT>e</TT> that could possibly denote that
object, where <TT>e</TT> is a subexpression of the
full-expression containing <TT>x</TT></SPAN>...

</BLOCKQUOTE>

<P><B>Additional notes (November, 2009):</B></P>

<P>The proposed wording (like the existing wording) requires that
<TT>S::a</TT> be defined in the following example:</P>

<PRE>
  struct S {
    static const int a = 1;
  };
  void g() {
    S::a;  //<SPAN style="font-family:Times;font-style:italic"> no lvalue-to-rvalue conversion</SPAN>
  }
</PRE>

<P>Although this particular example is obviously unimportant,
there could be similar cases where a use is buried in a nested
conditional and the result eventually discarded, perhaps as the
result of a macro expansion.  An alternative approach that
addresses this point might be something along the lines of</P>

<BLOCKQUOTE>

There is no lvalue expression <TT>e</TT> of which <TT>x</TT> is a
subexpression to which a reference is bound or to which the unary
<TT>&amp;</TT> operator is applied that could possibly denote
that object.

</BLOCKQUOTE>

<P>One objection to this latter approach is that it would require
defining <TT>S::a</TT> if the expression were something like
<TT>*&amp;S::a</TT>, which would not be the case with the wording
in the proposed resolution.</P>

<BR><BR><HR><A NAME="1174"></A><H4>1174.
  
When is a pure virtual function &#8220;used?&#8221;
</H4><B>Section: </B>3.2&#160; [basic.def.odr]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-07<BR>




<P>According to 3.2 [basic.def.odr] paragraph 2,</P>

<BLOCKQUOTE>

A variable or non-overloaded function whose name appears as a
potentially-evaluated expression is <I>used</I>... A virtual member
function is used if it is not pure.

</BLOCKQUOTE>

<P>However, that does not adequately address when a pure virtual
function is used or not used.  For example,</P>

<PRE>
    struct S {
      virtual void pure1() = 0;
      virtual void pure2() = 0;
    };
    void f(S* p) {
      p-&gt;pure1();
      p-&gt;S::pure2();
    };
</PRE>

<P>Both <TT>pure1</TT> and <TT>pure2</TT> satisfy the criterion that
their name appears in a potentially-evaluated expression, but
<TT>pure1</TT> should not be considered &#8220;used&#8221; (which
would require that it be defined); <TT>pure2</TT> <I>is</I>
&#8220;used&#8221; and must be defined.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 3.2 [basic.def.odr] paragraph 2 as follows:</P>

<BLOCKQUOTE>

...A variable <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or non-overloaded function</SPAN> whose name appears
as a potentially-evaluated expression is odr-used unless it is an
object that satisfies the requirements for appearing in a constant
expression (5.19 [expr.const]) and the lvalue-to-rvalue
conversion (4.1 [conv.lval]) is immediately applied...  A
virtual member function is odr-used if it is not pure.  A
<SPAN style="font-weight:bold;background-color:#A0FFA0">non-overloaded function whose name appears as a
potentially-evaluated expression or a</SPAN> member of a set of
candidate functions <SPAN style="text-decoration:line-through;background-color:#FFA0A0">is odr-used</SPAN> if <SPAN style="text-decoration:line-through;background-color:#FFA0A0">it is</SPAN>
selected by overload resolution when referred to from a
potentially-evaluated expression<SPAN style="font-weight:bold;background-color:#A0FFA0">, are odr-used, unless the
function is pure and its name is not explicitly
qualified</SPAN>. [<I>Note:</I>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1192"></A><H4>1192.
  
Inadvertent change to ODR and templates
</H4><B>Section: </B>3.2&#160; [basic.def.odr]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-03<BR>




<P><A HREF="
     cwg_defects.html#678">Issue 678</A> added a bullet to the list
in 3.2 [basic.def.odr] paragraph 5, inadvertently removing the
second bullet from the reach of the part of that paragraph that
reads,</P>

<BLOCKQUOTE>

If <TT>D</TT> is a template and is defined in more than one translation unit,
then the last four requirements from the list above shall apply to
names from the template's enclosing scope used in the template
definition (14.6.3 [temp.nondep]),

</BLOCKQUOTE>

<P>In fixing this error, the wording should be recast to be more
robust in the face of possible further edits to the list (i.e., not
just changing &#8220;four&#8221; to &#8220;five&#8221;).</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 3.2 [basic.def.odr] paragraph 5 as follows:</P>

<BLOCKQUOTE>

...If <TT>D</TT> is a template and is defined in more than one
translation unit, then the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">last four</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">preceding</SPAN>
requirements <SPAN style="text-decoration:line-through;background-color:#FFA0A0">from the list above</SPAN> shall apply
<SPAN style="font-weight:bold;background-color:#A0FFA0">both</SPAN> to names from the template's enclosing scope used in
the template definition (14.6.3 [temp.nondep]), and also to
dependent names at the point of instantiation (14.6.2 [temp.dep])...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="554"></A><H4>554.
  
Definition of &#8220;declarative region&#8221; and &#8220;scope&#8221;
</H4><B>Section: </B>3.3&#160; [basic.scope]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>29 December 2005<BR>




<P>The various uses of the term &#8220;declarative region&#8221;
throughout the Standard indicate that the term is intended to refer
to the entire block, class, or namespace that contains a given
declaration.  For example, 3.3 [basic.scope] paragraph 2
says, in part:</P>

<BLOCKQUOTE>

<P>[<I>Example:</I> in</P>

<PRE>
    int j = 24;
    int main()
    {
        int i = j, j;
        j = 42;
    }
</PRE>

<P>The declarative region of the first <TT>j</TT> includes the entire
example... The declarative region of the second declaration
of <TT>j</TT> (the <TT>j</TT> immediately before the semicolon)
includes all the text between <TT>{</TT> and <TT>}</TT>...</P>

</BLOCKQUOTE>

<P>However, the actual definition given for &#8220;declarative
region&#8221; in 3.3 [basic.scope] paragraph 1
does not match this usage:</P>

<BLOCKQUOTE>

Every name is introduced in some portion of program text called a
<I>declarative region</I>, which is the largest part of the program in
which that name is <I>valid</I>, that is, in which that name may be
used as an unqualified name to refer to the same entity.

</BLOCKQUOTE>

<P>Because (except in class scope) a name cannot be used before
it is declared, this definition contradicts the statement in the
example and many other uses of the term throughout the Standard.
As it stands, this definition is identical to that of the scope
of a name.</P>

<P>The term &#8220;scope&#8221; is also misused.  The scope of a
declaration is defined in 3.3 [basic.scope] paragraph 1 as
the region in which the name being declared is valid.  However, there
is frequent use of the phrase &#8220;the scope of a class,&#8221; not
referring to the region in which the class's name is valid but to the
declarative region of the class body, and similarly for namespaces,
functions, exception handlers, etc.  There is even a mention of
looking up a name &#8220;in the scope of the
complete <I>postfix-expression</I>&#8221; (3.4.5 [basic.lookup.classref] paragraph 3), which is the exact inverse of the scope
of a declaration.</P>

<P>This terminology needs a thorough review to make it logically
consistent.  (Perhaps a discussion of the scope of template
parameters could also be added to section 3.3 [basic.scope]
at the same time, as all other kinds of scopes are described there.)</P>

<P><B>Proposed resolution (November, 2006):</B></P>

<OL>
<LI><P>Change 3.3 [basic.scope] paragraph 1 as follows:
</P></LI>

<BLOCKQUOTE>

Every name is introduced in some portion of program text called a
<I>declarative region</I>, which is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the largest part of the
program in which that name is <I>valid</I>, that is, in which
that name may be used as an unqualified name to refer to the same
entity</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a <I>statement</I>, block, function declarator,
<I>function-definition</I>, class, handler, <I>template-declaration</I>,
<I>template-parameter-list</I> of a template
<I>template-parameter</I>, or namespace</SPAN>. In general, each
particular name <SPAN style="text-decoration:line-through;background-color:#FFA0A0">is valid</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">may be used as an unqualified
name to refer to the entity of its declaration or to the
label</SPAN> only within some possibly discontiguous portion of
program text called its <I>scope</I>. To determine the scope of a
declaration...

</BLOCKQUOTE>

<LI><P>Change 3.3 [basic.scope] paragraph 3 as follows:
</P></LI>

<BLOCKQUOTE>

The names declared by a declaration are introduced into the
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">scope in which the declaration occurs</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">declarative
region that directly encloses the declaration</SPAN>, except that
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>declaration-statement</I>s, function parameter names in the
declarator of a <I>function-definition</I>,
<I>exception-declaration</I>s (3.3.3 [basic.scope.local]),</SPAN>
the presence of a <TT>friend</TT> specifier (11.4 [class.friend]), certain uses of the
<I>elaborated-type-specifier</I> (7.1.6.3 [dcl.type.elab]),
and <I>using-directive</I>s (7.3.4 [namespace.udir]) alter
this general behavior.

</BLOCKQUOTE>

<LI><P>Change 3.3.3 [basic.scope.local] paragraphs 1-3 and add a
new paragraph 4 before the existing paragraph 4 as follows:
</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A name declared in a block (6.3 [stmt.block]) is
local to that block. Its potential scope begins at its point of
declaration (3.3.2 [basic.scope.pdecl]) and ends at the end of
its declarative region.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The declarative region of a name
declared in a <I>declaration-statement</I> is the directly
enclosing block (6.3 [stmt.block]). Such a name is local
to the block.</SPAN></P>

<P>The <SPAN style="text-decoration:line-through;background-color:#FFA0A0">potential scope</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">declarative region</SPAN> of a
function parameter name <SPAN style="text-decoration:line-through;background-color:#FFA0A0">(including one appearing </SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">in
the declarator of a <I>function-definition</I> or</SPAN> in a
<I>lambda-parameter-declaration-clause</I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">)</SPAN> or of a
function-local predefined variable in a function definition
(8.4 [dcl.fct.def]) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">begins at its point of
declaration. If the function has a <I>function-try-block</I> the
potential scope of a parameter or of a function-local predefined
variable ends at the end of the last associated handler,
otherwise it ends at the end of the outermost block of the
function definition. A parameter name</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is the entire
function definition or <I>lambda-expression</I>. Such a name is
local to the function definition and</SPAN> shall not be redeclared
in <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">any</SPAN> outermost block of the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">function
definition nor in the outermost block of any handler associated
with a <I>function-try-block</I></SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>function-body</I> (including handlers of a
<I>function-try-block</I>) or <I>lambda-expression</I></SPAN>.</P>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">The name in a <TT>catch</TT> exception-declaration</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">The declarative region of a name declared in an
<I>exception-declaration</I> is its entire handler. Such a
name</SPAN> is local to the handler and shall not be redeclared in
the outermost block of the handler.</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">The potential scope of any local name begins at its point
of declaration (3.3.2 [basic.scope.pdecl]) and ends at the end
of its declarative region.</SPAN></P>

</BLOCKQUOTE>

<LI><P>Change 3.3.5 [basic.funscope] as indicated:
</P></LI>

<BLOCKQUOTE>

Labels (6.1 [stmt.label]) have <I>function scope</I> and
may be used anywhere in the function in which they are declared
<SPAN style="font-weight:bold;background-color:#A0FFA0">except in members of local classes (9.8 [class.local])
of that function</SPAN>. Only labels have function scope.

</BLOCKQUOTE>

<LI><P>Change 6.7 [stmt.dcl] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>A declaration statement introduces one or more new <SPAN style="text-decoration:line-through;background-color:#FFA0A0">identifiers</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">names</SPAN> into a block; it has the form</P>

<UL>
<I>declaration-statement:</I>
<UL>
<I>block-declaration</I>
</UL></UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I></SPAN> If <SPAN style="text-decoration:line-through;background-color:#FFA0A0">an identifier</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a name</SPAN>
introduced by a declaration was previously declared in an outer
block, the outer declaration is hidden for the remainder of the
block, after which it resumes its force <SPAN style="font-weight:bold;background-color:#A0FFA0">(3.3.10 [basic.scope.hiding])</SPAN>. <SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end note</I>]</SPAN></P>

</BLOCKQUOTE>
</OL>

<P><I>[Drafting notes: This resolution deals almost exclusively
with the unclear definition of &#8220;declarative region.&#8221;
I've left the ambiguous use of &#8220;scope&#8221; alone for now.
However sections 3.3.x all have headings reading &#8220;xxx
scope,&#8221; but they don't mean the scope of a declaration but
the different kinds of declarative regions and their effects on
the scope of declarations contained therein. To me, it looks like
most of 3.4 should refer to &#8220;declarative region&#8221; and
not to &#8220;scope.&#8221;</I></P>

<P><I>The change to 6.7 fixes an &#8220;identifier&#8221; misuse
(e.g., <TT>extern T operator+(T,T);</TT> at block scope
introduces a name but not an identifier) and removes normative
redundancy.]</I></P>

<BR><BR><HR><A NAME="555"></A><H4>555.
  
Pseudo-destructor name lookup
</H4><B>Section: </B>3.4&#160; [basic.lookup]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Krzysztof Zelechowski
 &#160;&#160;&#160;

 <B>Date: </B>26 January 2006<BR>


<P>The Standard does not completely specify how to look up the
<I>type-name</I>(s) in a <I>pseudo-destructor-name</I> (5.2 [expr.post] paragraph 1, 5.2.4 [expr.pseudo]), and what
information it does have is incorrect and/or in the wrong place.
Consider, for instance, 3.4.5 [basic.lookup.classref] paragraphs
2-3:</P>

<BLOCKQUOTE>

<P>If the <I>id-expression</I> in a class member access (5.2.5 [expr.ref]) is an <I>unqualified-id</I>, and the type of the
object expression is of a class type <TT>C</TT> (or of pointer to a
class type <TT>C</TT>), the <I>unqualified-id</I> is looked up in the scope
of class <TT>C</TT>. If the type of the object expression is of pointer to
scalar type, the <I>unqualified-id</I> is looked up in the context of the
complete <I>postfix-expression</I>.</P>

<P>If the <I>unqualified-id</I> is <TT>~</TT><I>type-name</I>, and the
type of the object expression is of a class type <TT>C</TT> (or of
pointer to a class type <TT>C</TT>), the <I>type-name</I> is looked up
in the context of the entire <I>postfix-expression</I> and in the
scope of class <TT>C</TT>. The <I>type-name</I> shall refer to
a <I>class-name</I>. If <I>type-name</I> is found in both contexts,
the name shall refer to the same class type. If the type of the object
expression is of scalar type, the <I>type-name</I> is looked up in the
scope of the complete <I>postfix-expression</I>.</P>

</BLOCKQUOTE>

<P>There are at least three things wrong with this passage with
respect to pseudo-destructors:</P>

<OL>

<LI><P>A pseudo-destructor call (5.2.4 [expr.pseudo]) is not
a &#8220;class member access&#8221;, so the statements about scalar
types in the object expressions are vacuous: the object expression in
a class member access is required to be a class type or pointer to
class type (5.2.5 [expr.ref] paragraph 2).</P></LI>

<LI><P>On a related note, the lookup for the <I>type-name</I>(s) in a
pseudo-destructor name should not be described in a section entitled
&#8220;Class member access.&#8221;</P></LI>

<LI><P>Although the class member access object expressions are
carefully allowed to be either a class type or a pointer to a class
type, paragraph 2 mentions only a &#8220;pointer to scalar type&#8221;
(disallowing references) and paragraph 3 deals only with a
&#8220;scalar type,&#8221; presumably disallowing pointers (although
it could possibly be a very subtle way of referring to both non-class
pointers and references to scalar types at once).</P></LI>

</OL>

<P>The other point at which lookup of pseudo-destructors is
mentioned is 3.4.3 [basic.lookup.qual] paragraph 5:</P>

<BLOCKQUOTE>

If a <I>pseudo-destructor-name</I> (5.2.4 [expr.pseudo])
contains a <I>nested-name-specifier</I>, the <I>type-name</I>s are
looked up as types in the scope designated by the
<I>nested-name-specifier</I>.

</BLOCKQUOTE>

<P>Again, this specification is in the wrong location (a
<I>pseudo-destructor-name</I> is not a <I>qualified-id</I> and
thus should not be treated in the &#8220;Qualified name lookup&#8221;
section).</P>

<P>Finally, there is no place in the Standard that describes the
lookup for pseudo-destructor calls of the form
<TT>p-&gt;T::~T()</TT> and <TT>r.T::~T()</TT>, where <TT>p</TT>
and <TT>r</TT> are a pointer and reference to scalar, respectively.
To the extent that it gives any guidance at all,
3.4.5 [basic.lookup.classref] deals only with the case where the
<TT>~</TT> immediately follows the <TT>.</TT> or <TT>-&gt;</TT>, and
3.4.3 [basic.lookup.qual] deals only with the case where the
<I>pseudo-destructor-name</I> contains
a <I>nested-name-specifier</I> that designates a scope in which
names can be looked up.</P>

<P>See document J16/06-0008 = WG21 N1938 for further discussion of
this and related issues, including <A HREF="
     cwg_defects.html#244">244</A>,
<A HREF="
     cwg_defects.html#305">305</A>, <A HREF="
     cwg_active.html#399">399</A>,
and <A HREF="
     cwg_defects.html#414">414</A>.</P>

<P><B>Proposed resolution (June, 2008):</B></P>

<OL><LI><P>Add a new paragraph following 5.2 [expr.post]
paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

When a <I>postfix-expression</I> is followed by a dot <TT>.</TT> or
arrow <TT>-&gt;</TT> operator, the interpretation depends on the type
<TT>T</TT> of the expression preceding the operator. If the operator
is <TT>.</TT>, <TT>T</TT> shall be a scalar type or a complete class
type; otherwise, <TT>T</TT> shall be a pointer to a scalar type or a
pointer to a complete class type. When <TT>T</TT> is a (pointer to) a
scalar type, the <I>postfix-expression</I> to which the operator
belongs shall be a pseudo-destructor call (5.2.4 [expr.pseudo]); otherwise, it shall be a class member access
(5.2.5 [expr.ref]).

</BLOCKQUOTE>

<LI><P>Change 5.2.4 [expr.pseudo] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">The left-hand side of the dot operator shall be of scalar type. The
left-hand side of the arrow operator shall be of pointer to scalar
type. This scalar type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The type of the expression preceding the dot
operator, or the type to which the expression preceding the arrow
operator points,</SPAN> is the object type...

</BLOCKQUOTE>

<LI><P>Change 5.2.5 [expr.ref] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

For the first option (dot) the type of the first expression (the
object expression) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall be &#8220;class object&#8221; (of a
complete type)</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is a class type</SPAN>. For the second option
(arrow) the type of the first expression (the pointer expression)
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall be &#8220;pointer to class object&#8221; (of a complete
type)</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is a pointer to a class type</SPAN>. In these cases, the
<I>id-expression</I> shall name a member of the class or of one of its
base classes.

</BLOCKQUOTE>

<LI><P>Add a new paragraph following 3.4 [basic.lookup]
paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

In a <I>pseudo-destructor-name</I> that does not include a
<I>nested-name-specifier</I>, the <I>type-name</I>s are looked up as
types in the context of the complete expression.

</BLOCKQUOTE>

<LI><P>Delete the last sentence of 3.4.5 [basic.lookup.classref]
paragraph 2:</P></LI>

<BLOCKQUOTE>

If the <I>id-expression</I> in a class member access (5.2.5 [expr.ref]) is an <I>unqualified-id</I>, and the type of the object
expression is of a class type <TT>C</TT>, the
<I>unqualified-id</I> is looked up in the scope of class
<TT>C</TT>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">If the type of the object expression is of pointer to
scalar type, the <I>unqualified-id</I> is looked up in the
context of the complete <I>postfix-expression</I>.</SPAN>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="997"></A><H4>997.
  
Argument-dependent lookup and dependent function template parameter types
</H4><B>Section: </B>3.4.2&#160; [basic.lookup.argdep]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>6 November, 2009<BR>




<P>3.4.2 [basic.lookup.argdep] paragraph 2 excludes dependent parameter
types and return types from consideration in determining the associated
classes and namespaces of a function template.  Presumably this means
that an example like</P>

<PRE>
    namespace N {
      template&lt;class T&gt; struct A { };
      void f(void (*)());
    }

    template &lt;class T&gt;
    void g(T, N::A&lt;T&gt;);

    void g();

    int main() {
      f(g);
    }
</PRE>

<P>is ill-formed because the second parameter of the function template
<TT>g</TT> does not add namespace <TT>N</TT> to the list of associated
namespaces.  This was probably unintentional.</P>

<P>See also <A HREF="
     cwg_active.html#1015">issue 1015</A>.</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The CWG agreed that the rules should be changed to make this
example well-formed.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 3.4.2 [basic.lookup.argdep] paragraph 2 as follows:</P>

<BLOCKQUOTE>

...In addition, if the argument is the name or address of a set of
overloaded functions and/or function templates, its associated classes
and namespaces are the union of those associated with each of the
members of the set, i.e., the classes and namespaces associated with
its <SPAN style="text-decoration:line-through;background-color:#FFA0A0">(non-dependent)</SPAN> parameter types and return type.
<SPAN style="font-weight:bold;background-color:#A0FFA0">Additionally, if the aforementioned set of overloaded functions
is named with a <I>template-id</I>, its associated classes
and namespaces are those of its type
<I>template-argument</I>s and its template
<I>template-argument</I>s.</SPAN>

</BLOCKQUOTE>

<P>This resolution also resolves <A HREF="
     cwg_active.html#1015">issue 1015</A>.</P>

<P><I>[Drafting note: It's not clear that we need the inserted text
above, because for the example in <A HREF="
     cwg_active.html#1015">issue 1015</A>, the type <TT>N::S</TT> is already represented in the
type of the function address, so there is no need to pull it from
template arguments. For cases where template parameters are not
represented in the function type, it's not clear that we want ADL to
reach further.]</I></P>

<BR><BR><HR><A NAME="1015"></A><H4>1015.
  
Template arguments and argument-dependent lookup
</H4><B>Section: </B>3.4.2&#160; [basic.lookup.argdep]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2009-12-24<BR>




<P>Currently, according to 3.4.2 [basic.lookup.argdep] paragraph 2,
explicit template arguments in a function argument do not contribute
to the associated namespaces in a function call, although they plausibly
should in an example like the following:</P>

<PRE>
    namespace N {
        struct S { };
        void f(void (*)(S));
    };

    template&lt;typename T&gt; void g(T);

    void h() {
        f(g&lt;N::S&gt;);    //<SPAN style="font-family:Times;font-style:italic"> Should find </SPAN>N::f
    }
</PRE>

<P>See also <A HREF="
     cwg_active.html#997">issue 997</A>.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#997">issue 997</A>.</P>

<BR><BR><HR><A NAME="1190"></A><H4>1190.
  
Operations on non-safely-derived pointers
</H4><B>Section: </B>3.7.4.3&#160; [basic.stc.dynamic.safety]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Hans Boehm
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-01<BR>




<P>3.7.4.3 [basic.stc.dynamic.safety] paragraph 4 only prohibits the
dereferencing and deallocation of non-safely-derived pointers. This is
insufficient.  Explicit deallocation of storage is described as
rendering invalid all pointers to that storage, with the result that
<I>all</I> operations on such a pointer value causes undefined
behavior (3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 4).  The same should
be true if the storage pointed to by a non-safely-derived pointer is
garbage collected.  In particular, the promise of objects having
distinct addresses (1.8 [intro.object] paragraph 6) should not
apply if one of those objects is designated by a non-safely-derived
pointer.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 3.7.4.3 [basic.stc.dynamic.safety] paragraph 4 as follows:</P>

<BLOCKQUOTE>

...Alternatively, an implementation may have <I>strict pointer
safety</I>, in which case, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">if</SPAN> a pointer value that is not a
safely-derived pointer value is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">dereferenced or deallocated,
and</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">an invalid pointer value, unless</SPAN> the referenced
complete object is of dynamic storage duration and has <SPAN style="text-decoration:line-through;background-color:#FFA0A0">not</SPAN>
previously been declared reachable (20.9.10 [util.smartptr])<SPAN style="text-decoration:line-through;background-color:#FFA0A0">, the behavior is undefined</SPAN>. [<I>Note:</I>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">this</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The effect of using an invalid pointer value
(including passing it to a deallocation function) is undefined, see
3.7.4.2 [basic.stc.dynamic.deallocation]. This</SPAN> is true even if the
unsafely-derived pointer value might compare equal to some
safely-derived pointer value. &#8212;<I>end note</I>] It is
implementation defined...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="597"></A><H4>597.
  
Conversions applied to out-of-lifetime non-POD lvalues
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>27 September 2006<BR>


<P>An lvalue referring to an out-of-lifetime non-POD class objects can
be used in limited ways, subject to the restrictions in
3.8 [basic.life] paragraph 6:</P>

<BLOCKQUOTE>

if the original object will be or was of a non-POD class type, the
program has undefined behavior if:

<UL>
<LI><P>the lvalue is used to access a non-static data member or call a
non-static member function of the object, or</P></LI>

<LI><P>the lvalue is implicitly converted (4.10 [conv.ptr])
to a reference to a base class type, or</P></LI>

<LI><P>the lvalue is used as the operand of a <TT>static_cast</TT>
(5.2.9 [expr.static.cast]) except when the conversion is
ultimately to <I>cv</I> <TT>char&amp;</TT> or <I>cv</I> <TT>unsigned
char&amp;</TT> ), or</P></LI>

<LI><P>the lvalue is used as the operand of a <TT>dynamic_cast</TT>
(5.2.7 [expr.dynamic.cast]) or as the operand
of <TT>typeid</TT>.</P></LI>
</UL>

</BLOCKQUOTE>

<P>There are at least a couple of questionable things in this list.
First, there is no &#8220;implicit conversion to a reference to a
base class,&#8221; as assumed by the second bullet.  Presumably
this is intended to say that the lvalue is bound to a reference to
a base class, and the cross-reference should be to
8.5.3 [dcl.init.ref], not to 4.10 [conv.ptr]
(which deals with pointer conversions).  However, even given that
adjustment, it is not clear why it is forbidden to bind a reference
to a non-virtual base class of an out-of-lifetime object, as that is
just an address offset calculation.  (Binding to a virtual base, of
course, would require access to the value of the object and thus
cannot be done outside the object's lifetime.)</P>

<P>The third bullet also appears questionable.  It's not clear why
<TT>static_cast</TT> is discussed at all here, as the only
permissible <TT>static_cast</TT> conversions involving reference types
and non-POD classes are to references to base or derived classes and
to the same type, modulo cv-qualification; if implicit
&#8220;conversion&#8221; to a base class reference is forbidden in the
second bullet, why would an explicit conversion be permitted in the
third?  Was this intended to refer to
<TT>reinterpret_cast</TT>?  Also, is there a reason to allow char
types but disallow array-of-char types (which are more likely to be
useful than a single char)?</P>

<P><B>Proposed resolution (March, 2008):</B></P>

<OL>
<LI><P>Change 3.8 [basic.life] paragraph 5 as follows:</P></LI>

<BLOCKQUOTE>

<P>...If the object will be or was of a non-trivial class type,
the program has undefined behavior if:</P>

<UL>
<LI><P>the pointer is used to access a non-static data member or
call a non-static member function of the object, or</P></LI>

<LI><P>the pointer is implicitly converted (<secion_ref ref="4.10">4.10 [conv.ptr]</secion_ref>) to a pointer to a <SPAN style="font-weight:bold;background-color:#A0FFA0">virtual</SPAN> base class
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">type</SPAN>, or</P></LI>

<LI><P>the pointer is used as the operand of a
<TT>static_cast</TT> (5.2.9 [expr.static.cast]) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">(</SPAN>except
when the conversion is to <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>void*</TT>, or to <TT>void*</TT>
and subsequently to <TT>char*</TT>, or <TT>unsigned char*</TT>).</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">pointer to <TT>void</TT>, or to pointer to <TT>void</TT> and
subsequently to pointer to <I>cv</I> <TT>char</TT> or pointer to
<I>cv</I> <TT>unsigned char</TT>, or</SPAN></P></LI>

<LI><P>the pointer is used as the operand of a <TT>dynamic_cast</TT>
(5.2.7 [expr.dynamic.cast])...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 3.8 [basic.life] paragraph 6 as follows:
</P></LI>

<BLOCKQUOTE>

<P>...if the original object will be or was of a non-trivial
class type, the program has undefined behavior if:</P>

<UL>
<LI><P>the lvalue is used to access a non-static data member or
call a non-static member function of the object, or</P></LI>

<LI><P>the lvalue is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">implicitly converted (4.10 [conv.ptr])</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">bound</SPAN> to a reference to a <SPAN style="font-weight:bold;background-color:#A0FFA0">virtual</SPAN>
base class <SPAN style="text-decoration:line-through;background-color:#FFA0A0">type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">(8.5.3 [dcl.init.ref])</SPAN>,
or</P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">the lvalue is used as the operand of a
<TT>static_cast</TT> (5.2.9 [expr.static.cast]) except when the
conversion is ultimately to <I>cv</I> <TT>char&amp;</TT> or
<I>cv</I> <TT>unsigned char&amp;</TT>, or</SPAN></P></LI>

<LI><P>the lvalue is used as the operand of a
<TT>dynamic_cast</TT> (5.2.7 [expr.dynamic.cast]) or as the
operand of <TT>typeid</TT>.</P></LI>

</UL>

</BLOCKQUOTE>

</OL>

<P><I>[Drafting notes: Paragraph 5 was changed to track the
changes to paragraph 6.  See also the resolution for <A HREF="
     cwg_defects.html#658">issue 658</A>.]</I></P>

<BR><BR><HR><A NAME="1219"></A><H4>1219.
  
Non-static data member initializers in constant expressions
</H4><B>Section: </B>3.9&#160; [basic.types]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jens Maurer
 &#160;&#160;&#160;

 <B>Date: </B>2010-11-13<BR>


<P>The current treatment of constexpr constructors and constant expressions
does not deal with the initializers for non-static data members, which
should also be required to be constant expressions.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Change 3.6.2 [basic.start.init] paragraph 2 as follows:</P></LI>

<UL><LI><P>if an object with static or thread storage duration is
initialized by a constructor call, if the constructor is a
<TT>constexpr</TT> constructor, if all constructor arguments are
constant expressions (including conversions), and if, after function
invocation substitution (7.1.5 [dcl.constexpr]), every constructor call
and full-expression in the <I>mem-initializer</I>s <SPAN style="font-weight:bold;background-color:#A0FFA0">and in the
<I>brace-or-equal-initializer</I>s for non-static data members</SPAN>
is a constant expression </P></LI></UL>

<LI><P>Change 3.9 [basic.types] paragraph 10 as follows (wording
assumes the proposed resolution of <A HREF="
     cwg_active.html#981">issue 981</A>)</P></LI>

<BLOCKQUOTE>

<P>A type is a <I>literal type</I> if it is:</P>

<UL><LI><P>a scalar type; or</P></LI>

<LI><P>a class type (clause 9 [class]) that
<SPAN style="font-weight:bold;background-color:#A0FFA0">has all of the following properties:</SPAN></P></LI>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">it</SPAN> has a trivial destructor,</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">every constructor call and full-expression in the
<I>brace-or-equal-initializer</I>s for non-static data members (if
any) is a constant expression (5.19 [expr.const]),</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">it</SPAN> is an aggregate type (8.5.1 [dcl.init.aggr]) or
has at least one <TT>constexpr</TT> constructor or constructor
template that is not a copy or move constructor, and</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">it</SPAN> has all non-static data members and base
classes of literal types; or</P></LI>

</UL>

<LI><P>an array of literal type.</P></LI>

</UL>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1055"></A><H4>1055.
  
Permissible uses of <TT>void</TT>
</H4><B>Section: </B>3.9.1&#160; [basic.fundamental]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-17<BR>


<P>According to 3.9.1 [basic.fundamental] paragraph 9,</P>

<BLOCKQUOTE>

Any expression can be explicitly converted to type <I>cv</I>
<TT>void</TT> (5.4 [expr.cast]).  An expression of type
<TT>void</TT> shall be used only as an expression statement
(6.2 [stmt.expr]), as an operand of a comma expression
(5.18 [expr.comma]), as a second or third operand of
<TT>?:</TT> (5.16 [expr.cond]), as the operand of
<TT>typeid</TT>, or as the expression in a return statement
(6.6.3 [stmt.return]) for a function with the return type
<TT>void</TT>.

</BLOCKQUOTE>

<P>First, this is self-contradictory: if &#8220;any expression&#8221;
can be converted to <TT>void</TT>, why is such a conversion not listed
among the acceptable uses of an expression of type <TT>void</TT>?</P>

<P>Second, presumably an expression of type <TT>void</TT> can be used
as an operand of <TT>decltype</TT>, but this use is not listed.</P>

<P>Finally, there are several places in the Standard that speak of
expressions having a cv-qualified <TT>void</TT> type
(5.16 [expr.cond] paragraph 2, 6.6.3 [stmt.return]
paragraph 3).  However, an expression of type <TT>void</TT> is a
non-class prvalue, and there are no cv-qualified non-class prvalues
(3.10 [basic.lval] paragraph 4).</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<OL><LI><P>Change 3.9.1 [basic.fundamental] paragraph 9 as follows:</P></LI>

<BLOCKQUOTE>

...Any expression can be explicitly converted to type <I>cv</I>
<TT>void</TT> (5.4 [expr.cast]). An expression of type
<TT>void</TT> shall be used only as an expression statement
(6.2 [stmt.expr]), as an operand of a comma expression
(5.18 [expr.comma]), as a second or third operand of
<TT>?:</TT> (5.16 [expr.cond]), as the operand of
<TT>typeid</TT> <SPAN style="font-weight:bold;background-color:#A0FFA0">or <TT>decltype</TT></SPAN>, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or</SPAN> as the
expression in a return statement (6.6.3 [stmt.return]) for a
function with the return type <TT>void</TT><SPAN style="font-weight:bold;background-color:#A0FFA0">, or as the operand
of an explicit conversion to type <I>cv</I> <TT>void</TT></SPAN>.

</BLOCKQUOTE>

<LI><P>Change 5.16 [expr.cond] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

If either the second or the third operand has type <SPAN style="text-decoration:line-through;background-color:#FFA0A0">(possibly
cv-qualified)</SPAN> <TT>void</TT>, then...

</BLOCKQUOTE>

<LI><P>Change 6.6.3 [stmt.return] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

A return statement with an expression of type
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8220;<I>cv</I></SPAN> <TT>void</TT><SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8221;</SPAN> can be
used only in functions with a return type of <I>cv</I> <TT>void</TT>;
the expression is evaluated just before the function returns to its
caller.

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1180"></A><H4>1180.
  
Over-aligned class types
</H4><B>Section: </B>3.11&#160; [basic.align]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Clark Nelson
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-25<BR>


<P>Now that alignment can be applied directly to class types, the
current wording of the note at the end of 3.11 [basic.align]
paragraph 3 is no longer correct:</P>

<BLOCKQUOTE>

[<I>Note:</I> every over-aligned type is or contains a class type with
a non-static data member to which an extended alignment has been
applied. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P><U>Proposed resolution (November, 2010):</U></P>

<P>Change 3.11 [basic.align] paragraph 3 as follows:</P>

<BLOCKQUOTE>

[<I>Note:</I> every over-aligned type is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or contains</SPAN> a
class type <SPAN style="text-decoration:line-through;background-color:#FFA0A0">with a non-static data member to which an
extended alignment has been applied</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">to which extended
alignment applies (possibly through a non-static data
member)</SPAN>. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<BR><BR><HR><A NAME="240"></A><H4>240.
  
Uninitialized values and undefined behavior
</H4><B>Section: </B>4.1&#160; [conv.lval]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>8 Aug 2000<BR>




<P>4.1 [conv.lval] paragraph 1 says,</P>

<BLOCKQUOTE>

If the object to which the lvalue refers is not an object of type
<TT>T</TT> and is not an object of a type derived from <TT>T</TT>, or
if the object is uninitialized, a program that necessitates this
conversion has undefined behavior.

</BLOCKQUOTE>

<P>I think there are at least three related issues around this
specification:</P>

<OL>

<LI><P>Presumably assigning a valid value to an uninitialized
object allows it to participate in the lvalue-to-rvalue
conversion without undefined behavior (otherwise the number of
programs with defined behavior would be vanishingly small :-).
However, the wording here just says "uninitialized" and doesn't
mention assignment.</P></LI>

<LI><P>There's no exception made for <TT>unsigned char</TT> types.
The wording in 3.9.1 [basic.fundamental] was carefully crafted to
allow use of <TT>unsigned char</TT> to access uninitialized data so
that <TT>memcpy</TT> and such could be written in C++ without
undefined behavior, but this statement undermines that
intent.</P></LI>

<LI><P>It's possible to get an uninitialized rvalue without invoking
the lvalue-to-rvalue conversion.  For instance:</P>

<PRE>
        struct A {
            int i;
            A() { } // no init of A::i
        };
        int j = A().i;  // uninitialized rvalue
</PRE>

<P>There doesn't appear to be anything in the current IS wording
that says that this is undefined behavior.  My guess is that we
thought that in placing the restriction on use of uninitialized
objects in the lvalue-to-rvalue conversion we were catching all
possible cases, but we missed this one.</P></LI>

</OL>

<P>In light of the above, I think the discussion of uninitialized
objects ought to be removed from 4.1 [conv.lval] paragraph
1.  Instead, something like the following ought to be added to
3.9 [basic.types] paragraph 4 (which is where the concept of
"value" is introduced):</P>

<BLOCKQUOTE>
Any use of an indeterminate value (5.3.4 [expr.new],
8.5 [dcl.init], 12.6.2 [class.base.init]) of any type
other than <TT>char</TT> or <TT>unsigned char</TT> results in
undefined behavior.
</BLOCKQUOTE>

<P><U>John Max Skaller</U>:</P>

<P><TT>A().i</TT> had better be an lvalue; the rules are wrong.
Accessing a member of a structure requires it be converted to
an lvalue, the above calculation is 'as if':</P>

<PRE>
    struct A {
        int i;
        A *get() { return this; }
    };
    int j = (*A().get()).i;
</PRE>

<P>and you can see the bracketed expression is an lvalue. </P>

<P>A consequence is:</P>

<PRE>
    int &amp;j= A().i; // OK, even if the temporary evaporates
</PRE>

<P><TT>j</TT> now refers to a 'destroyed' value. Any use of <TT>j</TT>
is an error.  But the binding at the time is valid.</P>

<P><B>Proposed Resolution (November, 2006):</B></P>

<OL><LI><P>Add the indicated words to 3.9 [basic.types] paragraph 4:</P>

<BLOCKQUOTE>

... For trivial types, the value representation is a set of bits in the
object representation that determines a value, which is one discrete
element of an implementation-defined set of values. <SPAN style="font-weight:bold;background-color:#A0FFA0">Any use of an
indeterminate value (5.3.4 [expr.new], 8.5 [dcl.init],
12.6.2 [class.base.init]) of a type other than <TT>unsigned char</TT>
results in undefined behavior.</SPAN>

</BLOCKQUOTE>
</LI>

<LI><P>Change 4.1 [conv.lval] paragraph 1 as follows:</P>

<BLOCKQUOTE>

If the object to which the lvalue refers is not an object of
type <TT>T</TT> and is not an object of a type derived
from <TT>T</TT>, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or if the object is uninitialized,</SPAN> a program
that necessitates this conversion has undefined behavior.

</BLOCKQUOTE>
</LI>

</OL>

<P><B>Additional note (May, 2008):</B></P>

<P>The C committee is dealing with a similar issue in their <A HREF="http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_338.htm">DR336</A>.
According to <A HREF="http://wiki.dinkumware.com/twiki/pub/WG14/DefectReports/dr338_response.txt">
this analysis</A>, they plan to take almost the opposite approach
to the one described above by augmenting the description of their
version of the lvalue-to-rvalue conversion.  The CWG did not
consider that access to an unsigned char might still trap if it
is allocated in a register and needs to reevaluate the proposed
resolution in that light.  See also <A HREF="
     cwg_active.html#129">issue 129</A>.</P>

<BR><BR><HR><A NAME="342"></A><H4>342.
  
Terminology: "indirection" versus "dereference"
</H4><B>Section: </B>5.3&#160; [expr.unary]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>7 Oct 2001<BR>




<P>Split off from <A HREF="
     cwg_closed.html#315">issue 315</A>.</P>

<P>Incidentally, another thing that ought to be cleaned up is the inconsistent
use of "indirection" and "dereference".  We should pick one.</P>

<P><B>Proposed resolution (December, 2006):</B></P>

<OL>

<LI><P>Change 5.3.1 [expr.unary.op] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

The unary <TT>*</TT>
operator <SPAN style="text-decoration:line-through;background-color:#FFA0A0">performs <I>indirection</I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">dereferences a pointer
value</SPAN>: the expression to which it is applied shall be a pointer...

</BLOCKQUOTE>

<LI><P>Change 8.3.4 [dcl.array] paragraph 8 as follows:</P></LI>

<BLOCKQUOTE>

The <SPAN style="text-decoration:line-through;background-color:#FFA0A0">results are added and indirection applied</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">values are
added and the result is dereferenced</SPAN> to yield an array (of five
integers), which in turn is converted to a pointer to the first of the
integers.

</BLOCKQUOTE>

<LI><P>Change 8.3.5 [dcl.fct] paragraph 9 as follows:</P></LI>

<BLOCKQUOTE>

The binding of <TT>*fpi(int)</TT> is <TT>*(fpi(int))</TT>, so the
declaration suggests, and the same construction in an expression
requires, the calling of a function <TT>fpi</TT>, and then <SPAN style="text-decoration:line-through;background-color:#FFA0A0">using
indirection through</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">dereferencing</SPAN> the (pointer) result
to yield an integer. In the declarator <TT>(*pif)(const char*, const
char*)</TT>, the extra parentheses are necessary to indicate that
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">indirection through</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">dereferencing</SPAN> a pointer to a
function yields a function, which is then called.

</BLOCKQUOTE>

<LI><P>Change the index for <TT>*</TT> and &#8220;dereferencing&#8221;
no longer to refer to &#8220;indirection.&#8221;</P></LI>

</OL>

<P>[<I>Drafting note:</I> 26.6.9 [template.indirect.array]
requires no change.  Many more places in the current wording use
&#8220;dereferencing&#8221; than &#8220;indirection.&#8221;]</P>

<BR><BR><HR><A NAME="292"></A><H4>292.
  
Deallocation on exception in <TT>new</TT> before arguments evaluated
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Andrei Iltchenko
 &#160;&#160;&#160;

 <B>Date: </B>26 Jun 2001<BR>


<P>According to the C++ Standard section 5.3.4 [expr.new]
paragraph 21 it is unspecified whether the allocation function is called before
evaluating the constructor arguments or after evaluating the
constructor arguments but before entering the constructor.</P>

<P>On top of that paragraph 17 of the same section insists that</P>
<BLOCKQUOTE>
If any
part of the object initialization described above [Footnote: This may
include evaluating a new-initializer and/or calling a constructor.]
terminates by throwing an exception and a suitable deallocation
function is found, the deallocation function is called to free the
memory in which the object was being constructed... If no unambiguous
matching deallocation function can be found, propagating the exception
does not cause the object's memory to be freed...
</BLOCKQUOTE>

<P>Now suppose we have:</P>
<OL>
<LI>
An implementation that always evaluates the constructor arguments
first (for a new-expression that creates an object of a class type and
has a new-initializer) and calls the allocation function afterwards.
</LI>
<LI>
A class like this:
<PRE>
    struct  copy_throw  {
       copy_throw(const copy_throw&amp;)
       {   throw  std::logic_error("Cannot copy!");   }
       copy_throw(long, copy_throw)
       {   }
       copy_throw()
       {   }
    };
</PRE>
</LI>
<LI>
And a piece of code that looks like the one below:
<PRE>
    int  main()
    try  {
       copy_throw   an_object,     /* undefined behaviour */
          * a_pointer = ::new copy_throw(0, an_object);
       return  0;
    }
    catch(const std::logic_error&amp;)
    {   }
</PRE>
</LI>
</OL>
<P>Here the new-expression '<TT>::new copy_throw(0, an_object)</TT>' throws an
exception when evaluating the constructor's arguments and before the
allocation function is called. However, 5.3.4 [expr.new]
paragraph 17
prescribes that in such a case the implementation shall call the
deallocation function to free the memory in which the object was being
constructed, given that a matching deallocation function can be found.</P>

<P>So a call to the Standard library deallocation function '<TT>::operator
delete(void*)</TT>' shall be issued, but what argument is an implementation
supposed to supply to the deallocation function? As per
5.3.4 [expr.new] paragraph 17 - the argument is the address
of the memory in
which the object was being constructed. Given that no memory has yet
been allocated for the object, this will qualify as using an invalid
pointer value, which is undefined behaviour by virtue of
3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 4.</P>

<P><B>Suggested resolution:</B></P>

<P>Change the first sentence of 5.3.4 [expr.new] paragraph 17
to read:</P>
<BLOCKQUOTE>
If the memory for the object being created has already been
successfully allocated and any part of the object initialization
described above...
</BLOCKQUOTE>

<P><B>Proposed resolution (March, 2008):</B></P>

<P>Change 5.3.4 [expr.new] paragraph 18 as follows:</P>

<BLOCKQUOTE>

If any part of the object initialization described above
[<I>Footnote:</I> ...]  terminates by throwing an exception<SPAN style="font-weight:bold;background-color:#A0FFA0">,
storage has been obtained for the object,</SPAN> and a suitable
deallocation function can be found, the deallocation function is
called...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="236"></A><H4>236.
  
Explicit temporaries and integral constant expressions
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>19 Jul 2000<BR>




<P>Does an explicit temporary of an integral type qualify as an
integral constant expression?  For instance,</P>

<PRE>
    void* p = int();    // well-formed?
</PRE>

<P>It would appear to be, since <TT>int()</TT> is an explicit type
conversion according to 5.2.3 [expr.type.conv] (at least, it's
described in a section entitled "Explicit type conversion") and type
conversions to integral types are permitted in integral constant
expressions (5.19 [expr.const]).  However, this reasoning is
somewhat tenuous, and some at least have argued otherwise.</P>

<P><B>Note (March, 2008):</B></P>

<P>This issue should be closed as NAD as a result of the rewrite of
5.19 [expr.const] in conjunction with the constexpr proposal.</P>

<BR><BR><HR><A NAME="1098"></A><H4>1098.
  
Pointer conversions in constant expressions
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-01<BR>




<P>One of the bullets in 5.19 [expr.const] paragraph 2 says,</P>

<UL><LI><P>a type conversion from a pointer or
pointer-to-member type to a literal type</P></LI></UL>

<P>This appears to prohibit conversion from one pointer type to
another; for example,</P>

<PRE>
    int x;
    constexpr void* p = &amp;x;   //<SPAN style="font-family:Times;font-style:italic"> ill-formed</SPAN>
</PRE>

<P>This seems excessive and probably unintentional.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 5.19 [expr.const] paragraph 2 as follows:</P>

<UL><LI><P>a type conversion from a pointer <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or
pointer-to-member</SPAN> type to <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a literal</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">an
integral</SPAN> type <SPAN style="text-decoration:line-through;background-color:#FFA0A0">[<I>Note:</I> a user-defined conversion
invokes a function &#8212;<I>end note</I>]</SPAN>;</P></LI></UL>

<P><I>[Note: the proposed resolution of <A HREF="
     cwg_active.html#1188">issue 1188</A> edits this bullet in an incompatible fashion.]</I></P>

<BR><BR><HR><A NAME="1188"></A><H4>1188.
  
Type punning in constant expressions
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-31<BR>




<P>The status of the following example is not clear:</P>

<PRE>
    union U { float f; unsigned long u; };

    constexpr U u1 = { 1.0 };
    constexpr unsigned long u2 = u1.u;
</PRE>

<P>This might be ill-formed because the aliasing causes undefined
behavior, which should make the expression not a constant expression.
However, a similar example using a permitted aliasing would
presumably be acceptable:</P>

<PRE>
    union U {
        unsigned char c[sizeof(double)];
        double d;
    };
    constexpr U c1u = { 0x12, 0x34 /* etc. */ };
    constexpr double c1 = c1u.d;
</PRE>

<P>One suggestion was that unions should not be considered literal
types, but some in the ensuing discussion deemed that excessive.  That
also would not address similar examples using
<TT>reinterpret_cast</TT>, which is currently also permitted in
constant expressions.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 5.19 [expr.const] paragraph 2 as follows:</P>

<UL><LI><P>an lvalue-to-rvalue conversion...</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">an lvalue-to-rvalue conversion (4.1 [conv.lval])
that is applied to a glvalue that refers to a non-active member of a
union or a subobject thereof;</SPAN></P></LI>

<LI><P>...</P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a type conversion from a pointer or pointer-to-member type to a
literal type [<I>Note:</I> a user-defined conversion invokes a function
&#8212;<I>end note</I>]</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a <TT>reinterpret_cast</TT>
(5.2.10 [expr.reinterpret.cast])</SPAN>;</P></LI>

</UL>

<P><I>[Note: the proposed resolution of <A HREF="
     cwg_active.html#1098">issue 1098</A>
edits this bullet in an incompatible fashion.]</I></P>

<BR><BR><HR><A NAME="1204"></A><H4>1204.
  
Specifiers in a <I>for-range-declaration</I>
</H4><B>Section: </B>6.5&#160; [stmt.iter]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-01<BR>




<P>It seems unfortunate that the beginning of a C-style <TT>for</TT>
loop can look like</P>

<UL><TT>for (</TT> <I>attribute-specifier<SUB>opt</SUB> decl-specifier-seq<SUB>opt</SUB> declarator</I></UL>

<P>whereas the beginning of a range-based <TT>for</TT> loop looks like</P>

<UL><TT>for (</TT> <I>attribute-specifier<SUB>opt</SUB> type-specifier-seq<SUB>opt</SUB> declarator</I></UL>

<P>So that we don't know what constraints we are trying to apply to
the specifiers until we see, or don't see, a <TT>:</TT>.  The
inconsistency between <I>decl-specifier-seq</I> and
<I>type-specifier-seq</I> seems gratuitous and inconvenient.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Change the grammar 6.5 [stmt.iter] paragraph 1 as
follows:</P></LI>

<UL><I>for-range-declaration:</I>
<UL><I>attribute-specifier<SUB>opt</SUB> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">type-specifier-seq</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">decl-specifier-seq</SPAN> declarator</I></UL>

</UL>

<LI><P>Add the following as a new paragraph at the end of 6.5.4 [stmt.ranged]:</P></LI>

<BLOCKQUOTE>

<SPAN style="font-weight:bold;background-color:#A0FFA0">The the <I>decl-specifier-seq</I> of a <I>for-range-declaration</I>,
each <I>decl-specifier</I> shall be either a <I>type-specifier</I> or
<TT>constexpr</TT>.</SPAN>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1018"></A><H4>1018.
  
Ambiguity between <I>simple-declaration</I> and <I>attribute-declaration</I>
</H4><B>Section: </B>7&#160; [dcl.dcl]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2010-01-04<BR>


<P>The grammar for declarations includes the following two nonterminals:</P>

<UL><I>simple-declaration:</I>
<UL><I>attribute-specifier<SUB>opt</SUB> decl-specifier-seq<SUB>opt</SUB> init-declarator-list<SUB>opt</SUB></I> <TT>;</TT></UL>
</UL>

<UL><I>attribute-declaration:</I>
<UL><I>attribute-specifier</I> <TT>;</TT></UL>
</UL>

<P>An <I>attribute-specifier</I> followed by a semicolon could thus
be parsed as either an <I>attribute-declaration</I> or as a
<I>simple-declaration</I> that omits the optional
<I>decl-specifier-seq</I> and <I>init-declarator-list</I>, and the
current wording does not disambiguate the two.  (There doesn't seem
to be a compelling need for <I>attribute-declaration</I> as a
separate nonterminal, given that <I>simple-declaration</I> can
accommodate that form.)</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<P>Change 7 [dcl.dcl] paragraph 1 as follows:</P>

<UL><I>simple-declaration:</I>
<UL><I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">attribute-specifier-seq<SUB>opt</SUB></SPAN> decl-specifier-seq<SUB>opt</SUB> init-declarator-list<SUB>opt</SUB></I> <TT>;</TT><BR>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>attribute-specifier-seq decl-specifier-seq init-declarator-list</I> <TT>;</TT></SPAN>
</UL>

</UL>

<BLOCKQUOTE>

...The <SPAN style="text-decoration:line-through;background-color:#FFA0A0">optional</SPAN> <I>attribute-specifier-seq</I> in a
<I>simple-declaration</I> appertains to each of the entities declared
by the <I>declarator</I>s<SPAN style="text-decoration:line-through;background-color:#FFA0A0">; it shall not appear if the optional</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">of the</SPAN> <I>init-declarator-list</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">is omitted</SPAN>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1042"></A><H4>1042.
  
Attributes in <I>alias-declaration</I>s
</H4><B>Section: </B>7&#160; [dcl.dcl]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-04<BR>


<P>The grammar for an <I>alias-declaration</I> does not have a
place for an <I>attribute-specifier</I>, although a
<TT>typedef</TT> declaration does.  Since an
<I>alias-declaration</I> is essentially a different syntactic
form of a <TT>typedef</TT> declaration (7.1.3 [dcl.typedef] paragraph 2), this could be surprising.</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<OL><LI><P>Change the grammar in 7 [dcl.dcl] paragraph 1 as
follows:</P></LI>

<UL><I>alias-declaration:</I>
<UL><TT>using</TT> <I>identifier <SPAN style="font-weight:bold;background-color:#A0FFA0">attribute-specifier-seq<SUB>opt</SUB></SPAN></I> <TT>=</TT> <I>type-id</I> <TT>;</TT></UL>
</UL>

<LI><P>Change 7.1.3 [dcl.typedef] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

A <I>typedef-name</I> can also be introduced by an
<I>alias-declaration</I>. The <I>identifier</I> following the
<TT>using</TT> keyword becomes a <I>typedef-name</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">and the
optional <I>attribute-specifier-seq</I> following the <I>identifier</I>
appertains to that <I>typedef-name</I></SPAN>.  It has the same
semantics...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1186"></A><H4>1186.
  
Non-dependent <TT>constexpr</TT> violations in function templates
</H4><B>Section: </B>7.1.5&#160; [dcl.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-30<BR>


<P>7.1.5 [dcl.constexpr] paragraph 5 says,</P>

<BLOCKQUOTE>

If the instantiated template specialization of a constexpr function
template or member function of a class template would fail to satisfy
the requirements for a constexpr function or constexpr constructor,
that specialization is not a constexpr function or constexpr
constructor.  [<I>Note:</I> if the function is a member function it
will still be <TT>const</TT> as described below.  Implementations are
encouraged to issue a warning if a function is rendered not constexpr
by a non-dependent construct. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>A non-dependent error in a function template renders it ill-formed
with no diagnostic required (14.6 [temp.res] paragraph 8).
A similar approach is being taken in the proposed resolution of
<A HREF="
     cwg_defects.html#1125">issue 1125</A> with respect to constexpr
functions.  It would be more consistent to treat constexpr function
templates in the same way, along the lines of</P>

<BLOCKQUOTE>

If no specialization of the template would be <TT>constexpr</TT>,
the program is ill-formed, no diagnostic required.

</BLOCKQUOTE>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 7.1.5 [dcl.constexpr] paragraph 6 as follows:</P>

<BLOCKQUOTE>

If the instantiated template specialization of a constexpr function
template or member function of a class template would fail to satisfy
the requirements for a <TT>constexpr</TT> function or
<TT>constexpr</TT> constructor, that specialization is not a
<TT>constexpr</TT> function or <TT>constexpr</TT> constructor.
[<I>Note:</I> if the function is a member function it will still be
<TT>const</TT> as described below.  <SPAN style="text-decoration:line-through;background-color:#FFA0A0">Implementations are
encouraged to issue a warning if a function is rendered not
<TT>constexpr</TT> by a non-dependent construct.</SPAN> &#8212;<I>end
note</I>] <SPAN style="font-weight:bold;background-color:#A0FFA0">If no specialization of the template would yield a
<TT>constexpr</TT> function or <TT>constexpr</TT> constructor, the
program is ill-formed; no diagnostic required.</SPAN>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1194"></A><H4>1194.
  
Constexpr references
</H4><B>Section: </B>7.1.5&#160; [dcl.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-04<BR>




<P>7.1.5 [dcl.constexpr] restricts the <TT>constexpr</TT>
specifier to object and function declarations.  Especially given
the support for reference types in constexpr functions, and
considering that constexpr pointer declarations are permitted,
there does not seem to be a good reason for excluding constexpr
references.</P>

<P>(See also <A HREF="
     cwg_active.html#1195">issue 1195</A>.)</P>

<P><B>Proposed resolution (November. 2010):</B></P>

<OL><LI><P>Change 7.1.5 [dcl.constexpr] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

The constexpr specifier shall be applied only to the definition of
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">an object</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a variable</SPAN>, the declaration of a
function...

</BLOCKQUOTE>

<LI><P>Change 7.1.5 [dcl.constexpr] paragraph 8 as follows:</P></LI>

<BLOCKQUOTE>

A <TT>constexpr</TT> specifier used in an object declaration declares
the object as <TT>const</TT>.  Such an object shall be initialized. If
it is initialized by a constructor call, the constructor shall be a
constexpr constructor and every argument to the constructor shall be a
constant expression.  Otherwise, <SPAN style="font-weight:bold;background-color:#A0FFA0">or if a <TT>constexpr</TT>
specifier is used in a reference declaration,</SPAN> every
full-expression that appears in its initializer shall be a constant
expression...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1195"></A><H4>1195.
  
References to non-literal types in constexpr functions
</H4><B>Section: </B>7.1.5&#160; [dcl.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-05<BR>




<P>7.1.5 [dcl.constexpr] paragraph 3 is overly restrictive
in requiring that reference parameter and return types of a constexpr
function or constructor must refer to a literal type.
5.19 [expr.const] paragraph 2 already prevents any
problematic uses of lvalues of non-literal types, and it permits
use of pointers to non-literal types as address constants.  The
same should be permitted via reference parameters and return types
of constexpr functions.</P>

<P>(See also <A HREF="
     cwg_active.html#1194">issue 1194</A>.)</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Change 3.9 [basic.types] paragraph 10 as follows:</P></LI>

<BLOCKQUOTE>

<P>A type is a <I>literal type</I> if it is:</P>

<UL><LI><P>a scalar type; or</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">a reference type; or</SPAN></P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 7.1.5 [dcl.constexpr] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

<P>The definition of a constexpr function shall satisfy the following
constraints:</P>

<UL><LI><P>it shall not be virtual (10.3 [class.virtual])</P></LI>

<LI><P>its return type shall be a literal type <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or a reference to
literal type</SPAN></P></LI>

<LI><P>each of its parameter types shall be a literal type <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or a
reference to literal type</SPAN></P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 7.1.5 [dcl.constexpr] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

<P>The definition of a constexpr constructor shall satisfy the
following constraints:</P>

<UL><LI><P>each of its parameter types shall be a literal type <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or a
reference to literal type</SPAN>;</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1225"></A><H4>1225.
  
<TT>constexpr</TT> constructors and virtual bases
</H4><B>Section: </B>7.1.5&#160; [dcl.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-26<BR>




<P>A class with a virtual base should not be allowed to have a
<TT>constexpr</TT> constructor.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Add the following bullet to the list in 7.1.5 [dcl.constexpr]
paragraph 4:</P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">the class shall not have virtual base
classes;</SPAN></P></LI></UL>

<BR><BR><HR><A NAME="539"></A><H4>539.
  
Constraints on <I>type-specifier-seq</I>
</H4><B>Section: </B>7.1.6&#160; [dcl.type]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>5 October 2005<BR>


<P>The constraints on <I>type-specifier</I>s given in
7.1.6 [dcl.type] paragraphs 2 and 3 (at most one
<I>type-specifier</I> except as specified, at least one
<I>type-specifier</I>, no redundant cv-qualifiers) are couched in
terms of <I>decl-specifier-seq</I>s and <I>declaration</I>s.  However,
they should also apply to constructs that are not syntactically
<I>declaration</I>s and that are defined to use
<I>type-specifier-seq</I>s, including 5.3.4 [expr.new],
6.6 [stmt.jump], 8.1 [dcl.name], and
12.3.2 [class.conv.fct].</P>

<P><B>Proposed resolution (March, 2008):</B></P>

<P>Change 7.1.6 [dcl.type] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">At</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">In a complete <I>type-specifier-seq</I> or in a
complete <I>decl-specifier-seq</I> of a declaration, at</SPAN> least
one <I>type-specifier</I> that is not a
<I>cv-qualifier</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">is required in a declaration</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">shall
appear</SPAN> unless <SPAN style="text-decoration:line-through;background-color:#FFA0A0">it</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the declaration</SPAN> declares a
constructor, destructor or conversion function.

</BLOCKQUOTE>

<P><I>(Note: paper N2546, voted into the Working Draft in February,
2008, addresses part of this issue.)</I></P>

<BR><BR><HR><A NAME="1212"></A><H4>1212.
  
Non-function-call xvalues and <TT>decltype</TT>
</H4><B>Section: </B>7.1.6.2&#160; [dcl.type.simple]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-21<BR>




<P>Given</P>

<PRE>
    int&amp;&amp; f();
    int i;
</PRE>

<P>it is surprising that <TT>decltype(f())</TT> and
<TT>decltype(static_cast&lt;int&amp;&amp;&gt;(i))</TT> are not the
same type.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 7.1.6.2 [dcl.type.simple] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>The type denoted by <TT>decltype(e)</TT> is defined as follows:</P>

<UL><LI><P>if <TT>e</TT> is an unparenthesized <I>id-expression</I> or
a class member access (5.2.5 [expr.ref]),
<TT>decltype(e)</TT> is the type of the entity named by <TT>e</TT>.
If there is no such entity, or if <TT>e</TT> names a set of overloaded
functions, the program is ill-formed;</P></LI>

<LI><P>otherwise, if <TT>e</TT> is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a function call (5.2.2 [expr.call]) or an invocation of an overloaded operator (parentheses
around <TT>e</TT> are ignored), <TT>decltype(e)</TT> is the return
type of the statically chosen function</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">an xvalue,
<TT>decltype(e)</TT> is <TT>T&amp;&amp;</TT>, where <TT>T</TT> is the
type of <TT>e</TT></SPAN>;</P></LI>

<LI><P>otherwise, if <TT>e</TT> is an lvalue, <TT>decltype(e)</TT> is
<TT>T&amp;</TT>, where <TT>T</TT> is the type of <TT>e</TT>;</P></LI>

<LI><P>otherwise, <TT>decltype(e)</TT> is the type of
<TT>e</TT>.</P></LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1185"></A><H4>1185.
  
Misleading description of language linkage and member function types
</H4><B>Section: </B>7.5&#160; [dcl.link]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-29<BR>


<P>The current wording of 7.5 [dcl.link] paragraph 4 is:</P>

<BLOCKQUOTE>

...A C language linkage is ignored for the names of class members and
the member function type of class member functions...

</BLOCKQUOTE>

<P>This has two problems.  First, it sounds as if a class member
function has a &#8220;member function type,&#8221; while in fact
the type of a class member function is an ordinary function type
(cf 9.2 [class.mem] paragraph 11).</P>

<P>Second, even if that problem is fixed, it is not accurate to
say that a C language linkage is &#8220;ignored&#8221; for the
type of a member function.  It does not affect the language
linkage of the type of the member function, but it does affect
the language linkage of any function declarators appearing in
the parameter and return types of the function and thus the
type of the function.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 7.5 [dcl.link] paragraph 4 as follows:</P>

<BLOCKQUOTE>

...A C language linkage is ignored <SPAN style="text-decoration:line-through;background-color:#FFA0A0">for</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">in determining
the language linkage of</SPAN> the names of class members and the
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">member</SPAN> function type of class member functions...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1031"></A><H4>1031.
  
Optional elements in attributes
</H4><B>Section: </B>7.6.1&#160; [dcl.attr.grammar]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2010-02-10<BR>




<P>An <I>attribute-argument-clause</I> should be allowed to consist
solely of <TT>()</TT>, i.e., with no <I>balanced-token-seq</I>.
Furthermore, the grammar for <I>balanced-token</I> should make
the <I>balanced-token-seq</I> optional.  Both of these goals could
be accomplished by making the <I>balanced-token</I> optional in the
first production of the rule for <I>balanced-token-seq</I>.</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<P>Change the grammar of 7.6.1 [dcl.attr.grammar] paragraph 1 as
follows:</P>

<UL><I>balanced-token-seq:</I>
<UL><I>balanced-token<SPAN style="font-weight:bold;background-color:#A0FFA0"><SUB>opt</SUB></SPAN></I><BR>
<I>balanced-token-seq balanced-token</I>
</UL>
</UL>

<BR><BR><HR><A NAME="1033"></A><H4>1033.
  
Restrictions on alignment attributes
</H4><B>Section: </B>7.6.2&#160; [dcl.align]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2010-02-17<BR>




<P>According to 7.6.2 [dcl.align] paragraph 5,</P>

<BLOCKQUOTE>

The combined effect of all alignment attributes in a declaration
shall not specify an alignment that is less strict than the
alignment that would otherwise be required for the entity being
declared.

</BLOCKQUOTE>

<P>&#8220;...would otherwise be required&#8221; could be read as
referring to the alignment set by another declaration of the
entity.  However, it was intended to prevent specifying an
alignment smaller than the natural alignment the entity would
have in the absence of an <TT>align</TT> attribute.  The wording
should be changed to make that clearer.</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<P>Change 7.6.2 [dcl.align] paragraph 5 as follows:</P>

<BLOCKQUOTE>

The combined effect of all <I>alignment-specifier</I>s in a
declaration shall not specify an alignment that is less strict than
the alignment that would <SPAN style="text-decoration:line-through;background-color:#FFA0A0">otherwise</SPAN> be required for the
entity being declared <SPAN style="font-weight:bold;background-color:#A0FFA0">if all <I>alignment-specifier</I>s were
ignored (including those in other declarations)</SPAN>.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="482"></A><H4>482.
  
Qualified declarators in redeclarations
</H4><B>Section: </B>8.3&#160; [dcl.meaning]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>03 Nov 2004<BR>


<P>According to 8.3 [dcl.meaning] paragraph 1,</P>

<BLOCKQUOTE>

A <I>declarator-id</I> shall not be qualified except for the
definition of a member function (9.3 [class.mfct]) or
static data member (9.4 [class.static]) outside of its
class, the definition or explicit instantiation of a function or
variable member of a namespace outside of its namespace, or the
definition of a previously declared explicit specialization
outside of its namespace, or the declaration of a friend function
that is a member of another class or namespace (11.4 [class.friend]). When the <I>declarator-id</I> is qualified, the
declaration shall refer to a previously declared member of the
class or namespace to which the qualifier refers...

</BLOCKQUOTE>

<P>This restriction prohibits examples like the following:</P>

<PRE>
    void f();
    void ::f();        // error: qualified declarator

    namespace N {
      void f();
      void N::f() { }  // error: qualified declarator
    }
</PRE>

<P>There doesn't seem to be any good reason for disallowing such
declarations, and a number of implementations accept them in
spite of the Standard's prohibition.  Should the Standard be
changed to allow them?</P>

<P><B>Notes from the April, 2006 meeting:</B></P>

<P>In discussing <A HREF="
     cwg_closed.html#548">issue 548</A>, the CWG agreed
that the prohibition of qualified declarators inside their namespace
should be removed.</P>

<P><B>Proposed resolution (October, 2006):</B></P>

<P>Remove the indicated words from 8.3 [dcl.meaning]
paragraph 1:</P>

<BLOCKQUOTE>

...An <I>unqualified-id</I> occurring in a <I>declarator-id</I> shall
be a simple <I>identifier</I> except for the declaration of some
special functions (12.3 [class.conv], 12.4 [class.dtor], 13.5 [over.oper]) and for the declaration of
template specializations or partial specializations (). <SPAN style="text-decoration:line-through;background-color:#FFA0A0">A <I>declarator-id</I> shall not be qualified
except for the definition of a member function (9.3 [class.mfct]) or static data member (9.4 [class.static])
outside of its class, the definition or explicit instantiation of a
function or variable member of a namespace outside of its namespace,
or the definition of a previously declared explicit specialization
outside of its namespace, or the declaration of a friend function that
is a member of another class or namespace (11.4 [class.friend]).</SPAN> When the <I>declarator-id</I> is qualified, the
declaration shall refer to a previously declared member of the class
or namespace to which the qualifier refers, and the member shall not
have been introduced by a <I>using-declaration</I> in the scope of the
class or namespace nominated by the <I>nested-name-specifier</I> of
the <I>declarator-id</I>...

</BLOCKQUOTE>

<P>[<I>Drafting note:</I> The omission of &#8220;outside of its
class&#8221; here does not give permission for redeclaration of
class members; that is still prohibited by 9.2 [class.mem]
paragraph 1.  The removal of the enumeration of the kinds of
declarations in which a <I>qualified-id</I> can appear does allow
a <TT>typedef</TT> declaration to use a <I>qualified-id</I>, which
was not permitted before; if that is undesirable, the prohibition can
be reinstated here.]</P>

<BR><BR><HR><A NAME="547"></A><H4>547.
  
Partial specialization on member function types
</H4><B>Section: </B>8.3.5&#160; [dcl.fct]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Peter Dimov
 &#160;&#160;&#160;

 <B>Date: </B>04 November 2005<BR>




<P>The following example appears to be well-formed, with the partial
specialization matching the type of <TT>Y::f()</TT>, even though it
is rejected by many compilers:</P>

<PRE>
    template&lt;class T&gt; struct X;

    template&lt;class R&gt; struct X&lt; R() &gt; {
    };

    template&lt;class F, class T&gt; void test(F T::* pmf) {
        X&lt;F&gt; x;
    }

    struct Y {
        void f() {
        }
    };

    int main() {
        test( &amp;Y::f );
    }
</PRE>

<P>However, 8.3.5 [dcl.fct] paragraph 4 says,</P>

<BLOCKQUOTE>

A <I>cv-qualifier-seq</I> shall only be part of the function type for
a non-static member function, the function type to which a pointer to
member refers, or the top-level function type of a function typedef
declaration. The effect of a <I>cv-qualifier-seq</I> in a function
declarator is not the same as adding cv-qualification on top of the
function type. In the latter case, the cv-qualifiers are ignored.

</BLOCKQUOTE>

<P>This specification makes it impossible to write a partial
specialization for a <TT>const</TT> member function:</P>

<PRE>
    template&lt;class R&gt; struct X&lt;R() const&gt; {
    };
</PRE>

<P>A template argument is not one of the permitted contexts for
cv-qualification of a function type.  This restriction should be
removed.</P>

<P><B>Notes from the April, 2006 meeting:</B></P>

<P>During the meeting the CWG was of the opinion that the
&#8220;<TT>R() const</TT>&#8221; specialization would not match
the const member function even if it were allowed and so classified
the issue as NAD.  Questions have been raised since the meeting,
however, suggesting that the template argument in the partial
specialization would, in fact, match the type of a const member
function (see, for example, the very similar usage via typedefs
in 9.3 [class.mfct] paragraph 9).  The issue is thus being
left open for renewed discussion at the next meeting.</P>

<P><B>Proposed resolution (June, 2008):</B></P>

<P>Change 8.3.5 [dcl.fct] paragraph 7 as follows:</P>

<BLOCKQUOTE>

A <I>cv-qualifier-seq</I> shall only be part of the function type for a
non-static member function, the function type to which a pointer to
member refers, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or</SPAN> the top-level function type of a function typedef
declaration<SPAN style="font-weight:bold;background-color:#A0FFA0">, or the top-level function type of a <I>type-id</I> that is a
<I>template-argument</I> for a type <I>template-parameter</I></SPAN>. The
effect... A <I>ref-qualifier</I> shall only be part of the function type for
a non-static member function, the function type to which a pointer to
member refers, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or</SPAN> the top-level function type of a function typedef
declaration<SPAN style="font-weight:bold;background-color:#A0FFA0">, or the top-level function type of a <I>type-id</I> that is a
<I>template-argument</I> for a type <I>template-parameter</I></SPAN>. The
return type...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1183"></A><H4>1183.
  
Expansion of parameter packs in declarators
</H4><B>Section: </B>8.3.5&#160; [dcl.fct]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-26<BR>


<P>8.3.5 [dcl.fct] paragraph 13 says,</P>

<BLOCKQUOTE>

The type <TT>T</TT> of the <I>declarator-id</I> of the function
parameter pack shall contain a template parameter pack; each template
parameter pack in <TT>T</TT> is expanded by the function parameter
pack.

</BLOCKQUOTE>

<P>I think that's incorrect.  For example, I think</P>

<PRE>
    template&lt;class... P&gt; void f(int (* ...p)[sizeof...(P)]);
</PRE>

<P>should be an error, and that the function parameter pack <TT>p</TT>
does not expand the template parameter pack <TT>P</TT> in this case.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#778">issue 778</A>.</P>

<BR><BR><HR><A NAME="1058"></A><H4>1058.
  
Reference binding of incompatible array types
</H4><B>Section: </B>8.5.3&#160; [dcl.init.ref]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-20<BR>


<P>According to the logic in 8.5.3 [dcl.init.ref] paragraph 5,
the following example should create a temporary array and bind the
reference to that temporary:</P>

<PRE>
    const char (&amp;p)[10] = "123";
</PRE>

<P>That is presumably not intended (<A HREF="
     cwg_defects.html#450">issue 450</A>
calls a similar outcome for rvalue arrays &#8220;implausible&#8221;).
Current implementations reject this example.</P>

<P><B>Rationale (August, 2010):</B></P>

<P>The Standard does not describe initialization of array temporaries, so
a program that requires such is ill-formed.</P>

<P><B>Note (October, 2010):</B></P>

<P>Although in general an object of array type cannot be initialized
from another object of array type, there is special provision in
8.5.2 [dcl.init.string] for doing so when the source object is a
string literal, as in this example.  The issue is thus being reopened
for further consideration in this light.</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The CWG agreed that the current wording appears to permit this
example but still felt that array temporaries are undesirable.
Wording should be added to disallow this usage.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 8.5.3 [dcl.init.ref] paragraph 5 as follows:</P>

<UL><LI><P>...</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If the initializer expression is a string literal
(2.14.5 [lex.string]), the program is ill-formed.</SPAN></P></LI>

<LI><P>Otherwise, a temporary of type...</P></LI>

</UL>

<P>(See also <A HREF="
     cwg_active.html#1232">issue 1232</A>, which argues in
favor of allowing array temporaries.)</P>

<BR><BR><HR><A NAME="1095"></A><H4>1095.
  
List-initialization of references
</H4><B>Section: </B>8.5.4&#160; [dcl.init.list]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-07-26<BR>




<P>The current wording of the WP appears not to allow for list-initialization
of a reference like the following:</P>

<PRE>
    int i;
    int&amp; ir{i};
</PRE>

<P>First, 8.5 [dcl.init] paragraph 16 bullet 1 reads,</P>

<UL><LI><P>If the initializer is a braced-init-list, the
object is list-initialized (8.5.4).</P></LI></UL>

<P>A reference is not an object, so this does not appear to apply;
however, the second bullet sends reference initialization off to
8.5.3 [dcl.init.ref], which does not cover
<I>braced-init-list</I>s: paragraph 5 of that section deals only
with initilizer expressions, and a <I>braced-init-list</I> is not
an expression.</P>

<P>Assuming that the use of &#8220;object&#8221; in the first bullet
is just an oversight, 8.5.4 [dcl.init.list] also does not
cover the case of a reference to a scalar type whose initalizer
is a <I>braced-init-list</I> with a single element.  Bullet 7 of
paragraph 3 reads,</P>

<UL><LI><P>Otherwise, if the initializer list has a single
element, the object is initialized from that
element</P></LI></UL>

<P> and would cover this case except that, again, a
reference is not an object.  As a result, such an
initialization would end up in the last bullet and
consequently be ill-formed.</P>

<P>Presumably all that is needed is to add &#8220;or
reference&#8221; to the appropriate bullets of 8.5 [dcl.init]
paragraph 16 and 8.5.4 [dcl.init.list] paragraph 3.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Change 8.5 [dcl.init] paragraph 16 bullet 1
as follows:</P></LI>

<UL><LI><P>If the initializer is a <I>braced-init-list</I>, the object
<SPAN style="font-weight:bold;background-color:#A0FFA0">or reference</SPAN> is list-initialized (8.5.4 [dcl.init.list]).</P></LI></UL>

<LI><P>Change 8.5.4 [dcl.init.list] paragraph 3 bullet 7 as
follows:</P></LI>

<UL><LI><P>Otherwise, if the initializer list has a single element,
the object <SPAN style="font-weight:bold;background-color:#A0FFA0">or reference</SPAN> is initialized from that element;
if a narrowing conversion (see below) is required to convert the
element to <TT>T</TT>, the program is ill-formed.</P></LI></UL>

</OL>

<BR><BR><HR><A NAME="1215"></A><H4>1215.
  
Definition of POD struct
</H4><B>Section: </B>9&#160; [class]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-28<BR>


<P>The definition of a POD struct in 9 [class] paragraph 9
is not (but should be) restricted to non-union class types.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 9 [class] paragraph 9 as follows:</P>

<BLOCKQUOTE>

A <I>POD struct</I><SUP>109</SUP> is a <SPAN style="font-weight:bold;background-color:#A0FFA0">non-union</SPAN> class that
is both a trivial class and a standard-layout class...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1035"></A><H4>1035.
  
Omitted and required <I>decl-specifier</I>s
</H4><B>Section: </B>9.2&#160; [class.mem]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2010-02-25<BR>


<P>According to 9.2 [class.mem] paragraph 6,</P>

<BLOCKQUOTE>

 The <I>decl-specifier-seq</I> is omitted in constructor, destructor,
 and conversion function declarations only.

</BLOCKQUOTE>

<P>This is incorrect, as some <I>decl-specifier</I>s (<TT>explicit</TT>,
<TT>virtual</TT>, <TT>inline</TT>, <TT>constexpr</TT>) are permitted
in these declarations.  Conversely, C.1.5 [diff.dcl],
&#8220;Banning implicit int,&#8221; says,</P>

<BLOCKQUOTE>

In C++ a <I>decl-specifier-seq</I> must contain a <I>type-specifier</I>.

</BLOCKQUOTE>

<P>This is also incorrect for these declarations.</P>

<P><B>Proposed resolution (February, 2011):</B></P>

<OL><LI><P>Change 9.2 [class.mem] paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

The <I>decl-specifier-seq</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">is</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">may be</SPAN> omitted
in constructor, destructor, and conversion function declarations
only<SPAN style="font-weight:bold;background-color:#A0FFA0">; when declaring another kind of member the
<I>decl-specifier-seq</I> shall contain a <I>type-specifier</I> that
is not a <I>cv-qualifier</I></SPAN>.  The <I>member-declarator-list</I>
can be omitted...

</BLOCKQUOTE>

<LI><P>Change C.1.5 [diff.dcl], &#8220;Banning implicit
int,&#8221; as follows:</P></LI>

<BLOCKQUOTE>

In C++ a <I>decl-specifier-seq</I> must contain a
<I>type-specifier</I><SPAN style="font-weight:bold;background-color:#A0FFA0">, unless it is followed by a declarator for
a constructor, a destructor, or a conversion function</SPAN>.  In the
following example...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1101"></A><H4>1101.
  
Non-integral initialized static data members
</H4><B>Section: </B>9.4.2&#160; [class.static.data]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR>




<P>According to 9.4.2 [class.static.data] paragraph 3,</P>

<BLOCKQUOTE>

If a <TT>static</TT> data member is of <TT>const</TT>
literal type, its declaration in the class definition can
specify a <I>brace-or-equal-initializer</I> in which every
<I>initializer-clause</I> that is an
<I>assignment-expression</I> is a constant expression.  A
<TT>static</TT> data member of literal type can be declared in the
class definition with the <TT>constexpr</TT> specifier; if so, its
declaration shall specify a <I>brace-or-equal-initializer</I> in
which every <I>initializer-clause</I> that is an
<I>assignment-expression</I> is a constant expression.
[<I>Note:</I> In both these cases, the member may appear in
constant expressions. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>However, 5.19 [expr.const] paragraph 2 bullet 7
allows only integral and enumeration types in constant
expressions for the <TT>const</TT> case; the other types
require <TT>constexpr</TT> to be considered constant
expressions.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 9.4.2 [class.static.data] paragraph 3 as follows:</P>

<BLOCKQUOTE>

If a <SPAN style="font-weight:bold;background-color:#A0FFA0">non-volatile <TT>const</TT></SPAN> <TT>static</TT> data
member is of <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>const</TT> literal</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">integral or
enumeration</SPAN> type, its declaration in the class definition can
specify a
<I>brace-or-equal-initializer</I> in which every
<I>initializer-clause</I> that is an <I>assignment-expression</I> is a
constant expression <SPAN style="font-weight:bold;background-color:#A0FFA0">(5.19 [expr.const])</SPAN>. A
<TT>static</TT> data member of literal type can be declared in the
class definition with the <TT>constexpr</TT> specifier...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="512"></A><H4>512.
  
Union members with user-declared non-default constructors
</H4><B>Section: </B>9.5&#160; [class.union]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>19 Mar 2005<BR>


<P>Can a member of a union be of a class that has a user-declared
non-default constructor?  The restrictions on union membership in
9.5 [class.union] paragraph 1 only mention default and
copy constructors:</P>

<BLOCKQUOTE>

An object of a class with a non-trivial default constructor
(12.1 [class.ctor]), a non-trivial copy constructor
(12.8 [class.copy]), a non-trivial destructor (12.4 [class.dtor]), or a non-trivial copy assignment operator
(13.5.3 [over.ass], 12.8 [class.copy]) cannot be
a member of a union...

</BLOCKQUOTE>

<P>(12.1 [class.ctor] paragraph 11 does say,
&#8220;a non-trivial constructor,&#8221; but it's not clear whether
that was intended to refer only to default and copy constructors
or to any user-declared constructor.  For example,
12.2 [class.temporary] paragraph 3 also speaks of a
&#8220;non-trivial constructor,&#8221; but the cross-references
there make it clear that only default and copy constructors are
in view.)</P>

<P><B>Note (March, 2008):</B></P>

<P>This issue was resolved by the adoption of paper J16/08-0054 =
WG21 N2544 (&#8220;Unrestricted Unions&#8221;) at the Bellevue meeting.</P>

<BR><BR><HR><A NAME="462"></A><H4>462.
  
Lifetime of temporaries bound to comma expressions
</H4><B>Section: </B>12.2&#160; [class.temporary]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>April 2004<BR>


<P>Split off from <A HREF="
     cwg_defects.html#86">issue 86</A>.</P>

<P>Should binding a reference to the result of a "," operation
whose second operand is a temporary extend the lifetime of the
temporary?</P>
<PRE>
  const SFileName &amp;C = ( f(), SFileName("abc") );
</PRE>

<P><B>Notes from the March 2004 meeting:</B></P>

<P>We think the temporary should be extended.</P>

<P><B>Proposed resolution (October, 2004):</B></P>

<P>Change 12.2 [class.temporary] paragraph 2 as
indicated:</P>

<BLOCKQUOTE>

... In all these cases, the temporaries created during the
evaluation of the expression initializing the reference, except
the temporary <SPAN style="font-weight:bold;background-color:#A0FFA0">that is the overall result of the expression
[<I>Footnote:</I> For example, if the expression is a comma
expression (5.18 [expr.comma]) and the value of its
second operand is a temporary, the reference is bound to that
temporary.] and</SPAN> to which the reference is bound, are destroyed at
the end of the full-expression in which they are created and in
the reverse order of the completion of their construction...

</BLOCKQUOTE>

<P><I>[Note: this wording partially resolves <A HREF="
     cwg_defects.html#86">issue 86</A>.  See also <A HREF="
     cwg_defects.html#446">issue 446</A>.]</I></P>

<P><B>Notes from the April, 2005 meeting:</B></P>

<P>The CWG suggested a different approach from the 10/2004 resolution,
leaving 12.2 [class.temporary] unchanged and adding normative
wording to 5.18 [expr.comma] specifying that, if the result
of the second operand is a temporary, that temporary is the result of
the comma expression as well.</P>

<P><B>Proposed Resolution (November, 2006):</B></P>

<P>Add the indicated wording to 5.18 [expr.comma] paragraph 1:</P>

<BLOCKQUOTE>

... The type and value of the result are the type and value of the right
operand; the result is an lvalue if its right operand is an lvalue,
and is a bit-field if its right operand is an lvalue and a bit-field.
<SPAN style="font-weight:bold;background-color:#A0FFA0">If the value of the right operand is a temporary
(12.2 [class.temporary]), the result is that temporary.</SPAN>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="395"></A><H4>395.
  
Conversion operator template syntax
</H4><B>Section: </B>12.3.2&#160; [class.conv.fct]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>18 Dec 2002<BR>




<P>A posting in comp.lang.c++.moderated prompted me to
try the following code:</P>
<PRE>
  struct S {
    template&lt;typename T, int N&gt; (&amp;operator T())[N];
  };
</PRE>
<P>The goal is to have a (deducible) conversion operator
template to a reference-to-array type.</P>

<P>This is accepted by several front ends (g++, EDG), but
I now believe that 12.3.2 [class.conv.fct] paragraph 1
actually prohibits this.
The issue here is that we do in fact specify (part of)
a return type.</P>

<P>OTOH, I think it is legitimate to expect that this is
expressible in the language (preferably not using the
syntax above ;-).  Maybe we should extend the syntax
to allow the following alternative?</P>
<PRE>
  struct S {
    template&lt;typename T, int N&gt; operator (T(&amp;)[N])();
  };
</PRE>

<P><U>Eric Niebler</U>:
If the syntax is extended to support this, similar constructs should also be
considered.  For instance, I can't for the life of me figure out how to
write a conversion member function template to return a member function
pointer.  It could be useful if you were defining a null_t type.  This is
probably due to my own ignorance, but getting the syntax right is tricky.</P>

<P>Eg.</P>
<PRE>
  struct null_t {
    // null object pointer. works.
    template&lt;typename T&gt; operator T*() const { return 0; }
    // null member pointer. works.
    template&lt;typename T,typename U&gt; operator T U::*() const { return 0; }
    // null member fn ptr.  doesn't work (with Comeau online).  my error?
    template&lt;typename T,typename U&gt; operator T (U::*)()() const { return 0; }
  };
</PRE>

<P><U>Martin Sebor</U>:
Intriguing question. I have no idea how to do it in a single
declaration but splitting it up into two steps seems to work:</P>
<PRE>
  struct null_t {
    template &lt;class T, class U&gt;
    struct ptr_mem_fun_t {
      typedef T (U::*type)();
    };

    template &lt;class T, class U&gt;
    operator typename ptr_mem_fun_t&lt;T, U&gt;::type () const {
      return 0;
    }
  };
</PRE>

<P><I>Note:</I> In the April 2003 meeting, the core working group
noticed that the above doesn't actually work.</P>

<P><B>Note (June, 2010):</B></P>

<P>It has been suggested  that template aliases effectively
address this issue.  In particular, an identity alias like</P>

<PRE>
    template&lt;typename T&gt; using id = T;
</PRE>

<P>provides the necessary syntactic sugar to be able to specify
types with trailing declarator elements as a <I>conversion-type-id</I>.
For example, the two cases discussed above could be written as:</P>

<PRE>
    struct S {
        template&lt;typename T, int N&gt;
          operator id&lt;T[N]&gt;&amp;();
        template&lt;typename T, typename U&gt;
          operator id&lt;T (U::*)()&gt;() const;
    };
</PRE>

<P>This issue should thus be closed as now NAD.</P>

<BR><BR><HR><A NAME="111"></A><H4>111.
  
Copy constructors and cv-qualifiers
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jack Rouse
 &#160;&#160;&#160;

 <B>Date: </B>4 May 1999<BR>





<P><U>Jack Rouse:</U>
In 12.8 [class.copy]
 paragraph 8,
the standard includes
the following about the copying of class subobjects in such a
constructor:</P>
<UL>
<LI>if the subobject is of class type, the copy constructor for
the class is used;</LI>
</UL>

But there can be multiple copy constructors declared by the user with
differing cv-qualifiers on the source parameter.  I would assume
overload resolution would be used in such cases.  If so then the
passage above seems insufficient.

<P><B>Mike Miller:</B>
I'm more concerned about
12.8 [class.copy]
 paragraph 7,
which lists the situations in
which an implicitly-defined copy constructor can render a
program ill-formed.  Inaccessible and ambiguous copy
constructors are listed, but not a copy constructor with a
cv-qualification mismatch.  These two paragraphs taken together
could be read as requiring the calling of a copy constructor
with a non-const reference parameter for a const data member.</P>

<P><B>Proposed Resolution (November, 2006):</B></P>

<P>This issue is resolved by the proposed resolution for
<A HREF="
     cwg_active.html#535">issue 535</A>.</P>
<BR><BR><HR><A NAME="535"></A><H4>535.
  
Copy construction without a copy constructor
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>7 October 2005<BR>


<P>Footnote 112 (12.8 [class.copy] paragraph 2) says,</P>

<BLOCKQUOTE>

Because a template constructor is never a copy constructor, the
presence of such a template does not suppress the implicit declaration
of a copy constructor. Template constructors participate in overload
resolution with other constructors, including copy constructors, and a
template constructor may be used to copy an object if it provides a
better match than other constructors.

</BLOCKQUOTE>

<P>However, many of the stipulations about copy construction are
phrased to refer only to &#8220;copy constructors.&#8221;  For
example, 12.8 [class.copy] paragraph 14 says,</P>

<BLOCKQUOTE>

A program is ill-formed if the copy constructor...
for an object is implicitly used and the special member
function is not accessible (clause 11 [class.access]).

</BLOCKQUOTE>

<P>Does that mean that using an inaccessible template constructor
to copy an object is permissible, because it is not a &#8220;copy
constructor?&#8221;  Obviously not, but each use of the term
&#8220;copy constructor&#8221; in the Standard should be examined
to determine if it applies strictly to copy constructors or to
any constructor used for copying.  (A similar issue applies to
&#8220;copy assignment operators,&#8221; which have the same
relationship to assignment operator function templates.)</P>

<P><B>Proposed Resolution (February, 2008):</B></P>

<OL><LI><P>Change 3.2 [basic.def.odr] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

... [<I>Note:</I> this covers calls to named functions (5.2.2 [expr.call]), operator overloading (clause 13 [over]),
user-defined conversions (12.3.2 [class.conv.fct]), allocation
function for placement new (5.3.4 [expr.new]), as well as
non-default initialization (8.5 [dcl.init]). A <SPAN style="text-decoration:line-through;background-color:#FFA0A0">copy</SPAN>
constructor <SPAN style="font-weight:bold;background-color:#A0FFA0">selected to copy class objects</SPAN> is used even if the
call is actually elided by the implementation (12.8 [class.copy]). &#8212;<I>end note</I>] ... <SPAN style="text-decoration:line-through;background-color:#FFA0A0">A copy-assignment function
for a class</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">An assignment operator function in a class</SPAN>
is used by an implicitly-defined copy-assignment function
for another class as specified in 12.8 [class.copy]...

</BLOCKQUOTE>

<LI><P>Delete 12.1 [class.ctor] paragraphs 10 and 11:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A copy constructor (12.8 [class.copy]) is used to copy
objects of class type.</SPAN></P>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A union member shall not be of a class type (or array thereof)
that has a non-trivial constructor.</SPAN></P>

</BLOCKQUOTE>

<LI><P>Replace the &#8220;example&#8221; in 12.2 [class.temporary]
paragraph 1 with a note as follows:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">[<I>Example:</I> even if the copy constructor is not called, all
the semantic restrictions, such as accessibility (clause 11 [class.access]), shall be satisfied. &#8212;<I>end example</I>]</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> This includes accessibility (clause 11 [class.access]) for the constructor selected. &#8212;<I>end note</I>]</SPAN>

</BLOCKQUOTE>

<LI><P>Change 12.8 [class.copy] paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

<P>A non-user-provided copy constructor is <I>implicitly defined</I>
if it is used <SPAN style="text-decoration:line-through;background-color:#FFA0A0">to initialize an object of its class type from a copy
of an object of its class type or of a class type derived from its
class type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">(3.2 [basic.def.odr])</SPAN>. [<I>Footnote:</I>
See 8.5 [dcl.init] for more details on direct and copy
initialization. &#8212;<I>end footnote</I>] [<I>Note:</I> the copy
constructor is implicitly defined even if the implementation elided
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">its use (12.2 [class.temporary])</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the copy operation
(12.8 [class.copy])</SPAN>. &#8212;<I>end note</I>] <SPAN style="text-decoration:line-through;background-color:#FFA0A0">A program
is ill-formed if the class for which a copy constructor is implicitly
defined or explicitly defaulted has:</SPAN></P>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><UL>
<LI><P>a non-static data member of class type (or array thereof) with an inaccessible or ambiguous copy constructor, or</P></LI>

<LI><P>a base class with an inaccessible or ambiguous copy constructor.</P></LI>

</UL></SPAN><P>Before the non-user-provided copy constructor for a class is
implicitly defined...</P>

</BLOCKQUOTE>

<LI><P>Change 12.8 [class.copy] paragraph 8 as follows:</P></LI>

<BLOCKQUOTE>

<P>...Each subobject is copied in the manner appropriate to its type:</P>

<UL>
<LI><P>if the subobject is of class type, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the copy constructor for
the class is used</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">direct-initialization (8.5 [dcl.init]) is performed [<I>Note:</I> If overload resolution fails
or the constructor selected by overload resolution is inaccessible
(11 [class.access]) in the context of <TT>X</TT>, the program is
ill-formed. &#8212;<I>end note</I>]</SPAN>;</P></LI>

<LI><P>if the subobject is an array...</P></LI></UL>

</BLOCKQUOTE>

<P><I>[Drafting note: 8.5 [dcl.init] paragraph 15 requires
&#8220;unambiguous&#8221; and 13.3 [over.match] paragraph 3
requires &#8220;accessible,&#8221; thus no need for normative text
here.]</I></P>

<LI><P>Change 12.8 [class.copy] paragraph 12 as follows:</P></LI>

<BLOCKQUOTE>

<P>A non-user-provided copy assignment operator is <I>implicitly
defined</I> when <SPAN style="text-decoration:line-through;background-color:#FFA0A0">an object of its class type is assigned a value of
its class type or a value of a class type derived from its class
type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">it is used (3.2 [basic.def.odr])</SPAN>. A program is
ill-formed if the class for which a copy assignment operator is
implicitly defined or explicitly defaulted has<SPAN style="text-decoration:line-through;background-color:#FFA0A0">:</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a
non-static data member of const or reference type.</SPAN></P>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><UL>
<LI><P>a non-static data member of const type, or</P></LI>

<LI><P>a non-static data member of reference type, or</P></LI>

<LI><P>a non-static data member of class type (or array thereof) with
an inaccessible copy assignment operator, or</P></LI>

<LI><P>a base class with an inaccessible copy assignment
operator.</P></LI>
</UL></SPAN>

</BLOCKQUOTE>

<LI><P>Change 12.8 [class.copy] paragraph 13 as follows:</P></LI>

<BLOCKQUOTE>

<P>... Each subobject is assigned in the manner appropriate to its type:</P>

<UL>
<LI><P>if the subobject is of class type, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the copy assignment
operator for the class</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the assignment operator function
selected by overload resolution (13.3 [over.match]) for that
class</SPAN> is used (as if by explicit qualification; that
is, ignoring any possible virtual overriding functions in more derived
classes) <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> If overload resolution fails or the assignment
operator function selected by overload resolution is inaccessible
(11 [class.access]) in the context of <TT>X</TT>, the program
is ill-formed. &#8212;<I>end note</I>]</SPAN>;</P></LI>

<LI><P>if the subobject is an array...</P></LI>
</UL>

</BLOCKQUOTE>

<LI><P>Delete 12.8 [class.copy] paragraph 14:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">A program is ill-formed if the copy constructor or the copy
assignment operator for an object is implicitly used and the special
member function is not accessible (clause 11 [class.access]). [<I>Note:</I> Copying one object into another using the
copy constructor or the copy assignment operator does not change the
layout or size of either object. &#8212;<I>end note</I>]</SPAN>

</BLOCKQUOTE>

<LI><P>Change 12.8 [class.copy] paragraph 15 as follows:</P></LI>

<BLOCKQUOTE>

When certain criteria are met, an implementation is allowed to omit
the copy construction of a class object, even if the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">copy</SPAN> constructor
<SPAN style="font-weight:bold;background-color:#A0FFA0">selected for the copy operation</SPAN> and/or <SPAN style="font-weight:bold;background-color:#A0FFA0">the</SPAN> destructor
for the object have side effects. In such cases, the implementation
treats the source and target of the omitted copy operation as simply
two different ways of referring to the same object, and the
destruction of that object occurs at the later of the times when the
two objects would have been destroyed without the optimization.
[<I>Footnote:</I> Because only one object is destroyed instead of two,
and one <SPAN style="text-decoration:line-through;background-color:#FFA0A0">copy</SPAN> constructor is not executed, there is still one
object destroyed for each one constructed. &#8212;<I>end footnote</I>]
This elision...

</BLOCKQUOTE>

<LI><P>Change 13.3.3.1.2 [over.ics.user] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

A conversion of an expression of class type to the same class type is
given Exact Match rank, and a conversion of an expression of class
type to a base class of that type is given Conversion rank, in spite
of the fact that a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">copy</SPAN> constructor (i.e., a user-defined
conversion function) is called for those cases.

</BLOCKQUOTE>

<LI><P>Change 15.1 [except.throw] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

A <I>throw-expression</I> initializes a temporary object, called the
<I>exception object</I>, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the type of which</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">by
copy-initialization (8.5 [dcl.init]).  The type of that
temporary object</SPAN> is determined...

</BLOCKQUOTE>

<LI><P>Change 15.1 [except.throw] paragraph 5 as follows:</P></LI>

<BLOCKQUOTE>

When the thrown object is a class object, the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">copy</SPAN> constructor
<SPAN style="font-weight:bold;background-color:#A0FFA0">selected for the copy-initialization</SPAN> and the destructor shall
be accessible, even if the copy operation is elided (12.8 [class.copy]).

</BLOCKQUOTE>

<LI><P>Change 15.3 [except.handle] paragraphs 16-17 as follows:</P></LI>

<BLOCKQUOTE>

<P>When the <I>exception-declaration</I> specifies a class type, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">a
copy constructor</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">copy-initialization (8.5 [dcl.init])</SPAN> is used to initialize either the object declared in
the <I>exception-declaration</I> or, if
the <I>exception-declaration</I> does not specify a name, a temporary
object of that type.  The object shall not have an abstract class
type. The object is destroyed when the handler exits, after the
destruction of any automatic objects initialized within the
handler. The <SPAN style="text-decoration:line-through;background-color:#FFA0A0">copy</SPAN> constructor <SPAN style="font-weight:bold;background-color:#A0FFA0">selected for the
copy-initialization</SPAN> and <SPAN style="font-weight:bold;background-color:#A0FFA0">the</SPAN> destructor shall be accessible
in the context of the handler<SPAN style="font-weight:bold;background-color:#A0FFA0">, even if the copy operation is elided
(12.8 [class.copy])</SPAN>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">If the copy constructor and
destructor are implicitly declared (12.8 [class.copy]), such a
use in the handler causes these functions to be implicitly defined;
otherwise, the program shall provide a definition for these
functions.</SPAN></P>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">The copy constructor and destructor associated with the object
shall be accessible even if the copy operation is elided (12.8 [class.copy]).</SPAN></P>

</BLOCKQUOTE>

<LI><P>Change the footnote in 15.5.1 [except.terminate] paragraph 1
as follows:</P></LI>

<BLOCKQUOTE>

[<I>Footnote:</I> For example, if the object being thrown is of a
class <SPAN style="text-decoration:line-through;background-color:#FFA0A0">with a copy constructor</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">type</SPAN>,
<TT>std::terminate()</TT> will be called if <SPAN style="text-decoration:line-through;background-color:#FFA0A0">that copy constructor</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">the constructor selected to copy the object</SPAN> exits with an
exception during a <TT>throw</TT>. &#8212;<I>end footnote</I>]

</BLOCKQUOTE>

</OL>

<P>(This resolution also resolves <A HREF="
     cwg_active.html#111">issue 111</A>.)</P>

<P><I>[Drafting note: The following do not require changes:
5.17 [expr.ass] paragraph 4;
9 [class] paragraph 5;
9.5 [class.union] paragraph 1;
12.2 [class.temporary] paragraph 2;
12.8 [class.copy] paragraphs 1-2;
15.4 [except.spec] paragraph 14.]</I></P>

<P><B>Notes from February, 2008 meeting:</B></P>

<P>These changes overlap those that will be made when concepts are
added.  This issue will be maintained in &#8220;review&#8221; status
until the concepts proposal is adopted and any conflicts will be
resolved at that point.</P>

<BR><BR><HR><A NAME="1224"></A><H4>1224.
  
<TT>constexpr</TT> defaulted copy constructors
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-25<BR>




<P>12.1 [class.ctor] allows for a defaulted default
constructor to be <TT>constexpr</TT>, but 12.8 [class.copy]
does not do the same for a defaulted copy constructor.  This seems
wrong.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 12.8 [class.copy] paragraph 14 as follows:</P>

<BLOCKQUOTE>

A copy/move constructor that is defaulted and not defined as deleted
is <I>implicitly defined</I> if it is odr-used (3.2 [basic.def.odr]) to initialize an object of its class type from a copy of
an object of its class type or of a class type derived from its class
type<SUP>123</SUP> or when it is explicitly defaulted after its first
declaration.  [<I>Note:</I> the copy/move constructor is implicitly
defined even if the implementation elided its odr-use (3.2 [basic.def.odr], 12.2 [class.temporary]). &#8212;<I>end note</I>]
<SPAN style="font-weight:bold;background-color:#A0FFA0">If the implicitly-defined constructor would satisfy the
requirements of a <TT>constexpr</TT> constructor (7.1.5 [dcl.constexpr]), the implicitly-defined constructor is
<TT>constexpr</TT>.</SPAN>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1079"></A><H4>1079.
  
Overload resolution involving aggregate initialization
</H4><B>Section: </B>13.3.3.2&#160; [over.ics.rank]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-15<BR>




<P>The current wording makes some calls involving aggregate
initialization ambiguous that should not be.  For example, the
calls below to <TT>f</TT> and <TT>g</TT> should each prefer the
second overload:</P>

<PRE>
    struct A { int i; };

    void f (const A &amp;);
    void f (A &amp;&amp;);

    void g (A, double);
    void g (A, int);

    int main() {
       f ( { 1 } );
       g ( { 1 }, 1 );
    }
</PRE>

<P><B>Proposed resolution (August, 2010):</B></P>

<P>Change 13.3.3.2 [over.ics.rank]
paragraph 3 bullet 2 as follows:</P>

<UL><LI><P>User-defined conversion sequence <TT>U1</TT> is a better
conversion sequence than another user-defined conversion sequence
<TT>U2</TT> if they contain the same user-defined conversion function
or constructor <SPAN style="font-weight:bold;background-color:#A0FFA0">or aggregate initialization</SPAN> and if the
second standard conversion sequence of <TT>U1</TT> is better than the
second standard conversion sequence of <TT>U2</TT>.</P></LI></UL>

<BR><BR><HR><A NAME="778"></A><H4>778.
  
Template parameter packs in non-type template parameters
</H4><B>Section: </B>14.1&#160; [temp.param]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>13 February, 2009<BR>


<P>Consider an example like:</P>

<PRE>
    template &lt;typename T, T Value&gt; struct bar { };
    template &lt;typename... T, T ...Value&gt; void foo(bar&lt;T, Value&gt;);
</PRE>

<P>The current wording in 14.1 [temp.param] is unclear as to
whether this is permitted or not. For comparison,
8.3.5 [dcl.fct] paragraph 13 says,</P>

<BLOCKQUOTE>

A <I>declarator-id</I> or <I>abstract-declarator</I> containing an
ellipsis shall only be used in a <I>parameter-declaration</I>.  Such a
<I>parameter-declaration</I> is a parameter pack (14.5.3 [temp.variadic]). When it is part of a
<I>parameter-declaration-clause</I>, the parameter pack is a function
parameter pack (14.5.3 [temp.variadic]).  [<I>Note:</I>
Otherwise, the <I>parameter-declaration</I> is part of a
<I>template-parameter-list</I> and the parameter pack is a template
parameter pack; see 14.1 [temp.param]. &#8212;<I>end note</I>]
A function parameter pack, if present, shall occur at the end of the
<I>parameter-declaration-list</I>.  The type <TT>T</TT> of the
<I>declarator-id</I> of the function parameter pack shall contain a
template parameter pack; each template parameter pack in <TT>T</TT> is
expanded by the function parameter pack.

</BLOCKQUOTE>

<P>The requirement here that the type of a function parameter pack
must contain a template parameter pack is not repeated for template
non-type parameters in 14.1 [temp.param], nor is the statement
that it expands the template parameter pack.</P>

<P>A related issue is that neither function nor template parameter
packs are listed in 14.5.3 [temp.variadic] paragraph 4 among
the contexts in which a pack expansion can appear.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Change 5.3.3 [expr.sizeof] paragraph 5 as follows:</P></LI>

<BLOCKQUOTE>

The identifier in a <TT>sizeof...</TT> expression shall name a
parameter pack. The <TT>sizeof...</TT> operator yields the number of
arguments provided for the parameter pack <I>identifier</I>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">The
parameter pack is expanded (14.5.3 [temp.variadic]) by the
<TT>sizeof...</TT> operator</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A <TT>sizeof...</TT> expression
is a pack expansion (14.5.3 [temp.variadic])</SPAN>. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Change 8.3.5 [dcl.fct] paragraph 13 as follows:</P></LI>

<BLOCKQUOTE>

A <I>declarator-id</I> or <I>abstract-declarator</I> containing an
ellipsis shall only be used in a <I>parameter-declaration</I>.  Such a
<I>parameter-declaration</I> is a parameter pack (14.5.3 [temp.variadic]). When it is part of a
<I>parameter-declaration-clause</I>, the parameter pack is a function
parameter pack (14.5.3 [temp.variadic]).  [<I>Note:</I>
Otherwise, the <I>parameter-declaration</I> is part of a
<I>template-parameter-list</I> and the parameter pack is a template
parameter pack; see 14.1 [temp.param].  &#8212;<I>end
note</I>] <SPAN style="text-decoration:line-through;background-color:#FFA0A0">The type <TT>T</TT> of the <I>declarator-id</I> of the
function parameter pack shall contain a template parameter pack; each
template parameter pack in <TT>T</TT> is expanded by the function
parameter pack</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A function parameter pack is a pack
expansion (14.5.3 [temp.variadic])</SPAN>. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Change 14.1 [temp.param] paragraph 15 as follows:</P></LI>

<BLOCKQUOTE>

<P>If a <I>template-parameter</I> is a <I>type-parameter</I> with an
ellipsis prior to its optional <I>identifier</I> or is a
<I>parameter-declaration</I> that declares a parameter pack
(8.3.5 [dcl.fct]), then the <I>template-parameter</I> is a
template parameter pack (14.5.3 [temp.variadic]). <SPAN style="font-weight:bold;background-color:#A0FFA0">A template
parameter pack that is a <I>parameter-declaration</I> whose type
contains one or more unexpanded parameter packs is a pack
expansion. Similarly, a template parameter pack that is a
<I>type-parameter</I> with a <I>template-parameter-list</I> containing
one or more unexpanded parameter packs is a pack expansion.</SPAN>
[<I>Example:</I></P>

<PRE>
  template &lt;class... Types&gt; class Tuple; // Types<SPAN style="font-family:Times;font-style:italic"> is a template type parameter pack <SPAN style="font-weight:bold;background-color:#A0FFA0">and a pack expansion</SPAN></SPAN>
  template &lt;class T, int... Dims&gt; struct multi_array; // Dims<SPAN style="font-family:Times;font-style:italic"> is a non-type template parameter pack <SPAN style="font-weight:bold;background-color:#A0FFA0">but not a pack expansion</SPAN></SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template &lt;class T, T... Values&gt; struct static_array; // Values<SPAN style="font-family:Times;font-style:italic"> is a non-type template parameter pack and a pack expansion</SPAN></SPAN>
</PRE>

</BLOCKQUOTE>

<LI><P>Change 14.5.3 [temp.variadic] paragraphs 4-6 and add a new
paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

<P>A <I>pack expansion</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">is a sequence of tokens that names one
or more parameter packs, followed by an ellipsis.  The sequence of
tokens is called the <I>pattern of the expansion</I>; its syntax</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">consists of a <I>pattern</I> and an ellipsis, the instantiation
of which produces zero or more instantiations of the pattern in a list
(described below).  The form of the pattern</SPAN> depends on the
context in which the expansion occurs. Pack expansions can occur in
the following contexts:</P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">In a function parameter pack (8.3.5 [dcl.fct]);
the pattern is the <I>parameter-declaration</I> without the
ellipsis.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">In a template parameter pack that is a pack expansion
(14.1 [temp.param]):</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the template parameter pack is a
<I>parameter-declaration</I>; the pattern is the
<I>parameter-declaration</I> without the ellipsis,</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the template parameter pack is a <I>type-parameter</I>
with a <I>template-parameter-list</I>; the pattern is the corresponding
<I>type-parameter</I> without the ellipsis.</SPAN></P></LI>

</UL>

</LI>

<LI><P>...</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">In a <TT>sizeof...</TT> expression (5.3.3 [expr.sizeof]),
the pattern is an <I>identifier</I>.</SPAN></P></LI>

</UL>

<P>[<I>Example:...</I></P>

<P>A parameter pack whose name appears within the pattern of a pack
expansion is expanded by that pack expansion.  An appearance of the
name of a parameter pack is only expanded by the innermost enclosing
pack expansion.  The pattern of a pack expansion shall name one or
more parameter packs that are not expanded by a nested pack
expansion<SPAN style="font-weight:bold;background-color:#A0FFA0">; such parameter packs are called
<I>unexpanded</I> parameter packs in the pattern</SPAN>. All of the
parameter packs expanded...</P>

<PRE>
  ...
  void g(Args ... args) {  <SPAN style="font-weight:bold;background-color:#A0FFA0">//<SPAN style="font-family:Times;font-style:italic"> OK: &#8220;</SPAN>Args<SPAN style="font-family:Times;font-style:italic">&#8221; is expanded by the function parameter pack &#8220;</SPAN>args<SPAN style="font-family:Times;font-style:italic">&#8221;</SPAN></SPAN>
  ...
</PRE>

<P>The instantiation of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">an</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a pack</SPAN> expansion
<SPAN style="font-weight:bold;background-color:#A0FFA0">that is not a <TT>sizeof...</TT> expression</SPAN> produces a
list...</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">The instantiation of a <TT>sizeof...</TT> expression
(5.3.3 [expr.sizeof]) produces an integral constant containing
the number of elements in the parameter pack it expands.</SPAN></P>

</BLOCKQUOTE>

</OL>

<P>This resolution also resolves issues <A HREF="
     cwg_active.html#1182">1182</A>
and <A HREF="
     cwg_active.html#1183">1183</A>.</P>

<P><B>Additional note (February, 2011):</B></P>

<P>A problematic case is a function like</P>

<PRE>
  template&lt;typename... T, T... t&gt; void f(T...) { }
</PRE>

<P>where each element of the nontype pack actually has a different
type.  This causes problems for template argument deduction, since
<TT>T</TT> and <TT>t</TT> are supposed to be deduced independently,
but they're linked through their sizes.  There doesn't appear to be
any use case for this kind of example, so it should be ill-formed.</P>

<P>The rule should probably be to consider a non-type template
parameter pack that expands any template parameter packs from the same
<I>template-parameter-list</I> as ill-formed.</P>

<BR><BR><HR><A NAME="1206"></A><H4>1206.
  
Defining opaque enumeration members of class templates
</H4><B>Section: </B>14.5.1&#160; [temp.class]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-06<BR>




<P>Presumably an out-of-class definition for an opaque enumeration
member of a class template is intended to be allowed; however, the
current wording of 14.5.1 [temp.class] provides only for
out-of-class definitions of member functions, member classes,
static data members, and member templates, not for opaque
enumerations.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Change 14 [temp] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>...The <I>declaration</I> in a <I>template-declaration</I> shall</P>

<UL><LI><P>declare or define a function or class, or</P></LI>

<LI><P>define a member function, a member class<SPAN style="font-weight:bold;background-color:#A0FFA0">, a member
enumeration,</SPAN> or a static data member of a class template or of a
class nested within a class template, or</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 14.5.1 [temp.class] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

When a member function, a member class, <SPAN style="font-weight:bold;background-color:#A0FFA0">a member
enumeration,</SPAN> a static data member or a member template of a
class template is defined outside of the class template definition...

</BLOCKQUOTE>

<LI><P>Add a new section following 14.5.1.3 [temp.static]:</P></LI>

<BLOCKQUOTE>

<P><B><SPAN style="font-weight:bold;background-color:#A0FFA0">14.5.1.4 Enumeration members of class templates
[temp.mem.enum]</SPAN></B></P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">An enumeration member of a class template may be defined outside
the class template definition. [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template&lt;class T&gt; struct A {
    enum E: T;
  };
  A&lt;int&gt; a;
  template&lt;class T&gt; enum A&lt;T&gt;::E: T { e1, e2 };
  A&lt;int&gt;::E e = A&lt;int&gt;::e1;</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

<LI><P>Change 14.7 [temp.spec] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

A function instantiated from a function template is called an
instantiated function. A class instantiated from a class template is
called an instantiated class. A member function, a member class,
<SPAN style="font-weight:bold;background-color:#A0FFA0">a member enumeration,</SPAN> or a static data member of a class
template instantiated from the member definition of the class template
is called, respectively, an instantiated member function, member
class<SPAN style="font-weight:bold;background-color:#A0FFA0">, member enumeration,</SPAN> or static data member.  A member
function...

</BLOCKQUOTE>

<LI><P>Change 14.7.1 [temp.inst] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...The implicit instantiation of a class template specialization
causes the implicit instantiation of the declarations, but not of the
definitions or default arguments, of the class member functions,
member classes, <SPAN style="font-weight:bold;background-color:#A0FFA0">scoped member enumerations,</SPAN> static data
members and member templates; and it causes the implicit instantiation
of the definitions of <SPAN style="font-weight:bold;background-color:#A0FFA0">unscoped member enumerations and</SPAN> member
anonymous unions. Unless a member...

</BLOCKQUOTE>

<LI><P>Change 14.7.3 [temp.expl.spec] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>An explicit specialization of any of the following:</P>

<UL><LI><P>function template</P></LI>

<LI><P>class template</P></LI>

<LI><P>member function of a class template</P></LI>

<LI><P>static data member of a class template</P></LI>

<LI><P>member class of a class template</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">member enumeration of a class template</SPAN></P></LI>

<LI><P>member class template of a class or class template</P></LI>

<LI><P>member function template of a class or class template</P></LI>

<P>can be declared by a declaration introduced by
<TT>template&lt;&gt;</TT>...</P>

</UL>

</BLOCKQUOTE>

<LI><P>Change 14.7.3 [temp.expl.spec] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

A member function, a member class<SPAN style="font-weight:bold;background-color:#A0FFA0">, a member enumeration,</SPAN> or
a static data member of a class template may be explicitly specialized
for a class specialization that is implicitly instantiated...

</BLOCKQUOTE>

<LI><P>Add the indicated text to the example in 14.7 [temp.spec]
paragraph 6:</P></LI>

<PRE>
  template&lt;&gt; void sort&lt;&gt;(Array(&lt;char*&gt;&amp; v);        //<SPAN style="font-family:Times;font-style:italic"> OK: </SPAN>sort&lt;char*&gt;<SPAN style="font-family:Times;font-style:italic"> not yet used</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template&lt;class T&gt; struct A {
    enum E: T;
    enum class S: T;
  };
  template&lt;&gt; enum A&lt;int&gt;::E: int { eint };         //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
  template&lt;&gt; enum class A&lt;int&gt;::S: int { sint };   //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
  template&lt;class T&gt; enum A&lt;T&gt;::E: T { eT };
  template&lt;class T&gt; enum class A&lt;T&gt;::S: T { sT };
  template&lt;&gt; enum A&lt;char&gt;::E: int { echar };       //<SPAN style="font-family:Times;font-style:italic"> ill-formed, </SPAN>A&lt;char&gt;::E<SPAN style="font-family:Times;font-style:italic"> was instantiated when </SPAN>A&lt;char&gt;<SPAN style="font-family:Times;font-style:italic"> was instantiated</SPAN>
  template&lt;&gt; enum class A&lt;char&gt;::S: int { schar }; //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN></SPAN>
</PRE>

<LI><P>Change 14.7.3 [temp.expl.spec] paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

The placement of explicit specialization declarations for function
templates, class templates, member functions of class templates,
static data members of class templates, member classes of class
templates, <SPAN style="font-weight:bold;background-color:#A0FFA0">member enumerations of class templates,</SPAN> member
class templates of class templates, member function templates...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1182"></A><H4>1182.
  
Incorrect description of pack expansion syntax
</H4><B>Section: </B>14.5.3&#160; [temp.variadic]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-26<BR>


<P>According to 14.5.3 [temp.variadic] paragraph 4,</P>

<BLOCKQUOTE>

A <I>pack expansion</I> is a sequence of tokens that names one or more
parameter packs, followed by an ellipsis.

</BLOCKQUOTE>

<P>This is contradicted by 5.3.3 [expr.sizeof] paragraph 5,
which describes <TT>sizeof...(Types)</TT> as an expansion, as well
as the case where the expansion appears in a declarator like the
example given in 8.3.5 [dcl.fct] paragraph 13:
</P>

<PRE>
    template&lt;typename... T&gt; void f(T (* ...t)(int, int));
</PRE>

<P>This is also described as a pack expansion, although it does
not fit the syntactic summary.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#778">issue 778</A>.</P>

<BR><BR><HR><A NAME="1056"></A><H4>1056.
  
Template aliases, member definitions, and the current instantiation
</H4><B>Section: </B>14.5.7&#160; [temp.alias]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-17<BR>


<P>According to 14.6.2.1 [temp.dep.type] paragraph 1, in a primary
class template a name refers to the current instantiation if it is the
injected-class-name or the name of the class template followed by the
template argument list of the template.  Although a <I>template-id</I>
referring to a specialization of a template alias is described as
&#8220;equivalent to&#8221; the associated type, a specialization of
a template alias is neither of the things that qualifies as naming the
current instantiation, so presumably the <TT>typename</TT> keyword in
the following example is required:</P>

<PRE>
    template &lt;class T&gt; struct A;
    template &lt;class T&gt; using B = A&lt;T&gt;;

    template &lt;class T&gt; struct A {
        struct C {};
        typename B&lt;T&gt;::C bc;  // typename needed
    };
</PRE>

<P>(However, the list in 14.6.2.1 [temp.dep.type] may not be
exactly what we want; it doesn't allow use of a typedef denoting
the type of the current instantiation, either, but that presumably
should be accepted.)</P>

<P>For analogous reasons, it should not be permitted to use a
template alias as a <I>nested-name-specifier</I> when defining the
members of a class template:</P>

<PRE>
    template &lt;class T&gt; struct A {
        void g();
    };
    template &lt;class T&gt; using B = A&lt;T&gt;;
    template &lt;class T&gt; void B&lt;T&gt;::g() {} // error
</PRE>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The CWG disagreed with the suggested direction, feeling that aliases
should work like typedefs and that the examples should be accepted.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Change 14.6.2.1 [temp.dep.type] paragraph 1 as
follows:</P></LI>

<BLOCKQUOTE>

<P>In the definition of a class template, a nested class of a class
template, a member of a class template, or a member of a nested class
of a class template, a name refers to the <I>current instantiation</I>
if it is</P>

<UL><LI><P>the injected-class-name (Clause <sectkon_ref ref="9">9 [class]</sectkon_ref>) of
the class template or nested class,</P></LI>

<LI><P>in the definition of a primary class template, the name of the
class template followed by the template argument list of the primary
template (as described below) enclosed in <TT>&lt;&gt;</TT> <SPAN style="font-weight:bold;background-color:#A0FFA0">(or
a template alias specialization equivalent to same)</SPAN>,</P></LI>

<LI><P>in the definition of a nested class of a class template, the
name of the nested class referenced as a member of the current
instantiation, or</P></LI>

<LI><P>in the definition of a partial specialization, the name of the
class template followed by the template argument list of the partial
specialization enclosed in <TT>&lt;&gt;</TT> <SPAN style="font-weight:bold;background-color:#A0FFA0">(or a template
alias specialization equivalent to same)</SPAN>. If the <I>n</I>th
template parameter is a parameter pack, the <I>n</I>th template
argument is a pack expansion (14.5.3 [temp.variadic]) whose
pattern is the name of the parameter pack.</P></LI>

</UL>

</BLOCKQUOTE>

<P>Change 14.6.2.1 [temp.dep.type] paragraph 3 as follows:</P>

A template argument that is equivalent to a template parameter (i.e.,
has the same constant value or the same type as the template
parameter) can be used in place of that template parameter in a
reference to the current instantiation<SPAN style="font-weight:bold;background-color:#A0FFA0">, except that a
<I>decltype-specifier</I> that denotes a dependent type is always
considered non-equivalent</SPAN>. In the case of a non-type
template argument, the argument must have been given the value of the
template parameter and not an expression in which the template
parameter appears as a subexpression. [<I>Example:</I>...

</OL>

<P>This resolution also resolves <A HREF="
     cwg_active.html#1057">issue 1057</A>.</P>

<BR><BR><HR><A NAME="602"></A><H4>602.
  
When is the injected-class-name of a class template a template?
</H4><B>Section: </B>14.6.1&#160; [temp.local]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>23 October 2006<BR>




<P>Consider the following example:</P>

<PRE>
    template&lt;class T&gt;
    struct A {
         template&lt;class U&gt;
             friend struct A; // Which A?
    };
</PRE>

<P>Presumably the lookup for <TT>A</TT> in the friend declaration finds
the injected-class-name of the template.  However, according to
14.6.1 [temp.local] paragraph 1,</P>

<BLOCKQUOTE>

The injected-class-name can be used with or without a
<I>template-argument-list</I>. When it is used without a
<I>template-argument-list</I>, it is equivalent to the
injected-class-name followed by the <I>template-parameter</I>s of the
class template enclosed in <TT>&lt;&gt;</TT>. When it is used with a
<I>template-argument-list</I>, it refers to the specified class
template specialization, which could be the current specialization or
another specialization.

</BLOCKQUOTE>

<P>If that rule applies, then this example is ill-formed (because you
can't have a <I>template-argument-list</I> in a class template
declaration that is not a partial specialization).</P>

<P><U>Mike Miller</U>: The injected-class-name has a dual nature, as
described in 14.6.1 [temp.local], acting as either a
template name or a class name, depending on the context; a template
argument list forces the name to be interpreted as a template.  It
seems reasonable that in this example the injected-class-name has to
be understood as referring to the class template; a template header is
at least as strong a contextual indicator as a template argument list.
However, the current wording doesn't say that.</P>

<P>(See also <A HREF="
     cwg_active.html#1004">issue 1004</A>.)</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1004">issue 1004</A>.</P>

<BR><BR><HR><A NAME="1004"></A><H4>1004.
  
Injected-class-names as arguments for template template parameters
</H4><B>Section: </B>14.6.1&#160; [temp.local]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2009-11-19<BR>




<P>The injected-class-name of a class template can be used either
by itself, in which case it is a type denoting the current instantiation,
or followed by a template argument list, in which case it is a
<I>template-name</I>.  It would be helpful to extend this treatment
so that the injected-class-name could be used as an argument for a template
template parameter:</P>

<PRE>
    template &lt;class T&gt; struct A { };

    template &lt;template &lt;class&gt; class TTP&gt; struct B { };

    struct C: A&lt;int&gt; {
       B&lt;A&gt; b;
    };
</PRE>

<P>(This is accepted by g++.)</P>

<P><U>James Widman</U>:</P>

<P>It would not be so helpful when used with overloaded function
templates, for example:</P>

<PRE>
    template &lt;template &lt;class&gt; class TTP&gt;  void f(); // #1
    template &lt;                 class T  &gt;  void f(); // #2

    template &lt;class T&gt; struct A { };

    struct C: A&lt;int&gt; {
        void h(  ) {
            f&lt;A&gt;(); //  #1?  #2?  Substitution failure?
        }
    };
</PRE>

<P>(See also <A HREF="
     cwg_active.html#602">issue 602</A>.)</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 14.6.1 [temp.local] paragraphs 1-5 as follows:</P>

<BLOCKQUOTE>

<P>Like normal (non-template) classes, class templates have an
injected-class-name (Clause 9 [class]).  The
injected-class-name can be used <SPAN style="text-decoration:line-through;background-color:#FFA0A0">with or without a
<I>template-argument-list</I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">as a <I>template-name</I>
or a <I>type-name</I></SPAN>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">When it is used without a
<I>template-argument-list</I>, it is equivalent to the
injected-class-name followed by the <I>template-parameter</I>s of the
class template enclosed in <TT>&lt;&gt;</TT>.</SPAN> When it is used
with a <I>template-argument-list</I>, <SPAN style="font-weight:bold;background-color:#A0FFA0">as a
<I>template-argument</I> for a template <I>template-parameter</I>, or
as the final identifier in the <I>elaborated-type-specifier</I> of a
friend class template declaration</SPAN> it refers to the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">specified
class template specialization, which could be the current
specialization or another specialization.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">class template
itself.  Otherwise, it is equivalent to the <I>template-name</I>
followed by the <I>template-parameter</I>s of the class template
enclosed in <TT>&lt;&gt;</TT>.</SPAN></P>

<P>Within the scope of a class template specialization or partial
specialization, when the injected-class-name is not <SPAN style="text-decoration:line-through;background-color:#FFA0A0">followed by a
<TT>&lt;</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">used as a <I>type-name</I></SPAN>, it is
equivalent to the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">injected-class-name</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>template-name</I></SPAN> followed by the
<I>template-argument</I>s of the class template specialization or
partial specialization enclosed in
<TT>&lt;&gt;</TT>. [<I>Example:</I></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template&lt;template&lt;class&gt; class T&gt; class A { };</SPAN>
  template&lt;class T&gt; class Y;
  template&lt;&gt; class Y&lt;int&gt; {
    Y* p;           //<SPAN style="font-family:Times;font-style:italic"> meaning </SPAN>Y&lt;int&gt;
    Y&lt;char&gt;* q;     //<SPAN style="font-family:Times;font-style:italic"> meaning </SPAN>Y&lt;char&gt;
<SPAN style="font-weight:bold;background-color:#A0FFA0">    A&lt;Y&gt;* a;        //<SPAN style="font-family:Times;font-style:italic"> meaning </SPAN>A&lt;::Y&gt;
    class B {
      template&lt;class&gt; friend class Y;  //<SPAN style="font-family:Times;font-style:italic"> meaning </SPAN>::Y
    };</SPAN>
  };
</PRE>

<P>&#8212;<I>end example</I>]</P>

<P>The injected-class-name of a class template or class template
specialization can be used either <SPAN style="text-decoration:line-through;background-color:#FFA0A0">with or without a
<I>template-argument-list</I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">as a <I>template-name</I> or
a <I>type-name</I></SPAN> wherever it is in scope. [<I>Example:</I></P>

<PRE>
  template &lt;class T&gt; struct Base {
    Base* p;
  };

  template &lt;class T&gt; struct Derived: public Base&lt;T&gt; {
    typename Derived::Base* p;    //<SPAN style="font-family:Times;font-style:italic"> meaning </SPAN>Derived::Base&lt;T&gt;
  };

<SPAN style="font-weight:bold;background-color:#A0FFA0">  template&lt;class T, template&lt;class&gt; class U = T::template Base&gt; struct Third { };
  Third&lt;Base&lt;int&gt;&gt; t; //<SPAN style="font-family:Times;font-style:italic"> OK, default argument uses injected-class-name as a template</SPAN></SPAN>
</PRE>

<P>&#8212;<I>end example</I>]</P>

<P>A lookup that finds an injected-class-name (10.2 [class.member.lookup]) can result in an ambiguity in certain cases (for
example, if it is found in more than one base class). If all of the
injected-class-names that are found refer to specializations of the
same class template, and if the name is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">followed by a
<I>template-argument-list</I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">used as a
<I>template-name</I></SPAN>, the reference refers to the class template
itself and not a specialization thereof, and is not
ambiguous. [<I>Example:</I></P>

<PRE>
  template &lt;class T&gt; struct Base { };
  template &lt;class T&gt; struct Derived: Base&lt;int&gt;, Base&lt;char&gt; {
    typename Derived::Base b;             //<SPAN style="font-family:Times;font-style:italic"> error: ambiguous</SPAN>
    typename Derived::Base&lt;double&gt; d;     //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
  };
</PRE>

<P>&#8212;<I>end example</I>]</P>

<P>When the normal name of the template (i.e., the name from the
enclosing scope, not the injected-class-name) is used <SPAN style="text-decoration:line-through;background-color:#FFA0A0">without a
<I>template-argument-list</I></SPAN>, it <SPAN style="font-weight:bold;background-color:#A0FFA0">always</SPAN> refers to
the class template itself and not a specialization of the
template. [<I>Example:...</I></P>

</BLOCKQUOTE>

<P>This resolution also resolves <A HREF="
     cwg_active.html#602">issue 602</A>.</P>

<BR><BR><HR><A NAME="1057"></A><H4>1057.
  
<TT>decltype</TT> and the current instantiation
</H4><B>Section: </B>14.6.2.1&#160; [temp.dep.type]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-18<BR>


<P>According to 14.6.2.1 [temp.dep.type] paragraph 3,</P>

<BLOCKQUOTE>

A template argument that is equivalent to a template parameter
(i.e., has the same constant value or the same type as the
template parameter) can be used in place of that template
parameter in a reference to the current instantiation.

</BLOCKQUOTE>

<P>This would presumably include something like</P>

<PRE>
    template&lt;typename T&gt; struct A {
        struct B { };
        A&lt;decltype(T())&gt;::B b;    // no typename
    };
</PRE>

<P>However, this example is rejected by current implementations.
Does this need to be clarified in the existing wording?</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The example is not well-formed; if <TT>T</TT> is an rvalue reference
type, for example, <TT>decltype(T())</TT> is not equivalent to
<TT>T</TT>.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1056">issue 1056</A>.</P>

<BR><BR><HR><A NAME="1074"></A><H4>1074.
  
Value-dependent <I>noexcept-expression</I>s
</H4><B>Section: </B>14.6.2.3&#160; [temp.dep.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-04<BR>




<P>It is not clear why a <I>noexcept-expression</I> is value-dependent
if its operand is value-dependent.  It would seem that the value of the
expression depends only on the type of the operand, not its value.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Delete &#8220;<TT>noexcept(</TT> <I>expression</I> <TT>)</TT>&#8221;
from the list in 14.6.2.3 [temp.dep.constexpr] paragraph 3.</P>

<BR><BR><HR><A NAME="1088"></A><H4>1088.
  
Dependent non-type template arguments
</H4><B>Section: </B>14.6.2.3&#160; [temp.dep.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-28<BR>




<P>Given</P>

<PRE>
    template &lt;const char *N&gt; struct A { static const char *p; };
    template &lt;class T&gt;
       struct B { static const char c[1]; typedef A&lt;B&lt;T&gt;::c&gt; C; };
    template &lt;class T&gt;
       struct D { static const char c[1]; typedef A&lt;c&gt; C; };
</PRE>

<P>14.6.2.4 [temp.dep.temp] says that <TT>B&lt;T&gt;::c</TT> is
dependent because it is used as a non-integral non-type template
argument and it is a <I>qualified-id</I> with a
<I>nested-name-specifier</I> that names a dependent type.</P>

<P>There doesn't seem to be anything to say that <TT>c</TT> in the
definition of <TT>D&lt;T&gt;::C</TT> is dependent, which suggests that
<TT>D&lt;T&gt;::C</TT> is the same type for all <TT>T</TT>, which is
clearly false.</P>

<P>Instead of this special rule in 14.6.2.4 [temp.dep.temp],
14.6.2.3 [temp.dep.constexpr] should say that the address of a member
of a dependent type is value-dependent, regardless of whether the
address is written with a <I>qualified-id</I>.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<OL><LI><P>Add a new paragraph at the end of
14.6.2.3 [temp.dep.constexpr]:</P></LI>

<BLOCKQUOTE>

<SPAN style="font-weight:bold;background-color:#A0FFA0">An <I>id-expression</I> is value-dependent if it names a member
of an unknown specialization.</SPAN>

</BLOCKQUOTE>

<LI><P>Change 14.6.2.4 [temp.dep.temp] paragraphs 2-3 as follows:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">An integral</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A</SPAN> non-type
<I>template-argument</I> is dependent if <SPAN style="font-weight:bold;background-color:#A0FFA0">its type is dependent
or</SPAN> the constant expression it specifies is value-dependent.</P>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A non-integral</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Furthermore, a</SPAN> non-type
<I>template-argument</I> is dependent if <SPAN style="text-decoration:line-through;background-color:#FFA0A0">its type is dependent or it
has either of the following forms</SPAN></P>

<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>qualified-id</I></SPAN></UL>
<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>&amp;</TT> <I>qualified-id</I></SPAN></UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">and contains a <I>nested-name-specifier</I> which specifies a
<I>class-name</I> that names a dependent type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the
corresponding non-type <I>template-parameter</I> is of reference or
pointer type and the <I>template-argument</I> designates or points to
a member of the current instantiation or a member of a dependent
type</SPAN>.</P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1196"></A><H4>1196.
  
Definition required for explicit instantiation after explicit specialization?
</H4><B>Section: </B>14.7.2&#160; [temp.explicit]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-08<BR>


<P>According to 14.7.2 [temp.explicit] paragraph 4,</P>

<BLOCKQUOTE>

For a given set of template parameters, if an explicit instantiation
of a template appears after a declaration of an explicit
specialization for that template, the explicit instantiation has no
effect.

</BLOCKQUOTE>

<P>However, that does not appear to negate the requirements of paragraph
3 that a definition of the entity being instantiated must be in scope.
Consequently, the following would appear to be ill-formed, even though
there is no real need for the definition of <TT>C</TT>:</P>

<PRE>
    template&lt;typename T&gt; class C;
    template&lt;&gt; class C&lt;int&gt; { };
    template class C&lt;int&gt;;
</PRE>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 14.7.2 [temp.explicit] paragraphs 3-4 as follows:</P>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A declaration of a function template shall be in scope at the
point of the explicit instantiation of the function template. A
definition of the class or class template containing a member function
template shall be in scope at the point of the explicit instantiation
of the member function template. A definition of a class template or
class member template shall be in scope at the point of the explicit
instantiation of the class template or class member template.  A
definition of a class template shall be in scope at the point of an
explicit instantiation of a member function or a static data member of
the class template. A definition of a member class of a class template
shall be in scope at the point of an explicit instantiation of the
member class.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A declaration of a function template, a
member function or static data member of a class template, or a member
function template of a class or class template shall precede an
explicit instantiation of that entity. A definition of a class
template, a member class of a class template, or a member class
template of a class or class template shall precede an explicit
instantiation of that entity, unless the explicit instantiation is
preceded by an explicit specialization of the entity with the same
template arguments.</SPAN> If the declaration of the explicit
instantiation names an implicitly-declared special member function
(Clause 12 [special]), the program is ill-formed.</P>

<P>For a given set of template <SPAN style="text-decoration:line-through;background-color:#FFA0A0">parameters</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">arguments</SPAN>, if an explicit instantiation of a template
appears after a declaration of an explicit specialization for that
template, the explicit instantiation has no effect.  Otherwise...</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="531"></A><H4>531.
  
Defining members of explicit specializations
</H4><B>Section: </B>14.7.3&#160; [temp.expl.spec]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>1 October 2005<BR>


<P>The Standard does not fully describe the syntax to be used when a
member of an explicitly-specialized member class or member class
template is defined in namespace scope.  14.7.3 [temp.expl.spec]
paragraph 4 says that the &#8220;explicit specialization syntax&#8221;
(presumably referring to &#8220;<TT>template&lt;&gt;</TT>&#8221;) is
not used in defining a member of an explicit specialization when a
class template is explicitly specialized as a class.  However, nothing
is said anywhere about how to define a member of a specialization
when:</P>

<OL><LI><P>the entity being specialized is a class (member of a
template class) rather than a class template.</P></LI>

<LI><P>the result of the specialization is a class template rather
than a class (cf 14.7.3 [temp.expl.spec] paragraph 18, which
describes this case as a &#8220;member template that...
remain[s] unspecialized&#8221;).</P></LI>
</OL>

<P>(See paper J16/05-0148 = WG21 N1888 for further details, including
a survey of existing implementation practice.)</P>

<P><B>Notes from the October, 2005 meeting:</B></P>

<P>The CWG felt that the best approach, balancing consistency with
implementation issues and existing practice, would be to require that
<TT>template&lt;&gt;</TT> be used when defining members of all
explicit specializations, including those currently covered by
14.7.3 [temp.expl.spec] paragraph 4.</P>

<P><B>Proposed resolution (February, 2010):</B></P>

<P>Change 14.7.3 [temp.expl.spec] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<P>...The definition of an explicitly specialized class is
unrelated to the definition of a generated specialization. That
is, its members need not have the same names, types, etc. as the
members of a generated specialization. Definitions of members of
an explicitly specialized class are defined <SPAN style="text-decoration:line-through;background-color:#FFA0A0">in the same
manner as members of normal classes, and not using the syntax for
explicit specialization</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">using the same
<TT>template&lt;&gt;</TT> prefix(es) as the explicitly
specialized class</SPAN>. [<I>Example:</I></P>

<PRE>
    template&lt;class T&gt; struct A {
      void f(T) { /* ... */ }
<SPAN style="font-weight:bold;background-color:#A0FFA0">      struct B { /* ... */ };
      template&lt;class U&gt; struct C { /* ... */ };</SPAN>
    };
    template&lt;&gt; struct A&lt;int&gt; {
      void f(int);
<SPAN style="font-weight:bold;background-color:#A0FFA0">      struct B;
      template&lt;class U&gt; struct C;</SPAN>
    };
    void h() {
      A&lt;int&gt; a;
      a.f(16); // A&lt;int&gt;::f <SPAN style="font-family:Times;font-style:italic">must be defined somewhere</SPAN>
    }
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">    //<SPAN style="font-family:Times;font-style:italic"> explicit specialization syntax not used for a member of</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> explicitly specialized class template specialization</SPAN></SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">    //<SPAN style="font-family:Times;font-style:italic"> members of explicitly specialized classes are defined using</SPAN>
    //<SPAN style="font-family:Times;font-style:italic">the same syntax as the explicitly specialized class:</SPAN></SPAN>
    <SPAN style="font-weight:bold;background-color:#A0FFA0">template&lt;&gt; </SPAN>void A&lt;int&gt;::f(int) { /* ... */ }
<SPAN style="font-weight:bold;background-color:#A0FFA0">    template&lt;&gt; struct A&lt;int&gt;::B { /* ... */ };
    template&lt;&gt; template&lt;class T&gt; struct A&lt;int&gt;::C { /* ... */ };</SPAN>
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<P><B>Note (June, 2010):</B></P>

<P>Because the survey of implementations on which the CWG relied in
reaching this resolution is quite old, a new survey of current
practice is needed.</P>

<BR><BR><HR><A NAME="1178"></A><H4>1178.
  
Deduction failure matching placement new
</H4><B>Section: </B>14.8.2.6&#160; [temp.deduct.decl]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-19<BR>


<P>The new wording added by <A HREF="
     cwg_defects.html#873">issue 873</A> says,</P>

<BLOCKQUOTE>

...This is also done to determine whether a function template
specialization matches a placement <TT>operator new</TT> (3.7.4.2 [basic.stc.dynamic.deallocation], 5.3.4 [expr.new])... If, for the set of
function templates so considered, there is either no match or more
than one match after partial ordering has been considered
(14.5.6.2 [temp.func.order]), deduction fails and the declaration
is ill-formed.

</BLOCKQUOTE>

<P>The statement describing the consequence of deduction failure
(&#8220;the declaration is ill-formed&#8221;) does not apply to
the case when deduction is being performed for placement
<TT>operator delete</TT>, as there is no declaration involved.
It may not be necessary to describe what happens when deduction
fails in that case, but at least the wording should be tweaked to
limit the conclusion to declarative contexts.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 14.8.2.6 [temp.deduct.decl] paragraphs 1-2 as follows:</P>

<BLOCKQUOTE>

<P>In a declaration whose <I>declarator-id</I> refers to a
specialization of a function template, template argument deduction is
performed to identify the specialization to which the declaration
refers. Specifically, this is done for explicit instantiations
(14.7.2 [temp.explicit]), explicit specializations (14.7.3 [temp.expl.spec]), and certain friend declarations (14.5.4 [temp.friend]).  This is also done to determine whether a
<SPAN style="font-weight:bold;background-color:#A0FFA0">deallocation</SPAN> function template specialization matches a
placement <TT>operator new</TT> (3.7.4.2 [basic.stc.dynamic.deallocation],
5.3.4 [expr.new]).  In all these cases, <TT>P</TT> is the
type of the function template being considered as a potential match
and <TT>A</TT> is <SPAN style="font-weight:bold;background-color:#A0FFA0">either</SPAN> the function type from the
declaration <SPAN style="font-weight:bold;background-color:#A0FFA0">or the type of the deallocation function that would
match the placement <TT>operator new</TT> as described in 5.3.4 [expr.new]</SPAN>. The deduction is done as described in
14.8.2.5 [temp.deduct.type].</P>

<P>If, for the set of function templates so considered, there is
either no match or more than one match after partial ordering has been
considered (14.5.6.2 [temp.func.order]), deduction fails and<SPAN style="font-weight:bold;background-color:#A0FFA0">,
in the declaration cases,</SPAN> the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">declaration</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">program</SPAN> is ill-formed.</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="388"></A><H4>388.
  
Catching base<TT>*&amp;</TT> from a throw of derived<TT>*</TT>
</H4><B>Section: </B>15.3&#160; [except.handle]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>28 Oct 2002<BR>




<P>I have a question about exception handling with respect to derived to base
conversions of pointers caught by reference.</P>

<P>What should the result of this program be?</P>
<PRE>
  struct S             {};
  struct SS : public S {};

  int main()
  {
  	SS ss;
  	int result = 0;
  	try
  	{
  		throw &amp;ss; // throw object has type SS*
  		           // (pointer to derived class)
  	}
  	catch (S*&amp; rs) // (reference to pointer to base class)
  	{
  		result = 1;
  	}
  	catch (...)
  	{
  		result = 2;
  	}
  	return result;
  }
</PRE>

<P>The wording of 15.3 [except.handle] paragraph 3
would seem to say that the catch of S*&amp; does not
match and so the catch ... would be taken.</P>

<P>All of the compilers I tried (EDG, g++, Sun, and Microsoft) used the catch
of S*&amp; though.</P>

<P>What do we think is the desired behavior for such cases?</P>

<P>My initial reaction is that this is a bug in all of these compilers, but
the fact that they all do the same thing gives me pause.</P>

<P>On a related front, if the handler changes the parameter using the
reference, what is caught by a subsequent handler?</P>
<PRE>
  extern "C" int printf(const char *, ...);
  struct S             {};
  struct SS : public S {};
  SS ss;

  int f()
  {
  	try
  	{
  		throw &amp;ss;
  	}
  	catch (S*&amp; rs) // (reference to pointer to base class)
  	{
  		rs = 0;
  		throw;
  	}
  	catch (...)
  	{
  	}
  	return 0;
  }

  int main()
  {
  	try { f(); }
  	catch (S*&amp; rs) {
  		printf("rs=%p, &amp;ss=%p\n", rs, &amp;ss);
  	}
  }
</PRE>

<P>EDG, g++, and Sun all catch the original (unmodified) value.  Microsoft
catches the modified value.  In some sense the EDG/g++/Sun behavior makes
sense because the later catch could catch the derived class instead of the
base class, which would be difficult to do if you let the catch clause
update the value to be used by a subsequent catch.</P>

<P>But on this non-pointer case, all of the compilers later catch the
modified value:</P>
<PRE>
  extern "C" int printf(const char *, ...);
  int f()
  {
  	try
  	{
  		throw 1;
  	}
  	catch (int&amp; i)
  	{
  		i = 0;
  		throw;
  	}
  	catch (...)
  	{
  	}
  	return 0;
  }

  int main()
  {
  	try { f(); }
  	catch (int&amp; i) {
  		printf("i=%p\n", i);
  	}
  }
</PRE>

<P>To summarize:</P>
<OL>
<LI>Should "base*const&amp;" be able to catch a "derived*"? 
The current standard
seems to say "no" but parallels to how calls work, and existing practice,
suggest that the answer should be "yes".</LI>

<LI>Should "base*&amp;" be able to catch a "derived*".  Again,
the standard seems
seems to say "no".  Parallels to how calls work still suggest "no", but
existing practice suggests "yes".</LI>

<LI>If either of the above is "yes", what happens if you modify the pointer
referred to by the reference.  This requires a cast to remove const for
case #2.</LI>

<LI>On a related front, if you catch
"derived*&amp;" when a "derived*" is thrown,
what happens if you modify the pointer referred to by the reference?
EDG/g++/Sun still don't modify the underlying value that would be
caught by a rethrow in this case.  This case seems like it should be
the same as the "int&amp;" example above, but is not on the three compilers
mentioned.</LI>
</OL>

<P>(See also <A HREF="
     cwg_active.html#729">issue 729</A>.)</P>



<P><B>Notes from the October, 2009 meeting:</B></P>

<P>The consensus of the CWG was that it should not be possible to catch
a pointer to a derived class using a reference to a base class pointer,
and that a handler that takes a reference to non-const pointer should
allow the pointer to be modified by the handler.</P>

<P><B>Proposed resolution (February, 2010):</B></P>

<P>Change 15.3 [except.handle] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<P>A <I>handler</I> is a match for an exception object of type
<TT>E</TT> if</P>

<UL><LI><P>The <I>handler</I> is of type <I>cv</I> <TT>T</TT> or
<I>cv</I> <TT>T&amp;</TT> and <TT>E</TT> and <TT>T</TT> are the
same type (ignoring the top-level <I>cv-qualifier</I>s), or</P></LI>

<LI><P>the <I>handler</I> is of type <I>cv</I> <TT>T</TT> or
<I>cv</I> <TT>T&amp;</TT> and <TT>T</TT> is an unambiguous public
base class of <TT>E</TT>, or</P></LI>

<LI><P>the <I>handler</I> is of type <I>cv1</I> <TT>T<SPAN style="text-decoration:line-through;background-color:#FFA0A0">*</SPAN></TT><SPAN style="text-decoration:line-through;background-color:#FFA0A0">
<I>cv2</I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">or <TT>const T&amp;</TT> where <TT>T</TT>
is a pointer type</SPAN> and <TT>E</TT> is a pointer type that can
be converted to <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the type of the handler</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>T</TT></SPAN> by either or both of</P></LI>

<UL><LI><P>a standard pointer conversion (4.10 [conv.ptr]) not involving conversions to pointers to private or
protected or ambiguous classes</P></LI>

<LI><P>a qualification conversion</P></LI>

</UL>

<LI><P>the <I>handler</I> is <SPAN style="font-weight:bold;background-color:#A0FFA0">of type <I>cv</I> <TT>T</TT> or <TT>const T&amp;</TT> where <TT>T</TT> is</SPAN> a pointer or pointer to member type
and <TT>E</TT> is <TT>std::nullptr_t</TT>.</P></LI>

</UL>

</BLOCKQUOTE>

<P>(This resolution also resolves <A HREF="
     cwg_active.html#729">issue 729</A>.)</P>

<BR><BR><HR><A NAME="729"></A><H4>729.
  
Qualification conversions and handlers of reference-to-pointer type
</H4><B>Section: </B>15.3&#160; [except.handle]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>6 October, 2008<BR>


<P>Given the following example:</P>

<PRE>
    int f() {
        try { /* ... */ }
        catch(const int*&amp;) {
            return 1;
        }
        catch(int*&amp;) {
            return 2;
        }
        return 3;
    }
</PRE>

<P>can <TT>f()</TT> return <TT>2</TT>?  That is, does an
<TT>int*</TT> exception object match a <TT>const int*&amp;</TT>
handler?</P>

<P>According to 15.3 [except.handle] paragraph 3, it does not:</P>

<BLOCKQUOTE>

<P>A <I>handler</I> is a match for an exception object of type
<TT>E</TT> if</P>

<UL>
<LI><P>The <I>handler</I> is of type <I>cv</I> <TT>T</TT> or <I>cv</I>
<TT>T&amp;</TT> and <TT>E</TT> and <TT>T</TT> are the same type
(ignoring the top-level <I>cv-qualifier</I>s), or</P></LI>

<LI><P>the <I>handler</I> is of type <I>cv</I> <TT>T</TT> or <I>cv</I>
<TT>T&amp;</TT> and <TT>T</TT> is an unambiguous public base class of
<TT>E</TT>, or</P></LI>

<LI><P>the handler is of type <I>cv1</I> <TT>T*</TT> <I>cv2</I> and
<TT>E</TT> is a pointer type that can be converted to the type of the
handler by either or both of</P>

<UL>
<LI><P>a standard pointer conversion (4.10 [conv.ptr]) not
involving conversions to pointers to private or protected or ambiguous
classes</P></LI>

<LI><P>a qualification conversion</P></LI>
</UL></LI>

<LI><P>the <I>handler</I> is a pointer or pointer to member type and
<TT>E</TT> is <TT>std::nullptr_t</TT>.</P></LI>

</UL>

</BLOCKQUOTE>

<P>Only the third bullet allows qualification conversions, but
only the first bullet applies to a <I>handler</I> of
reference-to-pointer type.  This is consistent with how other
reference bindings work; for example, the following is ill-formed:</P>

<PRE>
    int* p;
    const int*&amp; r = p;
</PRE>

<P>(The consistency is not complete; the reference binding would be
permitted if <TT>r</TT> had type <TT>const int* const &amp;</TT>, but
a handler of that type would still not match an <TT>int*</TT>
exception object.)</P>

<P>However, implementation practice seems to be in the other
direction; both EDG and g++ do match an <TT>int*</TT> with a <TT>const
int*&amp;</TT>, and the Microsoft compiler issues an error for the
presumed hidden handler in the code above. Should the Standard be
changed to reflect existing practice?</P>

<P>(See also <A HREF="
     cwg_active.html#388">issue 388</A>.)</P>



<P><B>Notes from the October, 2009 meeting:</B></P>

<P>The CWG agreed that matching the exception object with a handler
should, to the extent possible, mimic ordinary reference binding in
cases like this.</P>

<P><B>Proposed resolution (February, 2010):</B></P>

<P>This issue is resolved by the resolution of <A HREF="
     cwg_active.html#388">issue 388</A>.</P>

<BR><BR><HR><A NAME="1216"></A><H4>1216.
  
Exceptions &#8220;allowed&#8221; by a <I>noexcept-specification</I>
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Jens Maurer
 &#160;&#160;&#160;

 <B>Date: </B>2010-11-02<BR>




<P>According to 15.4 [except.spec] paragraph2 8 and 9,</P>

<BLOCKQUOTE>

<P>A function is said to <I>allow</I> an exception of type <TT>E</TT>
if its <I>dynamic-exception-specification</I> contains a type
<TT>T</TT> for which a handler of type <TT>T</TT> would be a match
(15.3 [except.handle]) for an exception of type <TT>E</TT>.</P>

<P>Whenever an exception is thrown and the search for a handler
(15.3 [except.handle]) encounters the outermost block of a
function with an <I>exception-specification</I> that does not allow
the exception, then,</P>

<UL><LI><P>if the <I>exception-specification</I> is a
<I>dynamic-exception-specification</I>, the function
<TT>std::unexpected()</TT> is called (15.5.2 [except.unexpected]),</P></LI>

<LI><P>otherwise, the function <TT>std::terminate()</TT> is called
(15.5.1 [except.terminate]).</P></LI>

</UL>

</BLOCKQUOTE>

<P>This does not define what it means for a <I>noexcept-specification</I>
to allow an exception.</P>

<P><B>Proposed resolution (November, 2010):</B></P>

<P>Change 15.4 [except.spec] paragraph 8 as follows:</P>

<BLOCKQUOTE>

A function is said to <I>allow</I> an exception of type <TT>E</TT> if
<SPAN style="font-weight:bold;background-color:#A0FFA0">the <I>constant-expression</I> in its
<I>noexcept-specification</I> evaluates to <TT>false</TT> or</SPAN> its
<I>dynamic-exception-specification</I> contains a type <TT>T</TT> for
which a handler of type <TT>T</TT> would be a match (15.3 [except.handle]) for an exception of type <TT>E</TT>.

</BLOCKQUOTE>

<BR><BR><BR><BR><HR><A NAME="Drafting Status"></A><H3>Issues with "Drafting" Status</H3>
<HR><A NAME="369"></A><H4>369.
  
Are <TT>new</TT>/<TT>delete</TT> identifiers or <I>preprocessing-op-or-punc</I>?
</H4><B>Section: </B>2.5&#160; [lex.pptoken]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin v. Loewis
 &#160;&#160;&#160;

 <B>Date: </B>30 July 2002<BR>


<P>2.5 [lex.pptoken] paragraph 2 specifies that there are 5
categories of tokens in phases 3 to 6. With 2.13 [lex.operators]
paragraph 1, it is unclear whether <TT>new</TT> is an <I>identifier</I> or a
<I>preprocessing-op-or-punc</I>; likewise for <TT>delete</TT>. This is
relevant to answer the question whether</P>
<PRE>
#define delete foo
</PRE>
<P>is a well-formed control-line, since that requires an identifier 
after the <TT>define</TT> token.</P>

<P>(See also <A HREF="
     cwg_active.html#189">issue 189</A>.)</P>

<BR><BR><HR><A NAME="189"></A><H4>189.
  
Definition of <I>operator</I> and <I>punctuator</I>
</H4><B>Section: </B>2.13&#160; [lex.operators]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>20 Dec 1999<BR>





<P>The nonterminals <I>operator</I> and <I>punctuator</I> in
2.7 [lex.token]
 are not defined.  There is
a definition of the nonterminal <I>operator</I> in
13.5 [over.oper]
 paragraph 1, but it is
apparent that the two nonterminals are not the same: the latter
includes keywords and multi-token operators and does not include the
nonoverloadable operators mentioned in paragraph 3.</P>

<P>There is a definition of <I>preprocessing-op-or-punc</I> in
2.13 [lex.operators]
, with the notation that</P>

<BLOCKQUOTE>
Each <I>preprocessing-op-or-punc</I> is converted to a single token in
translation phase 7 (2.1).
</BLOCKQUOTE>

However, this list doesn't distinguish between <I>operator</I>s and
<I>punctuator</I>s, it includes digraphs and keywords (can a given
<I>token</I> be both a <I>keyword</I> and an <I>operator</I> at the
same time?), etc.

<P><B>Suggested resolution:</B></P>

<BR><OL>
<LI>Change 13.5 [over.oper]
 to use the term
<I>overloadable-operator</I>.</LI>

<LI>Change 2.7 [lex.token]
 to use the term
<I>operator-token</I> instead of <I>operator</I> (since there are
operators that are keywords and operators that are composed of more
than one token).</LI>

<LI>Change 2.13 [lex.operators]
 to define
the nonterminals <I>operator-token</I> and <I>punctuator</I>.</LI>
</OL>

<P><B>Additional note (April, 2005):</B></P>

<P>The resolution for this problem should also address the fact that
<TT>sizeof</TT> and <TT>typeid</TT> (and potentially others like
<TT>decltype</TT> that may be added in the future) are described in
some places as &#8220;operators&#8221; but are not listed in
13.5 [over.oper] paragraph 3 among the operators that cannot be
overloaded.</P>

<P>(See also <A HREF="
     cwg_active.html#369">issue 369</A>.)</P>
<BR><BR><HR><A NAME="1210"></A><H4>1210.
  
Injection of <I>elaborated-type-specifier</I> in enumeration scope
</H4><B>Section: </B>3.3.2&#160; [basic.scope.pdecl]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-13<BR>


<P>According to 3.3.2 [basic.scope.pdecl] paragraph 6,</P>

<BLOCKQUOTE>

<P>for an elaborated-type-specifier of the form</P>

<UL><I>class-key identifier</I></UL>

<P>if the <I>elaborated-type-specifier</I> is used in the
<I>decl-specifier-seq</I> or <I>parameter-declaration-clause</I> of a
function defined in namespace scope, the <I>identifier</I> is declared
as a <I>class-name</I> in the namespace that contains the declaration;
otherwise, except as a friend declaration, the <I>identifier</I> is
declared in the smallest non-class, non-function-prototype scope that
contains the declaration.</P>

</BLOCKQUOTE>

<P>This should have been, but was not, updated when enumeration
scope (3.3.8 [basic.scope.enum]) was added:</P>

<PRE>
    enum class E {
        e = sizeof((struct S*)0)
    };
</PRE>

<P>Presumably the name <TT>S</TT> belongs to the same scope as
<TT>E</TT>, not the enumeration scope of <TT>E</TT>.</P>

<BR><BR><HR><A NAME="225"></A><H4>225.
  
Koenig lookup and fundamental types
</H4><B>Section: </B>3.4.2&#160; [basic.lookup.argdep]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Derek Inglis
 &#160;&#160;&#160;

 <B>Date: </B>26 Jan 2000<BR>


<P>In discussing <A HREF="
     cwg_defects.html#197">issue 197</A>, the question
arose as to whether the handling of fundamental types in
argument-dependent lookup is actually what is desired.  This question
needs further discussion.</P>
<BR><BR><HR><A NAME="156"></A><H4>156.
  
Name lookup for conversion functions
</H4><B>Section: </B>3.4.5&#160; [basic.lookup.classref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Derek Inglis
 &#160;&#160;&#160;

 <B>Date: </B>18 Aug 1999<BR>





<P>Paragraph 7 of
3.4.5 [basic.lookup.classref]
 says,</P>

<BLOCKQUOTE>
If the <I>id-expression</I> is a <I>conversion-function-id</I>, its
<I>conversion-type-id</I> shall denote the same
type in both the context in which the
entire <I>postfix-expression</I> occurs
and in the context of the class of the object
expression (or the class pointed to by the pointer expression).
</BLOCKQUOTE>

Does this mean that the following example is ill-formed?

<PRE>
    struct A { operator int(); } a;
    void foo() {
      typedef int T;
      a.operator T(); // 1) error T is not found in the context
		      // of the class of the object expression?
    }
</PRE>

The second bullet in paragraph 1 of 
3.4.3.1 [class.qual]
 says,

<BLOCKQUOTE>
a <I>conversion-type-id</I> of an
<I>operator-function-id</I> is looked up both
in the scope of the class and in the
context in which the entire <I>postfix-expression</I>
occurs and shall refer to the
same type in both contexts
</BLOCKQUOTE>

How about:

<PRE>
    struct A { typedef int T; operator T(); };
    struct B : A { operator T(); } b;
    void foo() {
      b.A::operator T(); // 2) error T is not found in the context
			 // of the postfix-expression?
    }
</PRE>

Is this interpretation correct?  Or was the intent for
this to be an error only if
<TT>T</TT> was found in both scopes and referred to different entities?

<P>If the intent was for these to be errors,
how do these rules apply to template
arguments?</P>

<PRE>
    template &lt;class T1&gt; struct A { operator T1(); }
    template &lt;class T2&gt; struct B : A&lt;T2&gt; {
      operator T2();
      void foo() {
	T2 a = A&lt;T2&gt;::operator T2(); // 3) error? when instantiated T2 is not
				     // found in the scope of the class
	T2 b = ((A&lt;T2&gt;*)this)-&gt;operator T2(); // 4) error when instantiated?
      }
    }
</PRE>

<P>(Note bullets 2 and 3 in paragraph 1 of
3.4.3.1 [class.qual]
 refer to
<I>postfix-expression</I>.  It would be better to use
<I>qualified-id</I> in both cases.)</P>

<P><U>Erwin Unruh</U>:
The intent was that you look in both contexts. If you find it only once,
that's the symbol. If you find it in both, both symbols must be "the same"
in some respect. (If you don't find it, its an error).</P>

<P><U>Mike Miller</U>:
What's not clear to me in these examples is whether what is
being looked up is <TT>T</TT> or <TT>int</TT>.
Clearly the <TT>T</TT> has to be
looked up somehow, but the "name" of a conversion function
clearly involves the base (non-typedefed) type, not typedefs
that might be used in a definition or reference (cf
3 [basic]
 paragraph 7 and
12.3 [class.conv]
 paragraph 5).
(This is true even for types that must be written
using typedefs because of the limited syntax in
<I>conversion-type-id</I>s &#8212; e.g., the "name" of the conversion
function in the following example</P>

<PRE>
    typedef void (*pf)();
    struct S {
	operator pf();
    };
</PRE>

is <TT>S::operator void(*)()</TT>, even though you can't write its name
directly.)

<P>My guess is that this means that in each scope you look up
the type named in the reference and form the canonical
operator name; if the name used in the reference isn't found
in one or the other scope, the canonical name constructed
from the other scope is used.  These names must be identical,
and the <I>conversion-type-id</I> in the canonical operator name must
not denote different types in the two scopes (i.e., the type
might not be found in one or the other scope, but if it's found
in both, they must be the same type).</P>

<P>I think this is all very vague in the current wording.</P>
<BR><BR><HR><A NAME="682"></A><H4>682.
  
Missing description of lookup of template aliases
</H4><B>Section: </B>3.4.5&#160; [basic.lookup.classref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>1 March, 2008<BR>


<P>3.4.5 [basic.lookup.classref] does not mention template aliases as the
possible result of the lookup but should do so.</P>

<BR><BR><HR><A NAME="1089"></A><H4>1089.
  
Template parameters in member selections
</H4><B>Section: </B>3.4.5&#160; [basic.lookup.classref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-29<BR>




<P>In an example like</P>

<PRE>
    template&lt;typename T&gt; void f(T p)-&gt;decltype(p.T::x);
</PRE>

<P>The <I>nested-name-specifier</I> <TT>T::</TT> looks like it refers
to the template parameter.  However, if this is instantiated with a
type like</P>

<PRE>
    struct T { int x; };
    struct S: T { };
</PRE>

<P>the reference will be ambiguous, since it is looked up in both the
context of the expression, finding the template parameter, and in the
class, finding the base class injected-class-name, and this could be
a deduction failure.  As a result, the same declaration with a
different parameter name</P>

<PRE>
    template&lt;typename U&gt; void f(U p)-&gt;decltype(p.U::x);
</PRE>

<P>is, in fact, not a redeclaration because the two can be distinguished
by SFINAE.</P>

<P>It would be better to add a new lookup rule that says that if a
name in a template definition resolves to a template parameter, that
name is not subject to further lookup at instantiation time.</P>

<BR><BR><HR><A NAME="1220"></A><H4>1220.
  
Looking up <I>conversion-type-id</I>s
</H4><B>Section: </B>3.4.5&#160; [basic.lookup.classref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2010-11-13<BR>


<P>The resolution of <A HREF="
     cwg_active.html#1111">issue 1111</A> changes
3.4.5 [basic.lookup.classref] paragraph 7 to read,</P>

<BLOCKQUOTE>

[A] <I>conversion-type-id</I> is first looked up in the class of
the object expression and the name, if found and denotes a type,
is used.  Otherwise it is looked up in the context of the entire
<I>postfix-expression</I> and the name shall denote a type.

</BLOCKQUOTE>

<P>The result of this specification is that a non-type member
declaration in the class scope of the object expression will not
be found (although it will hide a base class type member of the
same name), but a non-type declaration in the context of the
expression will be found (and make the program ill-formed).</P>

<P>This is inconsistent with the way other lookups are handled
when they occur in a context that requires a type.  For example,
the lookup for a <I>nested-name-specifier</I> &#8220;considers
only namespaces, types, and templates whose specializations are
types&#8221; (3.4.3 [basic.lookup.qual] paragraph 1); the lookup
for a name appearing in an <I>elaborated-type-specifier</I> is
done &#8220;ignoring any non-type names that have been declared&#8221;
(3.4.4 [basic.lookup.elab] paragraph 2); and in the lookup for a name
in a <I>base-type-specifier</I>, &#8220;non-type names are
ignored&#8221; (10 [class.derived] paragraph 2). The lookup
for a <I>conversion-type-id</I> should be similar, and the wording
in 3.4.5 [basic.lookup.classref] paragraph 7 adjusted accordingly.</P>

<BR><BR><HR><A NAME="426"></A><H4>426.
  
Identically-named variables, one internally and one externally linked, allowed?
</H4><B>Section: </B>3.5&#160; [basic.link]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2 July 2003<BR>


<P>An example in
3.5 [basic.link] paragraph 6 creates two file-scope variables
with the same name,
one with internal linkage and one with external.</P>
<PRE>
  static void f();
  static int i = 0;                       //1
  void g() {
          extern void f();                // internal linkage
          int i;                          //2: i has no linkage
          {
                  extern void f();        // internal linkage
                  extern int i;           //3: external linkage
          }
  }
</PRE>
<P>Is this really what we want?
C99 has 6.2.2.7/7,
which gives undefined behavior for having an identifier appear with
internal and external linkage in the same translation unit.  C++
doesn't seem to have an equivalent.</P>

<P><B>Notes from October 2003 meeting:</B></P>

<P>We agree that this is an error.  We propose to leave the example
but change the comment to indicate that line //3 has undefined
behavior, and elsewhere add a normative rule giving such a
case undefined behavior.</P>

<P><B>Proposed resolution (October, 2005):</B></P>

<P>Change 3.5 [basic.link] paragraph 6 as indicated:</P>

<BLOCKQUOTE>

<P>...Otherwise, if no matching entity is found, the block scope entity
receives external linkage.  <SPAN style="font-weight:bold;background-color:#A0FFA0">If, within a translation unit, the same
entity is declared with both internal and external linkage, the
behavior is undefined.</SPAN></P>

<P>[<I>Example:</I></P>

<PRE>
    static void f();
    static int i = 0;            //<SPAN style="font-family:Times;font-style:italic"> 1</SPAN>
    void g () {
        extern void f ();        //<SPAN style="font-family:Times;font-style:italic"> internal linkage</SPAN>
        int i;                   //<SPAN style="font-family:Times;font-style:italic"> 2: </SPAN>i<SPAN style="font-family:Times;font-style:italic"> has no linkage</SPAN>
        {
            extern void f ();    //<SPAN style="font-family:Times;font-style:italic"> internal linkage</SPAN>
            extern int i;        //<SPAN style="font-family:Times;font-style:italic"> 3: external linkage</SPAN>
        }
    }
</PRE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">There are three objects named <TT>i</TT> in this program.  The
object with internal linkage introduced by the declaration in global
scope (line <TT>//1</TT> ), the object with automatic storage duration
and no linkage introduced by the declaration on line <TT>//2</TT>, and
the object with static storage duration and external linkage
introduced by the declaration on line <TT>//3</TT>.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Without the
declaration at line <TT>//2</TT>, the declaration at line <TT>//3</TT>
would link with the declaration at line <TT>//1</TT>.  But because the
declaration with internal linkage is hidden, <TT>//3</TT> is given
external linkage, resulting in a linkage conflict.</SPAN> &#8212;<I>end
example</I>]</P>

</BLOCKQUOTE>

<P><B>Notes frum the April 2006 meeting:</B></P>

<P>According to 3.5 [basic.link] paragraph 9, the two
variables with linkage in the proposed example are not &#8220;the
same entity&#8221; because they do not have the same linkage.  Some other
formulation will be needed to describe the relationship between those
two variables.</P>

<P><B>Notes from the October 2006 meeting:</B></P>

<P>The CWG decided that it would be better to make a program with this
kind of linkage mismatch ill-formed instead of having undefined
behavior.</P>

<BR><BR><HR><A NAME="1027"></A><H4>1027.
  
Type consistency and reallocation of scalar types
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>2010-02-03<BR>




<P>Is the following well-formed?</P>

<PRE>
    int f() {
        int i = 3;
        new (&amp;i) float(1.2);
        return i;
    }
</PRE>

<P>The wording that is intended to prevent such shenanigans,
3.8 [basic.life] paragraphs 7-9, doesn't quite apply here.
In particular, paragraph 7 reads,</P>

<BLOCKQUOTE>

<P>If, after the lifetime of an object has ended and before the
storage which the object occupied is reused or released, a new
object is created at the storage location which the original
object occupied, a pointer that pointed to the original object, a
reference that referred to the original object, or the name of
the original object will automatically refer to the new object
and, once the lifetime of the new object has started, can be used
to manipulate the new object, if:</P>

<UL><LI><P>the storage for the new object exactly overlays the
storage location which the original object occupied, and</P></LI>

<LI><P>the new object is of the same type as the original object
(ignoring the top-level cv-qualifiers), and...</P></LI>

</UL>

</BLOCKQUOTE>

<P>The problem here is that this wording only applies
&#8220;<B>after</B> the lifetime of an object has ended and
<B>before</B> the storage which the object occupied is
reused;&#8221; for an object of a scalar type, its lifetime only
ends <I>when</I> the storage is reused or released (paragraph 1),
so it appears that these restrictions cannot apply to such
objects.</P>

<P><B>Proposed resolution (August, 2010):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1116">issue 1116</A>.</P>

<BR><BR><HR><A NAME="1116"></A><H4>1116.
  
Aliasing of union members
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US27">N3092 comment
  US&#160;27<BR></A>

<P>Related to <A HREF="
     cwg_active.html#1027">issue 1027</A>, consider:</P>

<PRE>
    int f() {
      union U { double d; } u1, u2;
      (int&amp;)u1.d = 1;
      u2 = u1;
      return (int&amp;)u2.d;
    }
</PRE>

<P>Does this involve undefined behavior? 3.8 [basic.life] paragraph 4 seems to say that it's OK to clobber
<TT>u1</TT> with an <TT>int</TT> object. Then union
assignment copies the object representation, possibly
creating an <TT>int</TT> object in <TT>u2</TT> and making
the return statement well-defined. If this is well-defined,
compilers are significantly limited in the assumptions they
can make about type aliasing. On the other hand, the variant
where <TT>U</TT> has an array of <TT>unsigned char</TT>
member must be well-defined in order to support
<TT>std::aligned_storage</TT>.</P>

<P><U>Suggested resolution</U>: Clarify that this case is
undefined, but that adding an array of <TT>unsigned
char</TT> to union <TT>U</TT> would make it well-defined
&#8212; if a storage location is allocated with a particular
type, it should be undefined to create an object in that
storage if it would be undefined to access the stored value
of the object through the allocated type.</P>

<P><B>Proposed resolution (August, 2010):</B></P>

<OL><LI><P>Change 3.8 [basic.life] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>...The lifetime of an object of type <TT>T</TT> begins when
<SPAN style="font-weight:bold;background-color:#A0FFA0">storage with the proper alignment and size for type <TT>T</TT>
is obtained, and either</SPAN>:</P>

<UL><LI><SPAN style="text-decoration:line-through;background-color:#FFA0A0">storage with the proper alignment and size for type
<TT>T</TT> is obtained, and</SPAN></LI>

<LI><P>if the object has non-trivial initialization, its
initialization is complete<SPAN style="text-decoration:line-through;background-color:#FFA0A0">.</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">, or</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if <TT>T</TT> is trivially copyable, the object representation
of another <TT>T</TT> object is copied into the storage.</SPAN></P></LI>

</UL>

<P>The lifetime of an object of type <TT>T</TT> ends...</P>

</BLOCKQUOTE>

<LI><P>Change 3.8 [basic.life] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

<P>A program may end the lifetime of any object by reusing
the storage which the object occupies or by explicitly
calling the destructor for an object of a class type with a
non-trivial destructor.  For an object of a class type with
a non-trivial destructor, the program is not required to
call the destructor explicitly before the storage which the
object occupies is reused or released; however, if there is
no explicit call to the destructor or if a
<I>delete-expression</I> (5.3.5 [expr.delete]) is not
used to release the storage, the destructor shall not be
implicitly called and any program that depends on the side
effects produced by the destructor has undefined
behavior. <SPAN style="font-weight:bold;background-color:#A0FFA0">If a program obtains storage for an object of
a particular type <TT>A</TT> (e.g. with a variable definition or
<I>new-expression</I>) and later reuses that storage for an
object of another type <TT>B</TT> such that accessing the
stored value of the <TT>B</TT> object through a glvalue of
type <TT>A</TT> would have undefined behavior (3.10 [basic.lval]), the behavior is undefined. [<I>Example:</I>
</SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  int i;
  (double&amp;)i = 1.0; //<SPAN style="font-family:Times;font-style:italic"> undefined behavior</SPAN>

  struct S { unsigned char alignas(double) ar[sizeof (double)]; } s;
  (double&amp;)s = 1.0; //<SPAN style="font-family:Times;font-style:italic"> OK, can access stored </SPAN>double<SPAN style="font-family:Times;font-style:italic"> through </SPAN>s<SPAN style="font-family:Times;font-style:italic"> because it has an </SPAN>unsigned char<SPAN style="font-family:Times;font-style:italic"> subobject</SPAN></SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

<LI><P>Change 3.10 [basic.lval] paragraph 10 as follows:</P></LI>

<BLOCKQUOTE>

If a program attempts to access the stored value of an
object through a glvalue of other than one of the following
types the behavior is undefined<SUP>52</SUP><SPAN style="font-weight:bold;background-color:#A0FFA0">:</SPAN>

<UL><LI><P>the dynamic type of the object,</P></LI>

<LI><P>a cv-qualified version of the dynamic type of the
object,</P></LI>

<LI><P>a type similar (as defined in 4.4 [conv.qual]) to the dynamic type of the object,</P></LI>

<LI><P>a type that is the signed or unsigned type
corresponding to the dynamic type of the object,</P></LI>

<LI><P>a type that is the signed or unsigned type
corresponding to a cv-qualified version of the dynamic type
of the object,</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">a <TT>char</TT> or <TT>unsigned char</TT> type,</SPAN></P></LI>

<LI><P>an aggregate or union type that includes one of the
aforementioned types among its elements<SPAN style="font-weight:bold;background-color:#A0FFA0">, bases,</SPAN>
or non-static data members (including, recursively, an
element<SPAN style="font-weight:bold;background-color:#A0FFA0">, base,</SPAN> or non-static data member of a
subaggregate<SPAN style="font-weight:bold;background-color:#A0FFA0">, base,</SPAN> or contained
union)<SPAN style="text-decoration:line-through;background-color:#FFA0A0">,</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">.</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a type that is a (possibly cv-qualified) base class
type of the dynamic type of the object,</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a <TT>char</TT> or <TT>unsigned char</TT> type.</SPAN></P></LI>

</UL>

</BLOCKQUOTE>

</OL>

<P>This resolution also resolves <A HREF="
     cwg_active.html#1027">issue 1027</A>.</P>

<BR><BR><HR><A NAME="1059"></A><H4>1059.
  
Cv-qualified array types (with rvalues)
</H4><B>Section: </B>3.9.3&#160; [basic.type.qualifier]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-20<BR>


<P>In spite of the resolution of <A HREF="
     cwg_defects.html#112">issue 112</A>,
the exact relationship between cv-qualifiers and array types is not
clear.  There does not appear to be a definitive normative statement
answering the question of whether an array with a const-qualified
element type is itself const-qualified; the statement in
3.9.3 [basic.type.qualifier] paragraph 5,</P>

<BLOCKQUOTE>

Cv-qualifiers applied to an array type attach to the underlying
element type, so the notation &#8220;<I>cv</I> <TT>T</TT>,&#8221;
where <TT>T</TT> is an array type, refers to an array whose
elements are so-qualified.  Such array types can be said to be
more (or less) cv-qualified than other types based on the
cv-qualification of the underlying element types.

</BLOCKQUOTE>

<P>hints at an answer but is hardly decisive.  For example, is
the following example well-formed?</P>

<PRE>
    template &lt;class T&gt; struct is_const {
        static const bool value = false;
    };
    template &lt;class T&gt; struct is_const&lt;const T&gt; {
        static const bool value = true;
    };

    template &lt;class T&gt; void f(T &amp;) {
        char checker[is_const&lt;T&gt;::value];
    }

    int const arr[1] = {};

    int main() {
        f(arr);
    }
</PRE>

<P>Also, when 3.10 [basic.lval] paragraph 4 says,</P>

<BLOCKQUOTE>

Class prvalues can have cv-qualified types; non-class prvalues
always have cv-unqualified types.

</BLOCKQUOTE>

<P>does this apply to array rvalues, as it appears?  That is,
given</P>

<PRE>
    struct S {
        const int arr[10];
    };
</PRE>

<P>is the array rvalue <TT>S().arr</TT> an array of <TT>int</TT>
or an array of <TT>const int</TT>?</P>

<P>(The more general question is, when the Standard refers to
non-class types, should it be considered to include array types?
Or perhaps only arrays of non-class types?)</P>

<BR><BR><HR><A NAME="636"></A><H4>636.
  
Dynamic type of objects and aliasing
</H4><B>Section: </B>3.10&#160; [basic.lval]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>23 May 2007<BR>




<P>The aliasing rules given in 3.10 [basic.lval] paragraph
10 rely on the concept of &#8220;dynamic type.&#8221;  The problem is
that the dynamic type of an object often cannot be determined (or
even sufficiently constrained) at the point at which an optimizer
needs to be able to determine whether aliasing might occur or not.
For example, consider the function</P>

<PRE>
    void foo(int* p, double* q) {
        *p = 42;
        *q = 3.14;
    }
</PRE>

<P>An optimizer, on the basis of the existing aliasing rules, might
decide that an <TT>int*</TT> and a <TT>double*</TT> cannot
refer to the same object and reorder the assignments.  This
reordering, however, could result in undefined behavior if the
function <TT>foo</TT> is called as follows:</P>

<PRE>
   void goo() {
      union {
         int i; 
         double d;
      } t;

      t.i = 12;

      foo(&amp;t.i, &amp;t.d);

      cout &lt;&lt; t.d &lt;&lt; endl;
   };
</PRE>

<P>Here, the reference to <TT>t.d</TT> after the call to
<TT>foo</TT> will be valid only if the assignments in
<TT>foo</TT> are executed in the order in which they were
written; otherwise, the union will contain an <TT>int</TT>
object rather than a <TT>double</TT>.</P>

<P>One possibility would be to require that if such aliasing
occurs, it be done only via member names and not via
pointers.</P>

<P><B>Notes from the July, 2007 meeting:</B></P>

<P>This is the same issue as C's <A href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_236.htm">DR236</A>.
The CWG expressed a desire to address the issue the same way C99
does.  The issue also occurs in C++ when placement new is used to
end the lifetime of one object and start the lifetime of a different
object occupying the same storage.</P>

<BR><BR><HR><A NAME="1090"></A><H4>1090.
  
Alignment of subobjects
</H4><B>Section: </B>3.11&#160; [basic.align]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-23<BR>


<P>The current wording of the Standard does not recognize the fact
that the alignment of a complete object of a given type may be
different from its alignment as a subobject.  This arises in
particular with virtual base classes.  For example,</P>

<PRE>
    struct B { long double d; };
    struct D: virtual B { char c; };
</PRE>

<P>When <TT>D</TT> is a complete object, it will have a subobject of
type <TT>B</TT>, which must be aligned appropriately for a <TT>long
double</TT>.  On the other hand, if <TT>D</TT> appears as a suboject
of another object, the <TT>B</TT> subobject might be part of a
different subobject, reducing the alignment requirement on the
<TT>D</TT> subobject.</P>

<P>The Standard should make clear that it is the complete-object
alignment that is being described, in parallel with the distinction
between the size of a complete object and a subobject of the same
type.</P>

<BR><BR><HR><A NAME="1211"></A><H4>1211.
  
Misaligned lvalues
</H4><B>Section: </B>3.11&#160; [basic.align]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>David Svoboda
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-20<BR>




<P>3.11 [basic.align] speaks of &#8220;alignment
requirements,&#8221; and 3.7.4.1 [basic.stc.dynamic.allocation] requires
the result of an allocation function to point to &#8220;suitably
aligned&#8221; storage, but there is no explicit statement of
what happens when these requirements are violated (presumably
undefined behavior).</P>

<BR><BR><HR><A NAME="617"></A><H4>617.
  
Lvalue-to-rvalue conversions of uninitialized <TT>char</TT> objects
</H4><B>Section: </B>4.1&#160; [conv.lval]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Alan Stokes
 &#160;&#160;&#160;

 <B>Date: </B>6 February 2007<BR>




<P>According to 4.1 [conv.lval] paragraph 1, applying the
lvalue-to-rvalue conversion to any uninitialized object results in
undefined behavior.  However, character types are intended to allow
any data, including uninitialized objects and padding, to be copied
(hence the statements in 3.9.1 [basic.fundamental] paragraph 1
that &#8220;For character types, all bits of the object representation
participate in the value representation&#8221; and in
3.10 [basic.lval] paragraph 15 that <TT>char</TT> and
<TT>unsigned char</TT> types can alias any object).  The
lvalue-to-rvalue conversion should be permitted on uninitialized
objects of character type without evoking undefined behavior.</P>

<BR><BR><HR><A NAME="170"></A><H4>170.
  
Pointer-to-member conversions
</H4><B>Section: </B>4.11&#160; [conv.mem]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Stump
 &#160;&#160;&#160;

 <B>Date: </B>16 Sep 1999<BR>





<P>The descriptions of explicit
(5.2.9 [expr.static.cast]
 paragraph 9) and
implicit (4.11 [conv.mem]
 paragraph 2)
pointer-to-member conversions differ in two significant ways:</P>

<OL>
<LI>In a <TT>static_cast</TT>, a conversion in which the class in
the target pointer-to-member type is a base of the class in which
the member is declared is permitted and required to work correctly,
as long as the resulting pointer-to-member is eventually
dereferenced with an object whose dynamic type contains the
member.  That is, the class of the target pointer-to-member type
is not required to contain the member referred to by the value
being converted.  The specification of implicit pointer-to-member
conversion is silent on this question.

<P>(This situation cannot arise in an implicit pointer-to-member
conversion where the source value is something like <TT>&amp;X::f</TT>,
since you can only implicitly convert from pointer-to-base-member
to pointer-to-derived-member.  However, if the source value is
the result of an explicit "up-cast," the target type of the
conversion might still not contain the member referred to by the
source value.)</P></LI>

<LI>The target type in a <TT>static_cast</TT> is allowed to be
more cv-qualified than the source type; in an implicit conversion,
however, the cv-qualifications of the two types are required to
be identical.</LI>
</OL>

<P>The first difference seems like an oversight.  It is not clear
whether the latter difference is intentional or not.</P>

<P>(See also <A HREF="
     cwg_closed.html#794">issue 794</A>.)</P>

<BR><BR><HR><A NAME="536"></A><H4>536.
  
Problems in the description of <I>id-expression</I>s
</H4><B>Section: </B>5.1.1&#160; [expr.prim.general]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>13 October 2005<BR>


<P>There are at least a couple of problems in the description of
the various <I>id-expression</I>s in 5.1.1 [expr.prim.general]:</P>

<OL><LI><P>Paragraph 4 embodies an incorrect assumption about the
syntax of <I>qualified-id</I>s:</P>

<BLOCKQUOTE>

The operator <TT>::</TT> followed by an <I>identifier</I>, a
<I>qualified-id</I>, or an <I>operator-function-id</I> is a
<I>primary-expression</I>.

</BLOCKQUOTE>

<P>The problem here is that the <TT>::</TT> is actually part of the
syntax of <I>qualified-id</I>; consequently, &#8220;<TT>::</TT> followed by...
a <I>qualified-id</I>&#8221; could be something like
&#8220;<TT>:: ::i</TT>,&#8221; which is ill-formed.  Presumably
this should say something like, &#8220;A <I>qualified-id</I> with
no <I>nested-name-specifier</I> is a <I>primary-expression</I>.&#8221;</P>
</LI>

<LI><P>More importantly, some kinds of <I>id-expression</I>s are not
described by 5.1.1 [expr.prim.general].  The structure of this
section is that the result, type, and lvalue-ness are specified for
each of the cases it covers:</P>

<UL>
<LI><P>paragraph 4 deals with <I>qualified-id</I>s that have no
<I>nested-name-specifier</I></P></LI>

<LI><P>paragraph 7 deals with bare <I>identifier</I>s and with
<I>qualified-id</I>s containing a <I>nested-name-specifier</I>
that names a class</P></LI>

<LI><P>paragraph 8 deals with <I>qualified-id</I>s containing a
<I>nested-name-specifier</I> that names a namespace</P></LI>

</UL>

<P>This treatment leaves unspecified all the non-<I>identifier</I>
<I>unqualified-id</I>s (<I>operator-function-id</I>,
<I>conversion-function-id</I>, and <I>template-id</I>), as well as
(perhaps) &#8220;<TT>::</TT> <I>template-id</I>&#8221; (it's not clear
whether the &#8220;<TT>::</TT> followed by a <I>qualified-id</I>&#8221; case
is supposed to apply to <I>template-id</I>s or not).  Note also that the
proposed resolution of <A HREF="
     cwg_defects.html#301">issue 301</A> slightly
exacerbates this problem by removing the form
of <I>operator-function-id</I> that contains
a <I>tmeplate-argument-list</I>; as a result, references like
&#8220;<TT>::operator+&lt;X&gt;</TT>&#8221; are no longer covered in
5.1.1 [expr.prim.general].</P>
</LI>

</OL>

<BR><BR><HR><A NAME="232"></A><H4>232.
  
Is indirection through a null pointer undefined behavior?
</H4><B>Section: </B>5.3.1&#160; [expr.unary.op]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>5 Jun 2000<BR>




<P>At least a couple of places in the IS state that indirection
through a null pointer produces undefined behavior: 1.9 [intro.execution] paragraph 4 gives "dereferencing the null pointer" as an
example of undefined behavior, and 8.3.2 [dcl.ref]
paragraph 4 (in a note) uses this supposedly undefined behavior as
justification for the nonexistence of "null references."</P>

<P>However, 5.3.1 [expr.unary.op] paragraph 1, which describes
the unary "*" operator, does <I>not</I> say that the behavior is
undefined if the operand is a null pointer, as one might expect.
Furthermore, at least one passage gives dereferencing a null pointer
well-defined behavior: 5.2.8 [expr.typeid] paragraph 2
says</P>

<BLOCKQUOTE>
If the lvalue expression is obtained by applying the unary * operator
to a pointer and the pointer is a null pointer value (4.10 [conv.ptr]), the <TT>typeid</TT> expression throws the
<TT>bad_typeid</TT> exception (18.7.3 [bad.typeid]).
</BLOCKQUOTE>

<P>This is inconsistent and should be cleaned up.</P>

<P><U>Bill Gibbons</U>:</P>

<P>At one point we agreed that dereferencing a null pointer was
<I>not</I> undefined; only using the resulting value had undefined
behavior.</P>

<P>For example:</P>

<PRE>
    char *p = 0;
    char *q = &amp;*p;
</PRE>

<P>Similarly, dereferencing a pointer to the end of an array should be
allowed as long as the value is not used:</P>

<PRE>
    char a[10];
    char *b = &amp;a[10];   // equivalent to "char *b = &amp;*(a+10);"
</PRE>

<P>Both cases come up often enough in real code that they should be
allowed.</P>

<P><U>Mike Miller</U>:</P>

<P>I can see the value in this, but it doesn't seem to be well
reflected in the wording of the Standard.  For instance, presumably
<TT>*p</TT> above would have to be an lvalue in order to be the
operand of "<TT>&amp;</TT>", but the definition of "lvalue" in
3.10 [basic.lval] paragraph 2 says that "an lvalue refers to
an object."  What's the object in <TT>*p</TT>?  If we were to allow
this, we would need to augment the definition to include the result of
dereferencing null and one-past-the-end-of-array.</P>

<P><U>Tom Plum</U>:</P>

<P>Just to add one more recollection of the intent: I was <I>very</I>
happy when (I thought) we decided that it was only the attempt to
actually fetch a value that creates undefined behavior.  The words
which (I thought) were intended to clarify that are the first three
sentences of the lvalue-to-rvalue conversion, 4.1 [conv.lval]:</P>

<BLOCKQUOTE>

An lvalue (3.10 [basic.lval]) of a non-function, non-array
type <TT>T</TT> can be converted to an rvalue.  If <TT>T</TT> is an
incomplete type, a program that necessitates this conversion is
ill-formed.  If the object to which the lvalue refers is not an object
of type <TT>T</TT> and is not an object of a type derived from
<TT>T</TT>, or if the object is uninitialized, a program that
necessitates this conversion has undefined behavior.

</BLOCKQUOTE>

<P>In other words, it is only the act of "fetching", of
lvalue-to-rvalue conversion, that triggers the ill-formed or undefined
behavior.  Simply forming the lvalue expression, and then for example
taking its address, does not trigger either of those errors.  I
described this approach to WG14 and it may have been incorporated into
C 1999.</P>

<P><U>Mike Miller</U>:</P>

<P>If we admit the possibility of null lvalues, as Tom is suggesting
here, that significantly undercuts the rationale for prohibiting "null
references" -- what is a reference, after all, but a named lvalue?  If
it's okay to create a null lvalue, as long as I don't invoke the
lvalue-to-rvalue conversion on it, why shouldn't I be able to capture
that null lvalue as a reference, with the same restrictions on its
use?</P>

<P>I am not arguing in favor of null references.  I don't want them in
the language.  What I am saying is that we need to think carefully
about adopting the permissive approach of saying that it's all right
to create null lvalues, as long as you don't use them in certain ways.
If we do that, it will be very natural for people to question why they
can't pass such an lvalue to a function, as long as the function
doesn't do anything that is not permitted on a null lvalue.
</P>

<P>If we want to allow <TT>&amp;*(p=0)</TT>, maybe we should change
the definition of "<TT>&amp;</TT>" to handle dereferenced null
specially, just as <TT>typeid</TT> has special handling, rather than
changing the definition of lvalue to include dereferenced nulls, and
similarly for the array_end+1 case.  It's not as general, but I think
it might cause us fewer problems in the long run.
</P>

<P><B>Notes from the October 2003 meeting:</B></P>

<P>See also <A HREF="
     cwg_closed.html#315">issue 315</A>, which deals with
the call of a static member function through a null pointer.</P>

<P>We agreed that the approach in the standard seems okay:
<TT>p = 0; *p;</TT> is not inherently an error.  An
lvalue-to-rvalue conversion would give it undefined behavior.</P>

<P><B>Proposed resolution (October, 2004):</B></P>

<P>(Note: the resolution of <A HREF="
     cwg_active.html#453">issue 453</A>
also resolves part of this issue.)</P>

<OL>

<LI><P>Add the indicated words to 3.10 [basic.lval]
paragraph 2:</P>

<BLOCKQUOTE>

An lvalue refers to an object or function <SPAN style="font-weight:bold;background-color:#A0FFA0">or is an empty lvalue
(5.3.1 [expr.unary.op])</SPAN>.

</BLOCKQUOTE>

</LI>

<LI><P>Add the indicated words to 5.3.1 [expr.unary.op]
paragraph 1:</P>

<BLOCKQUOTE>

The unary <TT>*</TT> operator performs <I>indirection</I>: the
expression to which it is applied shall be a pointer to an object
type, or a pointer to a function type and the result is an lvalue
referring to the object or function to which the expression
points<SPAN style="font-weight:bold;background-color:#A0FFA0">, if any. If the pointer is a null pointer value
(4.10 [conv.ptr]) or points one past the last element
of an array object (5.7 [expr.add]), the result is an
<I>empty lvalue</I> and does not refer to any object or function.
An empty lvalue is not modifiable</SPAN>.  If the type of the
expression is &#8220;pointer to <TT>T</TT>,&#8221; the type of
the result is &#8220;<TT>T</TT>.&#8221; [<I>Note:</I> a pointer to an
incomplete type (other than cv void) can be dereferenced. The
lvalue thus obtained can be used in limited ways (to initialize a
reference, for example); this lvalue must not be converted to an
rvalue, see 4.1 [conv.lval].&#8212;<I>end note</I>]

</BLOCKQUOTE>

</LI>

<LI><P>Add the indicated words to 4.1 [conv.lval]
paragraph 1:</P>

<BLOCKQUOTE>

If the object to which the lvalue refers is not an object of type
<TT>T</TT> and is not an object of a type derived from
<TT>T</TT>, or if the object is uninitialized, <SPAN style="font-weight:bold;background-color:#A0FFA0">or if the
lvalue is an empty lvalue (5.3.1 [expr.unary.op]),</SPAN> a
program that necessitates this conversion has undefined behavior.

</BLOCKQUOTE>

</LI>

<LI><P>Change 1.9 [intro.execution] as indicated:</P>

<BLOCKQUOTE>

Certain other operations are described in this International
Standard as undefined (for example, the effect of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">dereferencing
the null pointer</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">division by zero</SPAN>).

</BLOCKQUOTE>

</LI>

</OL>

<P><B>Note (March, 2005):</B></P> 

<P>The 10/2004 resolution interacts with the resolution of <A HREF="
     cwg_defects.html#73">issue 73</A>.  We added wording to 3.9.2 [basic.compound] paragraph 3 to the effect that a pointer containing
the address one past the end of an array is considered to &#8220;point
to&#8221; another object of the same type that might be located there.
The 10/2004 resolution now says that it would be undefined behavior to
use such a pointer to fetch the value of that object.  There is at
least the appearance of conflict here; it may be all right, but it at
needs to be discussed further.</P>

<P><B>Notes from the April, 2005 meeting:</B>
</P>

<P>The CWG agreed that there is no contradiction between this
direction and the resolution of <A HREF="
     cwg_defects.html#73">issue 73</A>.
However, &#8220;not modifiable&#8221; is a compile-time concept, while
in fact this deals with runtime values and thus should produce
undefined behavior instead.  Also, there are other contexts in which
lvalues can occur, such as the left operand of <TT>.</TT>
or <TT>.*</TT>, which should also be restricted.  Additional drafting
is required.</P>

<P>(See also <A HREF="
     cwg_defects.html#1102">issue 1102</A>.)</P>

<BR><BR><HR><A NAME="901"></A><H4>901.
  
Deleted <TT>operator delete</TT>
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>20 May, 2009<BR>


<P>It is not clear from 5.3.4 [expr.new] whether a deleted
<TT>operator delete</TT> is referenced by a <I>new-expression</I> in
which there is no initialization or in which the initialization cannot
throw an exception, rendering the program ill-formed.  (The question
also arises as to whether such a
<I>new-expression</I> constitutes a &#8220;use&#8221; of the
deallocation function in the sense of 3.2 [basic.def.odr].)</P>

<P><B>Notes from the July, 2009 meeting:</B></P>

<P>The rationale for defining a deallocation function as deleted would
presumably be to prevent such objects from being freed.  Treating the
<I>new-expression</I> as a use of such a deallocation function would
mean that such objects could not be created in the first place.  There
is already an exemption from freeing an object if &#8220;a suitable
deallocation function [cannot] be found;&#8221; a deleted deallocation
function should be treated similarly.</P>

<BR><BR><HR><A NAME="837"></A><H4>837.
  
Constexpr functions and <TT>return</TT> <I>braced-init-list</I>
</H4><B>Section: </B>7.1.5&#160; [dcl.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>11 March, 2009<BR>


<P>The body of a constexpr function is required by
7.1.5 [dcl.constexpr] paragraph 3 to be of the form</P>

<UL><TT>{ return</TT> <I>expression</I><TT>; }</TT></UL>

<P>However, there does not seem to be any good reason for prohibiting
the alternate return syntax involving a <I>braced-init-list</I>.
The restriction should be removed.</P>

<P><B>Proposed resolution (March, 2010):</B></P>

<OL><LI><P>Change 6.6.3 [stmt.return] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

A return statement <SPAN style="text-decoration:line-through;background-color:#FFA0A0">without an expression</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">with neither an
<I>expression</I> nor a <I>braced-init-list</I></SPAN> can be used only
in functions that do not return a value...

</BLOCKQUOTE>

<LI><P>Change 7.1.5 [dcl.constexpr] paragraph 3 bullets 4
and 5 as follows:</P></LI>

<UL><LI><P>its <I>function-body</I> shall be a <I>compound-statement</I>
of the form</P>

<UL><TT>{ return </TT><I>expression</I><TT> ; }</TT></UL>

<P>where <I>expression</I> is a potential constant expression
(5.19)<SPAN style="font-weight:bold;background-color:#A0FFA0">, or</SPAN></P>

<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>{ return </TT><I>braced-init-list</I><TT> ; }</TT></SPAN></UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">where every <I>assignment-expression</I> that is an
<I>initializer-clause</I> appearing directly or indirectly within the
<I>braced-init-list</I> is a potential constant expression</SPAN></P>

</LI>

<LI><P>every <SPAN style="font-weight:bold;background-color:#A0FFA0">constructor call and</SPAN> implicit conversion
used in <SPAN style="text-decoration:line-through;background-color:#FFA0A0">converting <I>expression</I> to the function return
type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">initializing the return value</SPAN>
(<SPAN style="font-weight:bold;background-color:#A0FFA0">6.6.3 [stmt.return],</SPAN> 8.5 [dcl.init])
shall be one of those allowed in a constant expression
(5.19 [expr.const]).</P></LI>

</UL>

</OL>

<P><B>Notes from the March, 2010 meeting:</B></P>

<P>The new wording added in 5.19 [expr.const] in support
of reference parameters for constexpr functions should also be
considered to see whether additional changes are needed.</P>

<BR><BR><HR><A NAME="138"></A><H4>138.
  
Friend declaration name lookup
</H4><B>Section: </B>7.3.1.2&#160; [namespace.memdef]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin von Loewis
 &#160;&#160;&#160;

 <B>Date: </B>14 Jul 1999<BR>





<P>7.3.1.2 [namespace.memdef]
 paragraph 3 says,</P>

<BLOCKQUOTE>
If a <TT>friend</TT> declaration in a non-local class first declares a
class or function the friend class or function is a member of the
innermost enclosing namespace...  When looking for a prior declaration
of a class or a function declared as a <TT>friend</TT>, scopes outside
the innermost enclosing namespace scope are not considered.
</BLOCKQUOTE>

It is not clear from this passage how to determine whether an entity
is "first declared" in a <TT>friend</TT> declaration.  One question is
whether a <I>using-declaration</I> influences this determination.
For instance:

<PRE>
    void foo();
    namespace A{
      using ::foo;
      class X{
	friend void foo();
      };
    }
</PRE>

Is the <TT>friend</TT> declaration a reference to <TT>::foo</TT> or
a different <TT>foo</TT>?

<P>Part of the question involves determining the meaning of
the word "synonym" in
7.3.3 [namespace.udecl]
 paragraph 1:</P>

<BLOCKQUOTE>
A <I>using-declaration</I> introduces a name into the declarative
region in which the <I>using-declaration</I> appears.  That name
is a synonym for the name of some entity declared elsewhere.
</BLOCKQUOTE>

Is "<TT>using ::foo;</TT>" the declaration of a function or not?

<P>More generally, the question is how to describe the lookup of the
name in a <TT>friend</TT> declaration.</P>

<P><U>John Spicer</U>:
When a declaration specifies an unqualified name, that
name is declared, not looked up.  There is a mechanism in which that
declaration is linked to a prior declaration, but that mechanism is
not, in my opinion, via normal name lookup.  So, the friend always
declares a member of the nearest namespace scope regardless of how
that name may or may not already be declared there.</P>

<P><U>Mike Miller</U>:
3.4.1 [basic.lookup.unqual]
 paragraph 7 says:</P>

<BLOCKQUOTE>
A name used in the definition of a class <TT>X</TT> outside of a
member function body or nested class definition shall be declared in
one of the following ways:...  [<I>Note:</I> when looking for a
prior declaration of a class or function introduced by a <TT>friend</TT>
declaration, scopes outside of the innermost enclosing namespace scope
are not considered.]
</BLOCKQUOTE>

The presence of this note certainly implies that this paragraph
describes the lookup of names in <TT>friend</TT> declarations.

<P><U>John Spicer</U>:
It most certainly does not.  If that section described the friend
lookup it would yield the incorrect results for the friend declarations
of <TT>f</TT> and <TT>g</TT> below.
I don't know why that note is there, but it can't
be taken to mean that that is how the friend lookup is done.</P>

<PRE>
    void f(){}
    void g(){}
    class B {
        void g();
    };
    class A : public B {
        void f();
        friend void f(); // ::f not A::f
        friend void g(); // ::g not B::g
    };
</PRE>

<P><U>Mike Miller</U>:
If so, the lookups for friend functions and classes behave differently.
Consider the example in
3.4.4 [basic.lookup.elab]
 paragraph 3:</P>

<PRE>
    struct Base {
        struct Data;         // <I>OK: declares nested</I> Data
        friend class Data;   // <I>OK: nested</I> Data <I>is a friend</I>
    };
</PRE>

<P>If the <TT>friend</TT> declaration is <I>not</I> a reference to
<TT>::foo</TT>, there is a related but separate question: does the
<TT>friend</TT> declaration introduce a conflicting (albeit "invisible")
declaration into namespace <TT>A</TT>, or is it simply a reference
to an as-yet undeclared (and, in this instance, undeclarable)
<TT>A::foo</TT>?  Another part of the example in
3.4.4 [basic.lookup.elab]
 paragraph 3 is
related:</P>

<PRE>
    struct Data {
        friend struct Glob;  // <I>OK: Refers to (as yet) undeclared</I> Glob
                             // <I>at global scope.</I>
    };
</PRE>

<P><U>John Spicer</U>:
You can't refer to something that has not yet been declared.  The friend
is a declaration of <TT>Glob</TT>,
it just happens to declare it in a such a way that
its name cannot be used until it is redeclared.</P>

<P>(A somewhat similar question has been raised in connection with
<A HREF="
     cwg_active.html#36">issue 36</A>.  Consider:</P>

<PRE>
    namespace N {
        struct S { };
    }
    using N::S;
    struct S;          // legal?
</PRE>

<P>According to 9.1 [class.name] paragraph 2,</P>

<BLOCKQUOTE>

A declaration consisting solely of <I>class-key identifier ;</I>
is either a redeclaration of the name in the current scope or a
forward declaration of the identifier as a class name.

</BLOCKQUOTE>

<P>Should the elaborated type declaration in this example be
considered a redeclaration of <TT>N::S</TT> or an invalid
forward declaration of a different class?)</P>

<P>(See also issues
<A HREF="
     cwg_closed.html#95">95</A>,
<A HREF="
     cwg_defects.html#136">136</A>,
<A HREF="
     cwg_defects.html#139">139</A>,
<A HREF="
     cwg_defects.html#143">143</A>,
<A HREF="
     cwg_closed.html#165">165</A>, and
<A HREF="
     cwg_defects.html#166">166</A>, as well as paper J16/00-0006 = WG21
N1229.)</P>



<BR><BR><HR><A NAME="453"></A><H4>453.
  
References may only bind to &#8220;valid&#8221; objects
</H4><B>Section: </B>8.3.2&#160; [dcl.ref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Gennaro Prota
 &#160;&#160;&#160;

 <B>Date: </B>18 Jan 2004<BR>


<P>8.3.2 [dcl.ref] paragraph 4 says:</P>
<BLOCKQUOTE>
  A reference shall be initialized to refer to a valid object or
  function. [Note: in particular, a null reference cannot exist
  in a well-defined program, because the only way to create such
  a reference would be to bind it to the "object" obtained by
  dereferencing a null pointer, which causes undefined behavior
  ...]
</BLOCKQUOTE>
<P>What is a "valid" object? In particular the expression "valid object"
seems to exclude uninitialized objects, but the response to Core Issue
363 clearly says that's not the intent. This is an example
(overloading construction on constness of *this) by John Potter, which
I think is supposed to be legal C++ though it binds references to
objects that are not initialized yet:</P>
<PRE>
 struct Fun {
    int x, y;
    Fun (int x, Fun const&amp;) : x(x), y(42) { }
    Fun (int x, Fun&amp;) : x(x), y(0) { }
  };
  int main () {
    const Fun f1 (13, f1);
    Fun f2 (13, f2);
    cout &lt;&lt; f1.y &lt;&lt; " " &lt;&lt; f2.y &lt;&lt; "\n";
  }
</PRE>

<P>Suggested resolution: Changing the final part of
8.3.2 [dcl.ref] paragraph 4 to:</P>
<BLOCKQUOTE>
  A reference shall be initialized to refer to an object or function.
  From its point of declaration on (see 3.3.2 [basic.scope.pdecl])
  its name is an lvalue
  which refers to that object or function. The reference may be
  initialized to refer to an uninitialized object but, in that case,
  it is usable in limited ways (3.8 [basic.life], paragraph 6)
  [Note: On the other hand, a declaration like this:
<PRE>
    int &amp; ref = *(int*)0;
</PRE>
  is ill-formed because ref will not refer to any object or function
  ]
</BLOCKQUOTE>

<P>I also think a "No diagnostic is required." would better be added
(what about something like int&amp; r = r; ?)</P>

<P><B>Proposed Resolution (October, 2004):</B></P>

<P>(Note: the following wording depends on the proposed
resolution for <A HREF="
     cwg_active.html#232">issue 232</A>.)</P>

<P>Change 8.3.2 [dcl.ref] paragraph 4 as follows:</P>
<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A reference shall be initialized to refer to a valid object
or function.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">If an lvalue to which a reference is directly
bound designates neither an existing object or function of an
appropriate type (8.5.3 [dcl.init.ref]), nor a region of
memory of suitable size and alignment to contain an object of the
reference's type (1.8 [intro.object], 3.8 [basic.life], 3.9 [basic.types]), the behavior is
undefined.</SPAN> [<I>Note:</I> in particular, a null reference cannot
exist in a well-defined program, because the only way to create
such a reference would be to bind it to the
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8220;object&#8221;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">empty lvalue</SPAN> obtained by
dereferencing a null pointer, which <SPAN style="text-decoration:line-through;background-color:#FFA0A0">causes undefined behavior.
As</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">does not designate an object or function.  Also, as
</SPAN> described in 9.6 [class.bit],
a reference cannot be bound directly to a
bit-field. ]</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">The name of a reference shall not be used in its own
initializer.  Any other use of a reference before it is
initialized results in undefined behavior.  [<I>Example:</I>
</SPAN></P>

<SPAN style="font-weight:bold;background-color:#A0FFA0">
<PRE>
  int&amp; f(int&amp;);
  int&amp; g();

  extern int&amp; ir3;
  int* ip = 0;

  int&amp; ir1 = *ip;     // <I>undefined behavior: null pointer</I>
  int&amp; ir2 = f(ir3);  // <I>undefined behavior: </I>ir3<I> not yet initialized</I>
  int&amp; ir3 = g();
  int&amp; ir4 = f(ir4);  // <I>ill-formed: </I>ir4<I> used in its own initializer</I>
</PRE>
&#8212;<I>end example</I>]
</SPAN>
</BLOCKQUOTE>

<P><B>Rationale: </B> The proposed wording goes beyond the specific
concerns of the issue.  It was noted that, while the current
wording makes cases like <TT>int&amp; r = r;</TT> ill-formed (because
<TT>r</TT> in the initializer does not "refer to a valid object"), an
inappropriate initialization can only be detected, if at all, at
runtime and thus "undefined behavior" is a more appropriate treatment.
Nevertheless, it was deemed desirable to continue to require a
diagnostic for obvious compile-time cases.
</P>

<P>It was also noted that the current Standard does not say anything
about using a reference before it is initialized.  It seemed
reasonable to address both of these concerns in the same wording
proposed to resolve this issue.
</P>

<P><B>Notes from the April, 2005 meeting:</B></P>

<P>The CWG decided that whether to require an implementation to
diagnose initialization of a reference to itself should be handled as
a separate issue (<A HREF="
     cwg_active.html#504">504</A>) and also suggested referring
to &#8220;storage&#8221; instead of &#8220;memory&#8221; (because
1.8 [intro.object] defines an object as a &#8220;region of
storage&#8221;).</P>

<P><B>Proposed Resolution (April, 2005):</B></P>

<P>(Note: the following wording depends on the proposed
resolution for <A HREF="
     cwg_active.html#232">issue 232</A>.)</P>

<P>Change 8.3.2 [dcl.ref] paragraph 4 as follows:</P>
<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A reference shall be initialized to refer to a valid object
or function.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">If an lvalue to which a reference is directly
bound designates neither an existing object or function of an
appropriate type (8.5.3 [dcl.init.ref]), nor a region of
storage of suitable size and alignment to contain an object of the
reference's type (1.8 [intro.object], 3.8 [basic.life], 3.9 [basic.types]), the behavior is
undefined.</SPAN> [<I>Note:</I> in particular, a null reference cannot
exist in a well-defined program, because the only way to create
such a reference would be to bind it to the
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8220;object&#8221;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">empty lvalue</SPAN> obtained by
dereferencing a null pointer, which <SPAN style="text-decoration:line-through;background-color:#FFA0A0">causes undefined behavior.
As</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">does not designate an object or function.  Also, as
</SPAN> described in 9.6 [class.bit],
a reference cannot be bound directly to a
bit-field. ]</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">Any use of a reference before it is initialized results in
undefined behavior.  [<I>Example:</I>
</SPAN></P>

<SPAN style="font-weight:bold;background-color:#A0FFA0">
<PRE>
  int&amp; f(int&amp;);
  int&amp; g();

  extern int&amp; ir3;
  int* ip = 0;

  int&amp; ir1 = *ip;     // <SPAN style="font-family:Times;font-style:italic">undefined behavior: null pointer</SPAN>
  int&amp; ir2 = f(ir3);  // <SPAN style="font-family:Times;font-style:italic">undefined behavior: </SPAN>ir3<SPAN style="font-family:Times;font-style:italic"> not yet initialized</SPAN>
  int&amp; ir3 = g();
  int&amp; ir4 = f(ir4);  // <SPAN style="font-family:Times;font-style:italic">undefined behavior: </SPAN>ir4<SPAN style="font-family:Times;font-style:italic"> used in its own initializer</SPAN>
</PRE>
&#8212;<I>end example</I>]
</SPAN>
</BLOCKQUOTE>

<P><B>Note (February, 2006):</B></P>

<P>The word &#8220;use&#8221; in the last
paragraph of the proposed resolution was intended to refer to the
description in 3.2 [basic.def.odr] paragraph 2.  However, that
section does not define what it means for a reference to be
&#8220;used,&#8221; dealing only with objects and functions.  Additional
drafting is required to extend 3.2 [basic.def.odr] paragraph 2
to apply to references.  </P>

<P><B>Additional note (May, 2008):</B></P>

<P>The proposed resolution for <A HREF="
     cwg_defects.html#570">issue 570</A>
adds wording to define &#8220;use&#8221; for references.</P>

<BR><BR><HR><A NAME="393"></A><H4>393.
  
Pointer to array of unknown bound in template argument list in parameter
</H4><B>Section: </B>8.3.5&#160; [dcl.fct]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mark Mitchell
 &#160;&#160;&#160;

 <B>Date: </B>12 Dec 2002<BR>


<P>EDG rejects this code:
<PRE>
  template &lt;typename T&gt;
  struct S {};

  void f (S&lt;int (*)[]&gt;);
</PRE>
G++ accepts it.</P>

<P>This is another case where the standard isn't very clear:</P>

<P>The language from 8.3.5 [dcl.fct] is:
 <BLOCKQUOTE>
   If the type of a parameter includes a type of the form "pointer to
   array of unknown bound of T" or "reference to array of unknown bound
   of T," the program is ill-formed.
 </BLOCKQUOTE>
 Since "includes a type" is not a term defined in the standard, we're
 left to guess what this means.  (It would be better if this were a
 recursive definition, the way a type theoretician would do it:
 <UL>
 <LI> Every type includes itself. </LI>
 <LI> T* includes T </LI>
 <LI> T[] includes T </LI>
 <LI> ... </LI>
 </UL>
 )
 </P>

<P><B>Notes from April 2003 meeting:</B></P>

<P>We agreed that the example should be allowed.</P>

<BR><BR><HR><A NAME="1214"></A><H4>1214.
  
Kinds of initializers
</H4><B>Section: </B>8.5&#160; [dcl.init]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-30<BR>


<P>8.5 [dcl.init] paragraph 16 describes three kinds of
initializers: a single expression, a <I>braced-init-list</I>, and a
parenthesized list of expressions.  It is not clear which, if any,
of these categories is the appropriate description for an
initializer like</P>

<PRE>
    T t( { 1, 2 } )
</PRE>

<P>and thus not clear which of the bullets in the list applies.</P>

<BR><BR><HR><A NAME="233"></A><H4>233.
  
References vs pointers in UDC overload resolution
</H4><B>Section: </B>8.5.3&#160; [dcl.init.ref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Matthias Meixner
 &#160;&#160;&#160;

 <B>Date: </B>9 Jun 2000<BR>


<P>There is an inconsistency in the handling of references
vs pointers in user defined conversions and overloading. The reason
for that is that the combination of 8.5.3 [dcl.init.ref] and
4.4 [conv.qual] circumvents the standard way of ranking
conversion functions, which was probably not the intention of the
designers of the standard.</P>

<P>Let's start with some examples, to show what it is about:</P>

<PRE>
    struct Z { Z(){} };

    struct A {
       Z x;

       operator Z *() { return &amp;x; }
       operator const Z *() { return &amp;x; }
    };

    struct B {
       Z x;

       operator Z &amp;() { return x; }
       operator const Z &amp;() { return x; }
    };

    int main()
    {
       A a;
       Z *a1=a;
       const Z *a2=a; // not ambiguous

       B b;
       Z &amp;b1=b;
       const Z &amp;b2=b; // ambiguous
    }
</PRE>

<P>So while both classes <TT>A</TT> and <TT>B</TT> are structurally
equivalent, there is a difference in operator overloading. I want to
start with the discussion of the pointer case (<TT>const Z
*a2=a;</TT>): 13.3.3 [over.match.best] is used to select the best
viable function. Rule 4 selects <TT>A::operator const Z*()</TT> as
best viable function using 13.3.3.2 [over.ics.rank] since the
implicit conversion sequence <TT>const Z*</TT> -&gt; <TT>const Z*</TT>
is a better conversion sequence than <TT>Z*</TT> -&gt; <TT>const
Z*</TT>.</P>

<P>So what is the difference to the reference case?  Cv-qualification
conversion is only applicable for pointers according to 4.4 [conv.qual]. According to 8.5.3 [dcl.init.ref] paragraphs
4-7 references are initialized by binding using the concept of
reference-compatibility. The problem with this is, that in this
context of binding, there is no conversion, and therefore there is
also no comparing of conversion sequences. More exactly all
conversions can be considered identity conversions according to
13.3.3.1.4 [over.ics.ref] paragraph 1, which compare equal
and which has the same effect.  So binding <TT>const Z*</TT> to
<TT>const Z*</TT> is as good as binding <TT>const Z*</TT> to
<TT>Z*</TT> in terms of overloading. Therefore <TT>const Z
&amp;b2=b;</TT> is ambiguous.  [13.3.3.1.4 [over.ics.ref]
paragraph 5 and 13.3.3.2 [over.ics.rank] paragraph 3 rule 3
(S1 and S2 are reference bindings ...) do not seem to apply to this
case]</P>

<P>There are other ambiguities, that result in the special treatment
of references: Example:</P>

<PRE>
    struct A {int a;};
    struct B: public A { B() {}; int b;};

    struct X {
       B x;
       operator A &amp;() { return x; }
       operator B &amp;() { return x; }
    };

    main()
    {
       X x;
       A &amp;g=x; // ambiguous
    }
</PRE>

<P>Since both references of class <TT>A</TT> and <TT>B</TT> are
reference compatible with references of class <TT>A</TT> and since
from the point of ranking of implicit conversion sequences they are
both identity conversions, the initialization is ambiguous.
</P>

<P>So why should this be a defect?</P>

<UL>

<LI>References behave fundamentally different from pointers in combination 
with user defined conversions, although there is no reason to have this
different treatment.</LI>

<LI>This difference only shows up in combination with user defined
conversion sequences, for all other cases, there are special rules,
e.g. 13.3.3.2 [over.ics.rank] paragraph 3 rule 3.</LI>

</UL>

<P>So overall I think this was not the intention of the authors of the
standard.</P>

<P>So how could this be fixed? For comparing conversion sequences (and
only for comparing) reference binding should be treated as if it was a
normal assignment/initialization and cv-qualification would have to be
defined for references. This would affect 8.5.3 [dcl.init.ref] paragraph 6, 4.4 [conv.qual] and probably
13.3.3.2 [over.ics.rank] paragraph 3.</P>

<P>Another fix could be to add a special case in 13.3.3 [over.match.best] paragraph 1. </P>

<BR><BR><HR><A NAME="1005"></A><H4>1005.
  
Qualified name resolution in member functions of class templates
</H4><B>Section: </B>9.3.1&#160; [class.mfct.non-static]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>2009-11-19<BR>




<P>It's not clear how lookup of a non-dependent qualified name
should be handled in a non-static member function of a class
template.  For example,</P>

<PRE>
    struct A {
      int f(int);
      static int f(double);
    };

    struct B {};

    template&lt;typename T&gt; struct C : T {
      void g() {
        A::f(0);
      }
    };
</PRE>

<P>The call to <TT>A::f</TT> inside <TT>C::g()</TT> appears
non-dependent, so one might expect that it would be bound at
template definition time to <TT>A::f(double)</TT>.  However, the
resolution for <A HREF="
     cwg_defects.html#515">issue 515</A> changed
9.3.1 [class.mfct.non-static] paragraph 3 to transform an
<I>id-expression</I> to a member access expression using
<TT>(*this).</TT> if lookup resolves the name to a non-static
member of <I>any</I> class, making the reference dependent.  The
result is that if <TT>C</TT> is instantiated with <TT>A</TT>,
<TT>A::f(int)</TT> is called; if <TT>C</TT> is instantiated with
<TT>B</TT>, the call is ill-formed (the call is transformed to
<TT>(*this).A::f(0)</TT>, and there is no <TT>A</TT> subobject in
<TT>C&lt;B&gt;</TT>).  Both these results seem unintuitive.</P>

<P>(See also <A HREF="
     cwg_active.html#1017">issue 1017</A>.)</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

The CWG agreed that the resolution of <A HREF="
     cwg_defects.html#515">issue 515</A>
was ill-advised and should be reversed.

<BR><BR><HR><A NAME="1017"></A><H4>1017.
  
Member access transformation in unevaluated operands
</H4><B>Section: </B>9.3.1&#160; [class.mfct.non-static]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2009-12-30<BR>


<P>The following innocuous-appearing code is currently ill-formed:</P>

<PRE>
    struct A {
        int a;
    };

    struct B {
        void f() {
            decltype(A::a) i;    // ill-formed
        }
    };
</PRE>

<P>The reason is that, according to 9.3.1 [class.mfct.non-static]
paragraph 3, the reference to <TT>A::a</TT> is transformed into
<TT>(*this).A::a</TT>, and there is no <TT>A</TT> subobject of
<TT>B</TT>.  It would seem reasonable to suppress this transformation
in unevaluated operands, where a reference to a non-static member
is permitted without an object expression.</P>

<P>(See also <A HREF="
     cwg_active.html#1005">issue 1005</A>.)</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

The CWG agreed that the resolution of <A HREF="
     cwg_defects.html#515">issue 515</A>
was ill-advised and should be reversed.

<BR><BR><HR><A NAME="580"></A><H4>580.
  
Access in <I>template-parameter</I>s of member and friend definitions
</H4><B>Section: </B>11&#160; [class.access]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>16 May 2006<BR>


<P>The resolution of <A HREF="
     cwg_defects.html#372">issue 372</A> leaves
unclear whether the following are well-formed or not:</P>

<PRE>
    class C {
        typedef int I;                // private
        template &lt;int&gt; struct X;
        template &lt;int&gt; friend struct Y;
    }

    template &lt;C::I&gt; struct C::X { };  // C::I accessible to member?

    template &lt;C::I&gt; struct Y { };     // C::I accessible to friend?
</PRE>

<P>Presumably the answer to both questions is &#8220;yes,&#8221; but
the new wording does not address <I>template-parameter</I>s.</P>

<P><B>Proposed resolution (June, 2008):</B></P>

<P>Change 11 [class.access] paragraph 6 as follows:</P>

<BLOCKQUOTE>

...For purposes of access control, the <I>base-specifier</I>s of a class<SPAN style="font-weight:bold;background-color:#A0FFA0">, the
<I>template-parameter</I>s of a <I>template-declaration</I>,</SPAN> and
the definitions of class members that appear outside of the class
definition are considered to be within the scope of that class...

</BLOCKQUOTE>

<P><B>Notes from the September, 2008 meeting:</B></P>

<P>The proposed resolution preserves the word &#8220;scope&#8221;
as a holdover from the original specification prior to <A HREF="
     cwg_defects.html#372">issue 372</A>, which intended to change access
determination from a scope-based model to an entity-based model.
The resolution should eliminate all references to scope and simply
use the entity-based model.</P>

<P>(See also <A HREF="
     cwg_active.html#718">issue 718</A>.)</P>

<P><B>Proposed resolution (February, 2010):</B></P>

<P>Change 11 [class.access] paragraphs 6-7 as follows:</P>

<BLOCKQUOTE>

<P>All access controls in Clause 11 [class.access] affect
the ability to access a class member name from <SPAN style="font-weight:bold;background-color:#A0FFA0">a declaration
of</SPAN> a particular <SPAN style="text-decoration:line-through;background-color:#FFA0A0">scope</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">entity, including
references appearing in those parts of the declaration that
precede the name of the entity being declared and implicit
references to constructors, conversion functions, and destructors
involved in the creation and destruction of a static data
member</SPAN>.  <SPAN style="text-decoration:line-through;background-color:#FFA0A0">For purposes of access control, the
<I>base-specifier</I>s of a class and the definitions of class
members that appear outside of the class definition are
considered to be within the scope of that class.  In particular,
access controls apply as usual to member names accessed as part
of a function return type, even though it is not possible to
determine the access privileges of that use without first parsing
the rest of the function declarator.  Similarly, access control
for implicit calls to the constructors, the conversion functions,
or the destructor called to create and destroy a static data
member is performed as if these calls appeared in the scope of
the member's class.</SPAN> [<I>Example:</I></P>

<PRE>
  class A {
    typedef int I;    //<SPAN style="font-family:Times;font-style:italic"> private member</SPAN>
    I f();
    friend I g(I);
    static I x;
<SPAN style="font-weight:bold;background-color:#A0FFA0">    template&lt;int&gt; struct X;
    template&lt;int&gt; friend struct Y;</SPAN>
  protected:
    struct B { };
  };

  A::I A::f() { return 0; }
  A::I g(A::I p = A::x);
  A::I g(A::I p) { return 0; }
  A::I A::x = 0;
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template&lt;A::I&gt; struct A::X { };
  template&lt;A::I&gt; struct Y { };
</SPAN>
  struct D: A::B, A { };
</PRE>

<P>Here, all the uses of <TT>A::I</TT> are well-formed because
<TT>A::f</TT><SPAN style="text-decoration:line-through;background-color:#FFA0A0"> and</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">,</SPAN> <TT>A::x</TT><SPAN style="font-weight:bold;background-color:#A0FFA0">, and
<TT>A::X</TT></SPAN> are members of class <TT>A</TT> and
<TT>g</TT> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">is a friend</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">and <TT>Y</TT> are
friends</SPAN> of class <TT>A</TT>. This implies, for example,
that access checking on the first use of <TT>A::I</TT> must be
deferred until it is determined that this use of <TT>A::I</TT> is
as the return type of a member of class <TT>A</TT>. Similarly,
the use of <TT>A::B</TT> as a <I>base-specifier</I> is
well-formed because <TT>D</TT> is derived from <TT>A</TT>, so
checking of <I>base-specifier</I>s must be deferred until the
entire <I>base-specifier-list</I> has been seen.  &#8212;<I>end
example</I>]</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="952"></A><H4>952.
  
Insufficient description of &#8220;naming class&#8221;
</H4><B>Section: </B>11.2&#160; [class.access.base]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>7 August, 2009<BR>




<P>The access rules in 11.2 [class.access.base] do not appear to
handle references in nested classes and outside of nonstatic member
functions correctly.  For example,</P>

<PRE>
    struct A {
        typedef int I;    //<SPAN style="font-family:Times;font-style:italic"> public</SPAN>
    };
    struct B: private A { };
    struct C: B {
        void f() {
            I i1;         //<SPAN style="font-family:Times;font-style:italic"> error: access violation</SPAN>
        }
        I i2;             //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
        struct D {
            I i3;         //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
            void g() {
                I i4;     //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
            }
        };
    };
</PRE>

<P>The reason for this discrepancy is that the naming class in
the reference to <TT>I</TT> is different in these cases.  According
to 11.2 [class.access.base] paragraph 5,</P>

<BLOCKQUOTE>

The access to a member is affected by the class in which the member is
named. This naming class is the class in which the member name was
looked up and found.

</BLOCKQUOTE>

<P>In the case of <TT>i1</TT>, the reference to <TT>I</TT> is subject
to the transformation described in 9.3.1 [class.mfct.non-static]
paragraph 3:</P>

<BLOCKQUOTE>

Similarly during name lookup, when an <I>unqualified-id</I>
(5.1 [expr.prim]) used in the definition of a member function
for class <TT>X</TT> resolves to a <TT>static</TT> member, an
enumerator or a nested type of class <TT>X</TT> or of a base class of <TT>X</TT>, the
<I>unqualified-id</I> is transformed into a
<I>qualified-id</I> (5.1 [expr.prim]) in which the
<I>nested-name-specifier</I> names the class of the member function.

</BLOCKQUOTE>

<P>As a result, the reference to <TT>I</TT> in the declaration of
<TT>i1</TT> is transformed to <TT>C::I</TT>, so that the naming class
is <TT>C</TT>, and <TT>I</TT> is inacessible in <TT>C</TT>.  In the
remaining cases, however, the transformation does not apply.  Thus,
the naming class of <TT>I</TT> in these references is <TT>A</TT>, and
<TT>I</TT> is publicly accessible in <TT>A</TT>.</P>

<P>Presumably either the definition of &#8220;naming class&#8221;
must be changed or the transformation of <I>unqualified-id</I>s must
be broadened to include all uses within the scope of a class and not
just within nonstatic member functions (and following the
<I>declarator-id</I> in the definition of a static member, per
9.4 [class.static] paragraph 4).</P>

<BR><BR><HR><A NAME="472"></A><H4>472.
  
Casting across protected inheritance
</H4><B>Section: </B>11.5&#160; [class.protected]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>16 Jun 2004<BR>


<P>Does the restriction in 11.5 [class.protected] apply to
upcasts across protected inheritance, too?  For instance,</P>

<PRE>
    struct B {
        int i;
    };
    struct I: protected B { };
    struct D: I {
        void f(I* ip) {
            B* bp = ip;    // well-formed?
            bp-&gt;i = 5;     // aka "ip-&gt;i = 5;"
        }
    };
</PRE>

<P>I think the rationale for the 11.5 [class.protected]
restriction applies equally well here &#8212; you don't know whether
<TT>ip</TT> points to a <TT>D</TT> object or not, so <TT>D::f</TT> can't be trusted to treat
the protected <TT>B</TT> subobject consistently with the policies of its
actual complete object type.</P>

<P>The current treatment of &#8220;accessible base class&#8221;
in 11.2 [class.access.base] paragraph 4
clearly makes the conversion from <TT>I*</TT> to <TT>B*</TT> well-formed.  I
think that's wrong and needs to be fixed.  The rationale for
the accessibility of a base class is whether &#8220;an invented
public member&#8221; of the base would be accessible at the point of
reference, although we obscured that a bit in the
reformulation; it seems to me that the invented member ought to
be considered a non-static member for this purpose and thus
subject to 11.5 [class.protected].</P>

(See also issues <A HREF="
     cwg_defects.html#385">385</A> and <A HREF="
     cwg_closed.html#471">471</A>.).

<P><B>Notes from October 2004 meeting:</B></P>

<P>The CWG tentatively agreed that casting across protective
inheritance should be subject to the additional restriction in
11.5 [class.protected].</P>



<P><B>Proposed resolution (February, 2010):</B></P>

<P>Change 11.2 [class.access.base] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>A base class <TT>B</TT> of <TT>N</TT> is accessible at <I>R</I>, if</P>

<UL><LI><P>an invented public member of <TT>B</TT> would be a public
member of <TT>N</TT>, or</P></LI>

<LI><P><I>R</I> occurs in a member or friend of class <TT>N</TT>, and
an invented public member of <TT>B</TT> would be a private or
protected member of <TT>N</TT>, or</P></LI>

<LI><P><I>R</I> occurs in a member or friend of a class <TT>P</TT>
derived from <TT>N</TT>, and an invented public member of <TT>B</TT>
would be a private <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or protected</SPAN> member of <TT>P</TT>, or</P></LI>

<LI><P>there exists a class <TT>S</TT> such that <TT>B</TT> is a base
class of <TT>S</TT> accessible at <I>R</I> and <TT>S</TT> is a base
class of <TT>N</TT> accessible at <I>R</I>.</P></LI>

</UL>

<P>[<I>Example:</I></P>

<PRE>
    class B {
    public:
      int m;
    };

    class S: private B {
      friend class N;
    };
    class N: private S {
      void f() {
        B* p = this;    // <SPAN style="font-family:Times;font-style:italic">OK because class </SPAN>S<SPAN style="font-family:Times;font-style:italic"> satisfies the fourth condition</SPAN>
                        // <SPAN style="font-family:Times;font-style:italic">above: </SPAN>B<SPAN style="font-family:Times;font-style:italic"> is a base class of </SPAN>N<SPAN style="font-family:Times;font-style:italic"> accessible in </SPAN>f()<SPAN style="font-family:Times;font-style:italic"> because</SPAN>
                        // B<SPAN style="font-family:Times;font-style:italic"> is an accessible base class of </SPAN>S<SPAN style="font-family:Times;font-style:italic"> and </SPAN>S<SPAN style="font-family:Times;font-style:italic"> is an accessible</SPAN>
                        // <SPAN style="font-family:Times;font-style:italic">base class of </SPAN>N.
      }
    };
<SPAN style="font-weight:bold;background-color:#A0FFA0">
    class N2: protected B { };

    class P2: public N2 {
      void f2(N2* n2p) {
        B* bp = n2p;    // <SPAN style="font-family:Times;font-style:italic">error: invented member would be protected and naming</SPAN>
                        // <SPAN style="font-family:Times;font-style:italic">class </SPAN>N2<SPAN style="font-family:Times;font-style:italic"> not the same as or derived from the referencing</SPAN>
                        // <SPAN style="font-family:Times;font-style:italic">class </SPAN>P2<SPAN style="font-family:Times;font-style:italic"> (cf 11.5 [class.protected])</SPAN>
      }
    };</SPAN>
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="399"></A><H4>399.
  
Destructor lookup redux
</H4><B>Section: </B>12.4&#160; [class.dtor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>17 Jan 2003<BR>


<P>Mark Mitchell raised a number of issues related to the resolution of
<A HREF="
     cwg_defects.html#244">issue 244</A> and of destructor lookup in general.</P>

<P><A HREF="
     cwg_defects.html#244">Issue 244</A> says:</P>
<BLOCKQUOTE>
	... in a <I>qualified-id</I> of the form:
<UL>
::<SUB>opt</SUB> <I>nested-name-specifier</I><SUB>opt</SUB>
   <I>class-name</I> :: ~ <I>class-name</I>
</UL>
	the second class-name is looked up in the same scope as the first.
</BLOCKQUOTE>
<P>But if the reference is "<TT>p-&gt;X::~X()</TT>", the first
<I>class-name</I> is looked up
in two places (normal lookup and a lookup in the class of p).  Does
the new wording mean:
<OL>
<LI>
You look up the second class-name in the scope that you found the first
one.
</LI>
<LI>You look up the second class-name using the same kind of lookup that
   found the first one (normal vs. class).
</LI>
<LI>If you did a dual lookup for the first you do a dual lookup for the
   second.
</LI>
</OL>
</P>

<P>This is a test case that illustrates the issue:</P>
<PRE>
  struct A {
    typedef A C;
  };

  typedef A B;

  void f(B* bp) {
    bp-&gt;B::~B();  // okay B found by normal lookup
    bp-&gt;C::~C();  // okay C found by class lookup
    bp-&gt;B::~C();  // B found by normal lookup C by class -- okay?
    bp-&gt;C::~B();  // C found by class lookup B by normal -- okay?
  }
</PRE>

<P>A second issue concerns destructor references when the class involved is
a template class.</P>
<PRE>
  namespace N {
    template &lt;typename T&gt; struct S {
      ~S();
    };
  }

  void f(N::S&lt;int&gt;* s) {
    s-&gt;N::S&lt;int&gt;::~S();
  }
</PRE>
<P>The issue here is that the grammar uses "~<I>class-name</I>" for destructor
names, but in this case S is a template name when looked up in N.</P>

<P>Finally, what about cases like:</P>
<PRE>
  template &lt;typename T&gt; void f () {
    typename T::B x;
    x.template A&lt;T&gt;::template B&lt;T&gt;::~B();
  }
</PRE>
<P>When parsing the template definition, what checks can be done on "~B"?</P>

<P><U>Sandor Mathe</U> adds
:</P>

<P>The standard correction for <A HREF="
     cwg_defects.html#244">issue 244</A>
(now in DR status) is still incomplete.</P>

<P>Paragraph 5 of 3.4.3 [basic.lookup.qual] is
not applicable for p-&gt;T::~T since there is no nested-name-specifier.
Section 3.4.5 [basic.lookup.classref]
describes the lookup of p-&gt;~T but p-&gt;T::~T is still not
described.  There are examples (which are non-normative) that illustrate
this sort of lookup but they still leave questions unanswered.  The
examples imply that the name after ~ should be looked up in the same
scope as the name before the :: but it is not stated.  The problem is
that the name to the left of the :: can be found in two
different scopes.  Consider the following:</P>
<PRE>
  struct S {
    struct C { ~C() { } };
  };

  typedef S::C D;

  int main() {
    D* p;
    p-&gt;C::~D();  // valid?
  }
</PRE>

<P>Should the destructor call be valid?  If there were a nested name
specifier, then D should be looked for in the same scope as C.  But
here, C is looked for in 2 different ways.  First, it is searched for in
the type of the left hand side of -&gt; and it is also looked for in the
lexical context.  It is found in one or if both, they must match.  So, C
is found in the scope of what p points at.  Do you only look for D there?
If so, this is invalid.  If not, you would then look for D in the context
of the expression and find it.  They refer to the same underlying
destructor so this is valid.  The intended resolution of the original
defect report of the standard was that the name before the :: did not
imply a scope and you did not look for D inside of C.  However, it was
not made clear whether this was to be resolved by using the same lookup
mechanism or by introducing a new form of lookup which is to look in the
left hand side if that is where C was found, or in the context of the
expression if that is where C was found.  Of course, this begs the
question of what should happen when it is found in both?  Consider
the modification to the above case when C is also found in the context
of the expression.  If you only look where you found C, is this now
valid because it is in 1 of the two scopes or is it invalid because C
was in both and D is only in 1?</P>

<PRE>
  struct S {
    struct C { ~C() { } };
  };

  typedef S::C D;
  typedef S::C C;

  int main() {
    D* p;
    p-&gt;C::~D();  // valid?
  }
</PRE>

<P>I agree that the intention of the committee is that the original test
case in this defect is broken.  The standard committee clearly thinks
that the last name before the last :: does not induce a new scope which
is our current interpretation.  However, how this is supposed to work
is not defined.  This needs clarification of the standard.</P>

<P><U>Martin Sebor</U> adds this example (September 2003), along
with errors produced by the EDG front end:</P>
<PRE>
namespace N {
    struct A { typedef A NA; };
    template &lt;class T&gt; struct B { typedef B NB; typedef T BT; };
    template &lt;template &lt;class&gt; class T&gt; struct C { typedef C NC; typedef T&lt;A&gt; CA; };
}

void foo (N::A *p)
{
    p-&gt;~NA ();
    p-&gt;NA::~NA ();
}

template &lt;class T&gt;
void foo (N::B&lt;T&gt; *p)
{
    p-&gt;~NB ();
    p-&gt;NB::~NB ();
}

template &lt;class T&gt;
void foo (typename N::B&lt;T&gt;::BT *p)
{
    p-&gt;~BT ();
    p-&gt;BT::~BT ();
}

template &lt;template &lt;class&gt; class T&gt;
void foo (N::C&lt;T&gt; *p)
{
    p-&gt;~NC ();
    p-&gt;NC::~NC ();
}

template &lt;template &lt;class&gt; class T&gt;
void foo (typename N::C&lt;T&gt;::CA *p)
{
    p-&gt;~CA ();
    p-&gt;CA::~CA ();
}

Edison Design Group C/C++ Front End, version 3.3 (Sep  3 2003 11:54:55)
Copyright 1988-2003 Edison Design Group, Inc.

"t.cpp", line 16: error: invalid destructor name for type "N::B&lt;T&gt;"
      p-&gt;~NB ();
          ^

"t.cpp", line 17: error: qualifier of destructor name "N::B&lt;T&gt;::NB" does not
          match type "N::B&lt;T&gt;"
      p-&gt;NB::~NB ();
              ^

"t.cpp", line 30: error: invalid destructor name for type "N::C&lt;T&gt;"
      p-&gt;~NC ();
          ^

"t.cpp", line 31: error: qualifier of destructor name "N::C&lt;T&gt;::NC" does not
          match type "N::C&lt;T&gt;"
      p-&gt;NC::~NC ();
              ^

4 errors detected in the compilation of "t.cpp".
</PRE>

<P><U>John Spicer:</U>
The issue here is that we're unhappy with the destructor names when doing 
semantic analysis of the template definitions (not during an
instantiation).</P>

<P>My personal feeling is that this is reasonable.  After all, why 
would you call p-&gt;~NB for a class that you just named
as N::B&lt;T&gt; and you could just say p-&gt;~B?</P>

<P><B>Additional note (September, 2004)</B></P>

<P>The resolution for <A HREF="
     cwg_defects.html#244">issue 244</A> removed
the discussion of <TT>p-&gt;N::~S</TT>, where <TT>N</TT> is a
<I>namespace-name</I>.  However, the resolution did not make this
construct ill-formed; it simply left the semantics undefined.
The meaning should either be defined or the construct made
ill-formed.</P>

<P>See also issues <A HREF="
     cwg_defects.html#305">305</A> and
<A HREF="
     cwg_defects.html#466">466</A>.</P>

<BR><BR><HR><A NAME="1202"></A><H4>1202.
  
Calling virtual functions during destruction
</H4><B>Section: </B>12.7&#160; [class.cdtor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Bjarne Stroustrup
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-21<BR>




<P>According to 12.7 [class.cdtor] paragraph 4,</P>

<BLOCKQUOTE>

Member functions, including virtual functions (10.3 [class.virtual]), can be called during construction or destruction
(12.6.2 [class.base.init]).  When a virtual function is called
directly or indirectly from a constructor (including the
<I>mem-initializer</I> or <I>brace-or-equal-initializer</I> for a
non-static data member) or from a destructor, and the object to which
the call applies is the object under construction or destruction, the
function called is the one defined in the constructor or
destructor's own class or in one of its bases, but not a function
overriding it in a class derived from the constructor or
destructor's class, or overriding it in one of the other base
classes of the most derived object (1.8 [intro.object]).

</BLOCKQUOTE>

<P>This is clear regarding virtual functions called during the
initialization of a class's members, but it does not specifically
address the polymorphic behavior of the class during the destruction
of the members.  Presumably the behavior during destruction should
be the exact inverse of that of the constructor, i.e., the class's
virtual functions should still be called during member
destruction.</P>

<P>In addition, the wording</P>

<BLOCKQUOTE>

If the virtual function call uses an explicit class member access
(5.2.5 [expr.ref]) and the object-expression refers to the
object under construction or destruction but its type is neither the
constructor or destructor's own class or one of its bases, the
result of the call is undefined.

</BLOCKQUOTE>

<P>should be clarified that &#8220;refers to the object under
construction&#8221; does not include referring to member
subobjects but only to base or more-derived classes of the class
under construction or destruction.</P>

<BR><BR><HR><A NAME="1082"></A><H4>1082.
  
Implicit copy function if subobject has none?
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-22<BR>


<P>It seems odd to have an implicitly declared copy constructor (and
the same for the copy assignment operator) if one of the subobjects
does not have one.  For example,</P>

<PRE>
    struct A {
       A();
       A(A&amp;&amp;);
    };

    struct B: A { };

    B b;
    B b2(b); //<SPAN style="font-family:Times;font-style:italic"> error when implicitly defining </SPAN>B(B&amp;)<SPAN style="font-family:Times;font-style:italic">, should not be declared</SPAN>
</PRE>

<P>If we don't declare it in that case, we need to decide what happens
if one base has only a move constructor and another has only a copy
constructor.</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The consensus of the CWG was to change the behavior so that all
classes have a declaration of a copy constructor, but that it is
defined as deleted in the cases where the declaration is omitted
by the current rules.</P>

<BR><BR><HR><A NAME="260"></A><H4>260.
  
User-defined conversions and built-in <TT>operator=</TT>
</H4><B>Section: </B>13.6&#160; [over.built]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Scott Douglas
 &#160;&#160;&#160;

 <B>Date: </B>4 Nov 2000<BR>


<P>According to the Standard (although not implemented this way
in most implementations), the following code exhibits non-intuitive
behavior:</P>

<PRE>
  struct T {
    operator short() const;
    operator int() const;
  };

  short s;

  void f(const T&amp; t) {
    s = t;  // surprisingly calls T::operator int() const
  }
</PRE>

<P>The reason for this choice is 13.6 [over.built]
paragraph 18:</P>

<BLOCKQUOTE>

<P>For every triple (<I>L</I>, <I>VQ</I>, <I>R</I>), where <I>L</I> is an
arithmetic type, <I>VQ</I> is either <TT>volatile</TT> or empty, and
<I>R</I> is a promoted arithmetic type, there exist candidate operator
functions of the form</P> 

<UL><I>VQ</I> <I>L</I><TT>&amp; operator=(</TT><I>VQ L</I><TT>&amp;,</TT> <I>R</I><TT>);</TT></UL>

</BLOCKQUOTE>

<P>Because <I>R</I> is a "promoted arithmetic type," the second argument
to the built-in assignment operator is <TT>int</TT>, causing the
unexpected choice of conversion function.</P>

<P><B>Suggested resolution:</B> Provide built-in assignment operators
for the unpromoted arithmetic types.</P>

<P>Related to the preceding, but not resolved by the suggested
resolution, is the following problem.  Given:</P>

<PRE>
    struct T {
	 operator int() const;
	 operator double() const;
    };
</PRE>

<P>I believe the standard requires the following assignment to be
ambiguous (even though I expect that would surprise the user):</P>

<PRE>
    double x;
    void f(const T&amp; t) { x = t; }
</PRE>

<P>The problem is that both of these built-in <TT>operator=()</TT>s exist
(13.6 [over.built] paragraph 18):</P>

<PRE>
    double&amp; operator=(double&amp;, int);
    double&amp; operator=(double&amp;, double);
</PRE>

<P>Both are an exact match on the first argument and a user conversion
on the second.  There is no rule that says one is a better match than
the other.</P>

<P>The compilers that I have tried (even in their strictest setting)
do not give a peep.  I think they are not following the standard.
They pick <TT>double&amp; operator=(double&amp;, double)</TT> and use
<TT>T::operator double() const</TT>.</P>

<P>I hesitate to suggest changes to overload resolution, but a
possible resolution might be to introduce a rule that, for built-in
<TT>operator=</TT> only, also considers the conversion sequence from
the second to the first type.  This would also resolve the earlier
question.</P>

<P>It would still leave <TT>x += t</TT> etc. ambiguous -- which might
be the desired behavior and is the current behavior of some
compilers.</P>

<P><B>Notes from the 04/01 meeting:</B></P>

<P>The difference between initialization and assignment is
disturbing.  On the other hand, promotion is ubiquitous in the
language, and this is the beginning of a very slippery slope (as
the second report above demonstrates).
</P>

<P><B>Additional note (August, 2010):</B></P>

<P>See <A HREF="
     cwg_closed.html#507">issue 507</A> for a similar example
involving comparison operators.</P>

<BR><BR><HR><A NAME="205"></A><H4>205.
  
Templates and static data members
</H4><B>Section: </B>14&#160; [temp]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>11 Feb 2000<BR>



<P>Static data members of template classes and of nested classes of
template classes are not themselves templates but receive much the
same treatment as template.  For instance,
14 [temp]
 paragraph 1 says that templates
are only "classes or functions" but implies that "a static data member
of a class template or of a class nested within a class template" is
defined using the <I>template-declaration</I> syntax.</P>

<P>There are many places in the clause, however, where static data
members of one sort or another are overlooked.  For instance,
14 [temp]
 paragraph 6 allows static data
members of class templates to be declared with the <TT>export</TT>
keyword.  I would expect that static data members of (non-template)
classes nested within class templates could also be exported, but they
are not mentioned here.</P>

<P>Paragraph 8, however, overlooks static data members altogether and
deals only with "templates" in defining the effect of the
<TT>export</TT> keyword; there is no description of the semantics of
defining a static data member of a template to be exported.</P>

<P>These are just two instances of a systematic problem.  The entire
clause needs to be examined to determine which statements about
"templates" apply to static data members, and which statements about
"static data members of class templates" also apply to static data
members of non-template classes nested within class templates.</P>

<P>(The question also applies to member functions of template classes;
see <A HREF="
     cwg_defects.html#217">issue 217</A>, where the phrase
"non-template function" in 8.3.6 [dcl.fct.default] paragraph 4
is apparently intended <I>not</I> to include non-template member
functions of template classes.  See also <A HREF="
     cwg_defects.html#108">issue 108</A>, which would benefit from understanding nested classes of
class templates as templates.  Also, see <A HREF="
     cwg_defects.html#249">issue 249</A>, in which the usage of the phrase "member function
template" is questioned.)</P>

<P><B>Notes from the 4/02 meeting:</B></P>

<P>Daveed Vandevoorde will propose appropriate terminology.</P>

<BR><BR><HR><A NAME="314"></A><H4>314.
  
<TT>template</TT> in base class specifier
</H4><B>Section: </B>14.2&#160; [temp.names]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mark Mitchell
 &#160;&#160;&#160;

 <B>Date: </B>23 Aug 2001<BR>


<P>The EDG front-end accepts:</P>
<PRE>
template &lt;typename T&gt;
struct A {
  template &lt;typename U&gt;
  struct B {};
};

template &lt;typename T&gt;
struct C : public A&lt;T&gt;::template B&lt;T&gt; {
};
</PRE>
<P>It rejects this code if the base-specifier is spelled
<TT>A&lt;T&gt;::B&lt;T&gt;</TT>.</P>

<P>However, the grammar for a base-specifier does not allow the
<TT>template</TT> keyword.</P>

<P><B>Suggested resolution:</B></P>

It seems to me that a consistent approach to the solution that looks like
it will be adopted for <A HREF="
     cwg_defects.html#180">issue 180</A> (which deals
with the <TT>typename</TT> keyword in similar contexts) would be to
assume that <TT>B</TT> is a template if it is followed by a
"&lt;".  After all, an expression cannot appear in this context.

<P><B>Notes from the 4/02 meeting:</B></P>

<P>We agreed that <TT>template</TT> must be allowed in this context.
The syntax needs to be changed.  We also opened the related
<A HREF="
     cwg_active.html#343">issue 343</A>.</P>

<P><B>Additional note (August, 2010):</B></P>

<P>The same considerations apply to <I>mem-initializer-id</I>s, as noted
in <A HREF="
     cwg_closed.html#1019">issue 1019</A>.</P>

<BR><BR><HR><A NAME="1032"></A><H4>1032.
  
Empty pack expansions
</H4><B>Section: </B>14.5.3&#160; [temp.variadic]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>2010-02-16<BR>




<P>It was intended for empty pack expansions to be useful in contexts
like <I>base-specifier</I>s, e.g.,</P>

<PRE>
    template&lt;class... T&gt; struct A : T... {};
    A&lt;&gt; x; // ok?
</PRE>

<P>However, the current wording provides no description of how that
might work.  (More generally, the problem arises in any context
where the pack expansion follows a token that should only be
present when the pack expansion is non-empty: following another
argument in a function call, etc.)</P>

<BR><BR><HR><A NAME="996"></A><H4>996.
  
Ambiguous partial specializations of member class templates
</H4><B>Section: </B>14.5.5&#160; [temp.class.spec]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>28 Oct, 2009<BR>




<P>Given an example like</P>

<PRE>
  template&lt;typename T, typename U&gt;
  struct Outer {
    template&lt;typename X, typename Y&gt; struct Inner;
    template&lt;typename Y&gt; struct Inner&lt;T, Y&gt; {};
    template&lt;typename Y&gt; struct Inner&lt;U, Y&gt; {};
  };
  Outer&lt;int, int&gt; outer;                      // #1
  Outer&lt;int, int&gt;::Inner&lt;int, float&gt; inner;   // #2
</PRE>

<P>Is #1 ill-formed because of the identical partial specializations?
If not, presumably #2 is ill-formed because of the resulting
ambiguity (14.5.5.1 [temp.class.spec.match] paragraph 1).</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The instantiation of <TT>Outer&lt;int,int&gt;</TT> results in
duplicate declarations of the partial specialization, which are
ill-formed by 9.2 [class.mem] paragraph 1. No normative
change is required, but it might be helpful to add an example like
this somewhere.</P>

<BR><BR><HR><A NAME="549"></A><H4>549.
  
Non-deducible parameters in partial specializations
</H4><B>Section: </B>14.5.5.1&#160; [temp.class.spec.match]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin Sebor
 &#160;&#160;&#160;

 <B>Date: </B>18 November 2005<BR>


<P>In the following example, the template parameter in the partial
specialization is non-deducible:</P>

<PRE>
    template &lt;class T&gt; struct A { typedef T U; };
    template &lt;class T&gt; struct C { };
    template &lt;class T&gt; struct C&lt;typename A&lt;T&gt;::U&gt; { };
</PRE>

<P>Several compilers issue errors for this case, but there appears
to be nothing in the Standard that would make this ill-formed; it
simply seems that the partial specialization will never be matched,
so the primary template will be used for all specializations.
Should it be ill-formed?</P>

<P><B>Notes from the April, 2006 meeting:</B></P>

<P>It was noted that there are similar issues for constructors and
conversion operators with non-deducible parameters, and that they
should probably be dealt with similarly.</P>

<BR><BR><HR><A NAME="560"></A><H4>560.
  
Use of the <TT>typename</TT> keyword in return types
</H4><B>Section: </B>14.6&#160; [temp.res]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Greg Comeau
 &#160;&#160;&#160;

 <B>Date: </B>11 February 2006<BR>


<P>Consider the following example:</P>

<PRE>
    template &lt;class T&gt; struct Outer {
        struct Inner {
            Inner* self();
        };
    };
    template &lt;class T&gt; Outer&lt;T&gt;::Inner*
        Outer&lt;T&gt;::Inner::self() { return this; }
</PRE>

<P>According to 14.6 [temp.res] paragraph 3 (before the
salient wording was inadvertently removed, see
<A HREF="
     cwg_defects.html#559">issue 559</A>),</P>

<BLOCKQUOTE>

A <I>qualified-id</I> that refers to a type and in which the
<I>nested-name-specifier</I> depends on a <I>template-parameter</I>
(14.6.2 [temp.dep]) but does not refer to a member of the
current instantiation (14.6.2.1 [temp.dep.type]) shall be
prefixed by the keyword <TT>typename</TT> to indicate that
the <I>qualified-id</I> denotes a type, forming
a <I>typename-specifier</I>.

</BLOCKQUOTE>

<P>Because <TT>Outer&lt;T&gt;::Inner</TT> is a member of the current
instantiation, the Standard does not currently require that it be
prefixed with <TT>typename</TT> when it is used in the return type of
the definition of the <TT>self()</TT> member function.  However, it is
difficult to parse this definition correctly without knowing that the
return type is, in fact, a type, which is what the <TT>typename</TT>
keyword is for.  Should the Standard be changed to require
<TT>typename</TT> in such contexts?</P>

<BR><BR><HR><A NAME="1043"></A><H4>1043.
  
Qualified name lookup in the current instantiation
</H4><B>Section: </B>14.6.2.1&#160; [temp.dep.type]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-05<BR>




<P>14.6.2.1 [temp.dep.type] paragraph 4 treats <I>unqualified-id</I>s
and <I>qualified-id</I>s in which the <I>nested-name-specifier</I> refers
to the current instantiation as equivalent.  However, the lookups
associated with these two <I>id-expression</I>s are different in the
presence of dependent base classes (14.6.2 [temp.dep]
paragraph 3): with an <I>unqualified-id</I>, a dependent base class
scope is never examined, while with a <I>qualified-id</I> it is. The
current wording does not specify how an example like the following is
to be handled:</P>

<PRE>
  template&lt;typename T&gt; struct B {};
  struct C { typedef int type; };

  template&lt;typename T&gt;
  struct A : B&lt;T&gt;, C {
    template&lt;typename U&gt; type a(); // #1
    template&lt;typename U&gt; typename A&lt;T&gt;::type a(); // #2: different from #1?
  };

  template&lt;typename T&gt; template&lt;typename U&gt; typename A&lt;T&gt;::type
    A&lt;T&gt;::a() { ... } // defines #1 or #2?
</PRE>

<P>There seem to be two possible strategies for the handling of
<TT>typename A&lt;T&gt;::type</TT>:</P>

<OL><LI><P>It is handled like the <I>unqualified-id</I> case,
looking only in non-dependent base classes and not being a
dependent type.</P></LI>

<LI><P>Since the current instantiation has dependent base classes,
it is handled as a dependent type.</P></LI>

</OL>

<P>EDG seems to be doing the former, g++ the latter.</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The CWG agreed that if a name is found in a non-dependent base,
the type should be treated as non-dependent also.</P>

<P><B>Additional note (November, 2010):</B></P>

<P>The overall treatment of dependent base classes in handling a
<I>qualified-id</I> in which the <I>nested-name-specifier</I> names
the current instantiation or in a member access expression where the
object expression is <TT>*this</TT> is not very clear.  It would be
helpful if the resolution of this issue could clarify the overall
treatment while dealing with the mixed dependent/non-dependent case
given in the example.</P>

<BR><BR><HR><A NAME="2"></A><H4>2.
  
How can dependent names be used in member declarations that appear outside of the class template definition?
</H4><B>Section: </B>14.6.4&#160; [temp.dep.res]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>unknown
 &#160;&#160;&#160;

 <B>Date: </B>unknown<BR>





<PRE>
    template &lt;class T&gt; class Foo {
    
       public:
       typedef int Bar;
       Bar f();
    };
    template &lt;class T&gt; typename Foo&lt;T&gt;::Bar Foo&lt;T&gt;::f() { return 1;}
                       --------------------
</PRE>
In the class template definition, the declaration of the member function
is interpreted as:
<PRE>
   int Foo&lt;T&gt;::f();
</PRE>
In the definition of the member function that appears outside of the class
template, the return type is not known until the member function
is instantiated.
Must the return type of the member function be known when this out-of-line
definition is seen (in which case the definition above is ill-formed)?
Or is it OK to wait until the member function is instantiated to see if
the type of the return type matches the return type in the class template
definition (in which case the definition above is well-formed)?
    
<P><B>Suggested resolution:</B> (John Spicer)</P>
    
<P>My opinion (which I think matches several posted on the reflector recently)
is that the out-of-class definition must match the
declaration in the template. 
In your example they do match, so it is well formed.</P>
    
<P>I've added some additional cases that illustrate cases that I think
either are allowed or should be allowed, and some cases that I don't think
are allowed.</P>
<PRE>
    template &lt;class T&gt; class A { typedef int X; };
    
    
    template &lt;class T&gt; class Foo {
     public:
       typedef int Bar;
       typedef typename A&lt;T&gt;::X X;
       Bar f();
       Bar g1();
       int g2();
       X h();
       X i();
       int j();
     };
    
     // Declarations that are okay
     template &lt;class T&gt; typename Foo&lt;T&gt;::Bar Foo&lt;T&gt;::f()
                                                     { return 1;}
     template &lt;class T&gt; typename Foo&lt;T&gt;::Bar Foo&lt;T&gt;::g1()
                                                     { return 1;}
     template &lt;class T&gt; int Foo&lt;T&gt;::g2() { return 1;}
     template &lt;class T&gt; typename Foo&lt;T&gt;::X Foo&lt;T&gt;::h() { return 1;}
    
     // Declarations that are not okay
     template &lt;class T&gt; int Foo&lt;T&gt;::i() { return 1;}
     template &lt;class T&gt; typename Foo&lt;T&gt;::X Foo&lt;T&gt;::j() { return 1;}
</PRE>
In general, if you can match the declarations up using only information
from the template, then the declaration is valid.

<P>Declarations like <TT>Foo::i</TT> and <TT>Foo::j </TT>are invalid because
for a given instance of <TT>A&lt;T&gt;</TT>, <TT>A&lt;T&gt;::X</TT> may not actually
be int if the class is specialized.</P>

<P>This is not a problem for <TT>Foo::g1</TT> and <TT>Foo::g2</TT> because
for any instance of <TT>Foo&lt;T&gt;</TT> that is generated from the template
you know that Bar will always be int. If an instance of <TT>Foo</TT> is
specialized, the template member definitions are not used so it doesn't
matter whether a specialization defines <TT>Bar</TT> as int or not.</P>


<BR><BR><HR><A NAME="287"></A><H4>287.
  
Order dependencies in template instantiation
</H4><B>Section: </B>14.6.4.1&#160; [temp.point]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin Sebor
 &#160;&#160;&#160;

 <B>Date: </B>17 May 2001<BR>




<P>Implementations differ in their treatment of the following
code:</P>

<PRE>
    template &lt;class T&gt;
    struct A {
	typename T::X x;
    };

    template &lt;class T&gt;
    struct B {
	typedef T* X;
	A&lt;B&gt; a;
    };

    int main ()
    {
	B&lt;int&gt; b;
    }
</PRE>

<P>Some implementations accept it.  At least one rejects it
because the instantiation of <TT>A&lt;B&lt;int&gt; &gt;</TT>
requires that <TT>B&lt;int&gt;</TT> be complete, and it is
not at the point at which <TT>A&lt;B&lt;int&gt; &gt;</TT>
is being instantiated.</P>

<P><U>Erwin Unruh</U>:</P>

<P>In my view the programm is ill-formed. My reasoning:</P>

<UL>

<LI>you need a complete type <TT>B&lt;int&gt;</TT> because you declare
a variable in <TT>main</TT></LI>

<LI><TT>B&lt;int&gt;</TT> contains a member of type
<TT>A&lt;B&lt;int&gt; &gt;</TT>, so you need that complete.</LI>

<LI><TT>A&lt;B&lt;int&gt; &gt;</TT> tries to access
<TT>B&lt;int&gt;::X</TT>, which in turn needs <TT>B&lt;int&gt;</TT>
being complete.</LI>

</UL>

<P>So each class needs the other to be complete.</P>

<P>The problem can be seen much easier if you replace the typedef with</P>
<PRE>
    typedef T (*X) [sizeof(B::a)];
</PRE>

<P>Now you have a true recursion. The compiler cannot easily distinguish
between a true recursion and a potential recursion.</P>

<P><U>John Spicer</U>:</P>

<P>Using a class to form a qualified name does not require the class to be
complete, it only requires that the named member already have been declared.
In other words, this kind of usage is permitted:</P>

<PRE>
    class A {
        typedef int B;
        A::B ab;
    };
</PRE>

<P>In the same way, once <TT>B</TT> has been declared in <TT>A</TT>,
it is also visible to any template that uses <TT>A</TT> through a
template parameter.</P>

<P>The standard could be more clear in this regard, but there are two
notes that make this point.  Both 3.4.3.1 [class.qual] and
5.1.1 [expr.prim.general] paragraph 7 contain a note that says "a
class member can be referred to using a qualified-id at any point in
its potential scope (3.3.7 [basic.scope.class])."  A member's
potential scope begins at its point of declaration.</P>

<P>In other words, a class has three states: incomplete, being
completed, and complete.  The standard permits a qualified name to be
used once a name has been declared.  The quotation of the notes about
the potential scope was intended to support that.</P>

<P>So, in the original example, class <TT>A</TT> does not require the
type of <TT>T</TT> to be complete, only that it have already declared
a member <TT>X</TT>.</P>

<P><U>Bill Gibbons</U>:</P>

<P>The template and non-template cases are different.  In the non-template
case the order in which the members become declared is clear.  In the
template case the members of the instantiation are conceptually all
created at the same time.  The standard does not say anything about
trying to mimic the non-template case during the instantiation of a class
template.</P>

<P><U>Mike Miller</U>:</P>

<P>I think the relevant specification is 14.6.4.1 [temp.point] paragraph 3, dealing with the point of
instantiation:</P>

<BLOCKQUOTE>

For a class template specialization... if the specialization is
implicitly instantiated because it is referenced from within
another template specialization, if the context from which the
specialization is referenced depends on a template parameter, and
if the specialization is not instantiated previous to the
instantiation of the enclosing template, the point of
instantiation is immediately before the point of instantiation
of the enclosing template.  Otherwise, the point of instantiation
for such a specialization immediately precedes the namespace scope
declaration or definition that refers to the specialization.

</BLOCKQUOTE>

<P>That means that the point of instantiation of <TT>A&lt;B&lt;int&gt;
&gt;</TT> is before that of <TT>B&lt;int&gt;</TT>, not in the middle
of <TT>B&lt;int&gt;</TT> after the declaration of <TT>B::X</TT>, and
consequently a reference to <TT>B&lt;int&gt;::X</TT> from
<TT>A&lt;B&lt;int&gt; &gt;</TT> is ill-formed.</P>

<P>To put it another way, I believe John's approach requires that there
be an instantiation stack, with the results of partially-instantiated
templates on the stack being available to instantiations above them.
I don't think the Standard mandates that approach; as far as I can
see, simply determining the implicit instantiations that need to be
done, rewriting the definitions at their respective points of
instantiation with parameters substituted (with appropriate "forward
declarations" to allow for non-instantiating references), and
compiling the result normally should be an acceptable implementation
technique as well.  That is, the implicit instantiation of the
example (using, e.g., <TT>B_int</TT> to represent the generated name of the
<TT>B&lt;int&gt;</TT> specialization) could be something like</P>

<PRE>
        struct B_int;

        struct A_B_int {
            B_int::X x;    // error, incomplete type
        };

        struct B_int {
            typedef int* X;
            A_B_int a;
        };
</PRE>

<P><B>Notes from 10/01 meeting:</B></P>

<P>This was discussed at length.  The consensus was that the template case
should be treated the same as the non-template class case it terms of
the order in which members get declared/defined and classes get completed.</P>

<P><B>Proposed resolution:</B></P>

<P>
In 14.6.4.1 [temp.point] paragraph 3 change:</P>
<BLOCKQUOTE>
the point of instantiation is immediately before the point of
instantiation of the enclosing template. Otherwise, the point of
instantiation for such a specialization immediately precedes the
namespace scope declaration or definition that refers to the
specialization.
</BLOCKQUOTE>
<P> To:</P>
<BLOCKQUOTE>
the point of instantiation is <SPAN style="font-weight:bold;background-color:#A0FFA0">the same as</SPAN> the point of
instantiation of the enclosing template. Otherwise, the point of
instantiation for such a specialization immediately precedes the
<SPAN style="font-weight:bold;background-color:#A0FFA0">nearest enclosing declaration</SPAN>.
<SPAN style="font-weight:bold;background-color:#A0FFA0">[Note: The point of instantiation is still at namespace scope but
any declarations preceding the point of instantiation, even if not
at namespace scope, are considered to have been seen.]</SPAN>
</BLOCKQUOTE>

<P> Add following paragraph 3:</P>
<BLOCKQUOTE>
If an implicitly instantiated class template specialization, class
member specialization, or specialization of a class template references
a class, class template specialization, class member specialization, or
specialization of a class template containing a specialization reference
that directly or indirectly caused the instantiation, the requirements
of completeness and ordering of the class reference are applied in the
context of the specialization reference.
</BLOCKQUOTE>

<P>and the following example</P>

<PRE>
  template &lt;class T&gt; struct A {
          typename T::X x;
  };

  struct B {
          typedef int X;
          A&lt;B&gt; a;
  };

  template &lt;class T&gt; struct C {
          typedef T* X;
          A&lt;C&gt; a;
  };

  int main ()
  {
          C&lt;int&gt; c;
  }
</PRE>

<P><B>Notes from the October 2002 meeting:</B></P>

<P>This needs work.  Moved back to drafting status.</P>

<BR><BR><HR><A NAME="212"></A><H4>212.
  
Implicit instantiation is not described clearly enough
</H4><B>Section: </B>14.7.1&#160; [temp.inst]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Christophe de Dinechin
 &#160;&#160;&#160;

 <B>Date: </B>7 Mar 2000<BR>




<P>Three points have been raised where the wording in
14.7.1 [temp.inst] may not be sufficiently clear.</P>

<OL>

<LI>

In paragraph 4, the statement is made that

<BLOCKQUOTE>

A class template specialization is implicitly instantiated...  if the
completeness of the class type affects the semantics of the program...

</BLOCKQUOTE>

<P>It is not clear what it means for the "completeness... [to affect]
the semantics."  Consider the following example:</P>

<PRE>
        template&lt;class T&gt; struct A;
        extern A&lt;int&gt; a;

        void *foo() { return &amp;a; }

        template&lt;class T&gt; struct A
        {
        #ifdef OPTION
                void *operator &amp;() { return 0; }
        #endif
        };
</PRE>

<P>The question here is whether it is necessary for template class
<TT>A</TT> to declare an <TT>operator &amp;</TT> for the semantics of the
program to be affected.  If it does not do so, the meaning of
<TT>&amp;a</TT> will be the same whether the class is complete or
not and thus arguably the semantics of the program are not
affected.</P>

<P>Presumably what was intended is whether the presence or absence of
certain member declarations in the template class might be relevant in
determining the meaning of the program.  A clearer statement may be
desirable.</P>

</LI>

<LI>

Paragraph 5 says,

<BLOCKQUOTE>

If the overload resolution process can determine the correct function
to call without instantiating a class template definition, it is
unspecified whether that instantiation actually takes place.

</BLOCKQUOTE>

<P>The intent of this wording, as illustrated in the example in that
paragraph, is to allow a "smart" implementation not to instantiate
class templates if it can determine that such an instantiation will
not affect the result of overload resolution, even though the
algorithm described in clause 13 [over] requires that
all the viable functions be enumerated, including functions that might
be found as members of specializations.</P>

<P>Unfortunately, the looseness of the wording allowing this latitude
for implementations makes it unclear what "the overload resolution
process" is &#8212; is it the algorithm in 13 [over] or
something else? &#8212; and what "the correct function" is.</P>

</LI>

<LI>

According to paragraph 6,

<BLOCKQUOTE>

If an implicit instantiation of a class template specialization is
required and the template is declared but not defined, the program is
ill-formed.

</BLOCKQUOTE>

<P>Here, it is not clear what conditions "require" an implicit
instantiation.  From the context, it would appear that the intent is
to refer to the conditions in paragraph 4 that cause a specialization
to be instantiated.</P>

<P>This interpretation, however, leads to different treatment of
template and non-template incomplete classes.  For example, by this
interpretation,</P>

<PRE>
    class A;
    template &lt;class T&gt; struct TA;
    extern A a;
    extern TA&lt;int&gt; ta;

    void f(A*);
    void f(TA&lt;int&gt;*);

    int main()
    {
        f(&amp;a);    // well-formed; undefined if A
                  // has operator &amp;() member
        f(&amp;ta);   // ill-formed: cannot instantiate
    }
</PRE>

<P>A different approach would be to understand "required" in paragraph
6 to mean that a complete type is required in the expression.  In this
interpretation, if an incomplete type is acceptable in the context and
the class template definition is not visible, the instantiation is not
attempted and the program is well-formed.</P>

<P>The meaning of "required" in paragraph 6 must be clarified.</P>

</LI>

</OL>

<P>(See also issues <A HREF="
     cwg_defects.html#204">204</A> and
<A HREF="
     cwg_defects.html#63">63</A>.)</P>

<P><B>Notes on 10/01 meeting:</B></P>

<P>It was felt that item 1 is solved by addition of the word "might"
in the resolution for <A HREF="
     cwg_defects.html#63">issue 63</A>; item 2
is not much of a problem; and item 3 could be solved by changing
"required" to "required to be complete".</P>

<BR><BR><HR><A NAME="529"></A><H4>529.
  
Use of <TT>template&lt;&gt;</TT> with &#8220;explicitly-specialized&#8221; class templates
</H4><B>Section: </B>14.7.3&#160; [temp.expl.spec]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>16 August 2005<BR>


<P>Paragraph 17 of 14.7.3 [temp.expl.spec] says,</P>

<BLOCKQUOTE>

A member or a member template may be nested within many enclosing
class templates. In an explicit specialization for such a member, the
member declaration shall be preceded by a <TT>template&lt;&gt;</TT>
for each enclosing class template that is explicitly specialized.

</BLOCKQUOTE>

<P>This is curious, because paragraph 3 only allows explicit
specialization of members of implicitly-instantiated class
specializations, not explicit specializations.  Furthermore,
paragraph 4 says,</P>

<BLOCKQUOTE>

Definitions of members of an explicitly specialized class are defined
in the same manner as members of normal classes, and not using the
explicit specialization syntax.

</BLOCKQUOTE>

<P>Paragraph 18 provides a clue for resolving the apparent
contradiction:</P>

<BLOCKQUOTE>

In an explicit specialization declaration for a member of a class
template or a member template that appears in namespace scope, the
member template and some of its enclosing class templates may remain
unspecialized, except that the declaration shall not explicitly
specialize a class member template if its enclosing class templates
are not explicitly specialized as well. In such explicit
specialization declaration, the keyword <TT>template</TT> followed by
a <I>template-parameter-list</I> shall be provided instead of
the <TT>template&lt;&gt;</TT> preceding the explicit specialization
declaration of the member.

</BLOCKQUOTE>

<P>It appears from this and the following example that the phrase
&#8220;explicitly specialized&#8221; in paragraphs 17 and 18, when
referring to enclosing class templates, does not mean that explicit
specializations have been declared for them but that their names in
the <I>qualified-id</I> are followed by template argument lists.  This
terminology is confusing and should be changed.</P>

<P><B>Proposed resolution (October, 2005):</B></P>

<OL><LI><P>Change 14.7.3 [temp.expl.spec] paragraph 17 as
indicated:</P></LI>

<BLOCKQUOTE>

A member or a member template may be nested within many enclosing
class templates. In an explicit specialization for such a member, the
member declaration shall be preceded by a <TT>template&lt;&gt;</TT>
for each enclosing class template <SPAN style="text-decoration:line-through;background-color:#FFA0A0">that is explicitly specialized</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">specialization</SPAN>. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Change 14.7.3 [temp.expl.spec] paragraph 18 as
indicated:</P></LI>

<BLOCKQUOTE>

In an explicit specialization declaration for a member of a class
template or a member template that appears in namespace scope, the
member template and some of its enclosing class templates may remain
unspecialized, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">except that the declaration shall not explicitly
specialize a class member template if its enclosing class templates
are not explicitly specialized as well</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">that is, the
<I>template-id</I> naming the template may be composed of template
parameter names rather than <I>template-argument</I>s</SPAN>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">In</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">For each unspecialized template in</SPAN> such <SPAN style="font-weight:bold;background-color:#A0FFA0">an</SPAN> explicit
specialization declaration, the keyword <TT>template</TT> followed by
a <I>template-parameter-list</I> shall be provided instead of
the <TT>template&lt;&gt;</TT> preceding the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">explicit
specialization</SPAN> declaration of the member. The types of
the <I>template-parameter</I>s in the <I>template-parameter-list</I>
shall be the same as those specified in the primary template
definition. <SPAN style="font-weight:bold;background-color:#A0FFA0">In such declarations, an unspecialized <I>template-id</I>
shall not precede the name of a template specialization in the
<I>qualified-id</I> naming the member.</SPAN> [<I>Example:</I>...

</BLOCKQUOTE>

</OL>

<P><B>Notes from the April, 2006 meeting:</B></P>

<P>The revised wording describing &#8220;unspecialized&#8221; templates
needs more work to ensure that the parameter names in the
<I>template-id</I> are in the correct order; the distinction between
template argyments and parameters is also probably not clear enough.  It
might be better to replace this paragraph completely and avoid the
&#8220;unspecialized&#8221; wording altogether.</P>

<P><B>Proposed resolution (February, 2010):</B></P>

<OL><LI><P>Change 14.7.3 [temp.expl.spec] paragraph 17 as follows:</P></LI>

<BLOCKQUOTE>

A member or a member template may be nested within many enclosing
class templates.  In an explicit specialization for such a
member, the member declaration shall be preceded by a
<TT>template&lt;&gt;</TT> for each enclosing class template
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">that is explicitly specialized</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">specialization</SPAN>. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Change 14.7.3 [temp.expl.spec] paragraph 18 as follows:</P></LI>

<BLOCKQUOTE>

In an explicit specialization declaration for a member of a
class template or a member template that appears in namespace
scope, the member template and some of its enclosing class
templates may remain unspecialized, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">except that the declaration
shall not explicitly specialize a class member template if its
enclosing class templates are not explicitly specialized as well.
In such explicit specialization declaration, the keyword
<TT>template</TT> followed by a <I>template-parameter-list</I>
shall be provided instead of the <TT>template&lt;&gt;</TT>
preceding the explicit specialization declaration of the member.
The types of the <I>template-parameter</I>s in the
<I>template-parameter-list</I> shall be the same as those
specified in the primary template definition.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">that is,
the corresponding template prefix may specify a
<I>template-parameter-list</I> instead of <TT>template&lt;&gt;</TT>
and the <I>template-id</I> naming the template be written using
those <I>template-parameter</I>s as <I>template-argument</I>s.
In such a declaration, the number, kinds, and types of the
<I>template-parameter</I>s shall be the same as those specified in
the primary template definition, and the <I>template-parameter</I>s
shall be named in the <I>template-id</I> in the same order that they
appear in the <I>template-parameter-list</I>.  An unspecialized
<I>template-id</I> shall not precede the name of a template
specialization in the <I>qualified-id</I> naming the member.</SPAN>
[<I>Example:</I>...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1172"></A><H4>1172.
  
&#8220;instantiation-dependent&#8221; constructs
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-05<BR>


<P>There are certain constructs that are not covered by the existing
categories of &#8220;type dependent&#8221; and &#8220;value
dependent.&#8221;  For example, the expression
<TT>sizeof(sizeof(T()))</TT> is neither type-dependent nor
value-dependent, but its validity depends on whether <TT>T</TT>
can be value-constructed.  We should be able to overload on
such characteristics and select via deduction failure, but we
need a term like &#8220;instantiation-dependent&#8221; to
describe these cases in the Standard.  The phrase &#8220;expression
involving a template parameter&#8221; seems to come pretty close to
capturing this idea.</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The CWG favored extending the concepts of &#8220;type-dependent&#8221;
and &#8220;value-dependent&#8221; to cover these additional cases,
rather than adding a new concept.</P>

<BR><BR><HR><A NAME="1184"></A><H4>1184.
  
Argument conversions to nondeduced parameter types
</H4><B>Section: </B>14.8.2.1&#160; [temp.deduct.call]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-29<BR>


<P>It is not clear whether the following example is well-formed or not:</P>

<PRE>
    template&lt;class T&gt; struct identity { typedef T type; };

    template&lt;class T, class C&gt;
    void f(T C::*, typename identity&lt;T&gt;::type*){}

    struct X { void f() {}; };

    int main() { f(&amp;X::f, 0); }
</PRE>

<P>The null pointer conversion required for the second parameter of
<TT>f</TT> is not one of the ones permitted by
14.8.2.1 [temp.deduct.call] paragraph 4, but it's unclear whether
that list should apply to parameters with nondeduced types or not.
14.8.1 [temp.arg.explicit] paragraph 6 is explicit that</P>

<BLOCKQUOTE>

Implicit conversions (Clause 4 [conv]) will be performed
on a function argument to convert it to the type of the corresponding
function parameter if the parameter type contains no
<I>template-parameter</I>s that participate in template argument
deduction.

</BLOCKQUOTE>

<P>However, this statement appears in a section dealing with
explicitly-specified template arguments, so its applicability to
nondeduced contexts in general is not clear.</P>

<P>Implementations disagree on the handling of this example.</P>

<BR><BR><HR><A NAME="692"></A><H4>692.
  
Partial ordering of variadic class template partial specializations
</H4><B>Section: </B>14.8.2.5&#160; [temp.deduct.type]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>16 April, 2008<BR>




<P>14.8.2.5 [temp.deduct.type] paragraph 22 describes how we
cope with partial ordering between two function templates that
differ because one has a function parameter pack while the other
has a normal function parameter.  However, this paragraph was
meant to apply to template parameter packs as well, e.g., to help
with partial ordering of class template partial specializations:</P>

<PRE>
   template &lt;class T1, class ...Z&gt; class S; // #1
   template &lt;class T1, class ...Z&gt; class S&lt;T1, const Z&amp;...&gt; {}; // #2
   template &lt;class T1, class T2&gt; class S&lt;T1, const T2&amp;&gt; {};; // #3
   S&lt;int, const int&amp;&gt; s; // both #2 and #3 match; #3 is more specialized
</PRE>

<P>(See also <A HREF="
     cwg_defects.html#818">issue 818</A>.)</P>

<P><B>Proposed resolution (March, 2009):</B></P>

<P>Change 14.8.2.5 [temp.deduct.type] paragraphs 9-10 as follows
(and add the example above to paragraph 9):</P>

<BLOCKQUOTE>

<P>If <TT>P</TT> has a form that contains &lt;<TT>T</TT>&gt; or
&lt;<TT>i</TT>&gt;, then each argument
<TT>P</TT><SUB><I>i</I></SUB> of the respective template argument
list of <TT>P</TT> is compared with the corresponding argument
<TT>A</TT><SUB><I>i</I></SUB> of the corresponding template
argument list of <TT>A</TT>. If the template argument list of
<TT>P</TT> contains a pack expansion that is not the last
template argument, the entire template argument list is a
non-deduced context. If <TT>P</TT><SUB><I>i</I></SUB> is a pack
expansion, then the pattern of <TT>P</TT><SUB><I>i</I></SUB> is
compared with each remaining argument in the template argument
list of <TT>A</TT>. Each comparison deduces template arguments
for subsequent positions in the template parameter packs expanded
by <TT>P</TT><SUB><I>i</I></SUB>. <SPAN style="font-weight:bold;background-color:#A0FFA0">During partial ordering
(14.8.2.4 [temp.deduct.partial]), if <TT>A</TT><SUB><I>i</I></SUB>
was originally a pack expansion and <TT>P</TT><SUB><I>i</I></SUB>
is not a pack expansion, or if <TT>P</TT> does not contain a
template argument corresponding to <TT>A</TT><SUB><I>i</I></SUB>,
argument deduction fails.</SPAN></P>

<P>Similarly, if <TT>P</TT> has a form that contains
<TT>(T)</TT>, then each parameter type
<TT>P</TT><SUB><I>i</I></SUB> of the respective
<I>parameter-type-list</I> of <TT>P</TT> is compared with the
corresponding parameter type <TT>A</TT><SUB><I>i</I></SUB> of the
corresponding <I>parameter-type-list</I> of <TT>A</TT>. If the
<I>parameter-declaration</I> corresponding to
<TT>P</TT><SUB><I>i</I></SUB> is a function parameter pack, then
the type of its <I>declarator-id</I> is compared with each
remaining parameter type in the <I>parameter-type-list</I> of
<TT>A</TT>. Each comparison deduces template arguments for
subsequent positions in the template parameter packs expanded by
the function parameter pack. <SPAN style="font-weight:bold;background-color:#A0FFA0">During partial ordering
(14.8.2.4 [temp.deduct.partial]), if <TT>A</TT><SUB><I>i</I></SUB>
was originally a function parameter pack and
<TT>P</TT><SUB><I>i</I></SUB> is not a function parameter
pack, or if <TT>P</TT> does not contain a function parameter type
corresponding to <TT>A</TT><SUB><I>i</I></SUB>, argument deduction
fails.</SPAN> [<I>Note:</I> A function parameter pack
can only occur at the end of a <I>parameter-declaration-list</I>
(8.3.5 [dcl.fct]). &#8212;<I>end note</I>]</P>

</BLOCKQUOTE>

<BR><BR><BR><BR><HR><A NAME="Open Status"></A><H3>Issues with "Open" Status</H3>
<HR><A NAME="916"></A><H4>916.
  
Does a reference type have a destructor?
</H4><B>Section: </B>_N2914_.14.10.2.1&#160; [concept.map.fct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>12 June, 2009<BR>




<P>Is the following well-formed?</P>

<PRE>
    auto concept HasDestructor&lt;typename T&gt; {
      T::~T();
    }

    concept_map HasDestructor&lt;int&amp;&gt; { }
</PRE>

<P>According to _N2914_.14.10.2.1 [concept.map.fct] paragraph 4, the
destructor requirement in the concept map results in an expression
<TT>x.~X()</TT>, where <TT>X</TT> is the type <TT>int&amp;</TT>.
According to 5.2.4 [expr.pseudo], this expression is ill-formed
because the object type and the <I>type-name</I> must be the same type,
but the object type cannot be a reference type (references are dropped
from types used in expressions, 5 [expr] paragraph 5).</P>

<P>It is not clear whether this should be addressed by changing
5.2.4 [expr.pseudo] or _N2914_.14.10.2.1 [concept.map.fct].</P>

<BR><BR><HR><A NAME="616"></A><H4>616.
  
Definition of &#8220;indeterminate value&#8221;
</H4><B>Section: </B>1.3&#160; [intro.defs]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Bjarne Stroustrup
 &#160;&#160;&#160;

 <B>Date: </B>2 February 2007<BR>




<P>The C++ Standard uses the phrase &#8220;indeterminate value&#8221;
without defining it.  C99 defines it as &#8220;either an unspecified
value or a trap representation.&#8221;  Should C++ follow suit?</P>

<P>In addition, 4.1 [conv.lval] paragraph 1 says that
applying the lvalue-to-rvalue conversion to an &#8220;object
[that] is uninitialized&#8221; results in undefined behavior;
this should be rephrased in terms of an object with an
indeterminate value.</P>

<BR><BR><HR><A NAME="783"></A><H4>783.
  
Definition of &#8220;argument&#8221;
</H4><B>Section: </B>1.3&#160; [intro.defs]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>UK
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK3">N2800 comment
  UK&#160;3<BR></A>

<P>The definition of an argument does not seem to cover 
many assumed use cases, and we believe that is not 
intentional. There should be answers to
questions such as: Are lambda-captures 
arguments? Are type names in a throw-spec 
arguments? &#8220;Argument&#8221; to casts, typeid, alignof, 
alignas, decltype and sizeof? why in x[arg] arg is 
not an argument, but the value forwarded to 
operator[]() is? Does not apply to operators as 
call-points not bounded by parentheses? Similar 
for copy initialization and conversion? What are 
deduced template &#8220;arguments?&#8221; what are &#8220;default 
arguments?&#8221; can attributes have arguments? What 
about concepts, requires clauses and 
concept_map instantiations? What about user-defined
literals where parens are not used?</P>

<BR><BR><HR><A NAME="949"></A><H4>949.
  
Requirements for freestanding implementations
</H4><B>Section: </B>1.4&#160; [intro.compliance]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Detlef Vollman
 &#160;&#160;&#160;

 <B>Date: </B>2 August, 2009<BR>




<P>According to 1.4 [intro.compliance] paragraph 7,</P>

<BLOCKQUOTE>

A freestanding implementation is one in which execution may take place
without the benefit of an operating system, and has an
implementation-defined set of libraries that includes certain
language-support libraries (17.6.1.3 [compliance]).

</BLOCKQUOTE>

<P>This definition links two relatively separate topics: the lack
of an operating system and the minimal set of libraries.
Furthermore, 3.6.1 [basic.start.main] paragraph 1 says:</P>

<BLOCKQUOTE>

[<I>Note:</I> in a freestanding environment, start-up and termination
is implementation-defined; start-up contains the execution of
constructors for objects of namespace scope with static storage
duration; termination contains the execution of destructors for
objects with static storage duration. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>It would be helpful if the two characteristics (lack of an
operating system and restricted set of libraries) were named
separately and if these statements were clarified to identify exactly
what is implementation-defined.</P>

<P><B>Notes from the October, 2009 meeting:</B></P>

<P>The CWG felt that it needed a specific proposal in a paper before
attempting to resolve this issue.</P>

<BR><BR><HR><A NAME="784"></A><H4>784.
  
List of incompatibilities with the previous Standard
</H4><B>Section: </B>1.5&#160; [intro.structure]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>UK
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK6">N2800 comment
  UK&#160;6<BR></A>

<P>There should be a list of incompatibilities between the current
and previous Standards, as in ISO/IEC TR 10176 4.1.1 paragraph 9.</P>

<P>(See document N2733 for an initial list of this information.)</P>

<BR><BR><HR><A NAME="129"></A><H4>129.
  
Stability of uninitialized auto variables
</H4><B>Section: </B>1.9&#160; [intro.execution]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Nathan Myers
 &#160;&#160;&#160;

 <B>Date: </B>26 June 1999<BR>





<P>Does the Standard require that an uninitialized auto variable have
a stable (albeit indeterminate) value?  That is, does the Standard
require that the following function return <TT>true</TT>?</P>

<PRE>
    bool f() {
        unsigned char i;  // not initialized
        unsigned char j = i;
        unsigned char k = i;
        return j == k;    // true iff "i" is stable
    }
</PRE>

3.9.1 [basic.fundamental]
 paragraph 1
requires that uninitialized <TT>unsigned char</TT> variables have a
valid value, so the initializations of <TT>j</TT> and <TT>k</TT> are
well-formed and required not to trap.  The question here is whether
the value of <TT>i</TT> is allowed to change between those
initializations.

<P><U>Mike Miller</U>:
1.9 [intro.execution]
 paragraph 10 says,</P>

<BLOCKQUOTE>
An instance of each object with automatic storage
duration (3.7.3 [basic.stc.auto]
) is
associated with each entry into
its block.  Such an object exists and retains its
last-stored value during the execution of the block
and while the block is suspended...
</BLOCKQUOTE>

I think that the most reasonable way to read this is that the
only thing that is allowed to change the value of an automatic
(non-volatile?) value is a "store" operation in the abstract
machine.  There are no "store" operations to <TT>i</TT> between the
initializations of <TT>j</TT> and <TT>k</TT>, so it must retain its
original (indeterminate but valid) value, and the result of
the program is well-defined.

<P>The quibble, of course, is whether the wording "last-stored
value" should be applied to a "never-stored" value.  I
think so, but others might differ.</P>

<P><U>Tom Plum</U>:
7.1.6.1 [dcl.type.cv]
 paragraph 8 says,</P>

<BLOCKQUOTE>
[<I>Note:</I> <TT>volatile</TT> is a hint to the implementation
to avoid aggressive
optimization involving
the object because the value of the object might be changed by means
undetectable 
by an implementation. See
1.9 [intro.execution]
 for detailed
semantics. In general, the semantics
of <TT>volatile</TT>
are intended to be the same in C++ as they are in C. ]
</BLOCKQUOTE>

&gt;From this I would infer that non-volatile means "shall not be
changed
by means undetectable by an implementation"; that the compiler is entitled to
safely cache accesses to non-volatile objects if it can prove that no
"detectable"
means can modify them; and that therefore  i  <I>shall</I>
maintain the same value
during the example above.

<P><U>Nathan Myers</U>:
This also has practical code-generation consequences.  If the
uninitialized auto variable lives in a register, and its value is 
<I>really</I> unspecified, then until it is initialized that register 
can be used as a temporary.  Each time it's "looked at" the variable
has the value that last washed up in that register.  After it's 
initialized it's "live" and cannot be used as a temporary any more, 
and your register pressure goes up a notch.  Fixing the uninit'd 
value would make it "live" the first time it is (or might be) looked 
at, instead.</P>

<P><U>Mike Ball</U>:
I agree with this.  I also believe that it was certainly never
my intent that an uninitialized variable be stable, and I would
have strongly argued against such a provision.  Nathan has well
stated the case.
And I am quite certain that it would be disastrous for optimizers.
To ensure it, the frontend would have to generate an initializer,
because optimizers track not only the lifetimes of variables, but
the lifetimes of values assigned to those variables.  This would
put C++ at a significant performance disadvantage compared to
other languages.  Not even Java went this route.  Guaranteeing 
defined behavior for a very special case of a generally undefined
operation seems unnecessary.</P>
<BR><BR><HR><A NAME="698"></A><H4>698.
  
The definition of &#8220;sequenced before&#8221; is too narrow
</H4><B>Section: </B>1.9&#160; [intro.execution]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jens Maurer
 &#160;&#160;&#160;

 <B>Date: </B>13 July, 2008<BR>




<P>According to 1.9 [intro.execution] paragraph 14, &#8220;sequenced
before&#8221; is a relation between &#8220;evaluations.&#8221;  However,
3.6.3 [basic.start.term] paragraph 3 says,</P>

<BLOCKQUOTE>

If the completion of the initialization of a non-local object with
static storage duration is sequenced before a call to
<TT>std::atexit</TT> (see <TT>&lt;cstdlib&gt;</TT>, 18.5 [support.start.term]), the call to the function passed to <TT>std::atexit</TT>
is sequenced before the call to the destructor for the object. If a
call to <TT>std::atexit</TT> is sequenced before the completion of the
initialization of a non-local object with static storage duration, the
call to the destructor for the object is sequenced before the call to
the function passed to <TT>std::atexit</TT>. If a call to
<TT>std::atexit</TT> is sequenced before another call to
<TT>std::atexit</TT>, the call to the function passed to the second
<TT>std::atexit</TT> call is sequenced before the call to the function
passed to the first <TT>std::atexit</TT> call.

</BLOCKQUOTE>

<P>Except for the calls to <TT>std::atexit</TT>, these events do not
correspond to &#8220;evaluation&#8221; of expressions that appear in
the program.  If the &#8220;sequenced before&#8221; relation is to be
applied to them, a more comprehensive definition is needed.</P>

<BR><BR><HR><A NAME="578"></A><H4>578.
  
Phase 1 replacement of characters with <I>universal-character-name</I>s
</H4><B>Section: </B>2.2&#160; [lex.phases]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin Vejn&#225;r
 &#160;&#160;&#160;

 <B>Date: </B>7 May 2006<BR>


<P>According to 2.2 [lex.phases] paragraph 1, in translation
phase 1,</P>

<BLOCKQUOTE>

Any source file character not in the basic source character set
(2.3 [lex.charset]) is replaced by the
universal-character-name that designates that character.

</BLOCKQUOTE>

<P>If a character that is not in the basic character set is preceded
by a backslash character, for example</P>

<PRE>
    "\&#225;"
</PRE>

<P>the result is equivalent to</P>

<PRE>
    "\\u00e1"
</PRE>

<P>that is, a backslash character followed by the spelling of the
universal-character-name.  This is different from the result in C99,
which accepts characters from the extended source character set without
replacing them with universal-character-names.</P>

<BR><BR><HR><A NAME="985"></A><H4>985.
  
Alternative tokens and user-defined literals
</H4><B>Section: </B>2.6&#160; [lex.digraph]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>19 October, 2009<BR>


<P>2.12 [lex.key] paragraph 2 says,</P>

<BLOCKQUOTE>

Furthermore, the alternative representations shown in Table 4 for
certain operators and punctuators (2.6 [lex.digraph]) are
reserved and shall not be used otherwise:

</BLOCKQUOTE>

<P>Also, 2.6 [lex.digraph] paragraph 2 says,</P>

<BLOCKQUOTE>

In all respects of the language, each alternative token
behaves the same, respectively, as its primary token, except
for its spelling.

</BLOCKQUOTE>

<P>It is not clear whether the following example is well-formed:</P>

<PRE>
    #define STR2(x)  #x
    #define STR(x)   STR2(x)
    int main() {
        return sizeof STR('\0'bitor 0) - sizeof STR('\0'bitor 0);
    }
</PRE>

<P>In this example, <TT>bitor</TT> is not the <TT>|</TT> operator but
the <I>identifier</I> in a <I>user-defined-character-literal</I>.
Does this violate the restrictions of 2.12 [lex.key] and
2.6 [lex.digraph]?</P>

<BR><BR><HR><A NAME="912"></A><H4>912.
  
Character literals and <I>universal-character-name</I>s
</H4><B>Section: </B>2.14.3&#160; [lex.ccon]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>7 June, 2009<BR>


<P>According to 2.14.3 [lex.ccon] paragraph 1,</P>

<BLOCKQUOTE>

A character literal that does not begin with <TT>u</TT>, <TT>U</TT>,
or <TT>L</TT> is an ordinary character literal, also referred to as a
narrow-character literal.  An ordinary character literal that contains
a single <I>c-char</I> has type <TT>char</TT>, with value equal to the
numerical value of the encoding of the c-char in the execution
character set.

</BLOCKQUOTE>

<P>However, the definition of <I>c-char</I> includes as one
possibility a <I>universal-character-name</I>.  The value of a
<I>universal-character-name</I> cannot, in general, be represented
as a <TT>char</TT>, so this specification is impossible to
satisfy.</P>

<P>(See also <A HREF="
     cwg_active.html#411">issue 411</A> for related
questions.)</P>

<BR><BR><HR><A NAME="1024"></A><H4>1024.
  
Limits on multicharacter literals
</H4><B>Section: </B>2.14.3&#160; [lex.ccon]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>2010-01-31<BR>


<P>There is no limit placed on the number of <I>c-char</I>s in a
multicharacter literal or a wide-character literal containing
multiple <I>c-char</I>s, either in 2.14.3 [lex.ccon]
paragraphs 1-2 or in Annex B [implimits].  Presumably
this means that an implementation must accept arbitrarily long
literals.</P>

<P>An alternative approach might be to state that these literals
are conditionally supported with implementation-defined semantics,
allowing an implementation to impose a documented limit that
makes sense for the particular architecture.</P>

<BR><BR><HR><A NAME="411"></A><H4>411.
  
Use of universal-character-name in character versus string literals
</H4><B>Section: </B>2.14.5&#160; [lex.string]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Kanze
 &#160;&#160;&#160;

 <B>Date: </B>23 Apr 2003<BR>


<P>2.14.5 [lex.string] paragraph 5 reads</P>
<BLOCKQUOTE>
Escape sequences and
universal-character-names in string literals have the same meaning as in
character literals, except that the single quote ' is representable
either by itself or by the escape sequence \', and the double quote "
shall be preceded by a \. In a narrow string literal, a
universal-character-name may map to more than one char element due to
multibyte encoding.
</BLOCKQUOTE>

<P>The first sentence refers us to 2.14.3 [lex.ccon],
where we read in the
first paragraph that "An ordinary character literal that contains a
single c-char has type char [...]."  Since the grammar shows that a
universal-character-name is a c-char, something like '\u1234' must have
type char (and thus be a single char element); in paragraph 5, we read
that "A universal-character-name is translated to the encoding, in the
execution character set, of the character named.  If there is no such
encoding, the universal-character-name is translated to an
implemenation-defined encoding."</P>

<P>This is in obvious contradiction with the second sentence.  In addition,
I'm not really clear what is supposed to happen in the case where the
execution (narrow-)character set is UTF-8.  Consider the character
\u0153 (the oe in the French word oeuvre).  Should '\u0153' be a char,
with an "error" value, say '?' (in conformance with the requirement that
it be a single char), or an int, with the two char values 0xC5, 0x93, in
an implementation defined order (in conformance with the requirement
that a character representable in the execution character set be
represented).  Supposing the former, should "\u0153" be the equivalent of
"?" (in conformance with the first sentence), or "\xC5\x93" (in
conformance with the second).</P>

<P><B>Notes from October 2003 meeting:</B></P>

<P>We decided we should forward this to the C committee and let them
resolve it.  Sent via e-mail to John Benito on November 14, 2003.</P>

<P><B>Reply from John Benito:</B></P>
<BLOCKQUOTE>
<P>I talked this over with the C project editor, we believe this was
handled by the C committee before publication of the current standard.</P>

<P>WG14 decided there needed to be a more restrictive rule 
for one-to-one mappings: rather than saying "a single c-char" 
as C++ does, the C standard says "a single character that
maps to a single-byte execution character"; WG14 fully expect
some (if not many or even most) UCNs to map to multiple characters.</P>

<P>Because of the fundamental differences between C and C++ character
types, I am not sure the C committee is qualified to answer this
satisfactorily for WG21.  WG14 is willing to review any decision reached
for compatibility.</P>

<P>I hope this helps.</P>
</BLOCKQUOTE>

<P>(See also <A HREF="
     cwg_active.html#912">issue 912</A> for a related
question.)</P>

<BR><BR><HR><A NAME="1108"></A><H4>1108.
  
User-defined literals have not been implemented
</H4><B>Section: </B>2.14.8&#160; [lex.ext]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US18">N3092 comment
  US&#160;18<BR></A>

<P>User-defined literals should not be part of C++0x unless they have
implementation experience.</P>

<BR><BR><HR><A NAME="1239"></A><H4>1239.
  
Hexadecimal floating-point literals vs user-defined literals
</H4><B>Section: </B>2.14.8&#160; [lex.ext]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Howard Hinnant
 &#160;&#160;&#160;

 <B>Date: </B>2011-01-28<BR>




<P>2.11 [lex.name] paragraph 3 says,</P>

<BLOCKQUOTE>

In addition, some identifiers are reserved for use by C++
implementations and standard libraries (17.6.3.3.2 [global.names]) and shall not be used otherwise; no diagnostic is
required.

</BLOCKQUOTE>

<P>There is no corresponding mention in 2.14.8 [lex.ext]
of the restrictions on user-defined literal suffixes in
17.6.3.3.5 [usrlit.suffix].  Furthermore, considering the
likelihood of adding hexadecimal floating-point literals, whose
syntax overlaps that of user-defined literals except for that
restriction, it would be a good idea to require a diagnostic for
a violation of that rule.</P>

<BR><BR><HR><A NAME="1209"></A><H4>1209.
  
Is a potentially-evaluated expression in a template definition a &#8220;use?&#8221;
</H4><B>Section: </B>3.2&#160; [basic.def.odr]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-08<BR>




<P>Consider the following complete program:</P>

<PRE>
    void f();
    template&lt;typename T&gt; void g() { f(); }
    int main() { }
</PRE>

<P>Must <TT>f()</TT> be defined to make this program well-formed?  The
current wording of 3.2 [basic.def.odr] does not make any special
provision for expressions that appear only in uninstantiated template
definitions.</P>

<BR><BR><HR><A NAME="191"></A><H4>191.
  
Name lookup does not handle complex nesting
</H4><B>Section: </B>3.4.1&#160; [basic.lookup.unqual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alan Nash
 &#160;&#160;&#160;

 <B>Date: </B>29 Dec 1999<BR>





<P>The current description of unqualified name lookup in
3.4.1 [basic.lookup.unqual]
 paragraph 8 does
not correctly handle complex cases of nesting.  The Standard
currently reads,</P>

<BLOCKQUOTE>
A name used in the definition of a function that is a member function
(9.3) of a class <TT>X</TT> shall be declared in one of the following
ways:

<BR><UL>
<LI>before its use in the block in which it is used or in an enclosing
block (6.3), or</LI>

<LI>shall be a member of class <TT>X</TT> or be a member of a base
class of <TT>X</TT> (10.2), or</LI>

<LI>if <TT>X</TT> is a nested class of class <TT>Y</TT> (9.7), shall
be a member of <TT>Y</TT>, or shall be a member of a base class of
<TT>Y</TT> (this lookup applies in turn to <TT>Y</TT>'s enclosing
classes, starting with the innermost enclosing class), or</LI>

<LI>if <TT>X</TT> is a local class (9.8) or is a nested class of a
local class, before the definition of class <TT>X</TT> in a block
enclosing the definition of class <TT>X</TT>, or</LI>

<LI>if <TT>X</TT> is a member of namespace <TT>N</TT>, or is a nested
class of a class that is a member of <TT>N</TT>, or is a local class
or nested class within a local class of a function that is a member of
<TT>N</TT>, before the member function definition, in namespace
<TT>N</TT> or in one of <TT>N</TT>'s enclosing namespaces.</LI>
</UL>
</BLOCKQUOTE>

In particular, this formulation does not handle the following example:

<PRE>
    struct outer {
        static int i;
        struct inner {
            void f() {
                struct local {
                    void g() {
                        i = 5;
                    }
                };
            }
        };
    };
</PRE>

Here the reference to <TT>i</TT> is from a member function of a local
class of a member function of a nested class.  Nothing in the rules
allows <TT>outer::i</TT> to be found, although intuitively it should
be found.

<P>A more comprehensive formulation is needed that allows traversal of
any combination of blocks, local classes, and nested classes.
Similarly, the final bullet needs to be augmented so that a function
need not be a (direct) member of a namespace to allow searching that
namespace when the reference is from a member function of a class
local to that function.  That is, the current rules do not allow the
following example:</P>

<PRE>
    int j;    // global namespace
    struct S {
        void f() {
            struct local2 {
                void g() {
                    j = 5;
                }
            };
        }
    };
</PRE>
<BR><BR><HR><A NAME="192"></A><H4>192.
  
Name lookup in parameters
</H4><B>Section: </B>3.4.1&#160; [basic.lookup.unqual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alan Nash
 &#160;&#160;&#160;

 <B>Date: </B>6 Jan 2000<BR>





<P>The description of name lookup in the
<I>parameter-declaration-clause</I> of member functions in
3.4.1 [basic.lookup.unqual]
 paragraphs 7-8 is
flawed in at least two regards.</P>

<P>First, both paragraphs 7 and 8 apply to the
<I>parameter-declaration-clause</I> of a member function definition
and give different rules for the lookup.  Paragraph 7 applies to names
"used in the definition of a class <TT>X</TT> outside of a member
function body...," which includes the
<I>parameter-declaration-clause</I> of a member function definition,
while paragraph 8 applies to names following the function's
<I>declarator-id</I> (see the proposed resolution of
<A HREF="
     cwg_defects.html#41">issue 41</A>), including the
<I>parameter-declaration-clause</I>.</P>

<P>Second, paragraph 8 appears to apply to the type names used in the
<I>parameter-declaration-clause</I> of a member function defined
inside the class definition.  That is, it appears to allow the
following code, which was not the intent of the Committee:</P>

<PRE>
    struct S {
        void f(I i) { }
        typedef int I;
    };
</PRE>
<BR><BR><HR><A NAME="405"></A><H4>405.
  
Unqualified function name lookup
</H4><B>Section: </B>3.4.1&#160; [basic.lookup.unqual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>William M. Miller
 &#160;&#160;&#160;

 <B>Date: </B>14 Apr 2003<BR>


<P>There seems to be some confusion in the Standard regarding the
relationship between 3.4.1 [basic.lookup.unqual] (Unqualified name
lookup) and 3.4.2 [basic.lookup.argdep]
(Argument-dependent lookup).  For example,
3.4.1 [basic.lookup.unqual] paragraph 3 says,</P>

<BLOCKQUOTE>
The lookup for an unqualified name used as the
<I>postfix-expression</I> of a function call is described in
3.4.2 [basic.lookup.argdep].
</BLOCKQUOTE>

<P>In other words, nothing in 3.4.1 [basic.lookup.unqual]
applies to function names; the entire lookup is described in
3.4.2 [basic.lookup.argdep].</P>

<P>3.4.2 [basic.lookup.argdep] does not appear to share this
view of its responsibility.
The closest it comes is in 3.4.2 [basic.lookup.argdep] paragraph 2a:</P>

<BLOCKQUOTE>
...the set of declarations found by the lookup of the function
name is the union of the set of declarations found using ordinary
unqualified lookup and the set of declarations found in the namespaces
and classes associated with the argument types.
</BLOCKQUOTE>

<P>Presumably, "ordinary unqualified lookup" is a reference
to the processing described in
3.4.1 [basic.lookup.unqual], but, as noted above,
3.4.1 [basic.lookup.unqual]
explicitly precludes applying that processing to function names.  The
details of "ordinary unqualified lookup" of function names
are not described anywhere.</P>

<P>The other clauses that reference
3.4.2 [basic.lookup.argdep], clauses
13 [over] and 14 [temp], are
split over the question of the relationship between
3.4.1 [basic.lookup.unqual] and 3.4.2 [basic.lookup.argdep].
13.3.1.1.1 [over.call.func] paragraph 3, for instance, says</P>

<BLOCKQUOTE>
The name is looked up in the context of the function call
following the normal rules for name lookup in function calls
(3.4.2 [basic.lookup.argdep]).
</BLOCKQUOTE>

<P>I.e., this reference assumes that
3.4.2 [basic.lookup.argdep] is self-contained.  The
same is true of 13.3.1.2 [over.match.oper] paragraph 3,
second bullet:</P>

<BLOCKQUOTE>
The set of non-member candidates is the result of the
unqualified lookup of operator@ in the context of the expression
according to the usual rules for name lookup in unqualified function
calls (3.4.2 [basic.lookup.argdep]), except that all member
functions are ignored.
</BLOCKQUOTE>

<P>On the other hand, however, 14.6.4.2 [temp.dep.candidate]
paragraph 1 explicitly assumes that
3.4.1 [basic.lookup.unqual] and 3.4.2 [basic.lookup.argdep] are
both involved in function name lookup and do different things:</P>

<BLOCKQUOTE>
For a function call that depends on a template parameter, if
the function name is an <I>unqualified-id</I> but not a
<I>template-id</I>, the candidate functions are found using the usual
lookup rules (3.4.1 [basic.lookup.unqual],
3.4.2 [basic.lookup.argdep]) except that:
<UL>
<LI>For the part of the lookup using unqualified name lookup
(3.4.1 [basic.lookup.unqual]),
only function declarations with external linkage from the template
definition context are found.</LI>

<LI>For the part of the lookup using associated
namespaces (3.4.2 [basic.lookup.argdep]),
only function declarations with external linkage found in either the
template definition context or the template instantiation context are
found.</LI>
</UL>
</BLOCKQUOTE>

<B><P>Suggested resolution:</P></B>

<P>Change 3.4.1 [basic.lookup.unqual] paragraph 1 from</P>

<BLOCKQUOTE>
...name lookup ends as soon as a declaration is found for the
name.
</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>
...name lookup ends with the first scope containing one or more
declarations of the name.
</BLOCKQUOTE>

<P>Change the first sentence of 3.4.1 [basic.lookup.unqual]
paragraph 3 from</P>

<BLOCKQUOTE>
The lookup for an unqualified name used as the
<I>postfix-expression</I> of a function call is described in
3.4.2 [basic.lookup.argdep].
</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>
An unqualified name used as the <I>postfix-expression</I> of a
function call is looked up as described below.  In addition,
argument-dependent lookup (3.4.2 [basic.lookup.argdep]) is
performed on this name to
complete the resulting set of declarations.
</BLOCKQUOTE>

<BR><BR><HR><A NAME="1200"></A><H4>1200.
  
Lookup rules for template parameters
</H4><B>Section: </B>3.4.1&#160; [basic.lookup.unqual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-18<BR>


<P>Although 3.3.9 [basic.scope.temp] now describes the scope of a
template parameter, the description of unqualified name lookup in
3.4.1 [basic.lookup.unqual] do not cover uses of template parameter
names.  The note in 3.4.1 [basic.lookup.unqual] paragraph 16 says,</P>

<BLOCKQUOTE>

the rules for name lookup in template definitions are described in
14.6 [temp.res].

</BLOCKQUOTE>

<P>but the rules there cover dependent and non-dependent names, not
template parameters themselves.</P>

<BR><BR><HR><A NAME="321"></A><H4>321.
  
Associated classes and namespaces for argument-dependent lookup
</H4><B>Section: </B>3.4.2&#160; [basic.lookup.argdep]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Andrei Iltchenko
 &#160;&#160;&#160;

 <B>Date: </B>12 Nov 2001<BR>


<P>The last bullet of the second paragraph of section
3.4.2 [basic.lookup.argdep] says that:</P>
<BLOCKQUOTE>
If T is a template-id, its associated namespaces and classes are the
namespace in which the template is defined; for member templates, the member
template's class; the namespaces and classes associated with the types of
the template arguments provided for template type parameters (excluding
template template parameters); the namespaces in which any template template
arguments are defined; and the classes in which any member templates used as
template template arguments are defined.
</BLOCKQUOTE>

<P>The first problem with this wording is that it is misleading, since one
cannot get such a function argument whose type would be a template-id. The
bullet should be speaking about template specializations instead.</P>

<P>The second problem is owing to the use of the word "defined" in the phrases
"are the namespace in which the template is defined", "in which any template
template arguments are defined", and "as template template arguments are
defined". The bullet should use the word "declared" instead, since scenarios
like the one below are possible:</P>
<PRE>
namespace  A  {

   template&lt;class T&gt;
   struct  test  {

      template&lt;class U&gt;
      struct  mem_templ  {   };

   };

   // declaration in namespace 'A'
   template&lt;&gt; template&lt;&gt;
   struct  test&lt;int&gt;::mem_templ&lt;int&gt;;

   void  foo(test&lt;int&gt;::mem_templ&lt;int&gt;&amp;)
   {   }

}

// definition in the global namespace
template&lt;&gt; template&lt;&gt;
struct  A::test&lt;int&gt;::mem_templ&lt;int&gt;  {
};

int  main()
{
   A::test&lt;int&gt;::mem_templ&lt;int&gt;   inst;
   // According to the current definition of 3.4.2
   // foo is not found.
   foo(inst);
}
</PRE>

<P>In addition, the bullet doesn't make it clear whether a T which is a class
template specialization must also be treated as a class type, i.e. if the
contents of the second bullet of the second paragraph of section
3.4.2 [basic.lookup.argdep].
<BLOCKQUOTE>
<UL>
<LI>
If T is a class type (including unions), its associated classes are: the
class itself; the class of which it is a member, if any; and its direct and
indirect base classes. Its associated namespaces are the namespaces in which
its associated classes are defined.
[This wording is as updated by core issue 90.]
</LI>
</UL>
</BLOCKQUOTE>
must apply to it or not. The same stands for a T which is a function
template specialization. This detail can make a difference in an example
such as the one below:
<PRE>
template&lt;class T&gt;
struct  slist_iterator  {
   friend bool  operator==(const slist_iterator&amp; x, const slist_iterator&amp; y)
   {   return  true;   }
};

template&lt;class T&gt;
struct  slist  {
   typedef slist_iterator&lt;T&gt;   iterator;
   iterator  begin()
   {   return  iterator();   }
   iterator  end()
   {   return  iterator();   }
};

int  main()
{
   slist&lt;int&gt;   my_list;
   slist&lt;int&gt;::iterator   mi1 = my_list.begin(),  mi2 = my_list.end();
   // Must the the friend function declaration
   // bool  operator==(const slist_iterator&lt;int&gt;&amp;, const slist_iterator&lt;int&gt;&amp;);
   // be found through argument dependent lookup? I.e. is the specialization
   // 'slist&lt;int&gt;' the associated class of the arguments 'mi1' and 'mi2'. If we
   // apply only the contents of the last bullet of 3.4.2/2, then the type
   // 'slist_iterator&lt;int&gt;' has no associated classes and the friend declaration
   // is not found.
   mi1 == mi2;
}
</PRE>
</P>

<P><B>Suggested resolution</B>:</P>

<P>Replace the last bullet of the second paragraph of section
3.4.2 [basic.lookup.argdep]
<BLOCKQUOTE>
<UL>
<LI>
If <TT>T</TT> is a <I>template-id</I>,
its associated namespaces and classes are the
namespace in which the template is defined; for member templates, the member
template's class; the namespaces and classes associated with the types of
the template arguments provided for template type parameters (excluding
template template parameters); the namespaces in which any template template
arguments are defined; and the classes in which any member templates used as
template template arguments are defined.
</LI>
</UL>
</BLOCKQUOTE>
with
<BLOCKQUOTE>
<UL>
<LI>
If <TT>T</TT> is a class template
specialization, its associated namespaces and
classes are those associated with <TT>T</TT> when
<TT>T</TT> is regarded as a class type; the
namespaces and classes associated with the types of the template arguments
provided for template type parameters (excluding template template
parameters); the namespaces in which the primary templates making template
template arguments are declared; and the classes in which any primary member
templates used as template template arguments are declared.
</LI>
<LI>
If <TT>T</TT> is a function template specialization,
its associated namespaces and
classes are those associated with <TT>T</TT> when
<TT>T</TT> is regarded as a function type;
the namespaces and classes associated with the types of the template
arguments provided for template type parameters (excluding template template
parameters); the namespaces in which the primary templates making template
template arguments are declared; and the classes in which any primary member
templates used as template template arguments are declared.
</LI>
</UL>
</BLOCKQUOTE>
</P>
<P>Replace the second bullet of the second paragraph of section
3.4.2 [basic.lookup.argdep]
<BLOCKQUOTE>
<UL>
<LI>
If <TT>T</TT> is a class type (including unions),
its associated classes are: the
class itself; the class of which it is a member, if any; and its direct and
indirect base classes. Its associated namespaces are the namespaces in which
its associated classes are defined.
</LI>
</UL>
</BLOCKQUOTE>
with
<BLOCKQUOTE>
<UL>
<LI>
If <TT>T</TT> is a class type (including unions),
its associated classes are: the
class itself; the class of which it is a member, if any; and its direct and
indirect base classes. Its associated namespaces are the namespaces in which
its associated classes are declared [Note: in case of any of the associated
classes being a class template specialization, its associated namespace is
acually the namespace containing the declaration of the primary class
template of the class template specialization].
</LI>
</UL>
</BLOCKQUOTE>
</P>

<BR><BR><HR><A NAME="562"></A><H4>562.
  
<I>qualified-id</I>s in non-expression contexts
</H4><B>Section: </B>3.4.3.1&#160; [class.qual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>6 April 2006<BR>


<P>Both 3.4.3.1 [class.qual] and 3.4.3.2 [namespace.qual]
specify that some lookups are to be performed &#8220;in the context of the
entire <I>postfix-expression</I>,&#8221; ignoring the fact that
<I>qualified-id</I>s can appear outside of expressions.</P>

<P>It was suggested in document J16/05-0156 = WG21 N1896 that these
uses be changed to &#8220;the context in which the <I>qualified-id</I>
occurs,&#8221; but it isn't clear that this formulation adequately
covers all the places a <I>qualified-id</I> can occur.</P>

<BR><BR><HR><A NAME="278"></A><H4>278.
  
External linkage and nameless entities
</H4><B>Section: </B>3.5&#160; [basic.link]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>12 Apr 2000<BR>




<P>It is unclear to what extent entities without names match
across translation units.  For example,</P>

<PRE>
    struct S {
       int :2;
       enum { a, b, c } x;
       static class {} *p;
    };
</PRE>

<P>If this declaration appears in multiple translation units, are
all these members "the same" in each declaration?</P>

<P>A similar question can be asked about non-member declarations:</P>

<PRE>
    // Translation unit 1:
    extern enum { d, e, f } y;

    // Translation unit 2:
    extern enum { d, e, f } y;

    // Translation unit 3:
    enum { d, e, f } y;
</PRE>

<P>Is this valid C++?  Is it valid C?</P>

<P><U>James Kanze</U>: <TT>S::p</TT> cannot be defined, because to
do so requires a type specifier and the type cannot be named.
<TT>::y</TT> is valid C because C only requires compatible, not
identical, types.  In C++, it appears that there is a new type in
each declaration, so it would not be valid.  This differs from
<TT>S::x</TT> because the unnamed type is part of a named type
&#8212; but I don't know where or if the Standard says that.</P>

<P><U>John Max Skaller</U>:
It's not valid C++, because the type is a synthesised, unique name
for the enumeration type which differs across translation units, as if:</P>

<PRE>
    extern enum _synth1 { d,e,f} y;
    ..
    extern enum _synth2 { d,e,f} y;
</PRE>

<P>had been written.</P>

<P>However, within a class, the ODR implies the types are the same:</P>

<PRE>
    class X { enum { d } y; };
</PRE>

<P>in two translation units ensures that the type of member <TT>y</TT>
is the same: the two <TT>X</TT>'s obey the ODR and so denote the same class,
and it follows that there's only one member <TT>y</TT> and one type that it
has.</P>

<P>(See also issues <A HREF="
     cwg_closed.html#132">132</A> and
<A HREF="
     cwg_defects.html#216">216</A>.)</P>

<BR><BR><HR><A NAME="279"></A><H4>279.
  
Correspondence of "names for linkage purposes"
</H4><B>Section: </B>3.5&#160; [basic.link]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>4 Apr 2001<BR>




<P>The standard says that an unnamed class or enum definition can be given
a "name for linkage purposes" through a typedef.  E.g.,</P>

<PRE>
    typedef enum {} E;
    extern E *p;
</PRE>

<P>can appear in multiple translation units.</P>

<P>How about the following combination?</P>

<PRE>
    // Translation unit 1:
    struct S;
    extern S *q;

    // Translation unit 2:
    typedef struct {} S;
    extern S *q;
</PRE>

<P>Is this valid C++?</P>

<P>Also, if the answer is "yes", consider the following slight variant:</P>

<PRE>
    // Translation unit 1:
    struct S {};  // &lt;&lt;-- class has definition
    extern S *q;

    // Translation unit 2:
    typedef struct {} S;
    extern S *q;
</PRE>

<P>Is this a violation of the ODR because two definitions
of type <TT>S</TT> consist of differing token sequences?</P>

<BR><BR><HR><A NAME="338"></A><H4>338.
  
Enumerator name with linkage used as class name in other translation unit
</H4><B>Section: </B>3.5&#160; [basic.link]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>26 Feb 2002<BR>




<P>The following declarations are allowed within a translation
unit:</P>
<PRE>
  struct S;
  enum { S };
</PRE>
<P>However, 3.5 [basic.link] paragraph 9 seems to say
these two declarations
cannot appear in two different translation units.  That also
would mean that the inclusion of a header containing the above
in two different translation units is not valid C++.</P>

<P>I suspect this is an oversight and that users should be allowed
to have the declarations above appear in different translation
units.  (It is a fairly common thing to do, I think.)</P>

<P><U>Mike Miller</U>:
I think you meant "<TT>enum E { S };</TT>" -- enumerators only have
external linkage if the enumeration does (3.5 [basic.link]
paragraph 4), and 3.5 [basic.link] paragraph 9 only
applies to entities with external linkage.</P>

<P>I don't remember why enumerators were given linkage; I don't
think it's necessary for mangling non-type template arguments.
In any event, I can't think why cross-TU name collisions between
enumerators and other entities would cause a problem, so I guess
a change here would be okay.  I can think of three changes that
would have that effect:</P>

<OL>
<LI>
Saying that enumerators do not have linkage.
</LI>
<LI>
Removing enumerators from the list of entities in the first
sentence of 3.5 [basic.link] paragraph 9.
</LI>
<LI>
Saying that it's okay for an enumerator in one TU to have the
same name as a class type in another TU only if the enumerator
hides that same class type in both TUs (the example you gave).
</LI>
</OL>

<P><U>Daveed Vandevoorde</U>:
I don't think any of these are sufficient in the sense that the problem
isn't limited to enumerators.  E.g.:
<PRE>
  struct X;
  extern void X();
</PRE>
shouldn't create cross-TU collisions either.</P>

<P><U>Mike Miller</U>:
So you're saying that cross-TU collisions should only be
prohibited if both names denote entities of the same kind (both
functions, both objects, both types, etc.), or if they are both
references (regardless of what they refer to, presumably)?</P>

<P><U>Daveed Vandevoorde</U>:
Not exactly.  Instead, I'm saying that if two entities (with
external linkage) can coexist when they're both declared in the
same translation unit (TU), then they should also be allowed to
coexist when they're declared in two different translation units.</P>

<P>For example:
<PRE>
  int i;
  void i();  // Error
</PRE>
This is an error within a TU, so I don't see a reason to make it
valid across TUs.</P>

<P>However, "tag names" (class/struct/union/enum) can sometimes
coexist with identically named entities (variables, functions &amp;
enumerators, but not namespaces, templates or type names).</P>

<BR><BR><HR><A NAME="1003"></A><H4>1003.
  
Acceptable definitions of <TT>main</TT>
</H4><B>Section: </B>3.6.1&#160; [basic.start.main]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2009-11-17<BR>




<P>The specification of the forms of the definition of <TT>main</TT>
that an impliementation is required to accept is clear in C99 that
the parameter names and the exact syntactic form of the types can
vary.  Although it is reasonable to assume that a C++ implementation
would accept a definition like</P>

<PRE>
    int main(int foo, char** bar) { /* ... */ }
</PRE>

<P>instead of the canonical</P>

<PRE>
    int main(int argc, char* argv[]) { /* ... */ }
</PRE>

<P>it might be a good idea to clarify the intent using wording
similar to C99's.</P>

<BR><BR><HR><A NAME="371"></A><H4>371.
  
Interleaving of constructor calls
</H4><B>Section: </B>3.6.2&#160; [basic.start.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Matt Austern
 &#160;&#160;&#160;

 <B>Date: </B>7 August 2002<BR>




<P>Is a compiler allowed to interleave constructor calls when
performing dynamic initialization of nonlocal objects?
What I mean by interleaving is: beginning to execute a
particular constructor, then going off and doing
something else, then going back to the original constructor.
I can't find anything explicit about this in clause
3.6.2 [basic.start.init].</P>

<P>I'll present a few different examples, some of which get a
bit wild.  But a lot of what this comes down to is exactly
what the standard means when it talks about the order
of initialization.  If it says that some object x must be
initialized before a particular event takes place, does that
mean that x's constructor must be entered before that
event, or does it mean that it must be exited before that
event?  If object x must be initialized before object y,
does that mean that x's constructor must exit before y's
constructor is entered?</P>

<P>(The answer to that question might just be common sense,
but I couldn't find an answer in clause 3.6.2 [basic.start.init].
Actually, when I read 3.6.2 [basic.start.init]
carefully, I find there are a lot of things I took
for granted that aren't there.)</P>

<P>OK, so a few specific scenerios.</P>
<OL>
<LI>We have a translation unit with nonlocal objects A and B,
both of which require dynamic initialization.  A comes before
B.  A must be initialized before B.  May the compiler start
to construct A, get partway through the constructor, then
construct B, and then go back to finishing A?</LI>

<LI>We have a translation unit with nonlocal object A and
function f.  Construction of A is deferred until after the
first statement of main.  A must be constructed before the
first use of f.  Is the compiler permitted to start constructing
A, then execute f, then go back to constructing A?</LI>

<LI>We have nonlocal objects A and B, in two different
translation units.  The order in which A and B are constructed
is unspecified by the Standard.  Is the compiler permitted to
begin constructing A, then construct B, then finish A's
constructor?  Note the implications of a 'yes' answer.  If A's
and B's constructor both call some function f, then the call
stack might look like this:
<PRE>
   &lt;runtime gunk&gt;
     &lt;Enter A's constructor&gt;
        &lt;Enter f&gt;
           &lt;runtime gunk&gt;
              &lt;Enter B's constructor&gt;
                 &lt;Enter f&gt;
                 &lt;Leave f&gt;
              &lt;Leave B's constructor&gt;
        &lt;Leave f&gt;
     &lt;Leave A's constructor&gt;
</PRE>
The implication of a 'yes' answer for users is that any function
called by a constructor, directly or indirectly, must be reentrant.</LI>

<LI>This last example is to show why a 'no' answer to #3 might
be a problem too.  New scenerio: we've got one translation
unit containing a nonlocal object A and a function f1, and another
translation unit containing a nonlocal object B and a function f2.
A's constructor calls f2.  Initialization of A and B is deferred until
after the first statement of main().  Someone in main calls f1.
Question: is the compiler permitted to start constructing A, then
go off and construct B at some point before f2 gets called, then
go back and finish constructing A?  In fact, is the compiler
required to do that?  We've got an unpleasant tension here between
the bad implications of a 'yes' answer to #3, and the explicit
requirement in 3.6.2 [basic.start.init] paragraph 3.</LI>
</OL>

<P>At this point, you might be thinking we could avoid all of this
nonsense by removing compilers' freedom to defer initialization
until after the beginning of main().  I'd resist that, for two reasons.
First, it would be a huge change to make after the standard has
been out.  Second, that freedom is necessary if we want to have
support for dynamic libraries.  I realize we don't yet say anything
about dynamic libraries, but I'd hate to make decisions that would
make such support even harder.</P>

<BR><BR><HR><A NAME="640"></A><H4>640.
  
Accessing destroyed local objects of static storage duration
</H4><B>Section: </B>3.6.3&#160; [basic.start.term]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Howard Hinnant
 &#160;&#160;&#160;

 <B>Date: </B>30 July 2007<BR>




<P>3.6.3 [basic.start.term] paragraph 2 says,</P>

<BLOCKQUOTE>

If a function contains a local object of static storage duration
that has been destroyed and the function is called during the
destruction of an object with static storage duration, the
program has undefined behavior if the flow of control passes
through the definition of the previously destroyed local object.

</BLOCKQUOTE>

<P>I would like to turn this behavior from undefined to
well-defined behavior for the purpose of achieving a graceful
shutdown, especially in a multi-threaded world.</P>

<P>Background: Alexandrescu describes the &#8220;phoenix
singleton&#8221; in <I>Modern C++ Design</I>.  This is a class
used as a function local static, that will reconstruct itself,
and reapply itself to the <TT>atexit</TT> chain, if the program
attempts to use it after it is destructed in the <TT>atexit</TT>
chain.  It achieves this by setting a &#8220;destructed
flag&#8221; in its own state in its destructor.  If the object is
later accessed (and a member function is called on it), the
member function notes the state of the &#8220;destructed
flag&#8221; and does the reconstruction dance.  The phoenix
singleton pattern was designed to address issues only in
single-threaded code where accesses among static objects can have
a non-scoped pattern.  When we throw in multi-threading, and the
possibility that threads can be running after <TT>main</TT>
returns, the chances of accessing a destroyed static
significantly increase.</P>

<P>The very least that I would like to see happen is to standardize what  
I believe is existing practice:  When an object is destroyed in the  
<TT>atexit</TT> chain, the memory the object occupied is left in
whatever state the destructor put it in.  If this can only be
reliably done for objects with standard layout, that would be an
acceptable compromise.  This would allow objects to set &#8220;I'm
destructed&#8221; flags in their state and then do something
well-defined if accessed, such as throw an exception.</P>

<P>A possible refinement of this idea is to have the compiler set
up a 3-state flag around function-local statics instead of the
current 2-state flag:</P>

<UL>
<LI>Not constructed yet</LI>
<LI>Constructed but not destroyed yet</LI>
<LI>Destroyed</LI>
</UL>

<P>We have the first two states today.  We might choose to add
the third state, and if execution passes over a function-local
static with &#8220;destroyed&#8221; state, an exception could be
thrown.  This would mean that we would not have to guarantee
memory stability in destroyed objects of static duration.</P>

<P>This refinement would break phoenix singletons, and is not
required for the <TT>~mutex()</TT>/<TT>~condition()</TT> I've
described and prototyped.  But it might make it easier for Joe
Coder to apply this kind of guarantee to his own types.</P>

<BR><BR><HR><A NAME="365"></A><H4>365.
  
Storage duration and temporaries
</H4><B>Section: </B>3.7&#160; [basic.stc]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Kanze
 &#160;&#160;&#160;

 <B>Date: </B>24 July 2002<BR>


<P>There are several problems with 3.7 [basic.stc]:</P>
<UL>
<LI>
<P>3.7 [basic.stc] paragraph 2 says that "Static and automatic
storage durations are associated with objects introduced by
declarations (3.1 [basic.def]) and implicitly created
by the implementation (12.2 [class.temporary])."</P>

<P>In fact, objects "implicitly created by the implementation" are the
temporaries described in (12.2 [class.temporary]), and have neither
static nor automatic storage duration, but a totally different duration,
described in 12.2 [class.temporary].</P>
</LI>
<LI>
<P>3.7 [basic.stc] uses the expression "local object" in several 
places, without ever defining it.  Presumably, what is meant is "an 
object declared at block scope", but this should be said explicitly.</P>

<P>In a recent discussion in comp.lang.c++.moderated, on poster 
interpreted "local objects" as including temporaries.  This would require them 
to live until the end of the block in which they are created, which
contradicts 12.2 [class.temporary]. If temporaries are covered by
this section, and the statement in 3.7 [basic.stc]
seems to suggest, and they aren't local objects, then they must have
static storage duration, which isn't right either.</P>

<P>I propose adding a fourth storage duration to the list after
3.7 [basic.stc] paragraph 1:</P>
<UL>
<LI>
temporary storage duration
</LI>
</UL>
<P>And rewriting the second paragraph of this section as follows:</P>
<BLOCKQUOTE>
Temporary storage duration is associated with objects implicitly
created by the implementation, and is described in 12.2 [class.temporary].
Static and automatic storage durations are associated with objects defined
by declarations; in the following, an object defined by a declaration
with block scope is a local object.  The dynamic storage duration is
associated with objects created by the <TT>operator new</TT>.
</BLOCKQUOTE>
</LI>
</UL>

<P><U>Steve Adamczyk</U>:
There may well be an issue here, but one should bear in mind the
difference between storage duration and object lifetime.  As far
as I can see, there is no particular problem with temporaries having
automatic or static storage duration, as appropriate.  The point
of 12.2 [class.temporary] is that they have an unusual object
lifetime.</P>

<P><B>Notes from Ocrober 2002 meeting:</B></P>

<P>It might be desirable to shorten the storage duration of temporaries
to allow reuse of them.  The as-if rule allows some reuse, but such
reuse requires analysis, including noting whether the addresses of
such temporaries have been taken.</P>

<BR><BR><HR><A NAME="967"></A><H4>967.
  
Exception specification of replacement allocation function
</H4><B>Section: </B>3.7.4&#160; [basic.stc.dynamic]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>15 September, 2009<BR>




<P>The global allocation functions are implicitly declared in every
translation unit with <I>exception-specification</I>s
(3.7.4 [basic.stc.dynamic] paragraph 2).  It is not clear what
should happen if a replacement allocation function is declared without
an <I>exception-specification</I>.  Is that a conflict with the
implicitly-declared function (as it would be with explicitly-declared
functions, and presumably is if the <TT>&lt;new&gt;</TT> header is
included)?  Or does the new declaration replace the implicit one,
including the lack of an <I>exception-specification</I>?  Or does the
implicit declaration prevail?  (Regardless of the
<I>exception-specification</I> or lack thereof, it is presumably
undefined behavior for an allocation function to exit with an
exception that cannot be caught by a handler of type
<TT>std::bad_alloc</TT> (3.7.4.1 [basic.stc.dynamic.allocation] paragraph
3).)</P>

<BR><BR><HR><A NAME="312"></A><H4>312.
  
&#8220;use&#8221; of invalid pointer value not defined
</H4><B>Section: </B>3.7.4.2&#160; [basic.stc.dynamic.deallocation]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin von Loewis
 &#160;&#160;&#160;

 <B>Date: </B>20 Sep 2001<BR>


<P>3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 4 mentions that the effect
of using an invalid pointer value is undefined. However, the standard
never says what it means to 'use' a value.</P>

<P>There are a number of possible interpretations, but it appears that
each of them leads to undesired conclusions:</P>
<OL>
<LI>
A value is 'used' in a program if a variable holding this value
appears in an expression that is evaluated.
This interpretation would render the sequence
<PRE>
   int *x = new int(0);
   delete x;
   x = 0;
</PRE>
into undefined behaviour. As this is a common idiom, this is
clearly undesirable.
</LI>
<LI>
A value is 'used' if an expression evaluates to that value.
This would render the sequence
<PRE>
   int *x = new int(0);
   delete x;
   x-&gt;~int();
</PRE>
into undefined behaviour; according to 5.2.4 [expr.pseudo],
the variable x is
'evaluated' as part of evaluating the pseudo destructor call. This,
in turn, would mean that all containers (23 [containers])
of pointers show
undefined behaviour, e.g. 23.3.4.3 [list.modifiers]
requires to invoke the
destructor as part of the <TT>clear()</TT> method of the container.
</LI>
</OL>

<P>If any other meaning was intended for 'using an expression', that
meaning should be stated explicitly.</P>

<P>(See also <A HREF="
     cwg_closed.html#623">issue 623</A>.)</P>

<BR><BR><HR><A NAME="523"></A><H4>523.
  
Can a one-past-the-end pointer be invalidated by deleting an adjacent object?
</H4><B>Section: </B>3.7.4.2&#160; [basic.stc.dynamic.deallocation]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>comp.std.c++
 &#160;&#160;&#160;

 <B>Date: </B>8 July 2005<BR>


<P>When an object is deleted, 3.7.4.2 [basic.stc.dynamic.deallocation] says
that the deallocation &#8220;[renders] invalid all pointers referring
to any part of the deallocated storage.&#8221; According to
3.9.2 [basic.compound] paragraph 3, a pointer whose address is
one past the end of an array is considered to point to an unrelated
object that happens to reside at that address.  Does this need to be
clarified to specify that the one-past-the-end pointer of an array is
not invalidated by deleting the following object?  (See also
5.3.5 [expr.delete] paragraph 4, which also mentions that
the system deallocation function renders a pointer invalid.)</P>

<BR><BR><HR><A NAME="419"></A><H4>419.
  
Can cast to virtual base class be done on partially-constructed object?
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Judy Ward
 &#160;&#160;&#160;

 <B>Date: </B>2 June 2003<BR>


<P>Consider</P>
<PRE>
  extern "C" int printf (const char *,...);

  struct Base { Base();};
  struct Derived: virtual public Base {
     Derived() {;}
  };

  Derived d;
  extern Derived&amp; obj = d;

  int i;

  Base::Base() {
    if ((Base *) &amp;obj) i = 4;
    printf ("i=%d\n", i);
  }

  int main() { return 0; }
</PRE>

<P>12.7 [class.cdtor] paragraph 2 makes this valid, but
3.8 [basic.life] paragraph 5 implies that it isn't valid.</P>

<P><U>Steve Adamczyk:</U>
A second issue:</P>
<PRE>
  extern "C" int printf(const char *,...);
  struct A                      { virtual ~A(); int x; };
  struct B : public virtual A   { };
  struct C : public B           { C(int); };
  struct D : public C           { D(); };
 
  int main()                    { D t; printf("passed\n");return 0; }
 
  A::~A()                       {} 
  C::C(int)                     {} 
  D::D() : C(this-&gt;x)           {}
</PRE>
<P><A HREF="
     cwg_defects.html#52">Core issue 52</A> almost, but not quite,
says that in evaluating "this-&gt;x"
you do a cast to the virtual base class A, which would be an error
according to 12.7 [class.cdtor] paragraph 2 because the base
class B constructor hasn't started yet.
5.2.5 [expr.ref] should be clarified to say that
the cast does need to get done.</P>

<P><U>James Kanze</U> submitted the same issue via comp.std.c++
on 11 July 2003:</P>
<BLOCKQUOTE>
Richard Smith:
Nonsense. You can use "this" perfectly happily in a constructor, just
be careful that (a) you're not using any members that are not fully
initialised, and (b) if you're calling virtual functions you know
exactly what you're doing.
</BLOCKQUOTE>

<P>In practice, and I think in intent, you are right.  However, the
standard makes some pretty stringent restrictions in
3.8 [basic.life].  To start
with, it says (in paragraph 1): </P>
<BLOCKQUOTE>
    The lifetime of an object is a runtime property of the object.  The
    lifetime of an object of type T begins when:
<UL>
<LI>
        storage with the proper alignment and size for type T is
        obtained, and
</LI>
<LI>

        if T is a class type with a non-trivial constructor, the
        constructor calls has COMPLETED.
</LI>
</UL>
    The lifetime of an object of type T ends when:
<UL>
<LI>
        if T is a class type with a non-trivial destructor, the
        destructor call STARTS, or
</LI>
<LI>
        the storage which the object occupies is reused or released.
</LI>
</UL>
</BLOCKQUOTE>
(Emphasis added.)  Then when we get down to paragraph 5, it says:
<BLOCKQUOTE>
<P>
    Before the lifetime of an object has started but after the storage
    which the object will occupy has been allocated [which sounds to me
    like it would include in the constructor, given the text above] or,
    after the lifetime of an object has ended and before the storage
    which the object occupied is reused or released, any pointer that
    refers to the storage location where the object will be or was
    located may be used but only in limited ways. [...] If the object
    will be or was of a non-POD class type, the program has undefined
    behavior if:
</P>
<P>
    [...]
</P>
<UL>
<LI>
        the pointer is implicitly converted to a pointer to a base class
        type, or [...]
</LI>
</UL>
</BLOCKQUOTE>

<P>I can't find any exceptions for the this pointer.</P>

<P>Note that calling a non-static function in the base class, or even
constructing the base class in initializer list, involves an implicit
conversion of this to a pointer to the base class.  Thus undefined
behavior.  I'm sure that this wasn't the intent, but it would seem to be
what this paragraph is saying.</P>

<BR><BR><HR><A NAME="350"></A><H4>350.
  
<TT>signed char</TT> underlying representation for objects
</H4><B>Section: </B>3.9&#160; [basic.types]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Noah Stein
 &#160;&#160;&#160;

 <B>Date: </B>16 April 2002<BR>


<P>Sent in by David Abrahams:</P>

<P>Yes, and to add to this tangent, 3.9.1 [basic.fundamental]
paragraph 1 states "Plain char, signed char, and unsigned char are
three distinct types."  Strangely, 3.9 [basic.types]
paragraph 2 talks about how "... the underlying bytes making up
the object can be copied into an array of char or unsigned char.
If the content of the array of char or unsigned char is copied back
into the object, the object shall subsequently hold its original
value."  I guess there's no requirement that this copying
work properly with signed chars!</P>

<P><B>Notes from October 2002 meeting:</B></P>

<P>We should do whatever C99 does.  6.5p6 of the C99 standard says
"array of character type", and "character type" includes signed
char (6.2.5p15), and 6.5p7 says "character type".
But see also 6.2.6.1p4, which mentions (only) an array of unsigned char.</P>

<P><B>Proposed resolution (April 2003):</B></P>

<P>Change 3.8 [basic.life] paragraph 5 bullet 3 from</P>

<UL><LI>
the pointer is used as the operand of a
<TT>static_cast</TT>
(5.2.9 [expr.static.cast])
(except when the conversion is to
<TT>void*</TT>,
or to
<TT>void*</TT>
and subsequently to
<TT>char*</TT>,
or
<TT>unsigned</TT>
<TT>char*</TT>).
</LI>
</UL>

<P>to</P>

<UL><LI>
the pointer is used as the operand of a
<TT>static_cast</TT>
(5.2.9 [expr.static.cast])
(except when the conversion is to
<TT>void*</TT>,
or to
<TT>void*</TT>
and subsequently to a pointer to byte-character type).
</LI>
</UL>

<P>Change 3.8 [basic.life] paragraph 6 bullet 3 from </P>
<UL><LI>
the lvalue is used as the operand of a
<TT>static_cast</TT>
(5.2.9 [expr.static.cast])
(except when the conversion is ultimately to
<TT>char&amp;</TT>
or
<TT>unsigned</TT>
<TT>char&amp;</TT>),
or
</LI>
</UL>
<P>to</P>
<UL><LI>
the lvalue is used as the operand of a
<TT>static_cast</TT>
(5.2.9 [expr.static.cast])
(except when the conversion is ultimately to a reference to
byte-character type),
or
</LI>
</UL>

<P>Change the beginning of 3.9 [basic.types] paragraph 2 from</P>
<BLOCKQUOTE>
For any object (other than a base-class subobject) of POD type
<TT>T</TT>,
whether or not the object holds a valid value of type
<TT>T</TT>,
the underlying bytes (1.7 [intro.memory])
making up the object can be copied
into an array of
<TT>char</TT>
or
<TT>unsigned</TT>
<TT>char</TT>.
</BLOCKQUOTE>
<P>to</P>
<BLOCKQUOTE>
For any object (other than a base-class subobject) of POD type
<TT>T</TT>,
whether or not the object holds a valid value of type
<TT>T</TT>,
the underlying bytes (1.7 [intro.memory])
making up the object can be copied
into an array of byte-character type.
</BLOCKQUOTE>

<P>Add the indicated text to 3.9.1 [basic.fundamental] paragraph 1:</P>

<BLOCKQUOTE>
Objects declared as characters
(<TT>char</TT>)
shall be large enough to store any member of
the implementation's basic character set.
If a character from this set is stored in a character object,
the integral value of that character object
is equal to
the value of the single character literal form of that character.
It is implementation-defined whether a
<TT>char</TT>
object can hold negative values.
Characters can be explicitly declared
<TT>unsigned</TT>
or
<TT>signed</TT>.
Plain
<TT>char</TT>,
<TT>signed char</TT>,
and
<TT>unsigned char</TT>
are three distinct types<SPAN style="font-weight:bold;background-color:#A0FFA0">, called the <I>byte-character types</I></SPAN>.
A
<TT>char</TT>,
a
<TT>signed char</TT>,
and an
<TT>unsigned char</TT>
occupy the same amount of storage and have the same alignment requirements
(3.9 [basic.types]); that is, they have the
same object representation.
For <SPAN style="font-weight:bold;background-color:#A0FFA0">byte-</SPAN>character types, all bits of the object representation participate in
the value representation.
For unsigned <SPAN style="font-weight:bold;background-color:#A0FFA0">byte-</SPAN>character types, all possible bit
patterns of the value representation represent numbers.
These requirements
do not hold for other types.
In any particular implementation, a plain
<TT>char</TT>
object can take on either the same values as a
<TT>signed char</TT>
or an
<TT>unsigned char</TT>;
which one is implementation-defined.
</BLOCKQUOTE>

<P>Change 3.10 [basic.lval] paragraph 15 last bullet from</P>
<UL><LI>
a
<TT>char</TT>
or
<TT>unsigned</TT>
<TT>char</TT>
type.
</LI>
</UL>
<P>to</P>
<UL><LI>
a byte-character type.
</LI>
</UL>

<P><B>Notes from October 2003 meeting:</B></P>

<P>It appears that in C99 signed char may have padding bits but no trap
representation, whereas in C++ signed char has no padding bits but
may have -0.  A memcpy in C++ would have to copy the array preserving
the actual representation and not just the value.</P>

<P>March 2004: The liaisons to the C committee have been asked to tell us
whether this change would introduce any unnecessary incompatibilities
with C.</P>

<P><B>Notes from October 2004 meeting:</B></P>

<P>The C99 Standard appears to be inconsistent in its
requirements.  For example, 6.2.6.1 paragraph 4 says:</P>

<BLOCKQUOTE>

The value may be copied into an object of type
<TT>unsigned&#160;char&#160;[</TT><I>n</I><TT>]</TT> (e.g., by
<TT>memcpy</TT>); the resulting set of bytes is called the
<I>object representation</I> of the value.

</BLOCKQUOTE>

<P>On the other hand, 6.2 paragraph 6 says,</P>

<BLOCKQUOTE>

If a value is copied into an object having no declared type using
<TT>memcpy</TT> or <TT>memmove</TT>, or is copied as an array of
character type, then the effective type of the modified object
for that access and for subsequent accesses that do not modify
the value is the effective type of the object from which the
value is copied, if it has one.

</BLOCKQUOTE>

<P>Mike Miller will investigate further.</P>

<P><B>Proposed resolution (February, 2010):</B></P>

<OL><LI><P>Change 3.8 [basic.life] paragraph 5 bullet 4 as
follows:</P></LI>

<BLOCKQUOTE>

<P>...The program has undefined behavior if:</P>

<UL><LI><P>...</P></LI>

<LI><P>the pointer is used as the operand of a
<TT>static_cast</TT> (5.2.9 [expr.static.cast]) (except when
the conversion is to <SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I></SPAN> <TT>void*</TT>, or to
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I></SPAN> <TT>void*</TT> and subsequently to
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>char*</TT>, or <TT>unsigned char*</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a
pointer to a cv-qualified or cv-unqualified byte-character type
(3.9.1 [basic.fundamental])</SPAN>), or</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 3.8 [basic.life] paragraph 6 bullet 4 as
follows:</P></LI>

<BLOCKQUOTE>

<P>...The program has undefined behavior if:</P>

<UL><LI><P>...</P></LI>

<LI><P>the lvalue is used as the operand of a
<TT>static_cast</TT> (5.2.9 [expr.static.cast]) except when the
conversion is ultimately to <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>cv</I> <TT>char&amp;</TT> or
<I>cv</I> <TT>unsigned char&amp;</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a reference to a
cv-qualified or cv-unqualified byte-character type (3.9.1 [basic.fundamental]) or an array thereof</SPAN>, or</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 3.9 [basic.types] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

For any object (other than a base-class subobject) of trivially
copyable type <TT>T</TT>, whether or not the object holds a valid
value of type <TT>T</TT>, the underlying bytes (1.7 [intro.memory]) making up the object can be copied into an array of
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>char</TT> or <TT>unsigned char</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a
byte-character type (3.9.1 [basic.fundamental])</SPAN>.<SUP>39</SUP> If the content of
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">the</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">that</SPAN> array <SPAN style="text-decoration:line-through;background-color:#FFA0A0">of <TT>char</TT> or
<TT>unsigned char</TT></SPAN> is copied back into the object, the
object shall subsequently hold its original
value. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Change 3.9.1 [basic.fundamental] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...Characters can be explicitly declared <TT>unsigned</TT> or
<TT>signed</TT>.  Plain <TT>char</TT>, <TT>signed char</TT>, and
<TT>unsigned char</TT> are three distinct types<SPAN style="font-weight:bold;background-color:#A0FFA0">, called the
<I>byte-character types</I></SPAN>.  A <TT>char</TT>, a <TT>signed
char</TT>, and an <TT>unsigned char</TT> occupy the same amount
of storage and have the same alignment requirements (3.11 [basic.align]); that is, they have the same object
representation. For <SPAN style="font-weight:bold;background-color:#A0FFA0">byte-</SPAN>character types, all bits of
the object representation participate in the value
representation.  For <SPAN style="text-decoration:line-through;background-color:#FFA0A0">unsigned character types</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>unsigned char</TT></SPAN>, all possible bit patterns of
the value representation represent numbers...

</BLOCKQUOTE>

<LI><P>Change 3.10 [basic.lval] paragraph 15 final bullet
as follows:</P></LI>

<BLOCKQUOTE>

<P>If a program attempts to access the stored value of an object
through an lvalue of other than one of the following types the
behavior is undefined <SUP>52</SUP></P>

<UL>

<LI><P>...</P></LI>

<LI><P>a <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>char</TT> or <TT>unsigned char</TT></SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">byte-character</SPAN> type <SPAN style="font-weight:bold;background-color:#A0FFA0">(3.9.1 [basic.fundamental])</SPAN>.</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 3.11 [basic.align] paragraph 6 as follows:</P></LI>

<BLOCKQUOTE>

The alignment requirement of a complete type can be queried using
an <TT>alignof</TT> expression (5.3.6 [expr.alignof]).
Furthermore, the <SPAN style="font-weight:bold;background-color:#A0FFA0">byte-character</SPAN> types
<SPAN style="font-weight:bold;background-color:#A0FFA0">(3.9.1 [basic.fundamental])</SPAN> <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>char</TT>,
<TT>signed char</TT>, and <TT>unsigned char</TT></SPAN> shall have
the weakest alignment requirement.  [<I>Note:</I> this enables
the <SPAN style="font-weight:bold;background-color:#A0FFA0">byte-</SPAN>character types to be used as the underlying
type for an aligned memory area (7.6.2 [dcl.align]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 5.3.4 [expr.new] paragraph 10 as follows:</P></LI>

<BLOCKQUOTE>

...For arrays of <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>char</TT> and <TT>unsigned
char</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a byte-character type (3.9.1 [basic.fundamental])</SPAN>, the difference between the result of the
<I>new-expression</I> and the address returned by the allocation
function shall be an integral multiple of the strictest
fundamental alignment requirement (3.11 [basic.align]) of
any object type whose size is no greater than the size of the
array being created. [<I>Note:</I> Because allocation functions
are assumed to return pointers to storage that is appropriately
aligned for objects of any type with fundamental alignment, this
constraint on array allocation overhead permits the common idiom
of allocating <SPAN style="font-weight:bold;background-color:#A0FFA0">byte-</SPAN>character arrays into which objects
of other types will later be placed. &#8212;<I>end note</I>]

</BLOCKQUOTE>

</OL>

<P><B>Notes from the March, 2010 meeting:</B></P>

<P>The CWG was not convinced that there was a need to change the
existing specification at this time.  Some were concerned that there
might be implementation difficulties with giving <TT>signed char</TT>
the requisite semantics; implementations for which that is true can
currently make <TT>char</TT> equivalent to <TT>unsigned char</TT> and
avoid those problems, but the suggested change would undermine that
strategy.</P>

<BR><BR><HR><A NAME="496"></A><H4>496.
  
Is a volatile-qualified type really a POD?
</H4><B>Section: </B>3.9&#160; [basic.types]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Maddock
 &#160;&#160;&#160;

 <B>Date: </B>30 Dec 2004<BR>




<P>In 3.9 [basic.types] paragraph 10, the standard makes
it quite clear that volatile qualified types are PODs:</P>

<BLOCKQUOTE>

Arithmetic types (3.9.1 [basic.fundamental]), enumeration
types, pointer types, and pointer to member types (3.9.2 [basic.compound]), and <I>cv-qualified</I> versions of these
types (3.9.3 [basic.type.qualifier]) are collectively called
<I>scalar types</I>. Scalar types, POD-struct types, POD-union
types (clause 9 [class]), arrays of such types and
<I>cv-qualified</I> versions of these types (3.9.3 [basic.type.qualifier]) are collectively called <I>POD types</I>.

</BLOCKQUOTE>

<P>However in 3.9 [basic.types] paragraph 3, the
standard makes it clear that PODs can be copied &#8220;as
if&#8221; they were a collection of bytes by <TT>memcpy</TT>:</P>

<BLOCKQUOTE>

For any POD type <TT>T</TT>, if two pointers to <TT>T</TT> point to
distinct <TT>T</TT> objects <TT>obj1</TT> and <TT>obj2</TT>, where
neither <TT>obj1</TT> nor <TT>obj2</TT> is a base-class subobject, if
the value of <TT>obj1</TT> is copied into <TT>obj2</TT>, using
the <TT>std::memcpy</TT> library function, <TT>obj2</TT> shall
subsequently hold the same value as <TT>obj1</TT>.

</BLOCKQUOTE>

<P>The problem with this is that a volatile qualified type may
need to be copied in a specific way (by copying using only atomic
operations on multithreaded platforms, for example) in order to
avoid the &#8220;memory tearing&#8221; that may occur with a
byte-by-byte copy.</P>

<P>I realise that the standard says very little about volatile
qualified types, and nothing at all (yet) about multithreaded
platforms, but nonetheless this is a real issue, for the
following reason:</P>

<P>The forthcoming TR1 will define a series of traits that
provide information about the properties of a type, including
whether a type is a POD and/or has trivial construct/copy/assign
operations.  Libraries can use this information to optimise their
code as appropriate, for example an array of type <TT>T</TT>
might be copied with a <TT>memcpy</TT> rather than an
element-by-element copy if <TT>T</TT> is a POD.  This was one of
the main motivations behind the type traits chapter of the TR1.
However it's not clear how volatile types (or POD's which have a
volatile type as a member) should be handled in these cases.</P>

<P><B>Notes from the April, 2005 meeting:</B></P>

<P>It is not clear whether the volatile qualifier actually guarantees
atomicity in this way.  Also, the work on the memory model for
multithreading being done by the Evolution Working Group seems at this
point likely to specify additional semantics for volatile data, and
that work would need to be considered before resolving this issue.</P>

<BR><BR><HR><A NAME="146"></A><H4>146.
  
Floating-point zero
</H4><B>Section: </B>3.9.1&#160; [basic.fundamental]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Andy Sawyer
 &#160;&#160;&#160;

 <B>Date: </B>23 Jul 1999<BR>





<P>3.9.1 [basic.fundamental]
 does not impose
a requirement on the floating point types that there be an exact
representation of the value zero.  This omission is significant in
4.12 [conv.bool]
 paragraph 1, in which any
non-zero value converts to the <TT>bool</TT> value <TT>true</TT>.</P>

<P>Suggested resolution: require that all floating point types have an
exact representation of the value zero.</P>
<BR><BR><HR><A NAME="251"></A><H4>251.
  
How many signed integer types are there?
</H4><B>Section: </B>3.9.1&#160; [basic.fundamental]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Beman Dawes
 &#160;&#160;&#160;

 <B>Date: </B>18 Oct 2000<BR>




<P>3.9.1 [basic.fundamental] paragraph 2 says that</P>

<BLOCKQUOTE>

There are four <I>signed integer types</I>: "<TT>signed char</TT>",
"<TT>short int</TT>", "<TT>int</TT>", and "<TT>long int</TT>."

</BLOCKQUOTE>

<P>This would indicate that <TT>const int</TT> is not a signed
integer type.</P>

<BR><BR><HR><A NAME="483"></A><H4>483.
  
Normative requirements on integral ranges
</H4><B>Section: </B>3.9.1&#160; [basic.fundamental]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>21 Oct 2004<BR>


<P>There is no normative requirement on the ranges of the integral
types, although the footnote in 3.9.1 [basic.fundamental]
paragraph 2 indicates the intent (for <TT>int</TT>, at least)
that they match the values given in the <TT>&lt;climits&gt;</TT>
header.  Should there be an explicit requirement of some sort?</P>

<P>(See also paper N1693.)</P>

<BR><BR><HR><A NAME="689"></A><H4>689.
  
Maximum values of signed and unsigned integers
</H4><B>Section: </B>3.9.1&#160; [basic.fundamental]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Kanze
 &#160;&#160;&#160;

 <B>Date: </B>30 March, 2008<BR>




<P>The relationship between the values representable by corresponding
signed and unsigned integer types is not completely described, but
3.9 [basic.types] paragraph 4 says,</P>

<BLOCKQUOTE>

The <I>value representation</I> of an object is the set of bits that
hold the value of type <TT>T</TT>.

</BLOCKQUOTE>

<P>and 3.9.1 [basic.fundamental] paragraph 3 says,</P>

<BLOCKQUOTE>

The range of nonnegative values of a signed integer type is a
subrange of the corresponding unsigned integer type, and the
value representation of each corresponding signed/unsigned type
shall be the same.

</BLOCKQUOTE>

<P>I.e., the maximum value of each unsigned type must be larger
than the maximum value of the corresponding signed type.</P>

<P>C90 doesn't have this restriction, and C99 explicitly says
(6.2.6.2, paragraph 2),</P>

<BLOCKQUOTE>

For signed integer types, the bits of the object representation
shall be divided into three groups: value bits, padding bits, and
the sign bit. There need not be any padding bits; there shall be
exactly one sign bit. Each bit that is a value bit shall have the
same value as the same bit in the object representation of the
corresponding unsigned type (if there are <I>M</I> value bits in the
signed type and N in the unsigned type, then <I>M</I> &lt;= <I>N</I>).

</BLOCKQUOTE>

<P>Unlike C++, the sign bit is not part of the value, and on an
architecture that does not have native support of unsigned types,
an implementation can emulate unsigned integers by simply
ignoring what would be the sign bit in the signed type and be
conforming.</P>

<P>The question is whether we intend to make a conforming
implementation on such an architecture impossible. More
generally, what range of architectures do we intend to
support?  And to what degree do we want to follow C99 in
its evolution since C89?</P>

<P>(See paper J16/08-0141 = WG21 N2631.)</P>

<BR><BR><HR><A NAME="1076"></A><H4>1076.
  
Value categories and lvalue temporaries
</H4><B>Section: </B>3.10&#160; [basic.lval]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-10<BR>


<P>The taxonomy of value categories in 3.10 [basic.lval]
classifies temporaries as prvalues.  However, some temporaries are
explicitly referred to as lvalues (cf 15.1 [except.throw]
paragraph 3).</P>

<BR><BR><HR><A NAME="1115"></A><H4>1115.
  
C-compatible alignment specification
</H4><B>Section: </B>3.11&#160; [basic.align]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US25">N3092 comment
  US&#160;25<BR></A>
<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#GB31">N3092 comment
  GB&#160;31<BR></A>

<P>The C and C++ approaches to alignment are incompatible.  See
document PL22.16 10-0083 = WG21 N3093 for details.</P>

<P><B>Notes from the August, 2010 meeting:</B></P>

<P>CWG agreed that the alignment specifier should be a keyword
instead of an attributes.</P>

<BR><BR><HR><A NAME="1013"></A><H4>1013.
  
Uninitialized <TT>std::nullptr_t</TT> objects
</H4><B>Section: </B>4.1&#160; [conv.lval]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Miller
 &#160;&#160;&#160;

 <B>Date: </B>2009-12-10<BR>


<P>According to 4.1 [conv.lval] paragraph 1, an lvalue-to-rvalue
conversion on an uninitialized object produces undefined behavior.  Since
there is only one &#8220;value&#8221; of type <TT>std::nullptr_t</TT>, an
lvalue-to-rvalue conversion on a <TT>std::nullptr_t</TT> glvalue does not
need to fetch the value from storage.  Is there any need for undefined
behavior in this case?</P>

<BR><BR><HR><A NAME="330"></A><H4>330.
  
Qualification conversions and pointers to arrays of pointers
</H4><B>Section: </B>4.4&#160; [conv.qual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Roger Orr
 &#160;&#160;&#160;

 <B>Date: </B>2 Jan 2002<BR>


<P>Section 4.4 [conv.qual]
covers the case of multi-level pointers, but does not appear to cover the
case of pointers to arrays of pointers.
The effect is that arrays are treated differently from simple scalar
values.</P>

<P>Consider for example the following code:
(from the thread "Pointer to array conversion question" begun in
comp.lang.c++.moderated)
<PRE>
  int main()
  {
     double *array2D[2][3];
  
     double       *       (*array2DPtr1)[3] = array2D;     // Legal
     double       * const (*array2DPtr2)[3] = array2DPtr1; // Legal
     double const * const (*array2DPtr3)[3] = array2DPtr2; // Illegal
  }
</PRE>
and compare this code with:-
<PRE>
  int main()
  {
     double *array[2];
  
     double       *       *ppd1 = array; // legal
     double       * const *ppd2 = ppd1;  // legal
     double const * const *ppd3 = ppd2;  // certainly legal (4.4/4)
  }
</PRE>
</P>

<P>The problem appears to be that the pointed to types in example 1 are
unrelated since nothing in the
relevant section of the standard covers it - 4.4 [conv.qual]
does not mention conversions of the form
"cv array of N pointer to T"
into
"cv array of N pointer to cv T"</P>

<P>It appears that reinterpret_cast is the only way to perform the
conversion.</P>

<P><B>Suggested resolution:</B></P>

<P>Artem Livshits proposed a resolution :-</P>

<P>"I suppose if the definition of "similar" pointer types in
4.4 [conv.qual] paragraph 4 was
rewritten like this:
<BLOCKQUOTE>
<P>T1 is cv1,0 P0 cv1,1 P1 ... cv1,n-1 Pn-1 cv1,n T</P>
<P>and</P>
<P>T2 is cv1,0 P0 cv1,1 P1 ... cv1,n-1 Pn-1 cv1,n T</P>

<P>where Pi is either a "pointer to" or a "pointer to an array of Ni"; besides
P0 may be also a "reference to" or a "reference to an array of N0" (in the
case of P0 of T2 being a reference, P0 of T1 may be nothing).</P>
</BLOCKQUOTE>
it would address the problem.</P>

<P>In fact I guess Pi in this notation may be also a "pointer to member", so
4.4 [conv.qual]/{4,5,6,7} would be nicely wrapped in one
paragraph."</P>

<BR><BR><HR><A NAME="238"></A><H4>238.
  
Precision and accuracy constraints on floating point
</H4><B>Section: </B>5&#160; [expr]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Christophe de Dinechin
 &#160;&#160;&#160;

 <B>Date: </B>31 Jul 2000<BR>




<P>It is not clear what constraints are placed on a floating point
implementation by the wording of the Standard.  For instance, is
an implementation permitted to generate a "fused multiply-add"
instruction if the result would be different from what would
be obtained by performing the operations separately?  To what
extent does the "as-if" rule allow the kinds of optimizations
(e.g., loop unrolling) performed by FORTRAN compilers?</P>

<BR><BR><HR><A NAME="945"></A><H4>945.
  
Use of <TT>this</TT> in a late-specified return type
</H4><B>Section: </B>5.1.1&#160; [expr.prim.general]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>18 July, 2009<BR>


<P>(Moved from <A HREF="
     cwg_defects.html#760">issue 760</A>.)</P>

<P>Although it was considered and rejected as part of
<A HREF="
     cwg_closed.html#643">issue 643</A>, more recent developments
may argue in favor of allowing the use of <TT>this</TT> in a
late-specified return type.  In particular, declaring the return
type for a forwarding function in a derived class template that invokes
a member function of a dependent base class is difficult without
this facility.  For example:</P>

<PRE>
    template &lt;typename T&gt; struct derived: base&lt;T&gt; {
      auto invoke() -&gt; decltype(this-&gt;base_func()) {
        return this-&gt;base_func();
      }
    };
</PRE>

<P>(See also <A HREF="
     cwg_active.html#1207">issue 1207</A> for another
potential motivation for a change to this rule.)</P>

<P><B>Additional note (October, 2010):</B></P>



<P>The question should also be considered for parameter types; for
example,</P>

<PRE>
class comparable {
public:
   bool is_equal(decltype(*this) other) { // should be X&amp;
       return /*...*/;
   }
};
</PRE>

<BR><BR><HR><A NAME="974"></A><H4>974.
  
Default arguments for lambdas
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>4 September, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US29">N3092 comment
  US&#160;29<BR></A>



<P>There does not appear to be any technical difficulty that would
require the restriction in 5.1.2 [expr.prim.lambda] paragraph 5
against default arguments in <I>lambda-expression</I>s.</P>

<BR><BR><HR><A NAME="975"></A><H4>975.
  
Restrictions on return type deduction for lambdas
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>4 September, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US30">N3092 comment
  US&#160;30<BR></A>



<P>There does not appear to be any technical difficulty that would
require the current restriction that the return type of a lambda can
be deduced only if the body of the lambda consists of a single return
statement.  In particular, multiple return statements could be
permitted if they all return the same type.</P>

<BR><BR><HR><A NAME="798"></A><H4>798.
  
Overloaded subscript operator described in clause 5
</H4><B>Section: </B>5.2.1&#160; [expr.sub]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>UK
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK53">N2800 comment
  UK&#160;53<BR></A>

<P>5.2.1 [expr.sub] paragraph 2 deals with one particular
aspect of the overloaded <TT>operator[]</TT>, which seems out of place.
Either 5.2.1 [expr.sub] should be augmented to discuss
the overloaded <TT>operator[]</TT> in general or the information in
paragraph 2 should be moved into 13.5.5 [over.sub].</P>

<BR><BR><HR><A NAME="1213"></A><H4>1213.
  
Array subscripting and xvalues
</H4><B>Section: </B>5.2.1&#160; [expr.sub]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-24<BR>




<P>Because the subscripting operation is defined as indirection through
a pointer value, the result of a subscript operator applied to an
xvalue array is an lvalue, not an xvalue.  This could be surprising to
some.</P>

<BR><BR><HR><A NAME="943"></A><H4>943.
  
Is <TT>T()</TT> a temporary?
</H4><B>Section: </B>5.2.3&#160; [expr.type.conv]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Miller
 &#160;&#160;&#160;

 <B>Date: </B>14 July, 2009<BR>


<P>According to 5.2.3 [expr.type.conv] paragraphs 1 and 3 (stated
directly or by reference to another section of the Standard), all the
following expressions create temporaries:</P>

<PRE>
    T(1)
    T(1, 2)
    T{1}
    T{}
</PRE>

<P>However, paragraph 2 says,</P>

<BLOCKQUOTE>

The expression <TT>T()</TT>, where <TT>T</TT> is a
<I>simple-type-specifier</I> or <I>typename-specifier</I> for a
non-array complete effective object type or the (possibly
cv-qualified) <TT>void</TT> type, creates an rvalue of the specified
type, which is value-initialized (8.5 [dcl.init]; no
initialization is done for the <TT>void()</TT> case).

</BLOCKQUOTE>

<P>This does <I>not</I> say that the result is a temporary, which
means that the lifetime of the result is not specified by
12.2 [class.temporary].  Presumably this is just an oversight.</P>

<P><B>Notes from the October, 2009 meeting:</B></P>

<P>The specification in 5.2.3 [expr.type.conv] is in error, not
because it fails to state that <TT>T()</TT> is a temporary but because
it requires a temporary for the other cases with fewer than two operands.
The case where <TT>T</TT> is a class type is covered by
12.2 [class.temporary] paragraph 1 (&#8220;a conversion that creates
an rvalue&#8221;), and a temporary should <I>not</I> be created when
<TT>T</TT> is not a class type.</P>

<BR><BR><HR><A NAME="742"></A><H4>742.
  
Postfix increment/decrement with long bit-field operands
</H4><B>Section: </B>5.2.6&#160; [expr.post.incr]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>11 November, 2008<BR>


<P>Given the following declarations:</P>

<PRE>
    struct S {
        signed long long sll: 3;
    };
    S s = { -1 };
</PRE>

<P>the expressions <TT>s.sll-- &lt; 0u</TT> and <TT>s.sll &lt; 0u</TT>
have different results.  The reason for this is that <TT>s.sll--</TT>
is an rvalue of type <TT>signed long long</TT> (5.2.6 [expr.post.incr]), which means that the usual arithmetic conversions
(5 [expr] paragraph 10) convert <TT>0u</TT> to
<TT>signed long long</TT> and the result is <TT>true</TT>.
<TT>s.sll</TT>, on the other hand, is a bit-field lvalue, which is
promoted (4.5 [conv.prom] paragraph 3) to <TT>int</TT>; both
operands of <TT>&lt;</TT> have the same rank, so <TT>s.sll</TT> is
converted to <TT>unsigned int</TT> to match the type of <TT>0u</TT>
and the result is <TT>false</TT>.  This disparity seems
undesirable.</P>

<BR><BR><HR><A NAME="282"></A><H4>282.
  
Namespace for <TT>extended_type_info</TT>
</H4><B>Section: </B>5.2.8&#160; [expr.typeid]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jens Maurer
 &#160;&#160;&#160;

 <B>Date: </B>01 May 2001<BR>


<P>The original proposed resolution for <A HREF="
     cwg_defects.html#160">issue 160</A>
included changing <TT>extended_type_info</TT>
(5.2.8 [expr.typeid] paragraph 1, footnote 61) to
<TT>std::extended_type_info</TT>.  There was no consensus on whether
this name ought to be part of namespace <TT>std</TT> or in a
vendor-specific namespace, so the question was moved into a
separate issue.</P>

<BR><BR><HR><A NAME="528"></A><H4>528.
  
Why are incomplete class types not allowed with <TT>typeid</TT>?
</H4><B>Section: </B>5.2.8&#160; [expr.typeid]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Dave Abrahams
 &#160;&#160;&#160;

 <B>Date: </B>18 May 2005<BR>




<P>5.2.8 [expr.typeid] paragraph 4 says,</P>

<BLOCKQUOTE>

When <TT>typeid</TT> is applied to a <I>type-id</I>, the result refers
to a <TT>std::type_info</TT> object representing the type of
the <I>type-id</I>.  If the type of the <I>type-id</I> is a reference
type, the result of the <TT>typeid</TT> expression refers to
a <TT>std::type_info</TT> object representing the referenced type. If
the type of the <I>type-id</I> is a class type or a reference to a
class type, the class shall be completely-defined.

</BLOCKQUOTE>

<P>I'm wondering whether this is not overly restrictive.  I can't
think of a reason to require that <TT>T</TT> be completely-defined
in <TT>typeid(T)</TT> when <TT>T</TT> is a class type.  In fact,
several popular compilers enforce that restriction
for <TT>typeid(T)</TT>, but not for <TT>typeid(T&amp;)</TT>.  Can
anyone explain this?
</P>

<P><U>Nathan Sidwell</U>: I think this restriction is so that whenever
the compiler has to emit a typeid object of a class type, it knows
what the base classes are, and can therefore emit an array of
pointers-to-base-class typeids.  Such a tree is necessary to implement
<TT>dynamic_cast</TT> and exception catching (in a commonly
implemented and obvious manner).  If the class could be incomplete,
the compiler might have to emit a typeid for incomplete <TT>Foo</TT>
in one object file and a typeid for complete <TT>Foo</TT> in another
object file.  The compilation system will then have to make sure that
(a) those compare equal and (b) the complete <TT>Foo</TT> gets
priority, if that is applicable.
</P>

<P>Unfortunately, there is a problem with exceptions that means there
still can be a need to emit typeids for incomplete class.  Namely one
can throw a pointer-to-pointer-to-incomplete.  To implement the
matching of pointer-to-derived being caught by pointer-to-base, it is
necessary for the typeid of a pointer type to contain a pointer to the
typeid of the pointed-to type.  In order to do the qualification
matching on a multi-level pointer type, one has a chain of pointer
typeids that can terminate in the typeid of an incomplete type.  You
cannot simply NULL-terminate the chain, because one must distinguish
between different incomplete types.</P>

<P><U>Dave Abrahams</U>: So if implementations are still required to
be able to do it, for all practical purposes, why aren't we letting
the user have the benefits?</P>

<P><B>Notes from the April, 2006 meeting:</B></P>

<P>There was some concern expressed that this might be difficult under
the IA64 ABI.  It was also observed that while it is necessary to
handle exceptions involving incomplete types, there is no requirement
that the RTTI data structures be used for exception handling.</P>

<BR><BR><HR><A NAME="944"></A><H4>944.
  
<TT>reinterpret_cast</TT> for all types with the same size and alignment
</H4><B>Section: </B>5.2.10&#160; [expr.reinterpret.cast]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Miller
 &#160;&#160;&#160;

 <B>Date: </B>15 July, 2009<BR>


<P>During the discussion of <A HREF="
     cwg_defects.html#799">issue 799</A>, which
specified the result of using <TT>reinterpret_cast</TT> to convert an
operand to its own type, it was observed that it is probably reasonable
to allow <TT>reinterpret_cast</TT> between any two types that have the
same size and alignment.</P>

<BR><BR><HR><A NAME="203"></A><H4>203.
  
Type of address-of-member expression
</H4><B>Section: </B>5.3.1&#160; [expr.unary.op]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Lisa Lippincott
 &#160;&#160;&#160;

 <B>Date: </B>8 Feb 2000<BR>



<P>5.3.1 [expr.unary.op]
 paragraph 2 indicates
that the type of an address-of-member expression reflects the class in
which the member was declared rather than the class identified in the
<I>nested-name-specifier</I> of the <I>qualified-id</I>.  This
treatment is unintuitive and can lead to strange code and unexpected
results.  For instance, in</P>

<PRE>
    struct B { int i; };
    struct D1: B { };
    struct D2: B { };

    int (D1::* pmD1) = &amp;D2::i;   // NOT an error
</PRE>

More seriously, template argument deduction can give surprising
results:

<PRE>
    struct A {
       int i;
       virtual void f() = 0;
    };

    struct B : A {
       int j;
       B() : j(5)  {}
       virtual void f();
    };

    struct C : B {
       C() { j = 10; }
    };

    template &lt;class T&gt;
    int DefaultValue( int (T::*m) ) {
       return T().*m;
    }

    ... DefaultValue( &amp;B::i )    // Error: A is abstract
    ... DefaultValue( &amp;C::j )    // returns 5, not 10.
</PRE>

<P><B>Suggested resolution:</B>
5.3.1 [expr.unary.op]
 should be changed to
read,</P>

<BLOCKQUOTE>
If the member is a nonstatic member (perhaps by inheritance) of the
class nominated by the <I>nested-name-specifier</I> of the
<I>qualified-id</I> having type <TT>T</TT>, the type of the result is
"pointer to member of class <I>nested-name-specifier</I> of type
<TT>T</TT>."
</BLOCKQUOTE>

and the comment in the example should be changed to read,

<BLOCKQUOTE>
<TT>// <I>has type </I>int B::*</TT>
</BLOCKQUOTE>

<P><B>Notes from 04/00 meeting:</B></P>

<P>The rationale for the current treatment is to permit the widest
possible use to be made of a given address-of-member expression.
Since a pointer-to-base-member can be implicitly converted to a
pointer-to-derived-member, making the type of the expression a
pointer-to-base-member allows the result to initialize or be assigned
to either a pointer-to-base-member or a pointer-to-derived-member.
Accepting this proposal would allow only the latter use.</P>

<P><B>Additional notes:</B></P>

<P>Another problematic example has been mentioned:</P>

<PRE>
    class Base {
    public:
      int func() const;
    };

    class Derived : public Base {
    };

    template&lt;class T&gt;
    class Templ {
    public:
      template&lt;class S&gt;
      Templ(S (T::*ptmf)() const);
    };

    void foo()
    {
      Templ&lt;Derived&gt; x(&amp;Derived::func);    // <I>ill-formed</I>
    }
</PRE>

<P>In this example, even though the conversion of
<TT>&amp;Derived::func</TT> to <TT>int (Derived::*)() const</TT> is
permitted, the initialization of <TT>x</TT> cannot be done because
template argument deduction for the constructor fails.</P>

<P>If the suggested resolution were adopted, the amount of code broken
by the change might be reduced by adding an implicit conversion from
pointer-to-derived-member to pointer-to-base-member for appropriate
address-of-member expressions (not for arbitrary pointers to members,
of course).</P>

<P>(See also issues <A HREF="
     cwg_closed.html#247">247</A> and
<A HREF="
     cwg_defects.html#1121">1121</A>.)</P>

<BR><BR><HR><A NAME="1230"></A><H4>1230.
  
Confusing description of ambiguity of destructor name
</H4><B>Section: </B>5.3.1&#160; [expr.unary.op]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2010-12-13<BR>




<P>According to 5.3.1 [expr.unary.op] paragraph 10,</P>

<BLOCKQUOTE>

There is an ambiguity in the <I>unary-expression</I> <TT>~X()</TT>,
where <TT>X</TT> is a <I>class-name</I> or <I>decltype-specifier</I>.
The ambiguity is resolved in favor of treating <TT>~</TT> as a
unary complement rather than treating <TT>~X</TT> as referring
to a destructor.

</BLOCKQUOTE>

<P>It is not clear whether this is intended to apply to an
expression like <TT>(~S)()</TT>.  In large measure, that depends on
whether a <I>class-name</I> is an <I>id-expression</I> or not.  If it
is, the ambiguity described in 5.3.1 [expr.unary.op] paragraph
10 does apply; if not, the expression is an unambiguous reference to
the destructor for class <TT>S</TT>.  There are several places in the
Standard that indicate that the name of a type is an
<I>id-expression</I>, but that might be more confusing than helpful.</P>

<BR><BR><HR><A NAME="267"></A><H4>267.
  
Alignment requirement for <I>new-expression</I>s
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Kuyper
 &#160;&#160;&#160;

 <B>Date: </B>4 Dec 2000<BR>


<P>Requirements for the alignment of pointers returned by
<I>new-expression</I>s are given in 5.3.4 [expr.new]
paragraph 10:</P>

<BLOCKQUOTE>

For arrays of <TT>char</TT> and <TT>unsigned char</TT>, the difference
between the result of the <I>new-expression</I> and the address
returned by the allocation function shall be an integral multiple of
the most stringent alignment requirement (3.9 [basic.types])
of any object type whose size is no greater than the size of the array
being created.

</BLOCKQUOTE>

<P>The intent of this wording is that the pointer returned by the
<I>new-expression</I> will be suitably aligned for any data type
that might be placed into the allocated storage (since the
allocation function is constrained to return a pointer to
maximally-aligned storage).  However, there is an implicit
assumption that each alignment requirement is an integral multiple
of all smaller alignment requirements.  While this is probably a
valid assumption for all real architectures, there's no reason
that the Standard should require it.</P>

<P>For example, assume that <TT>int</TT> has an alignment requirement
of 3 bytes and <TT>double</TT> has an alignment requirement of 4
bytes.  The current wording only requires that a buffer that is big
enough for an <TT>int</TT> or a <TT>double</TT> be aligned on a 4-byte
boundary (the more stringent requirement), but that would allow the
buffer to be allocated on an 8-byte boundary &#8212; which might
<I>not</I> be an acceptable location for an <TT>int</TT>.</P>

<P><U>Suggested resolution</U>: Change "of any object type" to
"of every object type."</P>

<P>A similar assumption can be found in
5.2.10 [expr.reinterpret.cast] paragraph 7:</P>

<BLOCKQUOTE>

...converting an rvalue of type "pointer to <TT>T1</TT>" to the type
"pointer to <TT>T2</TT>" (where ... the alignment requirements of
<TT>T2</TT> are no stricter than those of <TT>T1</TT>) and back to its
original type yields the original pointer value...

</BLOCKQUOTE>

<P><U>Suggested resolution</U>: Change the wording to</P>

<BLOCKQUOTE>

...converting an rvalue of type "pointer to <TT>T1</TT>" to the type
"pointer to <TT>T2</TT>" (where ...  the alignment requirements of
<SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>T1</TT> are an integer multiple of those of <TT>T2</TT></SPAN>)
and back to its original type yields the original pointer value...

</BLOCKQUOTE>

<P>The same change would also be needed in paragraph 9.</P>

<BR><BR><HR><A NAME="473"></A><H4>473.
  
Block-scope declarations of allocator functions
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>12 Jul 2004<BR>


<P>Looking up <TT>operator new</TT> in a <I>new-expression</I>
uses a different mechanism from ordinary lookup.  According to
5.3.4 [expr.new] paragraph 9,</P>

<BLOCKQUOTE>
If the <I>new-expression</I> begins with a unary <TT>::</TT>
operator, the allocation function's name is looked up in the
global scope. Otherwise, if the allocated type is a class type
<TT>T</TT> or array thereof, the allocation function's name is
looked up in the scope of <TT>T</TT>. If this lookup fails to
find the name, or if the allocated type is not a class type, the
allocation function's name is looked up in the global scope.
</BLOCKQUOTE>

<P>Note in particular that the scope in which the
<I>new-expression</I> occurs is not considered.  For example,</P>

<PRE>
    void f() {
        void* operator new(std::size_t, void*);
        int* i = new int;    // okay?
    }
</PRE>

<P>In this example, the implicit reference to <TT>operator
new(std::size_t)</TT> finds the global declaration, even though
the block-scope declaration of <tt>operator new</tt> with a
different signature would hide it from an ordinary reference.</P>

<P>This seems strange; either the block-scope declaration should
be ill-formed or it should be found by the lookup.</P>

<P><B>Notes from October 2004 meeting:</B></P>

<P>The CWG agreed that the block-scope declaration should not be
found by the lookup in a <I>new-expression</I>.  It would,
however, be found by ordinary lookup if the allocation function
were invoked explicitly.</P>

<BR><BR><HR><A NAME="476"></A><H4>476.
  
Determining the buffer size for placement new
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Ben Hutchings
 &#160;&#160;&#160;

 <B>Date: </B>14 Sep 2004<BR>


<P>(See also <A HREF="
     cwg_defects.html#256">issue 256</A>.)</P>

<P>An implementation may have an unspecified amount of array
allocation overhead (5.3.4 [expr.new] paragraph 10),
so that evaluation of a <I>new-expression</I> in which the
<I>new-type-id</I> is <TT>T[n]</TT> involves a request for more
than <TT>n * sizeof(T)</TT> bytes of storage through the relevant
<TT>operator new[]</TT> function.</P>

<P>The placement <TT>operator new[]</TT> function does not and
cannot check whether the requested size is less than or equal to
the size of the provided region of memory (18.6.1.3 [new.delete.placement] paragraphs 5-6).  A program using placement
array new must calculate what the requested size will be in
advance.</P>

<P>Therefore any program using placement array new must take into
account the implementation's array allocation overhead, which
cannot be obtained or calculated by any portable means.</P>

<P><B>Notes from the April, 2005 meeting:</B></P>

<P>While the CWG agreed that there is no portable means to
accomplish this task in the current language, they felt that a
paper is needed to analyze the numerous mechanisms that might
address the problem and advance a specific proposal.  There is
no volunteer to write such a paper at this time.</P>

<BR><BR><HR><A NAME="196"></A><H4>196.
  
Arguments to deallocation functions </H4><B>Section: </B>5.3.5&#160; [expr.delete]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Matt Austern
 &#160;&#160;&#160;

 <B>Date: </B>20 Jan 2000<BR>





<P>5.3.4 [expr.new]
 paragraph 10 says that
the result of an array allocation function and the value of the array
<I>new-expression</I> from which it was invoked may be different,
allowing for space preceding the array to be used for implementation
purposes such as saving the number of elements in the array.  However,
there is no corresponding description of the relationship between the
operand of an array <I>delete-expression</I> and the argument passed
to its deallocation function.</P>

<P>3.7.4.2 [basic.stc.dynamic.deallocation]

paragraph 3 does state that</P>

<BLOCKQUOTE>
the value supplied to <TT>operator delete[](void*)</TT> in the
standard library shall be one of the values returned by a previous
invocation of either <TT>operator new[](std::size_t)</TT> or
<TT>operator new[](std::size_t, const std::nothrow_t&amp;)</TT> in the
standard library.
</BLOCKQUOTE>

<P>This statement might be read as requiring an implementation, when
processing an array <I>delete-expression</I> and calling the
deallocation function, to perform the inverse of the calculation
applied to the result of the allocation function to produce the value
of the <I>new-expression</I>.
(5.3.5 [expr.delete]
 paragraph 2 requires
that the operand of an array <I>delete-expression</I> "be the pointer
value which resulted from a previous array <I>new-expression</I>.")
However, it is not completely clear whether the "shall" expresses an
implementation requirement or a program requirement (or both).
Furthermore, there is no direct statement about user-defined
deallocation functions.</P>

<P><B>Suggested resolution:</B> A note should be added to
5.3.5 [expr.delete]
 to clarify that any
offset added in an array <I>new-expression</I> must be subtracted in
the array <I>delete-expression</I>.</P>
<BR><BR><HR><A NAME="242"></A><H4>242.
  
Interpretation of old-style casts
</H4><B>Section: </B>5.4&#160; [expr.cast]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>30 Aug 2000<BR>




<P>The meaning of an old-style cast is described in terms of
<TT>const_cast</TT>, <TT>static_cast</TT>, and
<TT>reinterpret_cast</TT> in 5.4 [expr.cast] paragraph 5.
Ignoring <TT>const_cast</TT> for the moment, it basically says that if
the conversion performed by a given old-style cast is one of those
performed by <TT>static_cast</TT>, the conversion is interpreted as if
it were a <TT>static_cast</TT>; otherwise, it's interpreted as if it
were a <TT>reinterpret_cast</TT>, if possible.  The following example
is given in illustration:</P>

<PRE>
    struct A {};
    struct I1 : A {};
    struct I2 : A {};
    struct D : I1, I2 {};
    A *foo( D *p ) {
	return (A*)( p ); // ill-formed static_cast interpretation
    }
</PRE>

<P>The obvious intent here is that a derived-to-base pointer
conversion is one of the conversions that can be performed using
<TT>static_cast</TT>, so <TT>(A*)(p)</TT> is equivalent to
<TT>static_cast&lt;A*&gt;(p)</TT>, which is ill-formed because of the
ambiguity.</P>

<P>Unfortunately, the description of <TT>static_cast</TT> in
5.2.9 [expr.static.cast] does NOT support this interpretation.
The problem is in the way 5.2.9 [expr.static.cast] lists the
kinds of casts that can be performed using <TT>static_cast</TT>.
Rather than saying something like "All standard conversions can be
performed using <TT>static_cast</TT>," it says</P>

<BLOCKQUOTE>
An expression e can be explicitly converted to a type <TT>T</TT> using
a <TT>static_cast</TT> of the form <TT>static_cast&lt;T&gt;(e)</TT> if
the declaration "<TT>T t(e);</TT>" is well-formed, for some invented
temporary variable <TT>t</TT>.
</BLOCKQUOTE>

<P>Given the declarations above, the hypothetical declaration</P>

<PRE>
    A* t(p);
</PRE>

<P>is NOT well-formed, because of the ambiguity.  Therefore the old-style
cast <TT>(A*)(p)</TT> is NOT one of the conversions that can be performed
using <TT>static_cast</TT>, and <TT>(A*)(p)</TT> is equivalent to
<TT>reinterpret_cast&lt;A*&gt;(p)</TT>, which is well-formed under
5.2.10 [expr.reinterpret.cast] paragraph 7.</P>

<P>Other situations besides ambiguity which might raise similar
questions include access violations, casting from virtual base
to derived, and casting pointers-to-members when virtual
inheritance is involved.</P>

<BR><BR><HR><A NAME="583"></A><H4>583.
  
Relational pointer comparisons against the null pointer constant
</H4><B>Section: </B>5.9&#160; [expr.rel]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>24 May 2006<BR>




<P>In C, this is ill-formed (cf C99 6.5.8):</P>

<PRE>
    void f(char* s) {
        if (s &lt; 0) { }
    }
</PRE>

<P>...but in C++, it's not.  Why?  Who would ever need to write
<TT>(s &gt; 0)</TT>
when they could just as well write <TT>(s != 0)</TT>?</P>

<P>This has been in the language since the ARM (and possibly earlier);
apparently it's because the pointer conversions (4.10 [conv.ptr]) need to be performed on both operands whenever one of
the operands is of pointer type.  So it looks like the
"null-ptr-to-real-pointer-type" conversion is hitching a ride with the
other pointer conversions.</P>

<BR><BR><HR><A NAME="631"></A><H4>631.
  
Jumping into a &#8220;then&#8221; clause
</H4><B>Section: </B>6.4.1&#160; [stmt.if]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Kanze
 &#160;&#160;&#160;

 <B>Date: </B>24 April 2007<BR>


<P>6.4.1 [stmt.if] is silent about whether the <TT>else</TT>
clause of an <TT>if</TT> statement is executed if the condition is not
evaluated.  (This could occur via a <TT>goto</TT> or a <TT>longjmp</TT>.)
C99 covers the <TT>goto</TT> case with the following provision:</P>

<BLOCKQUOTE>

If the first substatement is reached via a label, the second
substatement is not executed.

</BLOCKQUOTE>

<P>It should probably also be stated that the condition is not
evaluated when the &#8220;then&#8221; clause is entered directly.</P>

<BR><BR><HR><A NAME="1223"></A><H4>1223.
  
Syntactic disambiguation and <I>trailing-return-type</I>s
</H4><B>Section: </B>6.8&#160; [stmt.ambig]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2010-11-08<BR>


<P>Because the restriction that a <I>trailing-return-type</I> can
appear only in a declaration with &#8220;the single <I>type-specifier</I>
<TT>auto</TT>&#8221; (8.3.5 [dcl.fct] paragraph 2) is a
semantic, not a syntactic, restriction, it does not influence
disambiguation, which is &#8220;purely syntactic&#8221;
(6.8 [stmt.ambig] paragraph 3).  Consequently, some
previously unambiguous expressions are now ambiguous.  For example:</P>

<PRE>
struct A {
  A(int *);
  A *operator()(void);
  int B;
};
 
int *p;
typedef struct BB { int C[2]; } *B, C;
 
void foo() {
// The following line becomes invalid under C++0x:
  A (p)()-&gt;B;  // ill-formed function declaration
 
// In the following,
// - B()-&gt;C is either type-id or class member access expression
// - B()-&gt;C[1] is either type-id or subscripting expression
// N3126 subclause 8.2 [dcl.ambig.res] does not mention an ambiguity
// with these forms of expression
  A a(B ()-&gt;C);  // function declaration or object declaration
  sizeof(B ()-&gt;C[1]);  // sizeof(type-id) or sizeof on an expression
}
</PRE>

<BR><BR><HR><A NAME="157"></A><H4>157.
  
Omitted typedef declarator
</H4><B>Section: </B>7&#160; [dcl.dcl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>19 Aug 1999<BR>





<P>7 [dcl.dcl]
 paragraph 3 reads,</P>

<BLOCKQUOTE>
In a <I>simple-declaration</I>, the optional
<I>init-declarator-list</I> can be omitted only when... the
<I>decl-specifier-seq</I> contains either a <I>class-specifier</I>,
an <I>elaborated-type-specifier</I> with a <I>class-key</I>
(9.1 [class.name]
), or an
<I>enum-specifier</I>.  In these cases and whenever a
<I>class-specifier</I> or <I>enum-specifier</I> is present in the
<I>decl-specifier-seq</I>, the identifiers in those specifiers are
among the names being declared by the declaration...  In such cases,
and except for the declaration of an unnamed bit-field
(9.6 [class.bit]
), the
<I>decl-specifier-seq</I> shall introduce one or more names into the
program, or shall redeclare a name introduced by a previous
declaration.  [<I>Example:</I>

<PRE>
    enum { };           // <I>ill-formed</I>
    typedef class { };  // <I>ill-formed</I>
</PRE>

<I>&#8212;end example</I>]
</BLOCKQUOTE>

In the absence of any explicit restrictions in
7.1.3 [dcl.typedef]
, this paragraph appears
to allow declarations like the following:

<PRE>
    typedef struct S { };    // no declarator
    typedef enum { e1 };     // no declarator
</PRE>

In fact, the final example in
7 [dcl.dcl]
 paragraph 3 would seem to
indicate that this is intentional: since it is illustrating the
requirement that the <I>decl-specifier-seq</I> must introduce a name
in declarations in which the <I>init-declarator-list</I> is omitted,
presumably the addition of a class name would have made the example
well-formed.

<P>On the other hand, there is no good reason to allow such
declarations; the only reasonable scenario in which they might occur
is a mistake on the programmer's part, and it would be a service to
the programmer to require that such errors be diagnosed.</P>
<BR><BR><HR><A NAME="498"></A><H4>498.
  
Storage class specifiers in definitions of class members
</H4><B>Section: </B>7.1.1&#160; [dcl.stc]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Matt Austern
 &#160;&#160;&#160;

 <B>Date: </B>13 Jan 2005<BR>




<P>Suppose we've got this class definition:</P>

<PRE>
    struct X {
       void f();
       static int n;
    };
</PRE>

<P>I think I can deduce from the existing standard that the following 
member definitions are ill-formed:</P>

<PRE>
    static void X::f() { }
    static int X::n;
</PRE>

<P>To come to that conclusion, however, I have to put together several
things in different parts of the standard.  I would have expected to
find an explicit statement of this somewhere; in particular, I would
have expected to find it in 7.1.1 [dcl.stc].  I don't
see it there, or anywhere.</P>

<P><U>Gabriel Dos Reis</U>: Or in 3.5 [basic.link] which is
about linkage.  I would have expected that paragraph to say that that
members of class types have external linkage when the enclosing class
has an external linkage.  Otherwise 3.5 [basic.link]
paragraph 8:
</P>

<BLOCKQUOTE>

Names not covered by these rules have no linkage.

</BLOCKQUOTE>

<P>might imply that such members do not have linkage.</P>

<P><B>Notes from the April, 2005 meeting:</B></P>

<P>The question about the linkage of class members is already
covered by 3.5 [basic.link] paragraph 5.</P>

<BR><BR><HR><A NAME="609"></A><H4>609.
  
What is a &#8220;top-level&#8221; cv-qualifier?
</H4><B>Section: </B>7.1.6.1&#160; [dcl.type.cv]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Dawn Perchik
 &#160;&#160;&#160;

 <B>Date: </B>5 November 2006<BR>


<P>The phrase &#8220;top-level cv-qualifier&#8221; is used numerous
times in the Standard, but it is not defined.  The phrase could be
misunderstood to indicate that the <TT>const</TT> in something like
<TT>const T&amp;</TT> is at the &#8220;top level,&#8221; because
where it appears is the highest level at which it is permitted:
<TT>T&amp; const</TT> is ill-formed.</P>

<BR><BR><HR><A NAME="144"></A><H4>144.
  
Position of <TT>friend</TT> specifier
</H4><B>Section: </B>7.1.6.3&#160; [dcl.type.elab]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>22 Jul 1999<BR>





<P>7.1.6.3 [dcl.type.elab]
 paragraph 1 seems to
impose an ordering constraint on the elements of friend class
declarations.  However, the general rule is that declaration
specifiers can appear in any order.  Should</P>

<PRE>
    class C friend;
</PRE>

be well-formed?
<BR><BR><HR><A NAME="977"></A><H4>977.
  
When is an enumeration type complete?
</H4><B>Section: </B>7.2&#160; [dcl.enum]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>3 October, 2009<BR>




<P>There is disagreement among implementations as to when an enumeration
type is complete.  For example,</P>

<PRE>
    enum E { e = E() };
</PRE>

<P>is rejected by some and accepted by another.  The Standard does
not appear to resolve this question definitively.</P>

<BR><BR><HR><A NAME="987"></A><H4>987.
  
Which declarations introduce namespace members?
</H4><B>Section: </B>7.3&#160; [basic.namespace]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>19 October, 2009<BR>


<P>According to 7.3 [basic.namespace] paragraph 1,</P>

<BLOCKQUOTE>

The name of a namespace can be used to access entities
declared in that namespace; that is, the members of the
namespace.

</BLOCKQUOTE>

<P>implying that all declarations in a namespace, including
definitions of members of nested namespaces, explicit instantiations,
and explicit specializations, introduce members of the containing
namespace.  7.3.1.2 [namespace.memdef] paragraph 3 clarifies the
intent somewhat:</P>

<BLOCKQUOTE>

Every name first declared in a namespace is a member of that namespace.

</BLOCKQUOTE>

<P>However, current changes to clarify the behavior of deleted
functions (which must be deleted on their &#8220;first
declaration&#8221;) state that an explicit specialization of a
function template is its first declaration.</P>

<BR><BR><HR><A NAME="1021"></A><H4>1021.
  
Definitions of namespace members
</H4><B>Section: </B>7.3.1.2&#160; [namespace.memdef]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2010-01-14<BR>


<P>According to 7.3.1.2 [namespace.memdef] paragraphs 1 and 2 read,</P>

<BLOCKQUOTE>

<P>Members (including explicit specializations of templates
(14.7.3 [temp.expl.spec])) of a namespace can be defined
within that namespace.</P>

<P>Members of a named namespace can also be defined outside that
namespace by explicit qualification (3.4.3.2 [namespace.qual]) of the name being defined, provided that the
entity being defined was already declared in the namespace and
the definition appears after the point of declaration in a
namespace that encloses the declaration's namespace.</P>

</BLOCKQUOTE>

<P>It is not clear what these specifications mean for the
following pair of examples:</P>

<PRE>
    namespace N {
        struct A;
    }
    using N::A;
    struct A { };
</PRE>

<P>Although this does not satisfy the &#8220;by explicit
qualification&#8221; requirement, it is accepted by major
implementations.</P>

<PRE>
    struct S;
    namespace A {
        using ::S;
        struct S  { };
    }
</PRE>

<P>Is this a definition &#8220;within that namespace,&#8221; or
should that wording be interpreted as &#8220;directly within&#8221;
the namespace?</P>

<BR><BR><HR><A NAME="36"></A><H4>36.
  
<I>using-declaration</I>s in multiple-declaration contexts
</H4><B>Section: </B>7.3.3&#160; [namespace.udecl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Andrew Koenig
 &#160;&#160;&#160;

 <B>Date: </B>20 Aug 1998<BR>





<P>Section 7.3.3 [namespace.udecl]
 paragraph 8 says:</P>
<BLOCKQUOTE>A <I>using-declaration</I> is a declaration and can therefore be used
repeatedly where (and only where) multiple declarations are allowed.</BLOCKQUOTE>
It contains the following example:
<PRE>
    namespace A {
            int i;
    }
    
    namespace A1 {
            using A::i;
            using A::i;             // OK: double declaration
    }
    
    void f()
    {
            using A::i;
            using A::i;             // error: double declaration
    }
</PRE>
However, if "<TT>using A::i;</TT>" is really a declaration, and not a definition, it is far from clear that repeating it should be an error in either context.
Consider:
<PRE>
    namespace A {
            int i;
            void g();
    }
    
    void f() {
            using A::g;
            using A::g;
    }
</PRE>
Surely the definition of f should be analogous to
<PRE>
    void f() {
            void g();
            void g();
    }
</PRE>
which is well-formed because "<TT>void g();</TT>" is a declaration and
not a definition.

<P>Indeed, if the double using-declaration for <TT>A::i</TT> is prohibited
in <TT>f</TT>, why should it be allowed in namespace <TT>A1</TT>?</P>

<P><B>Proposed Resolution (04/99):</B>

Change the comment "<TT>// error: double declaration</TT>" to
"<TT>// OK: double declaration</TT>".

(This should be reviewed against existing practice.)</P>

<P><B>Notes from 04/00 meeting:</B></P>

<P>The core language working group was unable to come to consensus
over what kind of declaration a <I>using-declaration</I> should
emulate.  In a straw poll, 7 members favored allowing
<I>using-declaration</I>s wherever a non-definition declaration could
appear, while 4 preferred to allow multiple <I>using-declaration</I>s
only in namespace scope (the rationale being that the permission for
multiple <I>using-declaration</I>s is primarily to support its use in
multiple header files, which are seldom included anywhere other than
namespace scope).  John Spicer pointed out that <TT>friend</TT>
declarations can appear multiple times in class scope and asked if
<I>using-declaration</I>s would have the same property under the "like
a declaration" resolution.</P>

<P>As a result of the lack of agreement, the issue was returned to
"open" status.  </P>

<P>See also issues
<A HREF="
     cwg_defects.html#56">56</A>, <A HREF="
     cwg_defects.html#85">85</A>,
and <A HREF="
     cwg_active.html#138">138</A>..</P>

<P><B>Additional notes (January, 2005):</B></P>

<P>Some related issues have been raised concerning the following
example (modified from a C++ validation suite test):</P>

<PRE>
    struct A
    {
        int i;
        static int j;
    };

    struct B : A { };
    struct C : A { };

    struct D : virtual B, virtual C
    {
        using B::i;
        using C::i;
        using B::j;
        using C::j;
    };
</PRE>

<P>Currently, it appears that the <I>using-declaration</I>s of
<TT>i</TT> are ill-formed, on the basis of 7.3.3 [namespace.udecl] paragraph 10:</P>

<BLOCKQUOTE>

Since a <I>using-declaration</I> is a declaration, the
restrictions on declarations of the same name in the same
declarative region (3.3 [basic.scope]) also apply to
<I>using-declaration</I>s.

</BLOCKQUOTE>

<P>Because the <I>using-declaration</I>s of <TT>i</TT> refer to
different objects, declaring them in the same scope is not
permitted under 3.3 [basic.scope].  It might, however,
be preferable to treat this case as many other ambiguities are:
allow the declaration but make the program ill-formed if a name
reference resolves to the ambiguous declarations.</P>

<P>The status of the <I>using-declaration</I>s of <TT>j</TT>,
however, is less clear.  They both declare the same entity and
thus do not violate the rules of 3.3 [basic.scope].
This might (or might not) violate the restrictions of
9.2 [class.mem] paragraph 1:</P>

<BLOCKQUOTE>

Except when used to declare friends (11.4 [class.friend])
or to introduce the name of a member of a base class into a
derived class (7.3.3 [namespace.udecl], 11.3 [class.access.dcl]), <I>member-declaration</I>s declare members of the
class, and each such member-declaration shall declare at least
one member name of the class. A member shall not be declared
twice in the <I>member-specification</I>, except that a nested
class or member class template can be declared and then later
defined.

</BLOCKQUOTE>

<P>Do the <I>using-declaration</I>s of <TT>j</TT> repeatedly
declare the same member?  Or is the preceding sentence an
indication that a <I>using-declaration</I> is not a declaration
of a member?</P>

<BR><BR><HR><A NAME="109"></A><H4>109.
  
Allowing <TT>::template</TT> in <I>using-declaration</I>s
</H4><B>Section: </B>7.3.3&#160; [namespace.udecl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>6 Apr 1999<BR>



<P><I>Daveed Vandevoorde

:</I>
While reading <A HREF="
     cwg_defects.html#11">Core issue 11</A>
I thought it implied the following
possibility:</P>
<PRE>
    template&lt;typename T&gt;
    struct B {
       template&lt;int&gt; void f(int);
    };

    template&lt;typename T&gt;
    struct D: B&lt;T&gt; {
       using B&lt;T&gt;::template f;
       void g() { this-&gt;f&lt;1&gt;(0); } // OK, f is a template
    };
</PRE>
<P>However, the grammar for a <I>using-declaration</I> reads:</P>
<UL>
<TT>using typename<SUB>opt</SUB>&#160;::<SUB>opt</SUB>&#160;<I>nested-name-specifier&#160;unqualified-id</I> ;</TT>
</UL>
<P>and <I>nested-name-specifier</I> never ends in "<TT>template</TT>".</P>
<P>Is that intentional?</P>

<P><I>Bill Gibbons

:</I></P>
<P>It certainly appears to be, since we have:</P>
<UL>
<I>qualified-id</I>:
<UL><TT>::<SUB>opt</SUB> <I>nested-name-specifier</I> template<SUB>opt</SUB> <I>unqualified-id</I></TT></UL>
</UL>
so it would be easier to specify <I>using-declaration</I> as:
<UL>
<TT>using typename<SUB>opt</SUB> <I>qualified-id</I> ;</TT>
</UL>
if the "<TT>template</TT>" keyword were allowed.

There was a discussion about whether a dependent name specified in a
<I>using-declaration</I> could be given an "is a type" attribute through the
<TT>typename</TT> keyword; the decision was to allow this.  But I don't recall
if the "is a template" attribute was discussed.

<P><B>Rationale (04/99):</B> Any semantics associated with the
<TT>template</TT> keyword in <I>using-declaration</I>s should be considered an
extension.</P>

<P><B>Notes from the April 2003 meeting:</B></P>

<P>See also issues <A HREF="
     cwg_defects.html#96">96</A> and
<A HREF="
     cwg_defects.html#11">11</A>.</P>

<P>We decided to make no change and to close this issue as not-a-defect.
This is not needed functionality; the example above, for example, can
be written with <TT>-&gt;template</TT>.  This issue has been on the
issues list for years as an extension, and there has been no clamor
for it.</P>

<P>It was also noted that knowing that something is a template is
not enough; there's still the issue of knowing whether it is a
class or function template.</P>

<P><B>Additional note (February, 2011):</B></P>

<P>This issue is being reopened for further consideration after
additional discussion<committee-only>; see messages
<A href="
   http://accu.org/cgi-bin/wg21/message?wg=core&amp;msg=18492">18492</A> through <A href="
   http://accu.org/cgi-bin/wg21/message?wg=core&amp;msg=18499">18499</A></committee-only>.  It
was noted that, in addition to the workaround described above for
the member function template case, the new alias template facility
provides a workaround for the member class template case: instead
of</P>

<PRE>
    using T::template X;  //<SPAN style="font-family:Times;font-style:italic"> ill-formed</SPAN>
</PRE>

<P>for a class template member <TT>X</TT> of base class <TT>T</TT>,
one could write</P>

<PRE>
    template&lt;U&gt; using X = typename T::template X&lt;U&gt;;
</PRE>

<BR><BR><HR><A NAME="386"></A><H4>386.
  
Friend declaration of name brought in by using-declaration
</H4><B>Section: </B>7.3.3&#160; [namespace.udecl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Herb Sutter
 &#160;&#160;&#160;

 <B>Date: </B>8 Oct 2002<BR>


<P>The following came up recently on comp.lang.c++.moderated (edited for
brevity):</P>
<PRE>
  namespace N1 {
    template&lt;typename T&gt; void f( T* x ) {
      // ... other stuff ...
      delete x;
    }
  }

  namespace N2 {
    using N1::f;

    template&lt;&gt; void f&lt;int&gt;( int* ); // A: ill-formed

    class Test {
      ~Test() { }
      friend void f&lt;&gt;( Test* x );   // B: ill-formed?
    };
  }
</PRE>
<P>I strongly suspect, but don't have standardese to prove, that the friend
declaration in line B is ill-formed. Can someone show me the text that
allows or disallows line B?</P>

<P>Here's my reasoning: Writing "using" to pull the name into namespace N2
merely allows code in N2 to use the name in a call without qualification
(per 7.3.3 [namespace.udecl]).
But just as declaring a specialization must be done in the
namespace where the template really lives (hence line A is ill-formed), I
suspect that declaring a specialization as a friend must likewise be done
using the original namespace name, not obliquely through a "using". I see
nothing in 7.3.3 [namespace.udecl]
that would permit this use. Is there?</P>

<P><U>Andrey Tarasevich</U>:
14.5.4 [temp.friend] paragraph 2 seems to get pretty close:
"A friend declaration that is not a
template declaration and in which the name of the friend is an unqualified
'template-id' shall refer to a specialization of a function template
declared in the nearest enclosing namespace scope". </P>

<P><U>Herb Sutter</U>:
OK, thanks. Then the question in this is the word "declared" -- in
particular, we already know we cannot declare a specialization of a template
in any other namespace but the original one.</P>

<P><U>John Spicer</U>:
This seems like a simple question, but it isn't.</P>

<P>First of all, I don't think the standard comments on this usage one way 
or the other.</P>

<P>A similar example using a namespace qualified name is ill-formed based 
on 8.3 [dcl.meaning] paragraph 1:</P>
<PRE>
  namespace N1 {
        void f();
  }

  namespace N2 {
        using N1::f;
        class A {
                friend void N2::f();
        };
  }
</PRE>

<P><A HREF="
     cwg_active.html#138">Core issue 138</A> deals with this example:</P>
<PRE>
  void foo();
  namespace A{
    using ::foo;
    class X{
      friend void foo();
    };
  }
</PRE>
<P>The proposed resolution (not yet approved) for
<A HREF="
     cwg_active.html#138">issue 138</A> is that the 
friend declares a new
foo that conflicts with the using-declaration and results in an error.</P>

<P>Your example is different than this though because the presence of the 
explicit argument list
means that this is not declaring a new f but is instead using a 
previously declared f.</P>

<P>One reservation I have about allowing the example is the desire to have 
consistent rules for all of the "declaration like" uses of template 
functions.   <A HREF="
     cwg_defects.html#275">Issue 275</A> (in DR status) addresses the
issue of unqualified names in explicit instantiation and explicit 
specialization declarations.
It requires that such declarations refer to templates from the namespace 
containing the
explicit instantiation or explicit specialization.  I believe this rule 
is necessary for those directives but is not really required for friend 
declarations -- but there is the consistency issue.</P>

<P><B>Notes from April 2003 meeting:</B></P>

<P>This is related to <A HREF="
     cwg_active.html#138">issue 138</A>.  John Spicer
is supposed to update his paper on this topic.  This is a new case
not covered in that paper.  We agreed that the B line should be
allowed.</P>

<BR><BR><HR><A NAME="565"></A><H4>565.
  
Conflict rules for <I>using-declaration</I>s naming function templates
</H4><B>Section: </B>7.3.3&#160; [namespace.udecl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Paolo Carlini
 &#160;&#160;&#160;

 <B>Date: </B>9 March 2006<BR>




<P>The Standard does not appear to specify what happens for code like the
following:</P>

<PRE>
    namespace one {
      template&lt;typename T&gt; void fun(T);
    }

    using one::fun;

    template&lt;typename T&gt; void fun(T);
</PRE>

<P>7.3.3 [namespace.udecl] paragraph 13 does not appear to apply
because it deals only with functions, not function templates:</P>

<BLOCKQUOTE>

If a function declaration in namespace scope or block scope has the
same name and the same parameter types as a function introduced by a
<I>using-declaration</I>, and the declarations do not declare the same
function, the program is ill-formed.

</BLOCKQUOTE>

<P><U>John Spicer</U>: For function templates I believe the rule
should be that if they have the same function type (parameter types
and return type) and have identical template parameter lists, the
program is ill-formed.</P>

<BR><BR><HR><A NAME="813"></A><H4>813.
  
<TT>typename</TT> in a <I>using-declaration</I> with a non-dependent name
</H4><B>Section: </B>7.3.3&#160; [namespace.udecl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>UK
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK101">N2800 comment
  UK&#160;101<BR></A>

<P>7.3.3 [namespace.udecl] paragraph 20 says,</P>

<BLOCKQUOTE>

If a <I>using-declaration</I> uses the keyword <TT>typename</TT> and
specifies a dependent name (14.6.2 [temp.dep]), the name
introduced by the <I>using-declaration</I> is treated as a
<I>typedef-name</I> (7.1.3 [dcl.typedef]).

</BLOCKQUOTE>

<P>This wording does not address use of <TT>typename</TT> in a
<I>using-declaration</I> with a non-dependent name; the primary
specification of the <TT>typename</TT> keyword in 14.6 [temp.res] does not appear to describe this case, either.</P>

<BR><BR><HR><A NAME="852"></A><H4>852.
  
<I>using-declaration</I>s and dependent base classes
</H4><B>Section: </B>7.3.3&#160; [namespace.udecl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2 April, 2009<BR>


<P>The status of an example like the following is unclear in the current
Standard:</P>

<PRE>
    struct B {
        void f();
    };
    template&lt;typename T&gt; struct S: T {
        using B::f;
    };
</PRE>

<P>7.3.3 [namespace.udecl] does not deal explicitly with dependent
base classes, but does say in paragraph 3,</P>

<BLOCKQUOTE>

In a <I>using-declaration</I> used as a <I>member-declaration</I>, the
<I>nested-name-specifier</I> shall name a base class of the class
being defined. If such a <I>using-declaration</I> names a constructor,
the <I>nested-name-specier</I> shall name a direct base class of the
class being defined; otherwise it introduces the set of declarations
found by member name lookup (10.2 [class.member.lookup], 3.4.3.1 [class.qual]).

</BLOCKQUOTE>

<P>In the definition of <TT>S</TT>, <TT>B::f</TT> is not a dependent
name but resolves to an apparently unrelated class.  However, because
<TT>S</TT> could be instantiated as <TT>S&lt;B&gt;</TT>, presumably
14.6 [temp.res] paragraph 8 would apply:</P>

<BLOCKQUOTE>

No diagnostic shall be issued for a template definition for which a
valid specialization can be generated.

</BLOCKQUOTE>

<P>Note also the resolution of <A HREF="
     cwg_defects.html#515">issue 515</A>,
which permitted a similar use of a dependent base class named with a
non-dependent name.</P>

<BR><BR><HR><A NAME="563"></A><H4>563.
  
Linkage specification for objects
</H4><B>Section: </B>7.5&#160; [dcl.link]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>8 March 2006<BR>


<P>It is not clear whether some of the wording in 7.5 [dcl.link]
that applies only to function types and names ought also to apply to
object names.  In particular, paragraph 3 says,</P>

<BLOCKQUOTE>

Every implementation shall provide for linkage to functions written in
the C programming language, <TT>"C"</TT>, and linkage to C++
functions, <TT>"C++"</TT>.

</BLOCKQUOTE>

<P>Nothing is said about variable names, apparently meaning that
implementations need not provide C (or even C++!) linkage for
variable names.  Also, paragraph 5 says,</P>

<BLOCKQUOTE>

Except for functions with C++ linkage, a function declaration without
a linkage specification shall not precede the first linkage
specification for that function. A function can be declared without a
linkage specification after an explicit linkage specification has been
seen; the linkage explicitly specified in the earlier declaration is
not affected by such a function declaration.

</BLOCKQUOTE>

<P>There doesn't seem to be a good reason for these provisions not
to apply to variable names, as well.</P>

<BR><BR><HR><A NAME="1063"></A><H4>1063.
  
<TT>[[hiding]]</TT> with non-attribute declarations
</H4><B>Section: </B>7.6.5&#160; [dcl.attr.override]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-23<BR>




<P>There are some kinds of declarations that can appear in a derived
class and hide names from a base class, but for which the syntax does
not permit a <TT>[[hiding]]</TT> attribute.  For example:</P>

<PRE>
    struct B1 {
        int N;
        int M;
    };
    struct B2 {
        int M;
    };
    struct [[base_check]] D: B1, B2 {
        enum { N };    // hides B1::N but cannot take an attribute
        using B1::M;   // hides B2::M but cannot take an attribute
    };
</PRE>

<P><B>Additional note (October, 2010):</B></P>

<P><I>alias-declaration</I>s should also be considered in this
regard. </P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>Paper N3206 did not address these cases; in fact, it introduced
additional member declarations that cannot be annotated as hiding a
base class member (<I>function-definition</I>s and
<I>template-declaration</I>s), because the <TT>new</TT>
<I>virt-specifier</I> applies to a <I>member-declarator</I> and none
of these <I>member-declaration</I>s uses a <I>member-declarator</I>.</P>

<P><B>Additional note (November, 2010):</B></P>

<P>The injected-class-name can also hide a name from a base class
but cannot be annotated with <TT>new</TT>.</P>

<BR><BR><HR><A NAME="1133"></A><H4>1133.
  
Keywords vs attributes for control of hiding and overriding
</H4><B>Section: </B>7.6.5&#160; [dcl.attr.override]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US44">N3092 comment
  US&#160;44<BR></A>

<P>The facility for checking hiding and overriding of base class members
should not use the attribute syntax but should use keywords instead.
Concerns about breaking code by changing current identifiers into
keywords can be addressed by using contextual keywords, i.e., by putting
the keywords into syntactic locations where identifiers cannot appear
and thus continuing to allow their use as ordinary identifiers in other
contexts.</P>

<P><B>Notes from the August, 2010 meeting:</B></P>

<P>CWG expressed a preference for non-contextual keywords for these
features.</P>

<BR><BR><HR><A NAME="1243"></A><H4>1243.
  
Misleading footnote regarding multiple-declarator declarations
</H4><B>Section: </B>8&#160; [dcl.decl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-02-08<BR>




<P>The footnote for 8 [dcl.decl] paragraph 3 reads,</P>

<BLOCKQUOTE>

A declaration with several declarators is usually equivalent to the
corresponding sequence of declarations each with a single
declarator...  The exception occurs when a name introduced by one of
the <I>declarator</I>s hides a type name used by the
<I>decl-specifier</I>s, so that when the same decl-specifiers are used
in a subsequent declaration, they do not have the same meaning...

</BLOCKQUOTE>

<P>A more important exception to the rule has been added in C++0x,
specifically with the <TT>auto</TT> specifier when the deduced type is
not the same for all <I>declarator</I>s, which renders the declaration
ill-formed.  The footnote should be updated accordingly.</P>

<BR><BR><HR><A NAME="1234"></A><H4>1234.
  
<I>abstract-declarator</I> does not permit <TT>...</TT> after <I>ptr-operator</I>
</H4><B>Section: </B>8.1&#160; [dcl.name]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-01-18<BR>




<P>The ellipsis for a parameter pack enters the normal
<I>declarator</I> grammar as part of the <I>declarator-id</I>
nonterminal.  In contrast, however, the <I>abstract-declarator</I>
grammar has no counterpart to <I>declarator-id</I>; instead, the
ellipsis is one of the productions for the <I>abstract-declarator</I>
nonterminal itself.  It is thus impossible to declare a parameter
pack for a pointer or reference using an abstract declarator, e.g.,</P>

<PRE>
  template&lt;typename... T&gt; void f(T&amp; ...t);   //<SPAN style="font-family:Times;font-style:italic"> </SPAN>t<SPAN style="font-family:Times;font-style:italic"> is a parameter pack</SPAN>
  template&lt;typename... T&gt; void f(T&amp; ...);    //<SPAN style="font-family:Times;font-style:italic"> equivalent to </SPAN>void f(T&amp;, ...)
</PRE>

<BR><BR><HR><A NAME="504"></A><H4>504.
  
Should use of a reference in its own initializer require a diagnostic?
</H4><B>Section: </B>8.3.2&#160; [dcl.ref]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Bjarne Stroustrup
 &#160;&#160;&#160;

 <B>Date: </B>14 Apr 2005<BR>


<P> Split
off from <A HREF="
     cwg_active.html#453">issue 453</A>.</P>

<P>It is in general not possible to determine at compile time whether
a reference is used before it is initialized.  Nevertheless, there is
some sentiment to require a diagnostic in the obvious cases that can
be detected at compile time, such as the name of a reference appearing
in its own initializer.  The resolution of <A HREF="
     cwg_active.html#453">issue 453</A> originally made such uses ill-formed, but the CWG decided
that this question should be a separate issue.</P>

<P><B>Rationale (October, 2005):</B></P>

<P>The CWG felt that this error was not likely to arise very
often in practice.  Implementations can warn about such constructs,
and the resolution for <A HREF="
     cwg_active.html#453">issue 453</A> makes
executing such code undefined behavior; that seemed to address the
situation adequately.</P>

<P><B>Note (February, 2006):</B></P>

<P>Recent discussions  have suggested that undefined behavior be
reduced.  One possibility (broadening the scope of this issue to
include object declarations as well as references) was to require a
diagnostic if the initializer uses the value, but not just the
address, of the object or reference being declared:</P>

<PRE>
    int i = i;        //<SPAN style="font-family:Times;font-style:italic"> Ill-formed, diagnostic required</SPAN>
    void* p = &amp;p;     //<SPAN style="font-family:Times;font-style:italic"> Okay</SPAN>
</PRE>

<BR><BR><HR><A NAME="1222"></A><H4>1222.
  
Unnecessary restriction on <TT>auto</TT> array types
</H4><B>Section: </B>8.3.4&#160; [dcl.array]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2010-11-08<BR>


<P>According to 8.3.4 [dcl.array] paragraph 1,</P>

<BLOCKQUOTE>

<P>In a declaration <TT>T D</TT> where <TT>D</TT> has the form</P>

<UL><TT>D1 [</TT> <I>constant-expression<SUB>opt</SUB></I> <TT>]</TT> <I>attribute-specifier</I><SUB>opt</SUB></UL>

<P>and the type of the identifier in the declaration <TT>T D1</TT> is
&#8220;<I>derived-declarator-type-list</I> <TT>T</TT>&#8221;, then the
type of the identifier of <TT>D</TT> is an array type; if the type of
the identifier of <TT>D</TT> contains the <TT>auto</TT>
<I>type-specifier</I>, the program is ill-formed.</P>

</BLOCKQUOTE>

<P>This has the effect of prohibiting a declaration like</P>

<PRE>
    int v[1];
    auto (*p)[1] = &amp;v;
</PRE>

<P>This restriction is unnecessary and presumably unintentional.</P>

<P>Note also that the statement that &#8220;the type of the identifier
of <TT>D</TT> is an array type&#8221; is incorrect when the nested
declarator is not simply a <I>declarator-id</I>.  A similar problem
exists in the wording of 8.5.3 [dcl.init.ref] paragraph 3 for
function types.</P>

<BR><BR><HR><A NAME="332"></A><H4>332.
  
cv-qualified <TT>void</TT> parameter types
</H4><B>Section: </B>8.3.5&#160; [dcl.fct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michiel Salters
 &#160;&#160;&#160;

 <B>Date: </B>9 Jan 2002<BR>


<P>8.3.5 [dcl.fct]/2 restricts the use of void
as parameter type, but does not
mention CV qualified versions. Since <TT>void f(volatile void)</TT>
isn't a callable
function anyway, 8.3.5 [dcl.fct]
should also ban cv-qualified versions.
(BTW, this follows C)</P>

<P><B>Suggested resolution:</B></P>

<P>A possible resolution would be to add (cv-qualified) before void in</P>
<BLOCKQUOTE>
The parameter list <TT>(void)</TT> is equivalent to the empty
parameter list. Except
for this special case, <SPAN style="font-weight:bold;background-color:#A0FFA0">(cv-qualified)</SPAN> <TT>void</TT> shall
not be a parameter type (though types derived from <TT>void</TT>, such as
<TT>void*</TT>, can).
</BLOCKQUOTE>

<BR><BR><HR><A NAME="550"></A><H4>550.
  
Pointer to array of unknown bound in parameter declarations
</H4><B>Section: </B>8.3.5&#160; [dcl.fct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>22 November 2005<BR>


<P>The current wording of 8.3.5 [dcl.fct] paragraph 6
encompasses more than it should:</P>

<BLOCKQUOTE>

If the type of a parameter includes a type of the form &#8220;pointer
to array of unknown bound of <TT>T</TT>&#8221; or &#8220;reference to
array of unknown bound of <TT>T</TT>,&#8221; the program is
ill-formed. [<I>Footnote:</I> This excludes parameters of type
&#8220;<I>ptr-arr-seq</I> <TT>T2</TT>&#8221; where <TT>T2</TT> is
&#8220;pointer to array of unknown bound of <TT>T</TT>&#8221; and
where <I>ptr-arr-seq</I> means any sequence of &#8220;pointer
to&#8221; and &#8220;array of&#8221; derived declarator types. This
exclusion applies to the parameters of the function, and if a
parameter is a pointer to function or pointer to member function then
to its parameters also, etc. &#8212;<I>end footnote</I>]

</BLOCKQUOTE>

<P>The normative wording (contrary to the intention expressed in the
footnote) excludes declarations like</P>

<PRE>
    template&lt;class T&gt; struct S {};
    void f(S&lt;int (*)[]&gt;);
</PRE>

<P>and</P>

<PRE>
    struct S {};
    void f(int(*S::*)[]);
</PRE>

<P>but not</P>

<PRE>
    struct S {};
    void f(int(S::*)[]);
</PRE>

<BR><BR><HR><A NAME="577"></A><H4>577.
  
<TT>void</TT> in an empty parameter list
</H4><B>Section: </B>8.3.5&#160; [dcl.fct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Ben Hutchings
 &#160;&#160;&#160;

 <B>Date: </B>22 April 2006<BR>


<P>8.3.5 [dcl.fct] paragraph 2 says,</P>

<BLOCKQUOTE>

The parameter list <TT>(void)</TT> is equivalent to the empty
parameter list.

</BLOCKQUOTE>

<P>This special case is intended for C compatibility, but C99 describes
it differently (6.7.5.3 paragraph 10):</P>

<BLOCKQUOTE>

The special case of an unnamed parameter of type <TT>void</TT> as the
only item in the list specifies that the function has no parameters.

</BLOCKQUOTE>

<P>The C99 formulation allows typedefs for <TT>void</TT>, while C++
(and C90) accept only the keyword itself in this role.  Should the
C99 approach be adopted?</P>

<P><B>Notes from the October, 2006 meeting:</B></P>

<P>The CWG did not take a formal position on this issue; however,
there was some concern expressed over the treatment of function
templates and member functions of class templates if the C++ rule
were changed: for a template parameter <TT>T</TT>, would a function
taking a single parameter of type <TT>T</TT> become a no-parameter
function if it were instantiated with <TT>T = void</TT>?</P>

<BR><BR><HR><A NAME="325"></A><H4>325.
  
When are default arguments parsed?
</H4><B>Section: </B>8.3.6&#160; [dcl.fct.default]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Nathan Sidwell
 &#160;&#160;&#160;

 <B>Date: </B>27 Nov 2001<BR>


<P>The standard is not precise enough about when the default arguments of
member functions are parsed.  This leads to confusion over whether certain
constructs are legal or not, and the validity of certain compiler
implementation algorithms.</P>

<P>8.3.6 [dcl.fct.default] paragraph 5 says "names in the
expression are bound, and
the semantic constraints are checked, at the point where the default
argument expression appears"</P>

<P>However, further on at paragraph 9 in the same section there is an example,
where the salient parts are
<PRE>
  int b;
  class X {
    int mem2 (int i = b); // OK use X::b
    static int b;
  };
</PRE>
which appears to contradict the former constraint. At the point the default
argument expression appears in the definition of X, X::b has not been
declared, so one would expect ::b to be bound.  This of course appears to
violate 3.3.7 [basic.scope.class] paragraph 1(2) "A name N used in
a class S shall
refer to the same declaration in its context and when reevaluated in the
complete scope of S. No diagnostic is required."</P>

<P>Furthermore 3.3.7 [basic.scope.class] paragraph 1(1) gives the
 scope of names declared
in class to "consist not only of the declarative region following
the name's declarator, but also of .. default arguments ...". Thus implying
that X::b is in scope in the default argument of X::mem2 previously.</P>

<P>That previous paragraph hints at an implementation technique of saving the
token stream of a default argument expression and parsing it at the end of
the class definition (much like the bodies of functions defined in the
class).  This is a technique employed by GCC and, from its behaviour, in
the EDG front end.  The standard leaves two things unspecified. 
Firstly, is a default argument expression permitted to call a static member
function declared later in the class in such a way as to require evaluation of
that function's default arguments? I.e. is the following well formed?
<PRE>
  class A {
    static int Foo (int i = Baz ());
    static int Baz (int i = Bar ());
    static int Bar (int i = 5);
 };
</PRE>
If that is well formed, at what point does the non-sensicalness of
<PRE>
  class B {
    static int Foo (int i = Baz ());
    static int Baz (int i = Foo());
  };
</PRE>
become detected? Is it when B is complete? Is it when B::Foo or B::Baz is
called in such a way to require default argument expansion? Or is no
diagnostic required?</P>

<P>The other problem is with collecting the tokens that form the default
argument expression.  Default arguments which contain template-ids with
more than one parameter present a difficulty in determining when the
default argument finishes.  Consider,
<PRE>
  template &lt;int A, typename B&gt; struct T { static int i;};
  class C {
    int Foo (int i = T&lt;1, int&gt;::i);
  };
</PRE>
The default argument contains a non-parenthesized comma.  Is it required
that this comma is seen as part of the default argument expression and not
the beginning of another of argument declaration?  To accept this as
part of the default argument would require name lookup of T (to determine
that the '&lt;' was part of a template argument list and not a less-than
operator) before C is complete.  Furthermore, the more pathological
<PRE>
  class D {
    int Foo (int i = T&lt;1, int&gt;::i);
    template &lt;int A, typename B&gt; struct T {static int i;};
  };
</PRE>
would be very hard to accept. Even though T is declared after Foo, T is
in scope within Foo's default argument expression.</P>

<P><B>Suggested resolution:</B></P>

<P>Append the following text to 8.3.6 [dcl.fct.default] paragraph 8.</P>
<BLOCKQUOTE>
	The default argument expression of a member function declared in 
	the class definition consists of the sequence of tokens up until
	the next non-parenthesized, non-bracketed comma or close
	parenthesis.  Furthermore such default argument expressions shall
	not require evaluation of a default argument of a function
	declared later in the class.
</BLOCKQUOTE>

<P>This would make the above A, B, C and D ill formed and is in line with the
existing compiler practice that I am aware of.</P>

<P><B>Notes from the October, 2005 meeting:</B></P>

<P>The CWG agreed that the first example (<TT>A</TT>) is currently
well-formed and that it is not unreasonable to expect implementations
to handle it by processing default arguments recursively.</P>

<P><B>Additional notes, May, 2009:</B></P>

<P>Presumably the following is ill-formed:</P>

<PRE>
    int f(int = f());
</PRE>

<P>However, it is not clear what in the Standard makes it so.  Perhaps
there needs to be a statement to the effect that a default argument
only becomes usable after the complete declarator of which it is a
part.</P>

<BR><BR><HR><A NAME="361"></A><H4>361.
  
Forward reference to default argument
</H4><B>Section: </B>8.3.6&#160; [dcl.fct.default]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>17 June 2002<BR>




<P>Is this program well-formed?</P>
<PRE>
  struct S {
    static int f2(int = f1()); // OK?
    static int f1(int = 2);
  };
  int main()
  {
    return S::f2();
  }
</PRE>
<P>A class member function can in general refer to class members that
are declared lexically later.  But what about referring to default
arguments of member functions that haven't yet been declared?</P>

<P>It seems to me that if f2 can refer to f1, it can also refer to the
default argument of f1, but at least one compiler disagrees.</P>

<BR><BR><HR><A NAME="1226"></A><H4>1226.
  
Converting a <I>braced-init-list</I> default argument
</H4><B>Section: </B>8.3.6&#160; [dcl.fct.default]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2010-11-19<BR>


<P>According to the new wording of 8.3.6 [dcl.fct.default] paragraph 1,</P>

<BLOCKQUOTE>

A default argument is implicitly converted (Clause 4 [conv]) to the parameter type.

</BLOCKQUOTE>

<P>This is incorrect when the default argument is a
<I>braced-init-list</I>.  That sentence doesn't seem to be necessary,
but if it is kept, it should be recast in terms of initialization
rather than conversion.</P>

<BR><BR><HR><A NAME="253"></A><H4>253.
  
Why must empty or fully-initialized const objects be initialized?
</H4><B>Section: </B>8.5&#160; [dcl.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>11 Jul 2000<BR>




<P>Paragraph 9 of
8.5 [dcl.init]

 says:</P>
<BLOCKQUOTE>If no initializer is specified for an object, and the object
is of (possibly cv-qualified) non-POD class type (or array thereof), the
object shall be default-initialized; if the object is of const-qualified
type, the underlying class type shall have a user-declared default constructor.
Otherwise, if no initializer is specified for an object, the object and
its subobjects, if any, have an indeterminate initial value; if the object
or any of its subobjects are of const-qualified type, the program is ill-formed.</BLOCKQUOTE>

<P>What if a const POD object has no non-static data members?
This wording requires an empty initializer for such cases:</P>

<PRE>
    struct Z {
        // no data members
        operator int() const { return 0; }
    };

    void f() {
        const Z z1;         // ill-formed: no initializer
        const Z z2 = { };   // well-formed
    }
</PRE>

<P>Similar comments apply to a non-POD const object, all of whose
non-static data members and base class subobjects have default
constructors.  Why should the class of such an object be required
to have a user-declared default constructor?</P>

<P>(See also <A HREF="
     cwg_defects.html#78">issue 78</A>.)</P>

<P><B>Additional note (February, 2011):</B></P>

<P>This issue should be brought up again in light of constexpr
constructors and non-static data member initializers.
</P>

<BR><BR><HR><A NAME="611"></A><H4>611.
  
Zero-initializing references
</H4><B>Section: </B>8.5&#160; [dcl.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>29 December 2006<BR>


<P>According to 8.5 [dcl.init] paragraph 5,</P>

<BLOCKQUOTE>

<P>To <I>zero-initialize</I> an object of type <TT>T</TT> means:</P>

<UL>

<LI><P>...</P></LI>

<LI><P>if <TT>T</TT> is a reference type, no initialization is
performed.</P></LI>
</UL>

</BLOCKQUOTE>

<P>However, a reference is not an object, so this makes no sense.</P>

<BR><BR><HR><A NAME="670"></A><H4>670.
  
Copy initialization via derived-to-base conversion in the second step
</H4><B>Section: </B>8.5&#160; [dcl.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>20 December 2007<BR>




<P>In this example:</P>

<PRE>
    struct A {};

    struct B: A {
       B(int);
       B(B&amp;);
       B(A);
    };

    void foo(B);

    void bar() {
       foo(0);
    }
</PRE>

<P>we are copy-initializing a <TT>B</TT> from <TT>0</TT>. So by
13.3.1.4 [over.match.copy] we consider all the converting
constructors of <TT>B</TT>, and choose <TT>B(int)</TT> to create
a <TT>B</TT>.  Then, by 8.5 [dcl.init] paragraph 15, we
direct-initialize the parameter from that temporary <TT>B</TT>.  By
13.3.1.3 [over.match.ctor] we consider all constructors.  The copy
constructor cannot be called with a temporary, but <TT>B(A)</TT> is
callable.</P>

<P>As far as I can tell, the Standard says that this example is
well-formed, and calls <TT>B(A)</TT>.  EDG and G++ have rejected this
example with a message about the copy constructor not being callable,
but I have been unsuccessful in finding anything in the Standard that
says that we only consider the copy constructor in the second step of
copy-initialization.  I wouldn't mind such a rule, but it doesn't seem
to be there.  And implementing <A HREF="
     cwg_defects.html#391">issue 391</A>
causes G++ to start accepting the example.</P>

<P>This question came up before in
<A href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17431">a GCC bug
report</A>; in the discussion of that bug Nathan Sidwell said that
some EDG folks explained to him why the testcase is ill-formed, but
unfortunately didn't provide that explanation in the bug report.
</P>

<P>I think the resolution of <A HREF="
     cwg_defects.html#391">issue 391</A>
makes this example well-formed; it was previously ill-formed because
in order to bind the temporary <TT>B(0)</TT> to the argument of
<TT>A(const A&amp;)</TT> we needed to make another
temporary <TT>B</TT>, and that's what made the example ill-formed.  If
we want this example to stay ill-formed, we need to change something
else.</P>

<P><U>Steve Adamczyk:</U></P>

<P>I tracked down my response to Nathan at the time, and it related to
my paper N1232 (on the <TT>auto_ptr</TT> problem).  The change that
came out of that paper is in 13.3.3.1 [over.best.ics] paragraph
4:</P>

<BLOCKQUOTE>

However, when considering the argument of a user-defined conversion
function that is a candidate by 13.3.1.3 [over.match.ctor] when
invoked for the copying of the temporary in the second step of a class
copy-initialization, or by 13.3.1.4 [over.match.copy], 13.3.1.5 [over.match.conv], or 13.3.1.6 [over.match.ref] in all cases, only
standard conversion sequences and ellipsis conversion sequences are
allowed.

</BLOCKQUOTE>

<P>This is intended to prevent use of more than one implicit user-
defined conversion in an initialization.</P>

<P>I told Nathan <TT>B(A)</TT> can't be called because its argument
would require yet another user-defined conversion, but I was wrong.  I
saw the conversion from <TT>B</TT> to <TT>A</TT> and immediately
thought &#8220;user-defined,&#8221; but in fact because <TT>B</TT> is
a derived class of <TT>A</TT> the conversion according to 13.3.3.1 [over.best.ics] paragraph 6 is a derived-to-base Conversion (even
though it will be implemented by calling a copy constructor).</P>

<P>So I agree with you: with the analysis above and the change for
<A HREF="
     cwg_defects.html#391">issue 391</A> this example is well-formed.  We
should discuss whether we want to make a change to keep it
ill-formed.</P>

<BR><BR><HR><A NAME="1093"></A><H4>1093.
  
Value-initializing non-objects
</H4><B>Section: </B>8.5&#160; [dcl.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-07-17<BR>


<P>8.5 [dcl.init] paragraph 7 only describes how to
initialize objects:</P>

<BLOCKQUOTE>

To <I>value-initialize</I> an object of type <TT>T</TT> means:

</BLOCKQUOTE>

<P>However, 5.2.3 [expr.type.conv] paragraph 2 calls for
value-initializing prvalues, which in the case of scalar types
are not objects:</P>

<BLOCKQUOTE>

The expression <TT>T()</TT>, where <TT>T</TT> is a
<I>simple-type-specifier</I> or <I>typename-specifier</I>
for a non-array complete object type or the (possibly
cv-qualified) <TT>void</TT> type, creates a prvalue of the
specified type, which is value-initialized (8.5 [dcl.init]; no initialization is done for the
<TT>void()</TT> case).

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1236"></A><H4>1236.
  
Inconsistently-interrelated examples
</H4><B>Section: </B>8.5.3&#160; [dcl.init.ref]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>2011-01-20<BR>




<P>The examples in 8.5.3 [dcl.init.ref] paragraph 5 are
not consistent as to whether earlier code fragments are assumed to
be part of the example or not.  For instance, the variables
<TT>i</TT> and <TT>d</TT> are used as initializers without
declaration in later fragments, presumably intended to refer to
the declarations introduced in the first couple.  However, the
third fragment declares <TT>rca</TT>, which is an incompatible
redeclaration of a name declared in the first fragment.</P>

<BR><BR><HR><A NAME="1232"></A><H4>1232.
  
Creation of array temporaries using a <I>braced-init-list</I>
</H4><B>Section: </B>8.5.4&#160; [dcl.init.list]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Andrew Koenig
 &#160;&#160;&#160;

 <B>Date: </B>2011-01-03<BR>




<P>By analogy with the variable definition</P>

<PRE>
    int arr[3] = {1, 2, 3};
</PRE>

<P>it should be possible to write something like</P>

<PRE>
   void f(const int(&amp;)[3]);
   void g() {
     f({1, 2, 3});
   }
</PRE>

<P>There are currently at least two problems with the latter usage.
First, the variable initializer relies on brace elision, which appears
to be defined only for variable declarations (8.5.1 [dcl.init.aggr]
paragraph 11), and possibly only for certain forms of variable
declarations.</P>

<P>Second, the call would require creation of an array temporary to
which the parameter reference would be bound, and the current Standard
does not describe array temporaries (although rvalue arrays can occur
as members of class rvalues).  This is also contrary to the direction
established by CWG in considering <A HREF="
     cwg_active.html#1058">1058</A>.</P>

<BR><BR><HR><A NAME="511"></A><H4>511.
  
POD-structs with template assignment operators
</H4><B>Section: </B>9&#160; [class]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>19 Mar 2005<BR>


<P>A POD-struct is not permitted to have a user-declared copy
assignment operator (9 [class] paragraph 4).  However, a
template assignment operator is not considered a copy assignment
operator, even though its specializations can be selected by overload
resolution for performing copy operations (12.8 [class.copy]
paragraph 9 and especially footnote 114).  Consequently, <TT>X</TT> in
the following code is a POD, notwithstanding the fact that copy
assignment (for a non-const operand) is a member function call
rather than a bitwise copy:</P>

<PRE>
    struct X {
      template&lt;typename T&gt; const X&amp; operator=(T&amp;);
    };
    void f() {
      X x1, x2;
      x1 = x2;  //<SPAN style="font-family:Times;font-style:italic"> calls </SPAN>X::operator=&lt;X&gt;(X&amp;)
    }
</PRE>

<P>Is this intentional?</P>

<BR><BR><HR><A NAME="1141"></A><H4>1141.
  
Non-static data member initializers have not been implemented
</H4><B>Section: </B>9.2&#160; [class.mem]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US51">N3092 comment
  US&#160;51<BR></A>

<P>Non-static data member initializers should not be part of C++0x
unless they have implementation experience.</P>

<P><B>Notes from the August, 2010 meeting:</B></P>

<P>The C++/CLI dialect has a very similar feature that has been
implemented.</P>

<BR><BR><HR><A NAME="1143"></A><H4>1143.
  
Move semantics for <TT>*this</TT> have not been implemented
</H4><B>Section: </B>9.3.1&#160; [class.mfct.non-static]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US53">N3092 comment
  US&#160;53<BR></A>

<P>Move semantics for <TT>*this</TT> should not be part of C++0x
unless they have implementation experience.</P>

<BR><BR><HR><A NAME="57"></A><H4>57.
  
Empty unions
</H4><B>Section: </B>9.5&#160; [class.union]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>13 Oct 1998<BR>



<P>There doesn't seem to be a prohibition in 9.5 [class.union]
 against a declaration
like</P>
<PRE>
    union { int : 0; } x;
</PRE>
Should that be valid?  If so, 8.5 [dcl.init]

paragraph 5 third bullet, which deals with
default-initialization of unions, should say that no initialization is
done if there are no data members.
    
<P>What about:</P>
<PRE>
    union { } x;
    static union { };
</PRE>
If the first example is well-formed, should either or both of these cases
be well-formed as well?

<P>(See also the resolution for
<A HREF="
     cwg_defects.html#151">issue 151</A>.)</P>

<P><B>Notes from 10/00 meeting:</B> The resolution to
<A HREF="
     cwg_defects.html#178">issue 178</A>, which was accepted as a
DR, addresses the first point above (default initialization).
The other questions have not yet been decided, however.</P>
<BR><BR><HR><A NAME="675"></A><H4>675.
  
Signedness of bit-field with typedef or template parameter type
</H4><B>Section: </B>9.6&#160; [class.bit]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Corden
 &#160;&#160;&#160;

 <B>Date: </B>11 February, 2008<BR>




<P>Is the signedness of <TT>x</TT> in the following example
implementation-defined?</P>

<PRE>
    template &lt;typename T&gt; struct A {
        T x : 7;
    };

    template struct A&lt;long&gt;;
</PRE>

<P>A similar example could be created with a typedef.</P>

<P><U>Lawrence Crowl</U>: According to 9.6 [class.bit]
paragraph 3,</P>

<BLOCKQUOTE>

It is implementation-defined whether a plain (neither explicitly
signed nor unsigned) <TT>char</TT>, <TT>short</TT>, <TT>int</TT>
or <TT>long</TT> bit-field is signed or unsigned.

</BLOCKQUOTE>

<P>This clause is conspicuously silent on typedefs and template
parameters.</P>

<P><U>Clark Nelson</U>: At least in C, the intention is that the
presence or absence of this redundant keyword is supposed to be
remembered through typedef declarations. I don't remember discussing
it in C++, but I would certainly hope that we don't want to do
something different. And presumably, we would want template type
parameters to work the same way.</P>

<P>So going back to the original example, in an instantiation of
<TT>A&lt;long&gt;</TT>, the signedness of the bit-field is
implementation-defined, but in an instantiation of <TT>A&lt;signed
long&gt;</TT>, the bit-field is definitely signed.</P>

<P><U>Peter Dimov</U>: How can this work?
Aren't <TT>A&lt;long&gt;</TT> and <TT>A&lt;signed long&gt;</TT> the
same type?</P>

(See also <A HREF="
     cwg_active.html#739">issue 739</A>.)

<BR><BR><HR><A NAME="739"></A><H4>739.
  
Signedness of plain bit-fields
</H4><B>Section: </B>9.6&#160; [class.bit]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>3 November, 2008<BR>


<P>9.6 [class.bit] paragraph 3 says,</P>

<BLOCKQUOTE>

It is implementation-defined whether a plain (neither explicitly
signed nor unsigned) <TT>char</TT>, <TT>short</TT>, <TT>int</TT> or
<TT>long</TT> bit-field is signed or unsigned.

</BLOCKQUOTE>

<P>The implications of this permission for an implementation that
chooses to treat plain bit-fields as unsigned are not clear.  Does
this mean that the type of such a bit-field is adjusted to the
unsigned variant or simply that sign-extension is not performed when
the value is fetched?  C99 is explicit in specifying the former (6.7.2
paragraph 5: &#8220;for bit-fields, it is implementation-defined
whether the specifier <TT>int</TT> designates the same type as
<TT>signed int</TT> or the same type as <TT>unsigned
int</TT>&#8221;), while C90 takes the latter approach (6.5.2.1:
&#8220;Whether the high-order bit position of a (possibly qualified)
'plain' int bit-field is treated as a sign bit is
implementation-defined&#8221;).</P>

(See also <A HREF="
     cwg_active.html#675">issue 675</A> and
<A HREF="
     cwg_defects.html#741">issue 741</A>.)

<P><B>Additional note, May, 2009:</B></P>

<P>As an example of the implications of this question, consider the
following declaration:</P>

<PRE>
    struct S {
      int i: 2;
      signed int si: 2;
      unsigned int ui: 2;
    } s;
</PRE>

<P>Is it implementation-defined which expression,
<TT>cond?s.i:s.si</TT> or <TT>cond?s.i:s.ui</TT>, is an lvalue (the
lvalueness of the result depends on the second and third operands
having the same type, per 5.16 [expr.cond] paragraph 4)?</P>

<BR><BR><HR><A NAME="380"></A><H4>380.
  
Definition of "ambiguous base class" missing
</H4><B>Section: </B>10.2&#160; [class.member.lookup]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>22 Oct 2002<BR>


<P>The term "ambiguous base class" doesn't seem to be actually defined
anywhere.  10.2 [class.member.lookup] paragraph 7 seems like the place
to do it.</P>

<BR><BR><HR><A NAME="230"></A><H4>230.
  
Calls to pure virtual functions
</H4><B>Section: </B>10.4&#160; [class.abstract]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jim Hill
 &#160;&#160;&#160;

 <B>Date: </B>4 May 2000<BR>


<P>According to 10.4 [class.abstract] paragraph 6,</P>

<BLOCKQUOTE>

Member functions can be called from a constructor (or destructor) of
an abstract class; the effect of making a virtual call (10.3 [class.virtual]) to a pure virtual function directly or indirectly for
the object being created (or destroyed) from such a constructor (or
destructor) is undefined.

</BLOCKQUOTE>

<P>This prohibition is unnecessarily restrictive.  It should not apply
to cases in which the pure virtual function has been defined.</P>

<P>Currently the "pure" specifier for a virtual member function has
two meanings that need not be related:</P>

<OL>

<LI>A pure virtual function need not be defined.</LI>

<LI>A pure virtual function must be overridden in any concrete derived
class.</LI>

</OL>

<P>The prohibition of virtual calls to pure virtual functions arises
from the first meaning and unnecessarily penalizes those who only need
the second.</P>

<P>For example, consider a scenario such as the following.  A class
<TT>B</TT> is defined containing a (non-pure) virtual function
<TT>f</TT> that provides some initialization and is thus called from
the base class constructor.  As time passes, a number of classes are
derived from <TT>B</TT> and it is noticed that each needs to override
<TT>f</TT>, so it is decided to make <TT>B::f</TT> pure to enforce
this convention while still leaving the original definition of
<TT>B::f</TT> to perform its needed initialization.  However, the act
of making <TT>B::f</TT> pure means that every reference to <TT>f</TT>
that might occur during the execution of one of <TT>B</TT>'s
constructors must be tracked down and edited to be a qualified
reference to <TT>B::f</TT>.  This process is tedious and error-prone:
needed edits might be overlooked, and calls that actually should be
virtual when the containing function is called other than during
construction/destruction might be incorrectly changed.</P>

<P><B>Suggested resolution:</B> Allow virtual calls to pure virtual
functions if the function has been defined.</P>

<BR><BR><HR><A NAME="600"></A><H4>600.
  
Does access control apply to members or to names?
</H4><B>Section: </B>11&#160; [class.access]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>3 October 2006<BR>


<P>Referring to a private member of a class, 11 [class.access]
paragraph 1 says,</P>

<BLOCKQUOTE>

its name can be used only by members and friends of the class in which
it is declared.

</BLOCKQUOTE>

<P>That wording does not appear to reflect the intent of access control,
however.  Consider the following:</P>

<PRE>
    struct S {
        void f(int);
    private:
        void f(double);
    };

    void g(S* sp) {
        sp-&gt;f(2);        //<SPAN style="font-family:Times;font-style:italic"> Ill-formed?</SPAN>
    }
</PRE>

<P>The statement from 11 [class.access] paragraph 1 says that the
name <TT>f</TT> can be used only by members and friends of <TT>S</TT>.
Function <TT>g</TT> is neither, and it clearly contains a use of the
name <TT>f</TT>.  That appears to make it ill-formed, in spite of the fact
that overload resolution will select the public member.</P>

<P>A related question is whether the use of the term &#8220;name&#8221;
in the description of the effect of access control means that it does
not apply to constructors and destructors, which do not have names.</P>

<P><U>Mike Miller</U>: The phrase &#8220;its name can be used&#8221;
should be understood as &#8220;it can be referred to by name.&#8221;
Paragraph 4, among other places, makes it clear that access control is
applied after overload resolution.  The &#8220;name&#8221; phrasing is
there to indicate that access control does not apply where the name is
not used (in a call via a pointer, for example).</P>

<BR><BR><HR><A NAME="360"></A><H4>360.
  
Using-declaration that reduces access
</H4><B>Section: </B>11.2&#160; [class.access.base]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>4 June 2002<BR>




<P>I have heard a claim that the following code is valid, but I don't
see why.</P>
<PRE>
  struct A {
    int foo ();
  };

  struct B: A {
  private:
    using A::foo;
  };

  int main ()
  {
    return B ().foo ();
  }
</PRE>
<P>
It seems to me that the using declaration in B should hide the
public foo in A. Then the call to B::foo should fail because B::foo
is not accessible in main.</P>

<P>Am I missing something?</P>

<P><U>Steve Adamczyk</U>:
This is similar to the last example in 11.2 [class.access.base].
In prose, the rule is
that if you have access to cast to a base class and you have access
to the member in the base class, you are given access in the derived
class.  In this case, A is a public base class of B and foo is public
in A, so you can access foo through a B object.  The actual permission
for this is in the fourth bullet in
11.2 [class.access.base] paragraph 4.</P>

<P>The wording changes for <A HREF="
     cwg_defects.html#9">issue 9</A>
make this clearer, but I believe
even without them this example could be discerned to be valid.</P>

<P>See my paper J16/96-0034, WG21/N0852 on this topic.</P>

<P><U>Steve Clamage</U>:
But a using-declaration is a declaration (7.3.3 [namespace.udecl]).
Compare with</P>
<PRE>
  struct B : A {
  private:
    int foo();
  };
</PRE>
<P>In this case, the call would certainly be invalid, even though your
argument about casting B to an A would make it OK. Your argument
basically says that an access adjustment to make something less
accessible has no effect. That also doesn't sound right.</P>

<P><U>Steve Adamczyk</U>:
I agree that is strange.  I do think that's what 11.2 [class.access.base]
says, but perhaps that's not what we want it to say.</P>

<BR><BR><HR><A NAME="747"></A><H4>747.
  
Access of protected base classes
</H4><B>Section: </B>11.2&#160; [class.access.base]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Sam Saariste
 &#160;&#160;&#160;

 <B>Date: </B>18 November, 2008<BR>




<P>Consider the following example:</P>

<PRE>
    struct B { void f(){} };
    class N : protected B { };

    struct P: N { friend int main(); };
    int main() {
          N n;
          B&amp; b = n; // R
          b.f();
    }
</PRE>

<P>This code is rendered well-formed by bullet 3 of 11.2 [class.access.base]
paragraph 4, which says that a base class <TT>B</TT> of <TT>N</TT> is
accessible at <I>R</I> if</P>

<UL><LI><P><I>R</I> occurs in a member or friend of a class <TT>P</TT>
derived from <TT>N</TT>, and an invented public member of <TT>B</TT>
would be a private or protected member of <TT>P</TT></P></LI></UL>

<P>This provision circumvents the additional restrictions on access
to protected members found in 11.5 [class.protected] &#8212;
<TT>main()</TT> could not call <TT>B::f()</TT> directly because the
reference is not via an object of the class through which access is
obtained.  What is the purpose of this rule?</P>

<BR><BR><HR><A NAME="718"></A><H4>718.
  
Non-class, non-function friend declarations
</H4><B>Section: </B>11.4&#160; [class.friend]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>18 September, 2008<BR>


<P>With the change from a scope-based to an entity-based definition
of friendship (see issues <A HREF="
     cwg_defects.html#372">372</A> and
<A HREF="
     cwg_active.html#580">580</A>), it could well make sense to
grant friendship to enumerations and variables, for example:</P>

<PRE>
    enum E: int;
    class C {
      static const int i = 5;  //<SPAN style="font-family:Times;font-style:italic"> Private</SPAN>
      friend E;
      friend int x;
    };
    enum E { e = C::i; };      //<SPAN style="font-family:Times;font-style:italic"> OK: </SPAN>E<SPAN style="font-family:Times;font-style:italic"> is a friend</SPAN>
    int x = C::i;              //<SPAN style="font-family:Times;font-style:italic"> OK: </SPAN>x<SPAN style="font-family:Times;font-style:italic"> is a friend</SPAN>
</PRE>

<P>According to the current wording of 11.4 [class.friend]
paragraph 3, the friend declaration of <TT>E</TT> is well-formed
but ignored, while the friend declaration of <TT>x</TT> is
ill-formed.</P>

<BR><BR><HR><A NAME="581"></A><H4>581.
  
Can a templated constructor be explicitly instantiated or specialized?
</H4><B>Section: </B>12.1&#160; [class.ctor]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mark Mitchell
 &#160;&#160;&#160;

 <B>Date: </B>19 May 2006<BR>


<P>Although it is not possible to specify a constructor's template
arguments in a constructor invocation (because the constructor has
no name but is invoked by use of the constructor's class's name), it
is possible to &#8220;name&#8221; the constructor in declarative
contexts: per 3.4.3.1 [class.qual] paragraph 2,</P>

<BLOCKQUOTE>

In a lookup in which the constructor is an acceptable lookup result,
if the <I>nested-name-specifier</I> nominates a class <TT>C</TT>, and
the name specified after the <I>nested-name-specifier</I>, when looked
up in <TT>C</TT>, is the injected-class-name of <TT>C</TT> (clause
9 [class]), the name is instead considered to name the
constructor of class <TT>C</TT>... Such a constructor name shall be
used only in the <I>declarator-id</I> of a declaration that names a
constructor.

</BLOCKQUOTE>

<P>Should it therefore be possible to specify <I>template-argument</I>s
for a templated constructor in an explicit instantiation or specialization?
For example,</P>

<PRE>
    template &lt;int dim&gt; struct T {};
    struct X {
      template &lt;int dim&gt; X (T&lt;dim&gt; &amp;) {};
    };

    template X::X&lt;&gt; (T&lt;2&gt; &amp;);
</PRE>

<P>If so, that should be clarified in the text.  In
particular, 12.1 [class.ctor] paragraph 1 says,</P>

<BLOCKQUOTE>

Constructors do not have names. A special declarator syntax using an
optional sequence of <I>function-specifier</I>s (7.1.2 [dcl.fct.spec]) followed by the constructor&#8217;s class name followed by
a parameter list is used to declare or define the constructor.

</BLOCKQUOTE>

<P>This certainly sounds as if the parameter list must immediately
follow the class name, with no allowance for a template argument
list.</P>

<P>It would be worthwhile in any event to revise this wording
to utilize the &#8220;considered to name&#8221; approach of
3.4.3.1 [class.qual]; as it stands, this wording
sounds as if the following would be acceptable:</P>

<PRE>
    struct S {
        S();
    };
    S() { }    // <SPAN style="font-family:Times;font-style:italic">qualified-id</SPAN> not required?
</PRE>

<P><B>Notes from the October, 2006 meeting:</B></P>

<P>It was observed that explicitly specifying the template arguments
in a constructor declaration is never actually necessary because the
arguments are, by definition, all deducible and can thus be omitted.</P>

<BR><BR><HR><A NAME="1237"></A><H4>1237.
  
Deprecated implicit copy assignment in example
</H4><B>Section: </B>12.2&#160; [class.temporary]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Ryou Ezoe
 &#160;&#160;&#160;

 <B>Date: </B>2011-01-25<BR>


<P>An implicit declaration of a copy assignment operator is deprecated
if the class has a user-declared copy constructor or a user-declared
destructor.  However, the example in 12.2 [class.temporary] relies
on such an implicit declaration; an explicit declaration for the copy
assignment operator for class X should be provided:</P>

<PRE>
    class X {
    public:
      X(int);
      X(const X&amp;);
      ~X();
    };

    class Y {
    public:
      Y(int);
      Y(Y&amp;&amp;);
      ~Y();
    };

    X f(X);
    Y g(Y);

    void h() {
      X a(1);
      X b = f(X(2));
      Y c = g(Y(3));
      a = f(a);  //<SPAN style="font-family:Times;font-style:italic"> relies on implicitly-declared </SPAN>X::operator=(const X&amp;)
    }
</PRE>

<BR><BR><HR><A NAME="344"></A><H4>344.
  
Naming destructors
</H4><B>Section: </B>12.4&#160; [class.dtor]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jamie Schmeiser
 &#160;&#160;&#160;

 <B>Date: </B>25 April 2002<BR>


<P>Note that destructors suffer from similar problems as those of
constructors dealt with in <A HREF="
     cwg_defects.html#194">issue 194</A>
and in <A HREF="
     cwg_defects.html#263">263</A> (constructors as
friends).  Also, the wording in 12.4 [class.dtor],
paragraph 1 does not permit a
destructor to be defined outside of the memberlist.</P>

<P>Change 12.4 [class.dtor], paragraph 1 from</P>
<BLOCKQUOTE>
...A special declarator syntax using an optional <I>function-specifier</I>
(7.1.2 [dcl.fct.spec]) followed by <TT>~</TT> followed by
the destructor's class name followed
by an empty parameter list is used to declare the destructor in a
class definition.  In such a declaration, the <TT>~</TT> followed by the
destructor's class name can be enclosed in optional parentheses; such
parentheses are ignored....
</BLOCKQUOTE>
<P>to</P>
<BLOCKQUOTE>
...A special declarator syntax using an optional sequence of
<I>function-specifier</I>s (7.1.2 [dcl.fct.spec]),
an optional friend keyword, an optional
sequence of <I>function-specifier</I>s (7.1.2 [dcl.fct.spec])
followed by an optional <TT>::</TT>
scope-resolution-operator followed by an optional
<I>nested-name-specifier</I> followed by <TT>~</TT>
followed by the destructor's class
name followed by an empty parameter list is used to declare the
destructor.  The optional <I>nested-name-specifier</I> shall not be specified
in the declaration of a destructor within the member-list of the class
of which the destructor is a member.  In such a declaration, the
optional <TT>::</TT> scope-resolution-operator followed by an optional
<I>nested-name-specifier</I> followed by <TT>~</TT>
 followed by the destructor's class
name can be enclosed in optional parentheses; such parentheses are
ignored....
</BLOCKQUOTE>

<BR><BR><HR><A NAME="1241"></A><H4>1241.
  
Which members does a destructor destroy?
</H4><B>Section: </B>12.4&#160; [class.dtor]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Ryou Ezoe
 &#160;&#160;&#160;

 <B>Date: </B>2011-02-08<BR>




<P>The current wording of 12.4 [class.dtor] paragraph 7 says,</P>

<BLOCKQUOTE>

After executing the body of the destructor and destroying any
automatic objects allocated within the body, a destructor for class
<TT>X</TT> calls the destructors for <TT>X</TT>'s direct non-variant
members...

</BLOCKQUOTE>

<P>This is incorrect; it is only the non-static members that are
destroyed.</P>

<BR><BR><HR><A NAME="255"></A><H4>255.
  
Placement deallocation functions and lookup ambiguity
</H4><B>Section: </B>12.5&#160; [class.free]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>26 Oct 2000<BR>


<P>Paragraph 4 of 12.5 [class.free] speaks of looking up a
deallocation function.  While it is an error if a placement
deallocation function alone is found by this lookup, there seems to be
an assumption that a placement deallocation function and a usual
deallocation function can both be declared in a given class scope
without creating an ambiguity.  The normal mechanism by which
ambiguity is avoided when functions of the same name are declared in
the same scope is overload resolution; however, there is no mention of
overload resolution in the description of the lookup.  In fact, there
appears to be nothing in the current wording that handles this case.
That is, the following example appears to be ill-formed, according to
the current wording:</P>

<PRE>
    struct S {
        void operator delete(void*);
        void operator delete(void*, int);
    };
    void f(S* p) {
        delete p;    // ill-formed: ambiguous operator delete
    }
</PRE>

<P><B>Suggested resolution</B> (Mike Miller, March 2002):</P>

<P>I think you might get the right effect by replacing
the last sentence of 12.5 [class.free] paragraph 4
with something like:</P>
<BLOCKQUOTE>
After removing all placement deallocation functions,
the result of the lookup shall contain an unambiguous
and accessible deallocation function.
</BLOCKQUOTE>

<BR><BR><HR><A NAME="607"></A><H4>607.
  
Lookup of <I>mem-initializer-id</I>s
</H4><B>Section: </B>12.6.2&#160; [class.base.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Corden
 &#160;&#160;&#160;

 <B>Date: </B>5 December 2006<BR>




<P>In an example like,</P>

<PRE>
    struct Y {};

    template &lt;typename T&gt;
    struct X : public virtual Y { };

    template &lt;typename T&gt;
    class A : public X&lt;T&gt; {
      template &lt;typename S&gt;
      A (S)
        : S ()
      {
      }
    };

    template A&lt;int&gt;::A (Y);
</PRE>

<P>Should <TT>S</TT> be found?  (<TT>S</TT> is a dependent name, so
if it resolves to a base class type in the instantiated template, it
should satisfy the requirements.)  All the compilers I tried allowed
this example, but 12.6.2 [class.base.init] paragraph 2 says,</P>

<BLOCKQUOTE>

Names in a <I>mem-initializer-id</I> are looked up in the scope
of the constructor&#8217;s class and, if not found in that scope, are
looked up in the scope containing the constructor&#8217;s definition.

</BLOCKQUOTE>

<P>The name <TT>S</TT> is not declared in those scopes.</P>

<P><U>Mike Miller</U>: Here's another example that is accepted by
most/all compilers but not by the current wording:</P>

<PRE>
    namespace N {
      struct B { B(int); };
      typedef B typedef_B;
      struct D: B {
        D();
      };
    }

    N::D::D(): typedef_B(0) { }
</PRE>

<P>Except for the fact that the constructor function parameter
names are ignored (see paragraph 7), what the compilers seem to
be doing is essentially ordinary unqualified name lookup.</P>

<P><B>Notes from the October, 2009 meeting:</B></P>

<P>The eventual resolution of this issue should take into account the
template parameter scope introduced by the resolution of
<A HREF="
     cwg_defects.html#481">issue 481</A>.</P>

<BR><BR><HR><A NAME="838"></A><H4>838.
  
Use of <TT>this</TT> in a <I>brace-or-equal-initializer</I>
</H4><B>Section: </B>12.6.2&#160; [class.base.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>12 March, 2009<BR>


<P>References to non-static data members inside the body of a non-static
member function (which includes the <I>mem-initializer</I>s of a
constructor definition) are implicitly transformed to member access
expressions using <TT>(*this)</TT> (9.3.1 [class.mfct.non-static]
paragraph 3).  Although 5.1.1 [expr.prim.general] paragraph 3
permits use of <TT>this</TT> in a <I>brace-or-equal-initializer</I>
for a non-static data member, 12.6.2 [class.base.init] does not
give details about the value of <TT>this</TT> in that context, and
there is no parallel to the transformation of member references into
class member access expressions. This leaves use of non-static data
members in this context underspecified.</P>

<BR><BR><HR><A NAME="1242"></A><H4>1242.
  
Initializing variant class members
</H4><B>Section: </B>12.6.2&#160; [class.base.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Ryou Ezoe
 &#160;&#160;&#160;

 <B>Date: </B>2011-02-08<BR>




<P>The current wording of 12.6.2 [class.base.init] paragraph 5 says,</P>

<BLOCKQUOTE>

A <I>ctor-initializer</I> may initialize the member of an anonymous union
that is a member of the constructor's class.

</BLOCKQUOTE>

<P>The wording &#8220;the member&#8221; is strange; furthermore, this
should be restricted to non-static data members.  That could be
accomplished by using the existing term &#8220;variant members,&#8221;
which is defined in 9.5 [class.union] paragraph 8 to be
&#8220;the non-static data members of all anonymous unions that are
members of&#8221; the class (which by definition must be non-static
data members, since a storage class specifier is not allowed on an
anonymous union in class scope).</P>

<BR><BR><HR><A NAME="6"></A><H4>6.
  
Should the optimization that allows a class object to alias another object also allow the case of a parameter in an inline function to alias its argument?
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>unknown
 &#160;&#160;&#160;

 <B>Date: </B>unknown<BR>



<P>[Picked up by evolution group at October 2002 meeting.]</P>


 
(See also paper J16/99-0005 = WG21 N1182.)

<P>At the London meeting,
12.8 [class.copy]
 paragraph 15 was changed to
limit the optimization described to only the following cases:</P>
<UL>
<LI>
the source is a temporary object</LI>
    
<LI>
the return value optimization</LI>
</UL>
One other case was deemed desirable as well:
<UL>
<LI>
aliasing a parameter in an inline function call to the function call argument.</LI>
</UL>
However, there are cases when this aliasing was deemed undesirable and,
at the London meeting, the committee was not able to clearly delimit which
cases should be allowed and which ones should be prohibited.
    
<P>Can we find an appropriate description for the desired cases?</P>
    
<P><B>Rationale (04/99):</B> The absence of this optimization does
not constitute a defect in the Standard,
although the proposed resolution in the paper
should be considered when the Standard is revised.</P>

<P><B>Note (March, 2008):</B></P>

<P>The Evolution Working Group has accepted the intent of this issue and
referred it to CWG for action (not for C++0x).  See paper J16/07-0033 =
WG21 N2173.</P>

<P><B>Notes from the June, 2008 meeting:</B></P>

<P>The CWG decided to take no action on this issue until an interested
party produces a paper with analysis and a proposal.</P>
<BR><BR><HR><A NAME="1049"></A><H4>1049.
  
Copy elision through reference parameters of inline functions
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-10<BR>




<P>Consider the following example:</P>

<PRE>
    int c;

    struct A {
       A() { ++c; }
       A(const A&amp;) { ++c; }
    };

    struct B {
       A a;
       B(const A&amp; a): a(a) { }
    };

    int main() {
       (B(A()));
       return c - 1;
    }
</PRE>

<P>Here we would like to be able to avoid the copy and just
construct the <TT>A()</TT> directly into the <TT>A</TT> subobject
of <TT>B</TT>.  But we can't, because it isn't allowed by
12.8 [class.copy] paragraph 34 bullet 3:</P>

<UL><LI><P>when a temporary class object that has not been bound
to a reference (12.2 [class.temporary]) would be copied/moved
to a class object with the same cv-unqualified type, the
copy/move operation can be omitted by constructing the temporary
object directly into the target of the omitted
copy/move</P></LI></UL>

<P>The part about not being bound to a reference was added for an
unrelated reason by <A HREF="
     cwg_defects.html#185">issue 185</A>.  If
that resolution were recast to require that the temporary object
is not accessed after the copy, rather than banning the reference
binding, this optimization could be applied.</P>

<P>The similar example using pass by value is also not one of the
allowed cases, which could be considered part of <A HREF="
     cwg_active.html#6">issue 6</A>.
</P>

<BR><BR><HR><A NAME="1092"></A><H4>1092.
  
Cycles in overload resolution during instantiation
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-07-15<BR>




<P>Moving to always doing overload resolution for determining exception 
specifications and implicit deletion creates some unfortunate cycles:</P>

<PRE>
    template&lt;typename T&gt; struct A {
       T t;
    };

    template &lt;typename T&gt; struct B {
       typename T::U u;
    };

    template &lt;typename T&gt; struct C {
       C(const T&amp;);
    };

    template &lt;typename T&gt; struct D {
       C&lt;B&lt;T&gt; &gt; v;
    };

    struct E {
       typedef A&lt;D&lt;E&gt; &gt; U;
    };

    extern A&lt;D&lt;E&gt; &gt; a;
    A&lt;D&lt;E&gt; &gt; a2(a);
</PRE>

<P>If declaring the copy constructor for
<TT>A&lt;D&lt;E&gt;&gt;</TT> is part of instantiating the
class, then we need to do overload resolution on
<TT>D&lt;E&gt;</TT>, and thus <TT>C&lt;B&lt;E&gt;&gt;</TT>.
We consider <TT>C(const B&lt;E&gt;&amp;)</TT>, and therefore
look to see if there's a conversion from
<TT>C&lt;B&lt;E&gt;&gt;</TT> to <TT>B&lt;E&gt;</TT>, which
instantiates <TT>B&lt;E&gt;</TT>, which fails because it has
a field of type <TT>A&lt;D&lt;E&gt;&gt;</TT> which is
already being instantiated.</P>

<P>Even if we wait until <TT>A&lt;D&lt;E&gt;&gt;</TT> is
considered complete before finalizing the copy constructor
declaration, declaring the copy constructor for
<TT>B&lt;E&gt;</TT> will want to look at the copy
constructor for <TT>A&lt;D&lt;E&gt;&gt;</TT>, so we still
have the cycle.</P>

<P>I think that to avoid this cycle we need to short-circuit
consideration of <TT>C(const T&amp;)</TT> somehow.  But I
don't see how we can do that without breaking</P>

<PRE>
    struct F {
       F(F&amp;);
    };

    struct G;
    struct G2 {
       G2(const G&amp;);
    };

    struct G {
       G(G&amp;&amp;);
       G(const G2&amp;);
    };

    struct H: F, G { };

    extern H h;
    H h2(h);
</PRE>

<P>Here, since <TT>G</TT>'s move constructor suppresses the
implicit copy constructor, the defaulted <TT>H</TT> copy
constructor calls <TT>G(const G2&amp;)</TT> instead.  If the
move constructor did not suppress the implicit copy
constructor, I believe the implicit copy constructor would
always be viable, and therefore a better match than a
constructor taking a reference to another type.</P>

<P>So perhaps the answer is to reconsider that suppression
and then disqualify any constructor taking (a reference to)
a type other than the constructor's class from consideration
when looking up a subobject constructor in an implicitly
defined constructor.  (Or assignment operator,
presumably.)</P>

<P>Another possibility would be that when we're looking for
a conversion from <TT>C&lt;B&lt;E&gt;&gt;</TT> to
<TT>B&lt;E&gt;</TT> we could somehow avoid considering, or
even declaring, the <TT>B&lt;E&gt;</TT> copy constructor.
But that seems a bit dodgy.</P>

<P><B>Additional note (October, 2010):</B></P>

<P>An explicitly declared move constructor/op= should not suppress the
implicitly declared copy constructor/op=; it should cause it to be
deleted instead.  This should prevent a member function taking a
(reference to) an un-reference-related type from being chosen by
overload resolution in a defaulted member function.</P>

<P>And we should clarify that member functions taking
un-reference-related types are not even considered during overload
resolution in a defaulted member function, to avoid requiring their
parameter types to be complete.
</P>

<BR><BR><HR><A NAME="1150"></A><H4>1150.
  
Inheriting constructors have not been implemented
</H4><B>Section: </B>12.9&#160; [class.inhctor]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-03<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#US65">N3092 comment
  US&#160;65<BR></A>

<P>Inheriting constructors should not be part of C++0x unless they
have implementation experience.</P>

<BR><BR><HR><A NAME="545"></A><H4>545.
  
User-defined conversions and built-in operator overload resolution
</H4><B>Section: </B>13.3.1.2&#160; [over.match.oper]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>31 October 2005<BR>




<P>Consider the following example:</P>

<PRE>
    class B1 {};
    typedef void (B1::*PB1) (); //<SPAN style="font-family:Times;font-style:italic"> memptr to </SPAN>B1

    class B2 {};
    typedef void (B2::*PB2) (); //<SPAN style="font-family:Times;font-style:italic"> memptr to </SPAN>B2

    class D1 : public B1, public B2 {};
    typedef void (D1::*PD) (); //<SPAN style="font-family:Times;font-style:italic"> memptr to </SPAN>D1

    struct S {
         operator PB1(); //<SPAN style="font-family:Times;font-style:italic"> can be converted to </SPAN>PD
    } s;
    struct T {
         operator PB2(); //<SPAN style="font-family:Times;font-style:italic"> can be converted to </SPAN>PD
    } t;

    void foo() {
         s == t; //<SPAN style="font-family:Times;font-style:italic"> Is this an error?</SPAN>
    }
</PRE>

<P>According to 13.6 [over.built] paragraph 16, there is an
<TT>operator==</TT> for <TT>PD</TT> (&#8220;For every pointer to
member type...&#8221;), so why wouldn't it be used for this
comparison?</P>

<P><U>Mike Miller</U>: The problem, as I understand it, is that
13.3.1.2 [over.match.oper] paragraph 3, bullet 3, sub-bullet 3
is broader than it was intended to be.  It says that candidate
built-in operators must &#8220;accept operand types to which the given
operand or operands can be converted according to 13.3.3.1 [over.best.ics].&#8221; 13.3.3.1.2 [over.ics.user]
describes user-defined conversions as having a second standard
conversion sequence, and there is nothing to restrict that second
standard conversion sequence.</P>

<P>My initial thought on addressing this would be to say that
user-defined conversion sequences whose second standard conversion
sequence contains a pointer conversion or a pointer-to-member
conversion are not considered when selecting built-in candidate
operator functions.  They would still be applicable after the hand-off
to Clause 5 (e.g., in bringing the operands to their common type,
5.10 [expr.eq], or composite pointer type, 5.9 [expr.rel]), just not in constructing the list of built-in
candidate operator functions.</P>

<P>I started to suggest restricting the second standard conversion
sequence to conversions having Promotion or Exact Match rank, but that
would exclude the Boolean conversions, which are needed
for <TT>!</TT>, <TT>&amp;&amp;</TT>, and <TT>||</TT>.  (It would have
also restricted the floating-integral conversions, though, which might
be a good idea.  They can't be used implicitly, I think, because there
would be an ambiguity among all the promoted integral types; however,
none of the compilers I tested even tried those conversions because
the errors I got were not ambiguities but things like &#8220;floating
point operands not allowed for <TT>%</TT>&#8221;.)</P>

<P><U>Bill Gibbons</U>: I recall seeing this problem before, though
possibly not in committee discussions.  As written this rule makes the
set of candidate functions dependent on what classes have been
defined, including classes not otherwise required to have been defined
in order for "==" to be meaningful.  For templates this implies that
the set is dependent on what templates have been instantiated,
e.g.</P>

<PRE>
  template&lt;class T&gt; class U : public T { };
  U&lt;B1&gt; u;  //<SPAN style="font-family:Times;font-style:italic"> changes the set of candidate functions to include</SPAN>
            //<SPAN style="font-family:Times;font-style:italic"> </SPAN>operator==(U&lt;B1&gt;,U&lt;B1&gt;)<SPAN style="font-family:Times;font-style:italic">?</SPAN>
</PRE>

<P>There may be other places where the existence of a class
definition, or worse, a template instantiation, changes the semantics
of an otherwise valid program (e.g. pointer conversions?) but it seems
like something to be avoided.</P>

<P>(See also <A HREF="
     cwg_active.html#954">issue 954</A>.)</P>

<BR><BR><HR><A NAME="1228"></A><H4>1228.
  
Copy-list-initialization and <TT>explicit</TT> constructors
</H4><B>Section: </B>13.3.1.7&#160; [over.match.list]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-12-03<BR>




<P>The rules for selecting candidate functions in copy-list-initialization
(13.3.1.7 [over.match.list]) differ from those of regular
copy-initialization (13.3.1.4 [over.match.copy]): the latter specify
that only the converting (non-<TT>explicit</TT>) constructors are
considered, while the former include all constructors but state that
the program is ill-formed if an <TT>explicit</TT> constructor is
selected by overload resolution.  This is counterintuitive and can
lead to surprising results.  For example, the call to the function
object <TT>p</TT> in the following example is ambiguous because the
<TT>explicit</TT> constructor is a candidate for the initialization of
the operator's parameter:</P>

<PRE>
    struct MyList {
      explicit MyStore(int initialCapacity);
    };

    struct MyInt {
      MyInt(int i);
    };

    struct Printer {
      void operator()(MyStore const&amp; s);
      void operator()(MyInt const&amp; i);
    };

    void f() {
      Printer p;
      p({23});
    }
</PRE>

<BR><BR><HR><A NAME="418"></A><H4>418.
  
Imperfect wording on error on multiple default arguments on a called function
</H4><B>Section: </B>13.3.3&#160; [over.match.best]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Chris Bowler
 &#160;&#160;&#160;

 <B>Date: </B>27 May 2003<BR>




<P>According to
13.3.3 [over.match.best] paragraph 4, the following program
appears to be ill-formed:</P>
<PRE>
  void f(int, int=0);
  void f(int=0, int);

  void g() {
    f();
  }
</PRE>
<P>Though I do not expect this is the intent of this paragraph in the
standard.</P>

<P>13.3.3 [over.match.best] paragraph 4:</P>
<BLOCKQUOTE>
If the best viable function resolves to a function for which multiple
declarations were found, and if at least
two of these declarations or the declarations they refer to in the case of
using-declarations specify a
default argument that made the function viable, the program is ill-formed.
[Example:
<PRE>
namespace A {
  extern "C" void f(int = 5);
}
namespace B {
  extern "C" void f(int = 5);
}
using A::f;
using B::f;
void use() {
f(3); //OK, default argument was not used for viability
f(); //Error: found default argument twice
}
</PRE>
end example]</BLOCKQUOTE>

<BR><BR><HR><A NAME="455"></A><H4>455.
  
Partial ordering and non-deduced arguments
</H4><B>Section: </B>13.3.3&#160; [over.match.best]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Rani Sharoni
 &#160;&#160;&#160;

 <B>Date: </B>19 Jan 2004<BR>


<P>
It's not clear how overloading and partial ordering handle non-deduced pairs
of corresponding arguments. For example:</P>
<PRE>
template&lt;typename T&gt;
struct A { typedef char* type; };

template&lt;typename T&gt; char* f1(T, typename A&lt;T&gt;::type);  // #1
template&lt;typename T&gt; long* f1(T*, typename A&lt;T&gt;::type*); // #2

long* p1 = f1(p1, 0); // #3
</PRE>
<P>I thought that #3 is ambiguous but different compilers disagree on that.
Comeau C/C++ 4.3.3 (EDG 3.0.3) accepted the code, GCC 3.2 and BCC 5.5
selected #1 while VC7.1+ yields ambiguity.</P>

<P>I intuitively thought that the second pair should prevent overloading from
triggering partial ordering since both arguments are non-deduced and has
different types - (char*, char**). Just like in the following:</P>
<PRE>
template&lt;typename T&gt; char* f2(T, char*);   // #3
template&lt;typename T&gt; long* f2(T*, char**); // #4

long* p2 = f2(p2, 0); // #5
</PRE>
<P>In this case all the compilers I checked found #5 to be ambiguous.
The standard and DR <A HREF="
     cwg_defects.html#214">214</A> is not clear
about how partial ordering handle such
cases.</P>

<P>I think that overloading should not trigger partial ordering (in step
13.3.3 [over.match.best]/1/5) if some candidates have
non-deduced pairs with different
(specialized) types. In this stage the arguments are already adjusted so no
need to mention it (i.e. array to pointer). In case that one of the
arguments is non-deuced then partial ordering should only consider the type
from the specialization:</P>
<PRE>
template&lt;typename T&gt; struct B { typedef T type; };

template&lt;typename T&gt; char* f3(T, T);                   // #7
template&lt;typename T&gt; long* f3(T, typename B&lt;T&gt;::type); // #8

char* p3 = f3(p3, p3); // #9
</PRE>
<P>According to my reasoning #9 should yield ambiguity since second pair is (T,
long*). The second type (i.e. long*) was taken from the specialization
candidate of #8.
EDG and GCC accepted the code. VC and BCC found an ambiguity.</P>

<P><U>John Spicer:</U>
There may (or may not) be an issue concerning whether nondeduced
contexts are handled properly in the partial ordering rules.  In
general, I think nondeduced contexts work, but we should walk through
some examples to make sure we think they work properly.</P>

<P>Rani's description of the problem suggests that he believes that
partial ordering is done on the specialized types.  This is not
correct.  Partial ordering is done on the templates themselves,
independent of type information from the specialization.</P>

<P><B>Notes from October 2004 meeting:</B></P>

<P>John Spicer will investigate further to see if any action is
required.</P>

<P>(See also <A HREF="
     cwg_closed.html#885">issue 885</A>.)</P>

<BR><BR><HR><A NAME="1229"></A><H4>1229.
  
Overload resolution with empty <I>braced-init-list</I> argument
</H4><B>Section: </B>13.3.3.1.5&#160; [over.ics.list]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2010-12-09<BR>




<P>The changes for <A HREF="
     cwg_defects.html#990">issue 990</A> did not address
the description of overload resolution when an argument is an empty
<I>braced-init-list</I>.  For example:</P>

<PRE>
    struct A {
      A();
      A(std::initializer_list&lt;int&gt;);
      A(std::initializer_list&lt;double&gt;);
    };

    A a{};       //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>

    void f(A);

    void g() {
      f({});     //<SPAN style="font-family:Times;font-style:italic"> ambiguous</SPAN>
    }
</PRE>

<BR><BR><HR><A NAME="1238"></A><H4>1238.
  
Overloading ambiguity binding reference to function
</H4><B>Section: </B>13.3.3.2&#160; [over.ics.rank]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>2011-01-25<BR>




<P>Currently overload resolution does not distinguish between binding
an lvalue reference to a function lvalue and an rvalue reference to a
function lvalue.  The former should be preferred.</P>

<P>In a related point, the current wording of 13.3.3.1.4 [over.ics.ref]
paragraph 3 forbids binding an rvalue reference to an lvalue; this should
be changed to allow binding an rvalue reference to a function lvalue.</P>

<BR><BR><HR><A NAME="1038"></A><H4>1038.
  
Overload resolution of <TT>&amp;x.static_func</TT>
</H4><B>Section: </B>13.4&#160; [over.over]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-02<BR>


<P>The Standard is not clear whether the following example is
well-formed or not:</P>

<PRE>
    struct S {
        static void f(int);
        static void f(double);
    };
    S s;
    void (*pf)(int) = &amp;s.f;
</PRE>

<P>According to 5.2.5 [expr.ref] paragraph 4 bullet 3,
you do function overload resolution to determine whether
<TT>x.f</TT> is a static or non-static member function.
5.3.1 [expr.unary.op] paragraph 6 says that you can only
take the address of an overloaded function in a context that
determines the overload to be chosen, and the initialization of a
function pointer is such a context (13.4 [over.over]
paragraph 1).  The problem is that 13.4 [over.over] is
phrased in terms of &#8220;an overloaded function name,&#8221;
and this is a member access expression, not a name.</P>

<P>There is variability among implementations as to whether this
example is accepted; some accept it as written, some only if the
<TT>&amp;</TT> is omitted, and some reject it in both forms.</P>

<P><B>Additional note (October, 2010):</B></P>

<P>A related question concerns an example like</P>

<PRE>
    struct S {
        static void g(int*) {}
        static void g(long) {}
    } s;

    void foo() {
        (&amp;s.g)(0L);
    }
</PRE>

<P>Because the address occurs in a call context and not in one of
the contexts mentioned in 13.4 [over.over] paragraph 1,
the call expression in <TT>foo</TT> is presumably ill-formed.
Contrast this with the similar example</P>

<PRE>
    void g1(int*) {}
    void g1(long) {}

    void foo1() {
        (&amp;g1)(0L);
    }
</PRE>

<P>This call presumably is well-formed because 13.3.1.1 [over.match.call] applies to &#8220;the address of a set of overloaded
functions.&#8221; (This was clearer in the wording prior to the
resolution of <A HREF="
     cwg_defects.html#704">issue 704</A>: &#8220;...in
this context using <TT>&amp;F</TT> behaves the same as using the
name <TT>F</TT> by itself.&#8221;) It's not clear that there's any
reason to treat these two cases differently.</P>

<P>This question also bears on the original question of this issue,
since the original wording of 13.3.1.1 [over.match.call] also
described the case of an ordinary member function call like
<TT>s.g(0L)</TT> as involving the &#8220;name&#8221; of the function,
even though the <I>postfix-expression</I> is a member access
expression and not a &#8220;name.&#8221; Perhaps the reference to
&#8220;name&#8221; in 13.4 [over.over] should be similarly
understood as applying to member access expressions?</P>



<BR><BR><HR><A NAME="954"></A><H4>954.
  
Overload resolution of conversion operator templates with built-in types
</H4><B>Section: </B>13.6&#160; [over.built]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>19 August, 2009<BR>


<P>Consider the following example:</P>

<PRE>
    struct NullClass {
        template&lt;typename T&gt; operator T () { return 0 ; }
    };

    int main() {
        NullClass n;
        n==5;        // #1
        return 0;
    }
</PRE>

<P>The comparison at #1 is, according to the current Standard,
ambiguous.  According to 13.6 [over.built] paragraph 12, the
candidates for <TT>operator==(L, R)</TT> include functions &#8220;for
every pair of promoted arithmetic types,&#8221; so <TT>L</TT> could be
either <TT>int</TT> or <TT>long</TT>, and the conversion operator
template will provide an exact match for either.</P>

<P>Some implementations unambiguously choose the <TT>int</TT> candidate.
Perhaps the overload resolution rules could be tweaked to prefer
candidates in which <TT>L</TT> and <TT>R</TT> are the same type?</P>

<P>(See also <A HREF="
     cwg_active.html#545">issue 545</A>.)</P>

<BR><BR><HR><A NAME="110"></A><H4>110.
  
Can template functions and classes be declared in the same scope?
</H4><B>Section: </B>14&#160; [temp]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>28 Apr 1999<BR>




<P>According to 14 [temp]
 paragraph 5,</P>
<BLOCKQUOTE>

Except that a function template can be overloaded either by
(non-template) functions with the same name or by other function
templates with the same name
(14.8.3 [temp.over]
), a template name declared
in namespace scope or in class scope shall be unique in that scope.

</BLOCKQUOTE>
3.3.10 [basic.scope.hiding]
 paragraph 2 agrees
that only functions, not function templates, can hide a class name
declared in the same scope:
<BLOCKQUOTE>

A class name (9.1 [class.name]
) or
enumeration name (7.2 [dcl.enum]
) can be
hidden by the name of an object, function, or enumerator declared in
the same scope.

</BLOCKQUOTE>
However, 3.3 [basic.scope]
 paragraph 4
treats functions and template functions together in this regard:
<BLOCKQUOTE>

Given a set of declarations in a single declarative region, each of
which specifies the same unqualified name,

<UL>
<LI>they shall all refer to the same entity, or all refer to functions
and function templates; or</LI>

<LI>exactly one declaration shall declare a class name or enumeration
name that is not a typedef name and the other declarations shall all
refer to the same object or enumerator, or all refer to functions and
function templates; in this case the class name or enumeration name is
hidden</LI>

</UL>
</BLOCKQUOTE>

<P><B>John Spicer:</B> You should be able to take an existing program
and replace an existing function with a function template without
breaking unrelated parts of the program.

In addition, all of the compilers I tried allow this usage (EDG, Sun,
egcs, Watcom, Microsoft, Borland).

I would recommend that function templates be handled exactly like functions
for purposes of name hiding.</P>

<P><B>Martin O'Riordan:</B> I don't see any justification for extending
the purview of what is decidedly a hack, just for the sake of consistency.
In fact, I think we should go further and in the interest of consistency, we
should deprecate the hack, scheduling its eventual removal from the C++
language standard.</P>

<P>The hack is there to allow old C programs and especially the
'stat.h' file to compile with minimum effort (also several other Posix and X
headers).  People changing such older programs have ample opportunity to "do
it right".  Indeed, if you are adding templates to an existing program, you
should probably be placing your templates in a 'namespace', so the issue
disappears anyway.  The lookup rules should be able to provide the behaviour
you need without further hacking.</P>
<BR><BR><HR><A NAME="1246"></A><H4>1246.
  
Non-deduced non-final parameter packs
</H4><B>Section: </B>14.1&#160; [temp.param]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2011-02-23<BR>


<P>According to 14.1 [temp.param] paragraph 11,</P>

<BLOCKQUOTE>

If a <I>template-parameter</I> of a class template has a default
<I>template-argument</I>, each subsequent <I>template-parameter</I>
shall either have a default <I>template-argument</I> supplied or be a
template parameter pack.  If a <I>template-parameter</I> of a primary
class template is a template parameter pack, it shall be the last
<I>template-parameter</I>. [<I>Note:</I> These are not requirements
for function templates or class template partial specializations
because template arguments can be deduced (14.8.2 [temp.deduct])...

</BLOCKQUOTE>

<P>Should the Standard forbid non-final parameter packs in cases where
the declaration does not allow the template arguments to be deduced?
For example,</P>

<PRE>
    template&lt;typename... T, typename... U&gt; void f() { }
    template&lt;typename... T, typename U&gt; void g() { }
</PRE>

<BR><BR><HR><A NAME="343"></A><H4>343.
  
Make <TT>template</TT> optional in contexts that require a type
</H4><B>Section: </B>14.2&#160; [temp.names]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>23 April 2002<BR>


<P>By analogy with <TT>typename</TT>, the keyword <TT>template</TT>
used to indicate that a dependent name will be a template name should
be optional in contexts where a type is required, e.g.,
base class lists.  We could also consider member and parameter
declarations.</P>

<P>This was suggested by <A HREF="
     cwg_active.html#314">issue 314</A>.</P>

<BR><BR><HR><A NAME="579"></A><H4>579.
  
What is a &#8220;nested&#8221; <TT>&gt;</TT> or <TT>&gt;&gt;</TT>?
</H4><B>Section: </B>14.2&#160; [temp.names]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>11 May 2006<BR>


<P>The Standard does not normatively define which <TT>&gt;</TT> and
<TT>&gt;&gt;</TT> tokens are to be taken as closing a
<I>template-argument-list</I>; instead, 14.2 [temp.names]
paragraph 3 uses the undefined and imprecise term
&#8220;non-nested:&#8221;</P>

<BLOCKQUOTE>

When parsing a <I>template-id</I>, the first non-nested <TT>&gt;</TT>
is taken as the end of the <I>template-argument-list</I> rather than a
greater-than operator.  Similarly, the first
non-nested <TT>&gt;&gt;</TT> is treated as two consecutive but
distinct <TT>&gt;</TT> tokens, the first of which is taken as the end
of the <I>template-argument-list</I> and completes the <I>template-id</I>.

</BLOCKQUOTE>

<P>The (non-normative) footnote clarifies that</P>

<BLOCKQUOTE>

A <TT>&gt;</TT> that encloses the <I>type-id</I> of a <TT>dynamic_cast</TT>, <TT>static_cast</TT>,
<TT>reinterpret_cast</TT> or <TT>const_cast</TT>, or which encloses the
<I>template-argument</I>s of a subsequent <I>template-id</I>, is
considered nested for the purpose of this description.

</BLOCKQUOTE>

<P>Aside from the questionable wording of this footnote (e.g., in what
sense does a single terminating character &#8220;enclose&#8221;
anything, and is a nested <I>template-id</I>
&#8220;subsequent?&#8221;) and the fact that it is non-normative, it
does not provide a complete definition of what &#8220;nesting&#8221;
is intended to mean.  For example, is the first <TT>&gt;</TT> in this
putative <I>template-id</I> &#8220;nested&#8221; or not?</P>

<PRE>
    X&lt;a ? b &gt; c : d&gt;
</PRE>

<BR><BR><HR><A NAME="440"></A><H4>440.
  
Allow implicit pointer-to-member conversion on nontype template argument
</H4><B>Section: </B>14.3&#160; [temp.arg]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>David Abrahams
 &#160;&#160;&#160;

 <B>Date: </B>13 Nov 2003<BR>


<P>None of my compilers accept this, which surprised me a little.  Is
the base-to-derived member function conversion considered to be a
runtime-only thing?</P>
<PRE>
  template &lt;class D&gt;
  struct B
  {
      template &lt;class X&gt; void f(X) {}
      template &lt;class X, void (D::*)(X) = &amp;B&lt;D&gt;::f&lt;X&gt; &gt;
      struct row {};
  };
  struct D : B&lt;D&gt;
  {
      void g(int);
      row&lt;int,&amp;D::g&gt; r1;
      row&lt;char*&gt; r2;
  };
</PRE>
<P><U>John Spicer</U>:
This is not among the permitted conversions listed in 14.3.</P>

<P>I'm not sure there is a terribly good reason for that.  Some of the
template argument rules for external entities were made conservatively
because of concerns about issues of mangling template argument names.</P>

<P><U>David Abrahams</U>:
I'd really like to see that restriction loosened.  It is a serious
inconvenience because there appears to be no way to supply a usable
default in this case.  Zero would be an OK default if I could use the
function pointer's equality to zero as a compile-time switch to
choose an empty function implementation:</P>
<PRE>
  template &lt;bool x&gt; struct tag {};

  template &lt;class D&gt;
  struct B
  {
      template &lt;class X&gt; void f(X) {}

      template &lt;class X, void (D::*pmf)(X) = 0 &gt;
      struct row {
          void h() { h(tag&lt;(pmf == 0)&gt;(), pmf); }
          void h(tag&lt;1&gt;, ...) {}
          void h(tag&lt;0&gt;, void (D::*q)(X)) { /*something*/}
      };
  };

  struct D : B&lt;D&gt;
  {
      void g(int);
      row&lt;int,&amp;D::g&gt; r1;
      row&lt;char*&gt; r2;
  };
</PRE>

<P>But there appears to be no way to get that effect either.  The result
is that you end up doing something like:</P>
<PRE>
      template &lt;class X, void (D::*pmf)(X) = 0 &gt;
      struct row {
          void h() { if (pmf) /*something*/ }
      };
</PRE>

<P>which invariably makes compilers warn that you're switching on a
constant expression.</P>

<BR><BR><HR><A NAME="150"></A><H4>150.
  
Template template parameters and default arguments
</H4><B>Section: </B>14.3.3&#160; [temp.arg.template]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>3 Aug 1999<BR>



<P>[Picked up by evolution group at October 2002 meeting.]</P>



<P>How are default template arguments handled with respect to template
template parameters?  Two separate questions have been raised:</P>

<OL>
<LI>
Do default template arguments allow a template argument to match a
template parameter with fewer template parameters, and can the
template template parameter be specialized using the smaller number of
template arguments?  For example,

<PRE>
    template &lt;class T, class U = int&gt;
    class ARG { };

    template &lt;class X, template &lt;class Y&gt; class PARM&gt;
    void f(PARM&lt;X&gt;) { }    // specialization permitted?

    void g() {
        ARG&lt;int&gt; x;        // actually ARG&lt;int, int&gt;
        f(x);              // does ARG (2 parms, 1 with default)
                           // match PARM (1 parm)?
</PRE>

Template template parameters are deducible
(14.8.2.5 [temp.deduct.type]
 paragraph 9),
but 14.3.3 [temp.arg.template]
 does not
specify how matching is done.

<P><U>Jack Rouse</U>:
I implemented template template parameters assuming template signature
matching is analogous to function type matching.  This seems like the
minimum reasonable implementation.  The code in the example would not
be accepted by this compiler.  However, template default arguments are
compile time entities so it seems reasonable to relax the matching
rules to allow cases like the one in the example.  But I would
consider this to be an extension to the language.</P>

<P><U>Herb Sutter</U>:
An open issue in the LWG is that the standard
doesn't explicitly permit or forbid implementations' adding additional
<I>template-parameter</I>s
to those specified by the standard, and the LWG may be
leaning toward explicitly permitting this. 
[Under this interpretation,]
if the standard is ever modified to allow additional
<I>template-parameter</I>s,
then writing "a template that takes a standard library template as a
template template parameter" won't be just ugly because you have to mention
the defaulted parameters; it would not be (portably) possible at all except
possibly by defining entire families of overloaded templates to account for
all the possible numbers of parameters
<TT>vector&lt;&gt;</TT> (or anything else) might
actually have. That seems unfortunate.</P></LI>

<LI>
Are default arguments permitted in the template parameter list of a
template template parameter?  For example,

<PRE>
    template &lt;template &lt;class T, class U = int&gt; class PARM&gt;
    class C {
        PARM&lt;int&gt; pi;
    };
</PRE>

<P><U>Jack Rouse</U>:
I decided they could not in the compiler I support.  This continues
the analogy with function type matching.  Also, I did not see a strong
need to allow default arguments in this context.</P>

<P>A class template used as a template template argument can have default
template arguments from its declarations.  How are the two sources of
default arguments to be reconciled?  The default arguments from the
template template formal could override.  But it could be cofusing if
a <I>template-id</I> using the argument template, <TT>ARG&lt;int&gt;</TT>, behaves
differently from a <I>template-id</I> using the template formal name,
<TT>FORMAL&lt;int&gt;</TT>.</P></LI>

</OL>

<P><B>Rationale (10/99):</B> Template template parameters are intended
to be handled analogously to function function parameters.  Thus the
number of parameters in a template template argument must match the
number of parameters in a template template parameter, regardless of
whether any of those paramaters have default arguments or not.  Default
arguments are allowed for the parameters of a template template
parameter, and those default arguments alone will be considered in
a specialization of the template template parameter within a template
definition; any default arguments for the parameters of a template
template argument are ignored.</P>

<P><B>Note (Mark Mitchell, February, 2006):</B></P>

<P>Perhaps it is already obvious to all, but it seems worth noting that
this extension would change the meaning of conforming programs:</P>

<PRE>
    struct Dense { static const unsigned int dim = 1; };

    template &lt;template &lt;typename&gt; class View,
              typename Block&gt;
    void operator+(float, View&lt;Block&gt; const&amp;);

    template &lt;typename Block,
              unsigned int Dim = Block::dim&gt;
    struct Lvalue_proxy { operator float() const; };

    void test_1d (void) {
        Lvalue_proxy&lt;Dense&gt; p;
        float b;
        b + p;
    }
</PRE>

<P>If <TT>Lvalue_proxy</TT> is allowed to bind to <TT>View</TT>, then the
template <TT>operator+</TT> will be used to perform addition; otherwise,
<TT>Lvalue_proxy</TT>'s implicit conversion to float, followed by the
built-in addition on floats will be used.</P>

<P><B>Note (March, 2008):</B></P>

<P>The Evolution Working Group has accepted the intent of this issue
and referred it to CWG for action (not for C++0x).  See paper
J16/07-0033 = WG21 N2173.</P>

<P><B>Notes from the June, 2008 meeting:</B></P>

<P>The CWG decided to take no action on this issue until an interested
party produces a paper with analysis and a proposal.</P>
<BR><BR><HR><A NAME="1244"></A><H4>1244.
  
Equivalence of alias templates and class templates
</H4><B>Section: </B>14.4&#160; [temp.type]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-02-22<BR>




<P>The example in 14.4 [temp.type] paragraph 1 reads in
significant part,</P>

<PRE>
    template&lt;template&lt;class&gt; class TT&gt; struct X { };
    template&lt;class&gt; struct Y { };
    template&lt;class T&gt; using Z = Y&lt;T&gt;;
    X&lt;Y&gt; y;
    X&lt;Z&gt; z;
</PRE>

<P>and says that <TT>y</TT> and <TT>z</TT> have the same type.</P>

<P>This would only be true if alias template <TT>Z</TT> were
considered to be equivalent to class template <TT>Y</TT>.  However,
14.5.7 [temp.alias] describes equivalence only for
specializations of alias templates, not for the alias templates
themselves.  Either such rules should be specified, which could
be tricky, or the example should be deleted.</P>

<BR><BR><HR><A NAME="1245"></A><H4>1245.
  
Matching declarations involving <TT>decltype</TT>
</H4><B>Section: </B>14.5.1.1&#160; [temp.mem.func]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2011-02-22<BR>


<P>Type matching rules aren't well-specified in the current Standard,
but it seems reasonable to say that if a declaration uses <TT>decltype</TT>,
its definition must do so as well.  For example, the following should
be ill-formed:</P>

<PRE>
    template&lt;class T, T* u&gt; struct S {
      decltype(u) foo(T);
    };

    template&lt;class T, T *u&gt; T* S&lt;T, u&gt;::foo(T) {
       return nullptr;
    }
</PRE>

<BR><BR><HR><A NAME="1231"></A><H4>1231.
  
Variadic templates requiring an empty pack expansion
</H4><B>Section: </B>14.5.3&#160; [temp.variadic]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2010-12-20<BR>


<P>Should the Standard allow declarations of variadic templates or
member functions of class templates where only an empty expansion
would be well-formed?  For example,</P>

<PRE>
    template&lt;typename ... T&gt; struct A {
      void operator++(int, T... t);
    };
    template&lt;typename ... T&gt; union X: T... { };
    template&lt;typename ... T&gt; struct A: T..., T... { };
</PRE>

<BR><BR><HR><A NAME="708"></A><H4>708.
  
Partial specialization of member templates of class templates
</H4><B>Section: </B>14.5.5&#160; [temp.class.spec]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>8 Aug, 2008<BR>




<P>The Standard does not appear to specify clearly the effect of a
partial specialization of a member template of a class template.
For example:</P>

<PRE>
    template&lt;class T&gt; struct B {
         template&lt;class U&gt; struct A { // #1
             void h() {}
         };
         template&lt;class U&gt; struct A&lt;U*&gt; {  // #2
             void f() {}
         };
    };

    template&lt;&gt; template&lt;class U&gt; struct B&lt;int&gt;::A { // #3
         void g() {}
    };

    void q(B&lt;int&gt;::A&lt;char*&gt;&amp; p) {
         p.f();  // #4
    }
</PRE>

<P>The explicit specialization at #3 replaces the primary member
template #1 of <TT>B&lt;int&gt;</TT>; however, it is not clear
whether the partial specialization #2 should be considered to
apply to the explicitly-specialized member template of
<TT>A&lt;int&gt;</TT> (thus allowing the call to <TT>p.f()</TT>
at #4) or whether the partial specialization will be used only
for specializations of <TT>B</TT> that are implicitly
instantiated (meaning that #4 could call <TT>p.g()</TT> but not
<TT>p.f()</TT>).</P>

<BR><BR><HR><A NAME="310"></A><H4>310.
  
Can function templates differing only in parameter cv-qualifiers be overloaded?
</H4><B>Section: </B>14.5.6.1&#160; [temp.over.link]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Andrei Iltchenko
 &#160;&#160;&#160;

 <B>Date: </B>29 Aug 2001<BR>


<P>I get the following error diagnostic [from the EDG front end]:
<PRE>
line 8: error: function template "example&lt;T&gt;::foo&lt;R,A&gt;(A)" has
          already been declared
     R  foo(const A);
        ^
</PRE>
when compiling this piece of code:
<PRE>
struct  example  {
   template&lt;class R, class A&gt;   // 1-st member template
   R  foo(A);
   template&lt;class R, class A&gt;   // 2-nd member template
   const R  foo(A&amp;);
   template&lt;class R, class A&gt;   // 3-d  member template
   R  foo(const A);
};

/*template&lt;&gt; template&lt;&gt;
int  example&lt;char&gt;::foo(int&amp;);*/


int  main()
{
   int  (example&lt;char&gt;::* pf)(int&amp;) =
      &amp;example&lt;char&gt;::foo;
}
</PRE>
</P>

<P>The implementation complains that
<PRE>
   template&lt;class R, class A&gt;   // 1-st member template
   R  foo(A);
   template&lt;class R, class A&gt;   // 3-d  member template
   R  foo(const A);
</PRE>
cannot be overloaded and I don't see any reason for it
since it is function template specializations that are
treated like ordinary non-template functions, meaning
that the transformation of a
parameter-declaration-clause into the corresponding
parameter-type-list is applied to specializations
(when determining its type) and not to function
templates.</P>

<P>What makes me think so is the contents of 14.5.6.1 [temp.over.link]
and the following sentence from 14.8.2.1 [temp.deduct.call] "If P is a
cv-qualified type, the top level cv-qualifiers of P
are ignored for type deduction". If the transformation
was to be applied to function templates, then there
would be no reason for having that sentence in
14.8.2.1 [temp.deduct.call].</P>

<P>14.8.2.2 [temp.deduct.funcaddr], which my example is
based upon, says nothing
about ignoring the top level cv-qualifiers of the
function parameters of the function template whose
address is being taken.</P>

<P>As a result, I expect that template argument deduction
will fail for the 2-nd and 3-d member templates and
the 1-st one will be used for the instantiation of the
specialization.</P>

<BR><BR><HR><A NAME="23"></A><H4>23.
  
Some questions regarding partial ordering of function templates
</H4><B>Section: </B>14.5.6.2&#160; [temp.func.order]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>unknown
 &#160;&#160;&#160;

 <B>Date: </B>unknown<BR>





<P><U><B>Issue 1:</B></U></P>

<P>14.5.6.2 [temp.func.order]
 paragraph 2 says:
<BLOCKQUOTE>Given two overloaded function templates, whether one is more
specialized than another can be determined by transforming each template
in turn and using argument deduction (14.8.2 [temp.deduct]
) to compare it to the other.</BLOCKQUOTE>
14.8.2 [temp.deduct]
 now has 4 subsections describing argument deduction in different
situations. I think this paragraph should point to a subsection of
14.8.2 [temp.deduct]
.</P>

<P><B>Rationale:</B></P>

<P>This is not a defect; it is not necessary to pinpoint cross-references
to this level of detail.</P>

<P><B><U>Issue 2:</U></B></P>

<P>14.5.6.2 [temp.func.order]
 paragraph 4 says:</P>
<BLOCKQUOTE>Using the transformed function parameter list, perform argument
deduction against the other function template. The transformed template
is at least as specialized as the other if, and only if, the deduction
succeeds and the deduced parameter types are an exact match (so the deduction
does not rely on implicit conversions).</BLOCKQUOTE>
In "the deduced parameter types are an exact match", the terms exact match
do not make it clear what happens when a type T is compared to the reference
type T&amp;. Is that an exact match?



<P><B><U>Issue 3:</U></B></P>

<P>14.5.6.2 [temp.func.order]
 paragraph 5 says:</P>
<BLOCKQUOTE>A template is more specialized than another if, and only if,
it is at least as specialized as the other template and that template is
not at least as specialized as the first.</BLOCKQUOTE>
What happens in this case:
<PRE>
    template&lt;class T&gt; void f(T,int);
    template&lt;class T&gt; void f(T, T);
    void f(1,1);
</PRE>
For the first function template, there is no type deduction for the second
parameter. So the rules in this clause seem to imply that the second function
template will be chosen.

<P><B>Rationale:</B></P>

<P>This is not a defect; the standard unambiguously makes the above example
ill-formed due to ambiguity.</P>
<BR><BR><HR><A NAME="402"></A><H4>402.
  
More on partial ordering of function templates
</H4><B>Section: </B>14.5.6.2&#160; [temp.func.order]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Nathan Sidwell
 &#160;&#160;&#160;

 <B>Date: </B>7 Apr 2003<BR>




<P>This was split off from <A HREF="
     cwg_defects.html#214">issue 214</A> at
the April 2003 meeting.</P>

<P><U>Nathan Sidwell</U>:
John Spicer's proposed resolution does not make the following
well-formed.</P>
<PRE>
  template &lt;typename T&gt; int Foo (T const *) {return 1;} //#1
  template &lt;unsigned I&gt; int Foo (char const (&amp;)[I]) {return 2;} //#2

  int main ()
  {
    return Foo ("a") != 2;
  }
</PRE>
<P>Both #1 and #2 can deduce the "a" argument, #1 deduces T as char and
#2 deduces I as 2. However, neither is more specialized because the
proposed rules do not have any array to pointer decay.</P>

<P>#1 is only deduceable because of the rules in
14.8.2.1 [temp.deduct.call] paragraph 2 that
decay array and function type arguments when the template parameter is
not a reference. Given that such behaviour happens in deduction, I believe
there should be equivalent behaviour during partial ordering. #2 should be
resolved as more specialized as #1. The following alteration to the
proposed resolution of DR214 will do that.</P>

<P>Insert before,</P>
<UL>
<LI>If A is a cv-qualified type, A is replaced by the
         cv-unqualified version of A.</LI>
</UL>
<P>the following</P>
<UL>
<LI>If P was not originally a reference type,
<UL>
<LI>If A is an array type, A is replaced by the pointer type produced
            by the array to pointer conversion</LI>
<LI>If A is a function type, A is replaced by the pointer type
            produced by the function to pointer conversion</LI>
</UL>
</LI>
</UL>

<P>For the example above, this change results in deducing 'T const *' against
'char const *' in one direction (which succeeds), and 'char [I]'
against 'T const *' in the other (which fails).</P>

<P><U>John Spicer</U>:
I don't consider this a shortcoming of my proposed wording, as I don't
think this is part of the current rules.  In other words, the
resolution of 214 might make it clearer how this case is handled
(i.e., clearer that it is not allowed), but I don't believe it
represents a change in the language.</P>

<P>I'm not necessarily opposed to such a change, but I think it should be
reviewed by the core group as a related change and not a defect in the
proposed resolution to 214.</P>

<P><B>Notes from the October 2003 meeting:</B></P>

<P>There was some sentiment that it would be desirable to have
this case ordered, but we don't think it's worth spending the
time to work on it now.  If we look at some larger partial
ordering changes at some point, we will consider this again.</P>

<BR><BR><HR><A NAME="1157"></A><H4>1157.
  
Partial ordering of function templates is still underspecified
</H4><B>Section: </B>14.5.6.2&#160; [temp.func.order]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>CA
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-03<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#CA7">N3092 comment
  CA&#160;7<BR></A>

<P>14.5.6.2 [temp.func.order] paragraph 3 says,</P>

<BLOCKQUOTE>

To produce the transformed template, for each type,
non-type, or template template parameter (including template
parameter packs (14.5.3 [temp.variadic]) thereof)
synthesize a unique type, value, or class template
respectively and substitute it for each occurrence of that
parameter in the function type of the template.

</BLOCKQUOTE>

<P>The characteristics of the synthesized entities and how they
are determined is not specified.  For example, members of a dependent
type referred to in non-deduced contexts are not specified to exist,
even though the transformed function type would be invalid in their
absence.</P>

<P>Example 1:</P>

<PRE>
  template&lt;typename T, typename U&gt; struct A;
  template&lt;typename T&gt; void foo(A&lt;T, typename T::u&gt; *) { } //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> synthetic </SPAN>T1<SPAN style="font-family:Times;font-style:italic"> has member </SPAN>T1::u
  template &lt;typename T&gt; void foo(A&lt;T, typename T::u::v&gt; *) { } //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> synthetic </SPAN>T2<SPAN style="font-family:Times;font-style:italic"> has member </SPAN>T2::u<SPAN style="font-family:Times;font-style:italic"> and member </SPAN>T2::u::v
    //<SPAN style="font-family:Times;font-style:italic"> </SPAN>T<SPAN style="font-family:Times;font-style:italic"> in #1 deduces to synthetic </SPAN>T2<SPAN style="font-family:Times;font-style:italic"> in partial ordering;</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> deduced </SPAN>A<SPAN style="font-family:Times;font-style:italic"> for the parameter is </SPAN>A&lt;T2, T2::u&gt; *<SPAN style="font-family:Times;font-style:italic"> --this is not necessarily compatible</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> with </SPAN>A&lt;T2, T2::u::v&gt; *<SPAN style="font-family:Times;font-style:italic"> and it does not need to be. See Note 1. The effect is that</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> (in the call below) the compatibility of </SPAN>B::u<SPAN style="font-family:Times;font-style:italic"> and </SPAN>B::u::v<SPAN style="font-family:Times;font-style:italic"> is respected.</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> </SPAN>T<SPAN style="font-family:Times;font-style:italic"> in #2 cannot be successfully deduced in partial ordering from </SPAN>A&lt;T1, T1::u&gt; *;
    //<SPAN style="font-family:Times;font-style:italic"> invalid type </SPAN>T1::u::v<SPAN style="font-family:Times;font-style:italic"> will be formed when </SPAN>T1<SPAN style="font-family:Times;font-style:italic"> is substituted into non-deduced contexts.</SPAN>
  struct B {
    struct u { typedef u v; };
  };
  int main() {
    foo((A&lt;B, B::u&gt; *)0); //<SPAN style="font-family:Times;font-style:italic"> calls #2</SPAN>
  }
</PRE>

<P>Note 1: Template argument deduction is an attempt to
match a <TT>P</TT> and a deduced <TT>A</TT>; however,
template argument deduction is not specified to fail if the
<TT>P</TT> and the deduced <TT>A</TT> are incompatible. This
may occur in the presence of non-deduced contexts.
Notwithstanding the parenthetical statement in 14.8.2.4 [temp.deduct.partial] paragraph 9, template argument deduction
may succeed in determining a template argument for every
template parameter while producing a deduced <TT>A</TT> that
is not compatible with the corresponding <TT>P</TT>.</P>

<P>Example 2:</P>

<PRE>
  template &lt;typename T, typename U, typename V&gt; struct A;
  template &lt;typename T&gt;
    void foo(A&lt;T, struct T::u, struct T::u::u&gt; *); //<SPAN style="font-family:Times;font-style:italic"> #2.1</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> synthetic </SPAN>T1<SPAN style="font-family:Times;font-style:italic"> has member non-union class </SPAN>T1::u
  template &lt;typename T, typename U&gt;
    void foo(A&lt;T, U , U&gt; *); //<SPAN style="font-family:Times;font-style:italic"> #2.2</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> synthetic </SPAN>T2<SPAN style="font-family:Times;font-style:italic"> and </SPAN>U2<SPAN style="font-family:Times;font-style:italic"> has no required properties</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> </SPAN>T<SPAN style="font-family:Times;font-style:italic"> in #2.1 cannot be deduced in partial ordering from </SPAN>A&lt;T2, U2, U2&gt; *;
      //<SPAN style="font-family:Times;font-style:italic"> invalid types </SPAN>T2::u<SPAN style="font-family:Times;font-style:italic"> and </SPAN>T2::u::u<SPAN style="font-family:Times;font-style:italic"> will be formed when </SPAN>T2<SPAN style="font-family:Times;font-style:italic"> is substituted in nondeduced contexts.</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> </SPAN>T<SPAN style="font-family:Times;font-style:italic"> and </SPAN>U<SPAN style="font-family:Times;font-style:italic"> in #2.2 deduces to, respectively, </SPAN>T1<SPAN style="font-family:Times;font-style:italic"> and </SPAN>T1::u<SPAN style="font-family:Times;font-style:italic"> from </SPAN>A&lt;T1, T1::u, struct
T1::u::u&gt; *<SPAN style="font-family:Times;font-style:italic"> unless</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> </SPAN>struct T1::u::u<SPAN style="font-family:Times;font-style:italic"> does not refer to the injected-class-name of the class </SPAN>T1::u<SPAN style="font-family:Times;font-style:italic"> (if that is possible).</SPAN>
  struct B {
    struct u { };
  };
  int main() {
    foo((A&lt;B, B::u, struct B::u::u&gt; *)0); //<SPAN style="font-family:Times;font-style:italic"> calls #2.1</SPAN>
  }
</PRE>

<P>It is, however, unclear to what extent an implementation
will have to go to determine these minimal properties.</P>

<BR><BR><HR><A NAME="1235"></A><H4>1235.
  
&#8220;Unused&#8221; ellipsis and default arguments in partial ordering
</H4><B>Section: </B>14.5.6.2&#160; [temp.func.order]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>2011-01-18<BR>




<P>The specification for how to handle default arguments and ellipsis
in partial ordering of function templates is confusing.
14.5.6.2 [temp.func.order] paragraph 5 currently reads,</P>

<BLOCKQUOTE>

The presence of unused ellipsis and default arguments has no effect on
the partial ordering of function templates.

</BLOCKQUOTE>

<P>It is not clear what &#8220;unused&#8221; means in this context.
According to the original issue resolution that resulted in this
wording (<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1997/N1053.pdf">N1053</A>,
item 6.55), the intent was that &#8220;When partial ordering of
function templates containing a different number of parameters is done,
only the common parameters are considered.&#8221; Presumably this
would include parameters with default arguments if each function had
such parameters in corresponding positions.</P>

<P>The wording needs to be revised to make this intent clear.</P>

<BR><BR><HR><A NAME="186"></A><H4>186.
  
Name hiding and template <I>template-parameter</I>s
</H4><B>Section: </B>14.6.1&#160; [temp.local]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>11 Nov 1999<BR>





<P>The standard prohibits a class template from having the same name as
one of its template parameters
(14.6.1 [temp.local]
 paragraph 4).  This prohibits</P>

<PRE>
    template &lt;class X&gt; class X;
</PRE>

for the reason that the template name would hide the parameter, and
such hiding is in general prohibited.

<P>Presumably, we should also prohibit</P>

<PRE>
    template &lt;template &lt;class T&gt; class T&gt; struct A;
</PRE>

for the same reason.
<BR><BR><HR><A NAME="459"></A><H4>459.
  
Hiding of template parameters by base class members
</H4><B>Section: </B>14.6.1&#160; [temp.local]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2 Feb 2004<BR>


<P>Currently, member of nondependent base classes hide
references to template parameters in the definition
of a derived class template.</P>

<P>Consider the following example:</P>
<PRE>
   class B {
      typedef void *It;    // (1)
      // ...
    };

    class M: B {};

    template&lt;typename&gt; X {};

    template&lt;typename It&gt; struct S   // (2)
        : M, X&lt;It&gt; {   // (3)
      S(It, It);   // (4)
      // ...
    };
</PRE>
<P>As the C++ language currently stands, the name "It"
in line (3) refers to the template parameter declared
in line (2), but the name "It" in line (4) refers to
the typedef in the private base class (declared in
line (1)).</P>

<P>This situation is both unintuitive and a hindrance
to sound software engineering.  (See also the Usenet
discussion at http://tinyurl.com/32q8d .)  Among
other things, it implies that the private section
of a base class may change the meaning of the derived
class, and (unlike other cases where such things
happen) there is no way for the writer of the derived
class to defend the code against such intrusion (e.g.,
by using a qualified name).</P>

<P>Changing this can break code that is valid today.
However, such code would have to:
<OL>
<LI>
name a template parameter and not use it
         after the opening brace, and
</LI>
<LI>
use that same name to access a base-class
         name within the braces.
</LI>
</OL>
I personally have no qualms breaking such a program.</P>

<P>It has been suggested to make situations like these
ill-formed.  That solution is unattractive however
because it still leaves the writer of a derived class
template without defense against accidental name
conflicts with base members.  (Although at least the
problem would be guaranteed to be caught at compile
time.)  Instead, since just about everyone's intuition
agrees, I would like to see the rules changed to
make class template parameters hide members of the
same name in a base class.</P>

<P>See also <A HREF="
     cwg_defects.html#458">issue 458</A>.</P>

<P><B>Notes from the March 2004 meeting:</B></P>

<P>We have some sympathy for a change, but the current rules fall
straightforwardly out of the lookup rules, so they're not
&#8220;wrong.&#8221; Making private members invisible also would solve
this problem.  We'd be willing to look at a paper proposing that.</P>

<P><B>Additional discussion (April, 2005):</B></P>



<P><U>John Spicer</U>: Base class members are more-or-less treated as
members of the class, [so] it is only natural that the base [member]
would hide the template parameter.</P>

<P><U>Daveed Vandevoorde</U>: Are base class members really
&#8220;more or less&#8221; members of the class from a lookup
perspective?  After all, derived class members can hide base class
members of the same name.  So there is some pretty definite
boundary between those two sets of names.  IMO, the template
parameters should either sit between those two sets, or they
should (for lookup purposes) be treated as members of the class
they parameterize (I cannot think of a practical difference
between those two formulations).</P>

<P><U>John Spicer</U>: How is [hiding template parameters]
different from the fact that namespace members can be hidden
by private parts of a base class?  The addition of <TT>int C</TT>
to <TT>N::A</TT> breaks the code in namespace <TT>M</TT> in this
example:</P>

<PRE>
    namespace N {
       class A {
    private:
         int C;
       };
    }

    namespace M {
       typedef int C;
       class B : public N::A {
         void f() {
             C c;
         }
       };
    }
</PRE>

<P><U>Daveed Vandevoorde</U>: C++ has a mechanism in place to handle
such situations: qualified names.  There is no such mechanism in place
for template parameters.</P>

<P><U>Nathan Myers</U>: What I see as obviously incorrect ... is
simply that a name defined right where I can see it, and directly
attached to the textual scope of <TT>B</TT>'s class body, is ignored
in favor of something found in some other file.  I don't care that
<TT>C1</TT> is defined in <TT>A</TT>, I have a <TT>C1</TT> right
here that I have chosen to use.  If I want <TT>A::C1</TT>, I can
say so.</P>

<P>I doubt you'll find any regular C++ coder who doesn't find the
standard behavior bizarre.  If the meaning of any code is changed
by fixing this behavior, the overwhelming majority of cases will
be mysterious bugs magically fixed.</P>

<P><U>John Spicer</U>: I have not heard complaints that this is
actually a cause of problems in real user code.  Where is the
evidence that the status quo is actually causing problems?</P>

<P>In this example, the <TT>T2</TT> that is found is the one from
the base class.  I would argue that this is natural because base
class members are found as part of the lookup in class <TT>B</TT>:</P>

<PRE>
    struct A {
             typedef int T2;
    };
    template &lt;class T2&gt; struct B : public A {
             typedef int T1;
             T1 t1;
             T2 t2;
    };
</PRE>

<P>This rule that base class members hide template parameters was
formalized about a dozen years ago because it fell out of the
principle that base class members should be found at the same
stage of lookup as derived class members, and that to do otherwise
would be surprising.</P>

<P><U>Gabriel Dos Reis</U>: The bottom line is that:</P>

<OL>

<LI>the proposed change is a <B>silent</B> change of meaning;</LI>

<LI>the proposed change does not make the language any more regular;
the current behavior is consistent with everything else, however
&#8220;surprising&#8221; that might be;</LI>

<LI>the proposed change does have its own downsides.</LI>

</OL>

<P>Unless presented with real major programming problems the current
rules exhibit, I do not think the simple rule &#8220;scopes
nest&#8221; needs a change that silently mutates program meaning.</P>

<P><U>Mike Miller</U>: The rationale for the current specification is
really very simple:</P>

<OL>

<LI>&#8220;Unless redeclared in the derived class, members of a base
class are also considered to be members of the derived class.&#8221;
(10 [class.derived] paragraph 2)</LI>

<LI>In class scope, members hide nonmembers.</LI>

</OL>

<P>That's it.  Because template parameters are not members, they
are hidden by member names (whether inherited or not).  I don't find
that &#8220;bizarre,&#8221; or even particularly surprising.</P>

<P>I believe these rules are straightforward and consistent, so I
would be opposed to changing them.  However, I am not unsympathetic
toward Daveed's concern about name hijacking from base classes.  How
about a rule that would make a program ill-formed if a direct or
inherited member hides a template parameter?</P>

<P>Unless this problem is a lot more prevalent than I've heard so
far, I would not want to change the lookup rules; making this kind of
collision a diagnosable error, however, would prevent hijacking
without changing the lookup rules.</P>

<P><U>Erwin Unruh</U>: I have a different approach that is consistent
and changes the interpretation of the questionable code.  At present
lookup is done in this sequence:</P>

<UL>
block scope<BR>
derived class scope<BR>
base class scope<BR>
template parameters<BR>
namespace scope
</UL>

<P>If we change this order to</P>

<UL>
template parameters<BR>
block scope<BR>
derived class scope<BR>
base class scope<BR>
namespace scope<BR>
</UL>

<P>it is still consistent in that no lookup is placed between the base
class and the derived class.  However, it introduces another
inconsistency: now scopes do not nest the same way as curly braces
nest &#8212; but base classes are already inconsistent this way.</P>

<P><U>Nathan Myers</U>: This looks entirely satisfactory.  If even this
seems like too big a change, it would suffice to say that finding a
different name by this search order makes the program ill-formed.
Of course, a compiler might issue only a portability warning in that
case and use the name found Erwin's way, anyhow.</P>

<P><U>Gabriel Dos Reis</U>: It is a simple fact, even without
templates, that a writer of a derived class cannot protect himself
against declaration changes in the base class.</P>

<P><U>Richard Corden</U>: If a change is to be made, then making it
ill-formed is better than just changing the lookup rules.</P>

<PRE>
    struct B
    {
      typedef int T;
      virtual void bar (T const &amp; );
    };

    template &lt;typename T&gt;
    struct D : public B
    {
      virtual void bar (T const &amp; );
    };

    template class D&lt;float&gt;;
</PRE>

<P>I think changing the semantics of the above code silently would
result in very difficult-to-find problems.</P>

<P><U>Mike Miller</U>: Another case that may need to be considered in
deciding on Erwin's suggestion or the &#8220;ill-formed&#8221;
alternative is the treatment of <TT>friend</TT> declarations
described in 3.4.1 [basic.lookup.unqual] paragraph 10:</P>

<PRE>
    struct A {
        typedef int T;
        void f(T);
    };
    template&lt;typename T&gt; struct B {
        friend void A::f(T);  //<SPAN style="font-family:Times;font-style:italic"> Currently </SPAN>T<SPAN style="font-family:Times;font-style:italic"> is </SPAN>A::T
    };
</PRE>

<P><B>Notes from the October, 2005 meeting:</B></P>

<P>The CWG decided not to consider a change to the existing rules at
this time without a paper exploring the issue in more detail.</P>
<BR><BR><HR><A NAME="591"></A><H4>591.
  
When a dependent base class is the current instantiation
</H4><B>Section: </B>14.6.2&#160; [temp.dep]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>24 August 2006<BR>




<P>Is the following example well-formed?</P>

<PRE>
    template&lt;class T&gt; struct A {
         typedef int M;
         struct B {
             typedef void M;
             struct C;
         };
    };

    template&lt;class T&gt; struct A&lt;T&gt;::B::C : A&lt;T&gt; {
         M  // A&lt;T&gt;::M or A&lt;T&gt;::B::M?
             p[2];
    };
</PRE>

<P>14.6.2 [temp.dep] paragraph 3 says the use
of <TT>M</TT> should refer to <TT>A&lt;T&gt;::B::M</TT> because
the base class <TT>A&lt;T&gt;</TT> is not searched because it's
dependent.  But in this case <TT>A&lt;T&gt;</TT> is also the
current instantiation (14.6.2.1 [temp.dep.type]) so it
seems like it should be searched.
</P>

<BR><BR><HR><A NAME="1233"></A><H4>1233.
  
Pack expansions and dependent calls
</H4><B>Section: </B>14.6.2&#160; [temp.dep]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2011-01-11<BR>


<P>In an example like</P>

<PRE>
  void f(int, int, int);
  template&lt;int ...N&gt; void g() {
    f((N+N)...);
  }
  void h() {
    g&lt;1, 2, 3&gt;();
  }
</PRE>

<P>the call to <TT>f</TT> needs to be dependent; however, the arguments
are not type-dependent, so the criteria of 14.6.2 [temp.dep]
paragraph 1 are not met.  Presumably the specification needs to be
updated so that an argument list containing a type-level pack expansion
is dependent.</P>

<BR><BR><HR><A NAME="590"></A><H4>590.
  
Nested classes and the &#8220;current instantiation&#8221;
</H4><B>Section: </B>14.6.2.1&#160; [temp.dep.type]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>23 August 2006<BR>




<P>In 14.6.2.1 [temp.dep.type] paragraph 5 we have:</P>

<BLOCKQUOTE>

A name is a <I>member of an unknown specialization</I> if the name is a
<I>qualified-id</I> in which the <I>nested-name-specifier</I>
names a dependent type that is not the current instantiation.

</BLOCKQUOTE>

<P>So given:</P>

<PRE>
    template&lt;class T&gt; struct A {
        struct B {
            struct C {
                A&lt;T&gt;::B::C f();
            };
        };
    };
</PRE>

<P>it appears that the name <TT>A&lt;T&gt;::B::C</TT> should be
taken as a member of an unknown specialization, because the WP
refers to &#8220;the&#8221; current instantiation, implying that
there can be at most one at any given time.  At the declaration
of <TT>f()</TT>, the current instantiation is <TT>C</TT>,
so <TT>A&lt;T&gt;::B</TT> is not the current instantiation.</P>

<P>Would it be better to refer to &#8220;a known instantiation&#8221;
instead of &#8220;the current instantiation?&#8221;</P>

<P><U>Mike Miller</U>:</P>

<P>I agree that there is a problem here, but I don't think the
&#8220;current instantiation&#8221; terminology needs to be
replaced.  By way of background, paragraph 1 makes it clear that
<TT>A&lt;T&gt;::B</TT> &#8220;refers to&#8221; the current
instantiation:</P>

<BLOCKQUOTE>

<P>In the definition of a class template, a nested class of a
class template, a member of a class template, or a member of a
nested class of a class template, a name refers to the <I>current
instantiation</I> if it is</P>

<UL><LI><P>the injected-class-name (9 [class]) of
the class template or nested class,</P></LI>

<LI><P>in the definition of a primary class template, the name of
the class template followed by the template argument list of the
primary template (as described below) enclosed
in <TT>&lt;&gt;</TT>,</P></LI>

<LI><P>in the definition of a nested class of a class template,
the name of the nested class referenced as a member of the
current instantiation...</P></LI>

</UL>

</BLOCKQUOTE>

<P><TT>A&lt;T&gt;::B</TT> satisfies bullet 3.  Paragraph 4 says,</P>

<BLOCKQUOTE>

<P>A name is a member of the current instantiation if it is</P>

<UL><LI><P>An unqualified name that, when looked up, refers to a
member of a class template. [<I>Note:</I> this can only occur
when looking up a name in a scope enclosed by the definition of a
class template. &#8212;<I>end note</I>]</P></LI>

<LI><P>A <I>qualified-id</I> in which
the <I>nested-name-specifier</I> refers to the current
instantiation.</P></LI>

</UL>

</BLOCKQUOTE>

<P>So clearly by paragraphs 1 and 4, <TT>A&lt;T&gt;::B::C</TT> is
a member of the current instantiation.  The problem is in the
phrasing of paragraph 5, which incorrectly requires that the
<I>nested-name-specifier</I> &#8220;be&#8221; the current
instantiation rather than simply &#8220;referring to&#8221; the
current instantiation, which would be the correct complement to
paragraph 4.  Perhaps paragraph 5 could simply be rephrased as,
&#8220;...a dependent type and it is not a member of the current
instantiation.&#8221;</P>

<P>(Paragraph 1 may require a bit more wordsmithing to make it
truly recursive across multiple levels of nested classes; as it
stands, it's not clear whether the name of a nested class of a
nested class of a class template is covered or not.)</P>

<BR><BR><HR><A NAME="903"></A><H4>903.
  
Value-dependent integral null pointer constants
</H4><B>Section: </B>14.6.2.3&#160; [temp.dep.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>22 May, 2009<BR>




<P>Consider the following example:</P>

<PRE>
    void f(int*);
    void f(...);

    template &lt;int N&gt; void g() {
      f(N);
    }

    int main() {
      g&lt;0&gt;();
      g&lt;1&gt;();
    }
</PRE>

<P>The call to <TT>f</TT> in <TT>g</TT> is not type-dependent, so the
overload resolution must be done at definition time rather than at
instantiation time.  As a result, both of the calls to <TT>g</TT>
will result in calls to <TT>f(...)</TT>, i.e., <TT>N</TT> will not
be a null pointer constant, even if the value of <TT>N</TT> is 0.</P>

<P>It would be most consistent to adopt a rule that a value-dependent
expression can never be a null pointer constant, even in cases like</P>

<PRE>
    template &lt;int N&gt; void g() {
      int* p = N;
    }
</PRE>

<P>This would always be ill-formed, even when <TT>N</TT> is 0.</P>

<P><U>John Spicer</U>: It's clear that this treatment is required for
overload resolution, but it seems too expansive given that there are
other cases in which the value of a template parameter can affect
the validity of the program, and an implementation is forbidden to
issue a diagnostic on a template definition unless there are no
possible valid specializations.</P>

<P><B>Notes from the July, 2009 meeting:</B></P>

<P>There was a strong consensus among the CWG that only the literal
<TT>0</TT> should be considered a null pointer constant, not any
arbitrary zero-valued constant expression as is currently specified.</P>

<BR><BR><HR><A NAME="1028"></A><H4>1028.
  
Dependent names in non-defining declarations
</H4><B>Section: </B>14.6.4&#160; [temp.dep.res]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Sean Hunt
 &#160;&#160;&#160;

 <B>Date: </B>2010-02-03<BR>


<P>The current wording of 14.6.4 [temp.dep.res] seems to assume
that dependent names can only appear in the definition of a template:</P>

<BLOCKQUOTE>

<P>In resolving dependent names, names from the following sources
are considered:</P>

<UL><LI><P>Declarations that are visible at the point of
definition of the template.</P></LI>

<LI><P>Declarations from namespaces associated with the types of
the function arguments both from the instantiation context
(14.6.4.1 [temp.point]) and from the definition context.</P></LI>

</UL>

</BLOCKQUOTE>

<P>However, dependent names can occur in non-defining declarations of
the template as well; for instance,</P>

<PRE>
    template&lt;typename T&gt;
    T foo(T, decltype(bar(T())));
</PRE>

<P><TT>bar</TT> needs to be looked up, even though there is no
definition of <TT>foo</TT> in the translation unit.</P>

<P><B>Additional note (February, 2011):</B></P>

<P>The resolution of this issue can't simply replace the word
&#8220;definition&#8221; with the word &#8220;declaration,&#8221;
<I>mutatis mutandis</I>, because there can be multiple declarations
in a translation unit (which isn't true of &#8220;the definition&#8221;).
As a result, the issue was moved back to "open" status for further
consideration.</P>

<BR><BR><HR><A NAME="293"></A><H4>293.
  
Syntax of explicit instantiation/specialization too permissive
</H4><B>Section: </B>14.7.2&#160; [temp.explicit]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mark Mitchell
 &#160;&#160;&#160;

 <B>Date: </B>27 Jun 2001<BR>


<P>14.7.2 [temp.explicit] defines an explicit instantiation as</P>

<UL><I>explicit-instantiation</I>:
<UL><TT>template</TT> <I>declaration</I></UL>
</UL>

<P>Syntactically, that allows things like:</P>
<PRE>
    template int S&lt;int&gt;::i = 5, S&lt;int&gt;::j = 7;
</PRE>

<P>which isn't what anyone actually expects.  As far as I can tell,
nothing in the standard explicitly forbids this, as written.  Syntactically,
this also allows:</P>

<PRE>
    template namespace N { void f(); }
</PRE>

<P>although perhaps the surrounding context is enough to suggest that this is
invalid.</P>

<P><B>Suggested resolution:</B></P>

<P>I think we should say:</P>

<UL><I>explicit-instantiation</I>:
<UL><I>type-specifier-seq</I><SUB>opt</SUB>
    <I>declarator</I><SUB>opt</SUB> <TT>;</TT></UL>
</UL>

<P><I>[Steve Adamczyk: presumably, this should have</I>
<TT>template</TT> <I>at the beginning.]</I></P>

<P>and then say that:</P>

<UL>
<LI>
The declarator can be omitted only when the <I>type-specifier-seq</I>
consists solely of an <I>elaborated-type-specifier</I> for a class type, in
which case the instantiation is for the named class.  If the
declarator is present the instantiation is for the named entity.
</LI>
<LI>
The <I>type-specifier-seq</I> can be omitted only when the declarator
is for a constructor, destructor, or conversion operator.
</LI>
<LI>
The <I>type-specifier-seq</I> cannot define any new types.
</LI>
</UL>

<P>There are similar problems in 14.7.3 [temp.expl.spec]:</P>

<UL><I>explicit-specialization</I>:
<UL><TT>template</TT> &lt;&gt; <I>declaration</I></UL>
</UL>

<P>Here, I think we want:</P>

<UL><I>explicit-specialization</I>:
<UL><I>decl-specifier-seq</I><SUB>opt</SUB> <I>init-declarator</I><SUB>opt</SUB> <TT>;</TT></UL>
</UL>

<P>with similar restrictions as above.</P>

<P><I>[Steve Adamczyk: This also needs to have</I>
<TT>template &lt;&gt;</TT> <I>at the beginning, possibly repeated.]</I></P>



<BR><BR><HR><A NAME="1046"></A><H4>1046.
  
What is a &#8220;use&#8221; of a class specialization?
</H4><B>Section: </B>14.7.2&#160; [temp.explicit]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-08<BR>


<P>According to 14.7.2 [temp.explicit] paragraph 10,</P>

<BLOCKQUOTE>

An entity that is the subject of an explicit instantiation
declaration and that is also used in the translation unit shall
be the subject of an explicit instantiation definition somewhere
in the program; otherwise the program is ill-formed, no
diagnostic required.

</BLOCKQUOTE>

<P>The term &#8220;used&#8221; is too vague and needs to be defined.
In particular, &#8220;use&#8221; of a class template specialization as
an incomplete type &#8212; to form a pointer, for instance &#8212;
should not require the presence of an explicit instantiation definition
elsewhere in the program.</P>

<BR><BR><HR><A NAME="264"></A><H4>264.
  
Unusable template constructors and conversion functions
</H4><B>Section: </B>14.8.1&#160; [temp.arg.explicit]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>17 Nov 2000<BR>




<P>The note in paragraph 5 of 14.8.1 [temp.arg.explicit] makes
clear that explicit template arguments cannot be supplied in
invocations of constructors and conversion functions because they are
called without using a name.  However, there is nothing in the current
wording of the Standard that makes declaring a constructor or
conversion operator that is unusable because of nondeduced parameters
(i.e., that would need to be specified explicitly) ill-formed.  It
would be a service to the programmer to diagnose this useless
construct as early as possible.</P>

<BR><BR><HR><A NAME="271"></A><H4>271.
  
Explicit instantiation and template argument deduction
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>20 Feb 2001<BR>




<P>Nicolai Josuttis sent me an example like the following:</P>

<PRE>
    template &lt;typename RET, typename T1, typename T2&gt;
    const RET&amp; min (const T1&amp; a, const T2&amp; b)
    {
	return (a &lt; b ? a : b);
    }
    template const int&amp; min&lt;int&gt;(const int&amp;,const int&amp;);  // #1
    template const int&amp; min(const int&amp;,const int&amp;);       // #2
</PRE>

<P>Among the questions was whether explicit instantiation #2 is valid,
where deduction is required to determine the type of <TT>RET</TT>.</P>

<P>The first thing I realized when researching this is that the standard
does not really spell out the rules for deduction in declarative
contexts (friend declarations, explicit specializations, and
explicit instantiations).  For explicit instantiations,
14.7.2 [temp.explicit] paragraph 2 does
mention deduction, but it doesn't say which set of deduction rules from
14.8.2 [temp.deduct] should be applied.</P>

<P>Second, Nicolai pointed out that
14.7.2 [temp.explicit] paragraph 6 says</P>

<BLOCKQUOTE>
A trailing <I>template-argument</I>
can be left unspecified in an explicit instantiation provided it can
be deduced from the type of a function parameter
(14.8.2 [temp.deduct]).
</BLOCKQUOTE>

<P>This prohibits cases
like #2, but I believe this was not considered in the wording as there
is no reason not to include the return type in the deduction process.</P>

<P>I think there may have been some confusion because the return type is
excluded when doing deduction on a function call.  But there are
contexts where the return type is included in deduction, for example,
when taking the address of a function template specialization.</P>

<P><U>Suggested resolution</U>:</P>

<OL>

<LI>Update 14.8.2 [temp.deduct] to include a section
"Deducing template arguments from a declaration" that describes how
deduction is done when finding a template that matches a declaration.
This should, I believe, include the return type.</LI>

<LI>Update 14.7.2 [temp.explicit] to make reference to the new
rules in 14.8.2 [temp.deduct] and remove the description of
the deduction details from 14.7.2 [temp.explicit] paragraph
6.</LI>

</OL>
<BR><BR><HR><A NAME="297"></A><H4>297.
  
Which template does an explicit specialization specialize?
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Andrei Iltchenko
 &#160;&#160;&#160;

 <B>Date: </B>7 Jul 2001<BR>


<P>Andrei Iltchenko points out that the standard has no wording that
defines how to determine which template is specialized by an
explicit specialization of a function template.
He suggests "template argument deduction
in such cases proceeds in the same way as when taking the address
of a function template,
which is described in 14.8.2.2 [temp.deduct.funcaddr]."</P>

<P>John Spicer points out that the same problem exists for all
similar declarations, i.e., friend declarations and explicit
instantiation directives.  Finding a corresponding placement
<TT>operator delete</TT> may have a similar problem.</P>

<P><U>John Spicer</U>:
There are two aspects of "determining which template" is referred to by
a declaration: determining the function template associated with the
named specialization, and determining the values of the template arguments
of the specialization.</P>
<PRE>
    template &lt;class T&gt; void f(T);  #1
    template &lt;class T&gt; void f(T*); #2
    template &lt;&gt; void f(int*);
</PRE>

<P>In other words, which <TT>f</TT> is being specialized (#1 or #2)?
And then, what are the deduced template arguments?</P>

<P>14.5.6.2 [temp.func.order] does say that partial ordering is
done in contexts such as this.
Is this sufficient, or do we need to say more about the selection of the
function template to be selected? </P>

<P>14.8.2 [temp.deduct] probably needs a new section to cover
argument deduction for cases like this.</P>

<BR><BR><HR><A NAME="697"></A><H4>697.
  
Deduction rules apply to more than functions
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>6 June, 2008<BR>




<P>14.8.2 [temp.deduct] is all about function types, but these
rules also apply, e.g., when matching a class template partial
specialization.  We should add a note stating that we could be doing
substitution into the <I>template-id</I> for a class template partial
specialization.</P>

<P><B>Additional note (August 2008):</B></P>

<P>According to 14.5.5.1 [temp.class.spec.match] paragraph 2, argument
deduction is used to determine whether a given partial specialization
matches a given argument list.  However, there is nothing in
14.5.5.1 [temp.class.spec.match] nor in 14.8.2 [temp.deduct] and
its subsections that describes exactly how argument deduction is to
be performed in this case.  It would seem that more than just a note
is required to clarify this processing.</P>

<BR><BR><HR><A NAME="1227"></A><H4>1227.
  
Mixing immediate and non-immediate contexts in deduction failure
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-11-27<BR>




<P>Consider the following example:</P>

<PRE>
    template &lt;int&gt; struct X {
      typedef int type;
    };
    template &lt;class T&gt; struct Y { };
    template &lt;class T&gt; struct Z {
      static int const value = Y&lt;T&gt;::value;
    };

    template &lt;class T&gt; typename X&lt;Y&lt;T&gt;::value + Z&lt;T&gt;::value&gt;::type f(T);
    int f(...);

    int main() {
      sizeof f(0);
    }
</PRE>

<P>The problem here is that there is a combination of an invalid expression
in the immediate context (<TT>Y&lt;T&gt;::value</TT>) and in the
non-immediate context (within <TT>Z&lt;T&gt;</TT> when evaluating
<TT>Z&lt;T&gt;::value</TT>).  The Standard does not appear to state
clearly whether this program is well-formed (because the error in the
immediate context causes deduction failure) or ill-formed (because of
the error in the non-immediate context).</P>

<BR><BR><HR><A NAME="503"></A><H4>503.
  
Cv-qualified function types in template argument deduction
</H4><B>Section: </B>14.8.2.1&#160; [temp.deduct.call]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>22 Feb 2005<BR>




<P>Consider the following program:</P>

<PRE>
    template &lt;typename T&gt; int ref (T&amp;)                { return 0; }
    template &lt;typename T&gt; int ref (const T&amp;)          { return 1; }
    template &lt;typename T&gt; int ref (const volatile T&amp;) { return 2; }
    template &lt;typename T&gt; int ref (volatile T&amp;)       { return 4; }

    template &lt;typename T&gt; int ptr (T*)                { return 0; }
    template &lt;typename T&gt; int ptr (const T*)          { return 8; }
    template &lt;typename T&gt; int ptr (const volatile T*) { return 16; }
    template &lt;typename T&gt; int ptr (volatile T*)       { return 32; }

    void foo() {}

    int main()
    {
        return ref(foo) + ptr(&amp;foo);
    }
</PRE>

<P>The Standard appears to specify that the value returned from
<TT>main</TT> is 2.  The reason for this result is that references and
pointers are handled differently in template argument deduction.</P>

<P>For the reference case, 14.8.2.1 [temp.deduct.call] paragraph
3 says that &#8220;If <TT>P</TT> is a reference type, the type
referred to by <TT>P</TT> is used for type deduction.&#8221; Because
of <A HREF="
     cwg_defects.html#295">issue 295</A>, all four of the types for the
<TT>ref</TT> function parameters are the same, with no
cv-qualification; overload resolution does not find a best match among
the parameters and thus the most-specialized function is selected.</P>

<P>For the pointer type, argument deduction does not get as far as
forming a cv-qualified function type; instead, argument deduction
fails in the cv-qualified cases because of the cv-qualification
mismatch, and only the cv-unqualified version of <TT>ptr</TT> survives
as a viable function.</P>

<P>I think the choice of ignoring cv-qualifiers in the reference case
but not the pointer case is very troublesome.  The reason is that when
one considers function objects as function parameters, it introduces a
semantic difference whether the function parameter is declared a
reference or a pointer.  In all other contexts, it does not matter: a
function name decays to a pointer and the resulting semantics are the
same.</P>

<BR><BR><HR><A NAME="1221"></A><H4>1221.
  
Partial ordering and reference collapsing
</H4><B>Section: </B>14.8.2.4&#160; [temp.deduct.partial]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2010-11-08<BR>


<P>The current partial ordering rules produce surprising results in
the presence of reference collapsing. </P>

<P>Since partial ordering is currently based solely on the signature
of the function templates, the lack of difference following
substitution of the template type parameter in the following is not
taken into account.</P>

<P>Especially unsettling is that the allegedly "more specialized"
template (#2) is not a candidate in the first call where template
argument deduction fails for it despite a lack of non-deduced
contexts.</P>

<PRE>
    template &lt;typename T&gt;
    void foo(T&amp;&amp;);  // #1

    template &lt;typename T&gt;
    void foo(volatile T&amp;&amp;);  // #2

    int main(void) {
      const int x = 0;
      foo(x);  // calls #1 with T='const int &amp;'
      foo&lt;const int &amp;&gt;(x);  // calls #2
    }
</PRE>

<BR><BR><HR><A NAME="971"></A><H4>971.
  
Incorrect treatment of <I>exception-declaration</I>s
</H4><B>Section: </B>15.3&#160; [except.handle]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>28 September, 2009<BR>


<P>The current wording of 15.3 [except.handle] paragraph 16 is:</P>

<BLOCKQUOTE>

The object declared in an <I>exception-declaration</I> or, if the
<I>exception-declaration</I> does not specify a name, a temporary
(12.2 [class.temporary]) is copy-initialized (8.5 [dcl.init]) from the exception object.  The object shall not have an
abstract class type.  The object is destroyed when the handler exits,
after the destruction of any automatic objects initialized within the
handler.

</BLOCKQUOTE>

<P>There are two problems with this.  First, it's not clear what it
means for the handler's &#8220;parameter&#8221; to be a temporary.
This possibility is briefly mentioned in 12.2 [class.temporary],
but the lifetime of such a temporary is not defined there; the
discussion of lifetime is restricted to those temporaries that arise
during the evaluation of an expression, and this is not such a case.</P>

<P>Second, this wording assumes that there will be an object to be
destroyed and thus ignores the possibility that the
<I>exception-declaration</I> declares a reference.</P>

<BR><BR><HR><A NAME="1166"></A><H4>1166.
  
<I>exception-declaration</I>s that do not declare objects
</H4><B>Section: </B>15.3&#160; [except.handle]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-03<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#GB45">N3092 comment
  GB&#160;45<BR></A>

<P>According to 15.3 [except.handle] paragraph 16,</P>

<BLOCKQUOTE>

The object declared in an <I>exception-declaration</I> or, if the
<I>exception-declaration</I> does not specify a name, a
temporary (12.2 [class.temporary]) is copy-initialized
(8.5 [dcl.init]) from the exception object.  The
object shall not have an abstract class type.  The object is
destroyed when the handler exits, after the destruction of
any automatic objects initialized within the handler.

</BLOCKQUOTE>

<P>This wording leaves unspecified how an <I>exception-declaration</I>
that is a reference should be treated.  For example, presumably a
reference to an abstract class type should be permitted, but that is
not specified.  The treatment of ellipsis is also not clearly
addressed.</P>

<BR><BR><HR><A NAME="92"></A><H4>92.
  
Should exception specifications be part of the type system?
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jonathan Schilling
 &#160;&#160;&#160;

 <B>Date: </B>2 Feb 1999<BR>


    
<P>It was tentatively agreed at the Santa Cruz meeting
that exception specifications
should fully participate in the type system.  This change would
address gaps in the current static checking of exception specifications
such as</P>

<PRE>
    void (*p)() throw(int);
    void (**pp)() throw() = &amp;p;   // not currently an error
</PRE>
    
<P>This is such a major change that it deserves to be a separate
issue.</P>

<P>See also issues <A HREF="
     cwg_defects.html#25">25</A>,
<A HREF="
     cwg_defects.html#87">87</A>, and
<A HREF="
     cwg_closed.html#133">133</A>.</P>
<BR><BR><HR><A NAME="595"></A><H4>595.
  
Exception specifications in templates instantiated from class bodies
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>7 September 2006<BR>


<P>A type used in an exception specification must be complete
(15.4 [except.spec] paragraph 2).  The resolution of
<A HREF="
     cwg_defects.html#437">issue 437</A> stated that a class type
appearing in an exception specification inside its own
<I>member-specification</I> is considered to be complete.  Should
this also apply to exception specifications in class templates
instantiated because of a reference inside
the <I>member-specification</I> of a class?  For example,</P>

<PRE>
    template&lt;class T&gt; struct X {
        void f() throw(T) {}
    };

    struct S {
        X&lt;S&gt; xs;
    };
</PRE>

<BR><BR><HR><A NAME="219"></A><H4>219.
  
Cannot defend against destructors that throw exceptions
</H4><B>Section: </B>15.5.1&#160; [except.terminate]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Herb Sutter
 &#160;&#160;&#160;

 <B>Date: </B>31 Mar 2000<BR>




<P>Destructors that throw can easily cause programs to terminate,
with no possible defense.  Example: Given</P>

<PRE>
    struct XY { X x; Y y; };
</PRE>

<P>Assume that <TT>X::~X()</TT> is the only destructor in the entire
program that can throw. Assume further that <TT>Y</TT> construction is
the only other operation in the whole program that can throw. Then
<TT>XY</TT> cannot be used safely, in any context whatsoever, period
&#8212; even simply declaring an <TT>XY</TT> object can crash the
program:</P>

<PRE>
    XY xy; // construction attempt might terminate program:
	   //   1. construct x -- succeeds
	   //   2. construct y -- fails, throws exception
	   //   3. clean up by destroying x -- fails, throws exception,
	   //      but an exception is already active, so call 
	   //      std::terminate() (oops)
	   // there is no defense
</PRE>

So it is highly dangerous to have even one destructor that could throw.

<P>Suggested Resolution:</P>

<P>Fix the above problem in one of the following two ways. I prefer
the first.</P>

<OL>

<LI>We already have text that specifies that any destructor operation in 
the standard library (presumably including the destructors of UDTs used in 
containers or as predicates, etc.) may not throw. There is good reason to 
widen this injunction to specify that destructors may never throw at all.
(I realize this would render existing programs nonconforming if they did
do this, but it's unsafe anyway.)</LI>

<LI>Specify what happens in the above case so that
<TT>std::terminate()</TT> won't be called.</LI>

</OL>

<P><U>Fergus Henderson</U>: I disagree.  Code using <TT>XY</TT> may
well be safe, if <TT>X::~X()</TT> only throws if
<TT>std::uncaught_exception()</TT> is <TT>false</TT>.</P>

<P>I think the current exception handling scheme in C++ is certainly
flawed, but the flaws are IMHO design flaws, not minor technical
defects, and I don't think they can be solved by minor tweaks to the
existing design.  I think that at this point it is probably better to
keep the standard stable, and learn to live with the existing flaws,
rather than trying to solve them via TC.</P>

<P><U>Bjarne Stroustrup</U>: I strongly prefer to have the call to
<TT>std::terminate()</TT> be conforming. I see <TT>std::terminate()</TT> as a
proper way to blow away "the current mess" and get to the next level
of error handling. I do not want that escape to be non-conforming
&#8212; that would imply that programs relying on a error handling
based on serious errors being handled by terminating a process (which
happens to be a C++ program) in <TT>std::terminate()</TT> becomes
non-conforming. In many systems, there are &#8212; and/or should be
&#8212; error-handling and recovery mechanisms beyond what is offered
by a single C++ program.</P>

<P><U>Andy Koenig</U>: If we were to prohibit writing a destructor
that can throw, how would I solve the following problem?</P>

<P>I want to write a class that does buffered output.  Among the
other properties of that class is that destroying an object of
that class writes the last buffer on the output device before
freeing memory.</P>

<P>What should my class do if writing that last buffer indicates a
hardware output error?  My user had the option to flush the last
buffer explicitly before destroying the object, but didn't do so, and
therefore did not anticipate such a problem.  Unfortunately, the
problem happened anyway.  Should I be required to suppress this
error indication anyway?  In all cases?</P>

<P><U>Herb Sutter</U> (June, 2007): IMO, it's fine to suppress
it.  The user had the option of flushing the buffer and thus
being notified of the problem and chose not to use it.  If the
caller didn't flush, then likely the caller isn't ready for an
exception from the destructor, either.  You could also put an
assert into the destructor that would trigger if <TT>flush()</TT>
had not been called, to force callers to use the interface that
would report the error.  
</P>

<P>In practice, I would rather thrown an exception, even at the risk
of crashing the program if we happen to be in the middle of stack
unwinding.  The reason is that the program would crash only if a
hardware error occurred in the middle of cleaning up from some other
error that was in the process of being handled.  I would rather have
such a bizarre coincidence cause a crash, which stands a chance of
being diagnosed later, than to be ignored entirely and leave the
system in a state where the ignore error could cause other trouble
later that is even harder to diagnose.</P>

<P>If I'm not allowed to throw an exception when I detect this problem,
what are my options?</P>

<P><U>Herb Sutter</U>: I understand that some people might feel that
"a failed dtor during stack unwinding is preferable in certain cases"
(e.g., when recovery can be done beyond the scope of the program), but
the problem is "says who?"  It is the application program that should
be able to decide whether or not such semantics are correct for it,
and the problem here is that with the status quo a program cannot
defend itself against a <TT>std::terminate()</TT> &#8212; period. The
lower-level code makes the decision for everyone. In the original
example, the mere existence of an <TT>XY</TT> object puts at risk
every program that uses it, whether <TT>std::terminate()</TT> makes sense
for that program or not, and there is no way for a program to protect
itself.</P>

<P>That the "it's okay if the process goes south should a rare
combination of things happen" decision should be made by lower-level
code (e.g., <TT>X</TT> dtor) for all apps that use it, and which
doesn't even understand the context of any of the hundreds of apps
that use it, just cannot be correct.</P>

<BR><BR><HR><A NAME="596"></A><H4>596.
  
Replacing an exception object
</H4><B>Section: </B>15.5.2&#160; [except.unexpected]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>12 September 2006<BR>


<P>When a function throws an exception that is not in its
<I>exception-specification</I>, <TT>std::unexpected()</TT> is called.
According to 15.5.2 [except.unexpected] paragraph 2,</P>

<BLOCKQUOTE>

If [<TT>std::unexpected()</TT>] throws or rethrows an exception that
the <I>exception-specification</I> does not allow then the following
happens: If the <I>exception-specification</I> does not include the class
<TT>std::bad_exception</TT> (18.8.2 [bad.exception]) then
the function <TT>std::terminate()</TT> is called, otherwise the thrown
exception is replaced by an implementation-defined object of the type
<TT>std::bad_exception,</TT> and the search for another handler will
continue at the call of the function
whose <I>exception-specification</I> was violated.

</BLOCKQUOTE>

<P>The &#8220;replaced by&#8221; wording is imprecise and undefined.
For example, does this mean that the destructor is called for the
existing exception object, or is it simply abandoned?  Is the
replacement <I>in situ</I>, so that a pointer to the existing
exception object will now point to the <TT>std::bad_exception</TT>
object?</P>

<P><U>Mike Miller</U>: The call to <TT>std::unexpected()</TT> is
not described as analogous to invoking a handler, but if it were,
that would resolve this question; it is clearly specified what
happens to the previous exception object when a new exception is
thrown from a handler (15.1 [except.throw] paragraph 4).</P>

<P>This approach would also clarify other questions that have been
raised regarding the requirements for stack unwinding.  For
example, 15.5.1 [except.terminate] paragraph 2 says that</P>

<BLOCKQUOTE>

In the situation where no matching handler is found, it is
implementation-defined whether or not the stack is unwound before
<TT>std::terminate()</TT> is called.

</BLOCKQUOTE>

<P>This requirement could be viewed as in conflict with the statement
in 15.5.2 [except.unexpected] paragraph 1 that</P>

<BLOCKQUOTE>

If a function with an <I>exception-specification</I> throws an exception that
is not listed in the <I>exception-specification</I>, the function
<TT>std::unexpected()</TT> is called (D.13 [exception.unexpected])
immediately after completing the stack unwinding for the former
function.

</BLOCKQUOTE>

<P>If it is implementation-defined whether stack unwinding occurs before
calling <TT>std::terminate()</TT> and <TT>std::unexpected()</TT> is
called only after doing stack unwinding, does that mean that it is
implementation-defined whether <TT>std::unexpected()</TT> is called
if there is ultimately no handler found?</P>

<P>Again, if invoking <TT>std::unexpected()</TT> were viewed as
essentially invoking a handler, the answer to this would be clear,
because unwinding occurs before invoking a handler.</P>

<BR><BR><HR><A NAME="925"></A><H4>925.
  
Type of character literals in preprocessor expressions
</H4><B>Section: </B>16.1&#160; [cpp.cond]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>29 June, 2009<BR>


<P>According to 16.1 [cpp.cond] paragraph 4,</P>

<BLOCKQUOTE>

The resulting tokens comprise the controlling constant expression
which is evaluated according to the rules of 5.19 [expr.const]
using arithmetic that has at least the ranges specified in
18.3 [support.limits], except that all signed and unsigned integer
types act as if they have the same representation as, respectively,
<TT>intmax_t</TT> or <TT>uintmax_t</TT> (_N3035_.18.4.2 [stdinth]).
This includes interpreting character literals, which may involve
converting escape sequences into execution character set members.

</BLOCKQUOTE>

<P>Ordinary character literals with a single <I>c-char</I> have the
type <TT>char</TT>, which is neither a signed nor an unsigned integer
type. Although 4.5 [conv.prom] paragraph 1 is clear that
<TT>char</TT> values promote to <TT>int</TT>, regardless of whether
the implementation treats <TT>char</TT> as having the values of
<TT>signed char</TT> or <TT>unsigned char</TT>, 16.1 [cpp.cond] paragraph 4 isn't clear on whether character literals
should be treated as signed or unsigned values.  In C99, such
literals have type <TT>int</TT>, so the question does not arise.
If an implementation in which plain <TT>char</TT> has the values of
<TT>unsigned char</TT> were to treat character literals as unsigned,
an expression like <TT>'0'-'1'</TT> would thus have different values
in C and C++, namely -1 in C and some large unsigned value in C++.</P>

<BR><BR><HR><A NAME="268"></A><H4>268.
  
Macro name suppression in rescanned replacement text
</H4><B>Section: </B>16.3.4&#160; [cpp.rescan]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Bjarne Stroustrup
 &#160;&#160;&#160;

 <B>Date: </B>18 Jan 2001<BR>




<P>It is not clear from the Standard what the result of the
following example should be:</P>

<BLOCKQUOTE>
<PRE>
#define NIL(xxx) xxx
#define G_0(arg) NIL(G_1)(arg)
#define G_1(arg) NIL(arg)
G_0(42)
</PRE>
</BLOCKQUOTE>

<P>The relevant text from the Standard is found in
16.3.4 [cpp.rescan] paragraph 2:</P>

<BLOCKQUOTE>

If the name of the macro being replaced is found during this scan of
the replacement list (not including the rest of the source file's
preprocessing tokens), it is not replaced. Further, if any nested
replacements encounter the name of the macro being replaced, it is not
replaced. These nonreplaced macro name preprocessing tokens are no
longer available for further replacement even if they are later
(re)examined in contexts in which that macro name preprocessing token
would otherwise have been replaced.

</BLOCKQUOTE>

<P>The sequence of expansion of <TT>G0(42)</TT> is as follows:</P>

<BLOCKQUOTE>
<PRE>
G0(42)
NIL(G_1)(42)
G_1(42)
NIL(42)
</PRE>
</BLOCKQUOTE>

<P>The question is whether the use of <TT>NIL</TT> in the last
line of this sequence qualifies for non-replacement under the
cited text.  If it does, the result will be <TT>NIL(42)</TT>.  If
it does not, the result will be simply <TT>42</TT>.</P>

<P>The original intent of the J11 committee in this text was
that the result should be <TT>42</TT>, as demonstrated by the
original pseudo-code description of the replacement algorithm
provided by Dave Prosser, its author.

The English description,
however, omits some of the subtleties of the pseudo-code and
thus arguably gives an incorrect answer for this case.</P>

<P><U>Suggested resolution (Mike Miller)</U>: Replace the cited
paragraph with the following:</P>

<BLOCKQUOTE>

<P>As long as the scan involves only preprocessing tokens from
a given macro's replacement list, or tokens resulting from a
replacement of those tokens, an occurrence of the macro's name
will not result in further replacement, even if it is later
(re)examined in contexts in which that macro name preprocessing
token would otherwise have been replaced.</P>

<P>Once the scan reaches the preprocessing token following a
macro's replacement list &#8212; including as part of the
argument list for that or another macro &#8212; the macro's
name is once again available for replacement.  [<I>Example:</I></P>

<PRE>
    #define NIL(xxx) xxx
    #define G_0(arg) NIL(G_1)(arg)
    #define G_1(arg) NIL(arg)
    G_0(42)                         // result is 42, not NIL(42)
</PRE>

<P>The reason that <TT>NIL(42)</TT> is replaced is that <TT>(42)</TT>
comes from outside the replacement list of <TT>NIL(G_1)</TT>, hence
the occurrence of <TT>NIL</TT> within the replacement list for
<TT>NIL(G_1)</TT> (via the replacement of <TT>G_1(42)</TT>) is not
marked as nonreplaceable.  <I>&#8212;end example</I>]</P>

</BLOCKQUOTE>

<P>(Note: The resolution of this issue must be coordinated with
J11/WG14.)</P>

<P><B>Notes (via Tom Plum) from April, 2004 WG14 Meeting:</B></P>

<P>Back in the 1980's it was understood by several WG14 people
that there were tiny differences between the "non-replacement"
verbiage and the attempts to produce pseudo-code.  The
committee's decision was that no realistic programs "in the wild"
would venture into this area, and trying to reduce the
uncertainties is not worth the risk of changing conformance
status of implementations or programs.</P>

<BR><BR><HR><A NAME="745"></A><H4>745.
  
Effect of ill-formedness resulting from <TT>#error</TT>
</H4><B>Section: </B>16.5&#160; [cpp.error]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Clark Nelson
 &#160;&#160;&#160;

 <B>Date: </B>13 November, 2008<BR>


<P>C99 is very clear that a <TT>#error</TT> directive causes a translation
to fail: Clause 4 paragraph 4 says,</P>

<BLOCKQUOTE>

The implementation shall not successfully translate a preprocessing
translation unit containing a <TT>#error</TT> preprocessing directive
unless it is part of a group skipped by conditional inclusion.

</BLOCKQUOTE>

<P>C++, on the other hand, simply says that a <TT>#error</TT> directive
&#8220;renders the program ill-formed&#8221; (16.5 [cpp.error]),
and the only requirement for an ill-formed program is that a diagnostic
be issued; the translation may continue and succeed.  (Noted in passing:
if this difference between C99 and C++ is addressed, it would be helpful
for synchronization purposes in other contexts as well to introduce the
term &#8220;preprocessing translation unit.&#8221;)</P>

<BR><BR><HR><A NAME="897"></A><H4>897.
  
<TT>_Pragma</TT> and extended <I>string-literal</I>s
</H4><B>Section: </B>16.9&#160; [cpp.pragma.op]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>9 May, 2009<BR>




<P>The specification of how the <I>string-literal</I> in a <TT>_Pragma</TT>
operator is handled does not deal with the new kinds of string literals.
16.9 [cpp.pragma.op] says,</P>

<BLOCKQUOTE>

The string literal is <I>destringized</I> by deleting the <TT>L</TT>
prefix, if present, deleting the leading and trailing double-quotes,
replacing each escape sequence...

</BLOCKQUOTE>

<P>The various other prefixes should either be handled or prohibited.</P>

<BR><BR><HR><A NAME="223"></A><H4>223.
  
The meaning of deprecation
</H4><B>Section: </B>D&#160; [depr]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>19 Apr 2000<BR>


<P>During the discussion of issues <A HREF="
     cwg_closed.html#167">167</A> and
<A HREF="
     cwg_closed.html#174">174</A>, it became apparent that there was no
consensus on the meaning of deprecation.  Some thought that
deprecating a feature reflected an intent to remove it from
the language.  Others viewed it more as an encouragement to
programmers not to use certain constructs, even though they might be
supported in perpetuity.</P>

<P>There is a formal-sounding definition of deprecation in Annex
D [depr] paragraph 2:

<BLOCKQUOTE>

deprecated is defined as: Normative for the current edition of the
Standard, but not guaranteed to be part of the Standard in future
revisions.

</BLOCKQUOTE>

However, this definition would appear to say that any
non-deprecated feature <I>is</I> "guaranteed to be part of the
Standard in future revisions."  It's not clear that that implication
was intended, so this definition may need to be amended.
</P>

<P>This issue is intended to provide an avenue for discussing and
resolving those questions, after which the original issues may be
reopened if that is deemed desirable.</P>
<BR><BR><BR><BR></BODY>
</HTML>
