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

    C++ Standard Core Language
    
      Active Issues
     </TITLE>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<STYLE TYPE="text/css">
  INS { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  .INS { text-decoration:none; background-color:#D0FFD0 }
  DEL { text-decoration:line-through; background-color:#FFA0A0 }
  .DEL { text-decoration:line-through; background-color: #FFD0D0 }
  @media (prefers-color-scheme: dark) {
    HTML { background-color:#202020; color:#f0f0f0; }
    A { color:#5bc0ff; }
    A:visited { color:#c6a8ff; }
    A:hover, a:focus { color:#afd7ff; }
    INS { background-color:#033a16; color:#aff5b4; }
    .INS { background-color: #033a16; }
    DEL { background-color:#67060c; color:#ffdcd7; }
    .DEL { background-color:#67060c; }
  }
  SPAN.cmnt { font-family:Times; font-style:italic }
</STYLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2025-09-12</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 14882:2024
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reply to:
     </TD>
<TD>
      &#160;Jens Maurer
     </TD>
</TR>
<TR>
<TD></TD>
<TD>
      &#160;<A HREF="mailto://jens.maurer@gmx.net">jens.maurer@gmx.net</A>
</TD>
</TR>
</TABLE>
<BR CLEAR="ALL"><BR><CENTER><H2>

     C++ Standard Core Language
     
       Active Issues,
      

     Revision
     118</H2></CENTER>
<BR><P>
      This document contains the C++ core language issues on which the
      Committee (INCITS PL22.16 + WG21) has not yet acted, that is, issues
      with status
      "<A HREF="#Ready%20Status">Ready</A>,"
      "<A HREF="#Tentatively%20Ready%20Status">Tentatively Ready</A>,"
      "<A HREF="#Review%20Status">Review</A>,"
      "<A HREF="#Drafting%20Status">Drafting</A>," and
      "<A HREF="#Open%20Status">Open</A>."
     (See <A HREF="#Issue%20Status">Issue Status</A> below.)
     </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, as well as other issues accepted by the Committee, 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/2025/n5014.pdf">WG21 N5014</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:2024 document and corrected defects in the earlier
2020, 2017, 2014, 2011, 2003, and 1998 documents; others refer to
text in the working draft for the next revision of the C++
language 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.</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:2024, and be
submitted to the InterNational Committee for Information Technology Standards
(INCITS),
700&#160;K&#160;Street&#160;NW, Suite 600, Washington,&#160;DC&#160;20001,
USA.</P>

<P>Information regarding C++ standardization can be found at
<A HREF="http://isocpp.org/std">http://isocpp.org/std</A>.</P>

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

<UL>

<P><B>Revision 118, 2025-09-12:</B></P>

<P>Added new issues
<A HREF="cwg_active.html#3022">3022</A>,
<A HREF="cwg_active.html#3023">3023</A>,
<A HREF="cwg_active.html#3024">3024</A>,
<A HREF="cwg_active.html#3025">3025</A>,
<A HREF="cwg_active.html#3026">3026</A>,
<A HREF="cwg_active.html#3027">3027</A>,
<A HREF="cwg_active.html#3028">3028</A>,
<A HREF="cwg_active.html#3029">3029</A>,
<A HREF="cwg_active.html#3030">3030</A>,
<A HREF="cwg_active.html#3031">3031</A>,
<A HREF="cwg_active.html#3032">3032</A>,
<A HREF="cwg_active.html#3033">3033</A>,
<A HREF="cwg_active.html#3034">3034</A>,
<A HREF="cwg_active.html#3035">3035</A>,
<A HREF="cwg_active.html#3036">3036</A>,
<A HREF="cwg_active.html#3037">3037</A>,
<A HREF="cwg_active.html#3038">3038</A>,
<A HREF="cwg_active.html#3039">3039</A>,
<A HREF="cwg_active.html#3040">3040</A>,
<A HREF="cwg_active.html#3041">3041</A>,
<A HREF="cwg_active.html#3042">3042</A>,
<A HREF="cwg_active.html#3043">3043</A>,
<A HREF="cwg_active.html#3044">3044</A>,
<A HREF="cwg_active.html#3045">3045</A>,
<A HREF="cwg_active.html#3046">3046</A>,
<A HREF="cwg_active.html#3047">3047</A>,
<A HREF="cwg_active.html#3048">3048</A>,
<A HREF="cwg_active.html#3049">3049</A>,
<A HREF="cwg_active.html#3050">3050</A>,
<A HREF="cwg_active.html#3051">3051</A>,
<A HREF="cwg_active.html#3052">3052</A>,
<A HREF="cwg_active.html#3053">3053</A>,
<A HREF="cwg_active.html#3054">3054</A>,
<A HREF="cwg_active.html#3055">3055</A>,
<A HREF="cwg_active.html#3056">3056</A>,
<A HREF="cwg_active.html#3057">3057</A>,
<A HREF="cwg_active.html#3058">3058</A>,
<A HREF="cwg_active.html#3059">3059</A>,
<A HREF="cwg_active.html#3060">3060</A>,
<A HREF="cwg_active.html#3061">3061</A>,
<A HREF="cwg_active.html#3062">3062</A>, and
<A HREF="cwg_active.html#3063">3063</A>.
Reflected the decisions of the June, 2025 plenary meeting.
Reflected the deliberations of the teleconferences up to 2025-06-06.
</P>

<P><B>Revision 117, 2025-04-13:</B></P>

<P>Added new issues
<A HREF="cwg_active.html#2971">2971</A>,
<A HREF="cwg_active.html#2972">2972</A>,
<A HREF="cwg_active.html#2973">2973</A>,
<A HREF="cwg_active.html#2974">2974</A>,
<A HREF="cwg_active.html#2975">2975</A>,
<A HREF="cwg_active.html#2976">2976</A>,
<A HREF="cwg_active.html#2977">2977</A>,
<A HREF="cwg_active.html#2978">2978</A>,
<A HREF="cwg_active.html#2979">2979</A>,
<A HREF="cwg_active.html#2980">2980</A>,
<A HREF="cwg_active.html#2981">2981</A>,
<A HREF="cwg_defects.html#2982">2982</A>,
<A HREF="cwg_active.html#2983">2983</A>,
<A HREF="cwg_active.html#2984">2984</A>,
<A HREF="cwg_defects.html#2985">2985</A>,
<A HREF="cwg_active.html#2986">2986</A>,
<A HREF="cwg_defects.html#2987">2987</A>,
<A HREF="cwg_active.html#2988">2988</A>,
<A HREF="cwg_active.html#2989">2989</A>,
<A HREF="cwg_defects.html#2990">2990</A>,
<A HREF="cwg_active.html#2991">2991</A>,
<A HREF="cwg_active.html#2992">2992</A>,
<A HREF="cwg_active.html#2993">2993</A>,
<A HREF="cwg_active.html#2994">2994</A>,
<A HREF="cwg_active.html#2995">2995</A>,
<A HREF="cwg_active.html#2996">2996</A>,
<A HREF="cwg_active.html#2997">2997</A>,
<A HREF="cwg_active.html#2998">2998</A>,
<A HREF="cwg_active.html#2999">2999</A>,
<A HREF="cwg_active.html#3000">3000</A>,
<A HREF="cwg_active.html#3001">3001</A>,
<A HREF="cwg_active.html#3002">3002</A>,
<A HREF="cwg_active.html#3003">3003</A>,
<A HREF="cwg_active.html#3004">3004</A>,
<A HREF="cwg_active.html#3005">3005</A>,
<A HREF="cwg_active.html#3006">3006</A>,
<A HREF="cwg_active.html#3007">3007</A>,
<A HREF="cwg_active.html#3008">3008</A>,
<A HREF="cwg_active.html#3009">3009</A>,
<A HREF="cwg_active.html#3010">3010</A>,
<A HREF="cwg_active.html#3011">3011</A>,
<A HREF="cwg_active.html#3012">3012</A>,
<A HREF="cwg_defects.html#3013">3013</A>,
<A HREF="cwg_defects.html#3014">3014</A>,
<A HREF="cwg_defects.html#3015">3015</A>,
<A HREF="cwg_defects.html#3016">3016</A>,
<A HREF="cwg_active.html#3017">3017</A>,
<A HREF="cwg_defects.html#3018">3018</A>,
<A HREF="cwg_active.html#3019">3019</A>,
<A HREF="cwg_defects.html#3020">3020</A>, and
<A HREF="cwg_active.html#3021">3021</A>.
Reflected the decisions of the February, 2025 plenary meeting.
Reflected the deliberations of the teleconferences up to 2025-04-11.
</P>

<P><B>Revision 116, 2024-12-19:</B></P>

<P>Added new issues
<A HREF="cwg_defects.html#2913">2913</A>,
<A HREF="cwg_active.html#2914">2914</A>,
<A HREF="cwg_defects.html#2915">2915</A>,
<A HREF="cwg_active.html#2916">2916</A>,
<A HREF="cwg_active.html#2917">2917</A>,
<A HREF="cwg_defects.html#2918">2918</A>,
<A HREF="cwg_defects.html#2919">2919</A>,
<A HREF="cwg_active.html#2920">2920</A>,
<A HREF="cwg_defects.html#2921">2921</A>,
<A HREF="cwg_defects.html#2922">2922</A>,
<A HREF="cwg_active.html#2923">2923</A>,
<A HREF="cwg_defects.html#2924">2924</A>,
<A HREF="cwg_closed.html#2925">2925</A>,
<A HREF="cwg_active.html#2926">2926</A>,
<A HREF="cwg_defects.html#2927">2927</A>,
<A HREF="cwg_active.html#2928">2928</A>,
<A HREF="cwg_active.html#2929">2929</A>,
<A HREF="cwg_defects.html#2930">2930</A>,
<A HREF="cwg_defects.html#2931">2931</A>,
<A HREF="cwg_active.html#2932">2932</A>,
<A HREF="cwg_defects.html#2933">2933</A>,
<A HREF="cwg_active.html#2934">2934</A>,
<A HREF="cwg_active.html#2935">2935</A>,
<A HREF="cwg_defects.html#2936">2936</A>,
<A HREF="cwg_defects.html#2937">2937</A>,
<A HREF="cwg_active.html#2938">2938</A>,
<A HREF="cwg_defects.html#2939">2939</A>,
<A HREF="cwg_active.html#2940">2940</A>,
<A HREF="cwg_active.html#2941">2941</A>,
<A HREF="cwg_active.html#2942">2942</A>,
<A HREF="cwg_defects.html#2943">2943</A>,
<A HREF="cwg_defects.html#2944">2944</A>,
<A HREF="cwg_active.html#2945">2945</A>,
<A HREF="cwg_active.html#2946">2946</A>,
<A HREF="cwg_active.html#2947">2947</A>,
<A HREF="cwg_active.html#2948">2948</A>,
<A HREF="cwg_active.html#2949">2949</A>,
<A HREF="cwg_active.html#2950">2950</A>,
<A HREF="cwg_active.html#2951">2951</A>,
<A HREF="cwg_active.html#2952">2952</A>,
<A HREF="cwg_active.html#2953">2953</A>,
<A HREF="cwg_closed.html#2954">2954</A>,
<A HREF="cwg_active.html#2955">2955</A>,
<A HREF="cwg_active.html#2956">2956</A>,
<A HREF="cwg_active.html#2957">2957</A>,
<A HREF="cwg_active.html#2958">2958</A>,
<A HREF="cwg_active.html#2959">2959</A>,
<A HREF="cwg_active.html#2960">2960</A>,
<A HREF="cwg_active.html#2961">2961</A>,
<A HREF="cwg_active.html#2962">2962</A>,
<A HREF="cwg_active.html#2963">2963</A>,
<A HREF="cwg_active.html#2964">2964</A>,
<A HREF="cwg_active.html#2965">2965</A>,
<A HREF="cwg_active.html#2966">2966</A>,
<A HREF="cwg_active.html#2967">2967</A>,
<A HREF="cwg_active.html#2968">2968</A>,
<A HREF="cwg_active.html#2969">2969</A>, and
<A HREF="cwg_defects.html#2970">2970</A>.
Reflected the decisions of the November, 2024 plenary meeting.
Reflected the deliberations of the teleconferences up to 2024-12-13.
</P>

<P><B>Revision 115, 2024-07-20:</B></P>

<P>Added new issues
<A HREF="cwg_defects.html#2880">2880</A>,
<A HREF="cwg_defects.html#2881">2881</A>,
<A HREF="cwg_defects.html#2882">2882</A>,
<A HREF="cwg_defects.html#2883">2883</A>,
<A HREF="cwg_closed.html#2884">2884</A>,
<A HREF="cwg_active.html#2885">2885</A>,
<A HREF="cwg_defects.html#2886">2886</A>,
<A HREF="cwg_defects.html#2887">2887</A>,
<A HREF="cwg_active.html#2888">2888</A>,
<A HREF="cwg_active.html#2889">2889</A>,
<A HREF="cwg_defects.html#2890">2890</A>,
<A HREF="cwg_defects.html#2891">2891</A>,
<A HREF="cwg_defects.html#2892">2892</A>,
<A HREF="cwg_closed.html#2893">2893</A>,
<A HREF="cwg_defects.html#2894">2894</A>,
<A HREF="cwg_defects.html#2895">2895</A>,
<A HREF="cwg_active.html#2896">2896</A>,
<A HREF="cwg_active.html#2897">2897</A>,
<A HREF="cwg_defects.html#2898">2898</A>,
<A HREF="cwg_defects.html#2899">2899</A>,
<A HREF="cwg_active.html#2900">2900</A>,
<A HREF="cwg_defects.html#2901">2901</A>,
<A HREF="cwg_active.html#2902">2902</A>,
<A HREF="cwg_active.html#2903">2903</A>,
<A HREF="cwg_active.html#2904">2904</A>,
<A HREF="cwg_defects.html#2905">2905</A>,
<A HREF="cwg_defects.html#2906">2906</A>,
<A HREF="cwg_defects.html#2907">2907</A>,
<A HREF="cwg_defects.html#2908">2908</A>,
<A HREF="cwg_defects.html#2909">2909</A>,
<A HREF="cwg_defects.html#2910">2910</A>,
<A HREF="cwg_defects.html#2911">2911</A>, and
<A HREF="cwg_active.html#2912">2912</A>.
Reflected the decisions of the June, 2024 plenary meeting.
Reflected the deliberations of the teleconferences up to 2024-06-14.
</P>

<P><B>Revision 114, 2024-04-18:</B></P>

<P>Added new issues
<A HREF="cwg_active.html#2842">2842</A>,
<A HREF="cwg_defects.html#2843">2843</A>,
<A HREF="cwg_active.html#2844">2844</A>,
<A HREF="cwg_defects.html#2845">2845</A>,
<A HREF="cwg_defects.html#2846">2846</A>,
<A HREF="cwg_active.html#2847">2847</A>,
<A HREF="cwg_defects.html#2848">2848</A>,
<A HREF="cwg_defects.html#2849">2849</A>,
<A HREF="cwg_defects.html#2850">2850</A>,
<A HREF="cwg_defects.html#2851">2851</A>,
<A HREF="cwg_active.html#2852">2852</A>,
<A HREF="cwg_defects.html#2853">2853</A>,
<A HREF="cwg_defects.html#2854">2854</A>,
<A HREF="cwg_defects.html#2855">2855</A>,
<A HREF="cwg_defects.html#2856">2856</A>,
<A HREF="cwg_defects.html#2857">2857</A>,
<A HREF="cwg_defects.html#2858">2858</A>,
<A HREF="cwg_defects.html#2859">2859</A>,
<A HREF="cwg_closed.html#2860">2860</A>,
<A HREF="cwg_defects.html#2861">2861</A>,
<A HREF="cwg_active.html#2862">2862</A>,
<A HREF="cwg_active.html#2863">2863</A>,
<A HREF="cwg_defects.html#2864">2864</A>,
<A HREF="cwg_defects.html#2865">2865</A>,
<A HREF="cwg_active.html#2866">2866</A>,
<A HREF="cwg_defects.html#2867">2867</A>,
<A HREF="cwg_active.html#2868">2868</A>,
<A HREF="cwg_defects.html#2869">2869</A>,
<A HREF="cwg_defects.html#2870">2870</A>,
<A HREF="cwg_defects.html#2871">2871</A>,
<A HREF="cwg_defects.html#2872">2872</A>,
<A HREF="cwg_active.html#2873">2873</A>,
<A HREF="cwg_defects.html#2874">2874</A>,
<A HREF="cwg_active.html#2875">2875</A>,
<A HREF="cwg_defects.html#2876">2876</A>,
<A HREF="cwg_defects.html#2877">2877</A>,
<A HREF="cwg_active.html#2878">2878</A>, and
<A HREF="cwg_defects.html#2879">2879</A>.
Reflected the decisions of the March, 2024 plenary meeting.
Reflected the deliberations of the teleconferences up to 2024-04-05.
</P>

<P><B>Revision 113, 2023-12-19:</B></P>

<P>Added new issues
<A HREF="cwg_active.html#2781">2781</A>,
<A HREF="cwg_active.html#2782">2782</A>,
<A HREF="cwg_defects.html#2783">2783</A>,
<A HREF="cwg_active.html#2784">2784</A>,
<A HREF="cwg_defects.html#2785">2785</A>,
<A HREF="cwg_active.html#2786">2786</A>,
<A HREF="cwg_active.html#2787">2787</A>,
<A HREF="cwg_active.html#2788">2788</A>,
<A HREF="cwg_defects.html#2789">2789</A>,
<A HREF="cwg_active.html#2790">2790</A>,
<A HREF="cwg_defects.html#2791">2791</A>,
<A HREF="cwg_defects.html#2792">2792</A>,
<A HREF="cwg_defects.html#2793">2793</A>,
<A HREF="cwg_active.html#2794">2794</A>,
<A HREF="cwg_defects.html#2795">2795</A>,
<A HREF="cwg_defects.html#2796">2796</A>,
<A HREF="cwg_active.html#2797">2797</A>,
<A HREF="cwg_defects.html#2798">2798</A>,
<A HREF="cwg_active.html#2799">2799</A>,
<A HREF="cwg_active.html#2800">2800</A>,
<A HREF="cwg_defects.html#2801">2801</A>,
<A HREF="cwg_active.html#2802">2802</A>,
<A HREF="cwg_defects.html#2803">2803</A>,
<A HREF="cwg_active.html#2804">2804</A>,
<A HREF="cwg_active.html#2805">2805</A>,
<A HREF="cwg_defects.html#2806">2806</A>,
<A HREF="cwg_defects.html#2807">2807</A>,
<A HREF="cwg_active.html#2808">2808</A>,
<A HREF="cwg_defects.html#2809">2809</A>,
<A HREF="cwg_defects.html#2810">2810</A>,
<A HREF="cwg_defects.html#2811">2811</A>,
<A HREF="cwg_active.html#2812">2812</A>,
<A HREF="cwg_defects.html#2813">2813</A>,
<A HREF="cwg_closed.html#2814">2814</A>,
<A HREF="cwg_defects.html#2815">2815</A>,
<A HREF="cwg_active.html#2816">2816</A>,
<A HREF="cwg_active.html#2817">2817</A>,
<A HREF="cwg_defects.html#2818">2818</A>,
<A HREF="cwg_defects.html#2819">2819</A>,
<A HREF="cwg_defects.html#2820">2820</A>,
<A HREF="cwg_active.html#2821">2821</A>,
<A HREF="cwg_defects.html#2822">2822</A>,
<A HREF="cwg_defects.html#2823">2823</A>,
<A HREF="cwg_defects.html#2824">2824</A>,
<A HREF="cwg_defects.html#2825">2825</A>,
<A HREF="cwg_active.html#2826">2826</A>,
<A HREF="cwg_active.html#2827">2827</A>,
<A HREF="cwg_defects.html#2828">2828</A>,
<A HREF="cwg_active.html#2829">2829</A>,
<A HREF="cwg_defects.html#2830">2830</A>,
<A HREF="cwg_defects.html#2831">2831</A>,
<A HREF="cwg_active.html#2832">2832</A>,
<A HREF="cwg_active.html#2833">2833</A>,
<A HREF="cwg_active.html#2834">2834</A>,
<A HREF="cwg_active.html#2835">2835</A>,
<A HREF="cwg_defects.html#2836">2836</A>,
<A HREF="cwg_active.html#2837">2837</A>,
<A HREF="cwg_active.html#2838">2838</A>,
<A HREF="cwg_active.html#2839">2839</A>,
<A HREF="cwg_active.html#2840">2840</A>, and
<A HREF="cwg_active.html#2841">2841</A>.
Reflected the decisions of the November, 2023 plenary meeting.
Reflected the deliberations of the teleconferences up to 2023-12-15.
</P>

<P><B>Revision 112, 2023-08-18:</B></P>

<P>Added new issues
<A HREF="cwg_defects.html#2711">2711</A>,
<A HREF="cwg_defects.html#2712">2712</A>,
<A HREF="cwg_defects.html#2713">2713</A>,
<A HREF="cwg_defects.html#2714">2714</A>,
<A HREF="cwg_defects.html#2715">2715</A>,
<A HREF="cwg_defects.html#2716">2716</A>,
<A HREF="cwg_defects.html#2717">2717</A>,
<A HREF="cwg_defects.html#2718">2718</A>,
<A HREF="cwg_defects.html#2719">2719</A>,
<A HREF="cwg_defects.html#2720">2720</A>,
<A HREF="cwg_defects.html#2721">2721</A>,
<A HREF="cwg_defects.html#2722">2722</A>,
<A HREF="cwg_defects.html#2723">2723</A>,
<A HREF="cwg_defects.html#2724">2724</A>,
<A HREF="cwg_defects.html#2725">2725</A>,
<A HREF="cwg_active.html#2726">2726</A>,
<A HREF="cwg_active.html#2727">2727</A>,
<A HREF="cwg_defects.html#2728">2728</A>,
<A HREF="cwg_defects.html#2729">2729</A>,
<A HREF="cwg_active.html#2730">2730</A>,
<A HREF="cwg_active.html#2731">2731</A>,
<A HREF="cwg_defects.html#2732">2732</A>,
<A HREF="cwg_defects.html#2733">2733</A>,
<A HREF="cwg_active.html#2734">2734</A>,
<A HREF="cwg_active.html#2735">2735</A>,
<A HREF="cwg_active.html#2736">2736</A>,
<A HREF="cwg_active.html#2737">2737</A>,
<A HREF="cwg_active.html#2738">2738</A>,
<A HREF="cwg_active.html#2739">2739</A>,
<A HREF="cwg_active.html#2740">2740</A>,
<A HREF="cwg_active.html#2741">2741</A>,
<A HREF="cwg_active.html#2742">2742</A>,
<A HREF="cwg_active.html#2743">2743</A>,
<A HREF="cwg_active.html#2744">2744</A>,
<A HREF="cwg_defects.html#2745">2745</A>,
<A HREF="cwg_defects.html#2746">2746</A>,
<A HREF="cwg_defects.html#2747">2747</A>,
<A HREF="cwg_defects.html#2748">2748</A>,
<A HREF="cwg_defects.html#2749">2749</A>,
<A HREF="cwg_defects.html#2750">2750</A>,
<A HREF="cwg_closed.html#2751">2751</A>,
<A HREF="cwg_active.html#2752">2752</A>,
<A HREF="cwg_defects.html#2753">2753</A>,
<A HREF="cwg_defects.html#2754">2754</A>,
<A HREF="cwg_defects.html#2755">2755</A>,
<A HREF="cwg_active.html#2756">2756</A>,
<A HREF="cwg_active.html#2757">2757</A>,
<A HREF="cwg_defects.html#2758">2758</A>,
<A HREF="cwg_defects.html#2759">2759</A>,
<A HREF="cwg_defects.html#2760">2760</A>,
<A HREF="cwg_defects.html#2761">2761</A>,
<A HREF="cwg_defects.html#2762">2762</A>,
<A HREF="cwg_defects.html#2763">2763</A>,
<A HREF="cwg_defects.html#2764">2764</A>,
<A HREF="cwg_active.html#2765">2765</A>,
<A HREF="cwg_active.html#2766">2766</A>,
<A HREF="cwg_active.html#2767">2767</A>,
<A HREF="cwg_defects.html#2768">2768</A>,
<A HREF="cwg_active.html#2769">2769</A>,
<A HREF="cwg_active.html#2770">2770</A>,
<A HREF="cwg_defects.html#2771">2771</A>,
<A HREF="cwg_defects.html#2772">2772</A>,
<A HREF="cwg_active.html#2773">2773</A>,
<A HREF="cwg_active.html#2774">2774</A>,
<A HREF="cwg_defects.html#2775">2775</A>,
<A HREF="cwg_active.html#2776">2776</A>,
<A HREF="cwg_defects.html#2777">2777</A>,
<A HREF="cwg_active.html#2778">2778</A>,
<A HREF="cwg_active.html#2779">2779</A>, and
<A HREF="cwg_defects.html#2780">2780</A>.
Closed issues
<A HREF="cwg_closed.html#6">6</A>,
<A HREF="cwg_closed.html#504">504</A>,
<A HREF="cwg_closed.html#528">528</A>, and
<A HREF="cwg_closed.html#640">640</A>.
Reflected the decisions of the June, 2023 plenary meeting.
Reflected the deliberations of the teleconferences up to 2023-07-14.
</P>

<P><B>Revision 111, 2023-03-24:</B></P>

<P>Added new issues
<A HREF="cwg_closed.html#2655">2655</A>,
<A HREF="cwg_active.html#2656">2656</A>,
<A HREF="cwg_defects.html#2657">2657</A>,
<A HREF="cwg_defects.html#2658">2658</A>,
<A HREF="cwg_defects.html#2659">2659</A>,
<A HREF="cwg_active.html#2660">2660</A>,
<A HREF="cwg_defects.html#2661">2661</A>,
<A HREF="cwg_defects.html#2662">2662</A>,
<A HREF="cwg_defects.html#2663">2663</A>,
<A HREF="cwg_defects.html#2664">2664</A>,
<A HREF="cwg_closed.html#2665">2665</A>,
<A HREF="cwg_active.html#2666">2666</A>,
<A HREF="cwg_defects.html#2667">2667</A>,
<A HREF="cwg_defects.html#2668">2668</A>,
<A HREF="cwg_active.html#2669">2669</A>,
<A HREF="cwg_active.html#2670">2670</A>,
<A HREF="cwg_active.html#2671">2671</A>,
<A HREF="cwg_defects.html#2672">2672</A>,
<A HREF="cwg_defects.html#2673">2673</A>,
<A HREF="cwg_defects.html#2674">2674</A>,
<A HREF="cwg_active.html#2675">2675</A>,
<A HREF="cwg_active.html#2676">2676</A>,
<A HREF="cwg_active.html#2677">2677</A>,
<A HREF="cwg_defects.html#2678">2678</A>,
<A HREF="cwg_active.html#2679">2679</A>,
<A HREF="cwg_active.html#2680">2680</A>,
<A HREF="cwg_defects.html#2681">2681</A>,
<A HREF="cwg_defects.html#2682">2682</A>,
<A HREF="cwg_defects.html#2683">2683</A>,
<A HREF="cwg_active.html#2684">2684</A>,
<A HREF="cwg_defects.html#2685">2685</A>,
<A HREF="cwg_active.html#2686">2686</A>,
<A HREF="cwg_defects.html#2687">2687</A>,
<A HREF="cwg_active.html#2688">2688</A>,
<A HREF="cwg_defects.html#2689">2689</A>,
<A HREF="cwg_defects.html#2690">2690</A>,
<A HREF="cwg_defects.html#2691">2691</A>,
<A HREF="cwg_defects.html#2692">2692</A>,
<A HREF="cwg_active.html#2693">2693</A>,
<A HREF="cwg_active.html#2694">2694</A>,
<A HREF="cwg_defects.html#2695">2695</A>,
<A HREF="cwg_closed.html#2696">2696</A>,
<A HREF="cwg_defects.html#2697">2697</A>,
<A HREF="cwg_defects.html#2698">2698</A>,
<A HREF="cwg_defects.html#2699">2699</A>,
<A HREF="cwg_defects.html#2700">2700</A>,
<A HREF="cwg_active.html#2701">2701</A>,
<A HREF="cwg_active.html#2702">2702</A>,
<A HREF="cwg_defects.html#2703">2703</A>,
<A HREF="cwg_active.html#2704">2704</A>,
<A HREF="cwg_active.html#2705">2705</A>,
<A HREF="cwg_active.html#2706">2706</A>,
<A HREF="cwg_defects.html#2707">2707</A>,
<A HREF="cwg_defects.html#2708">2708</A>,
<A HREF="cwg_closed.html#2709">2709</A>, and
<A HREF="cwg_defects.html#2710">2710</A>.
Reflected the deliberations of the teleconferences up to 2023-03-03.
Reflected the decisions of the February, 2023 plenary meeting.
</P>

<P><B>Revision 110, 2022-11-27:</B></P>

<P>Reflected publication of the C++23 CD N4917.
Closed issue
<A HREF="cwg_defects.html#578">578</A>.
Added new issues
<A HREF="cwg_defects.html#2610">2610</A>,
<A HREF="cwg_defects.html#2611">2611</A>,
<A HREF="cwg_defects.html#2612">2612</A>,
<A HREF="cwg_defects.html#2613">2613</A>,
<A HREF="cwg_defects.html#2614">2614</A>,
<A HREF="cwg_defects.html#2615">2615</A>,
<A HREF="cwg_defects.html#2616">2616</A>,
<A HREF="cwg_active.html#2617">2617</A>,
<A HREF="cwg_defects.html#2618">2618</A>,
<A HREF="cwg_defects.html#2619">2619</A>,
<A HREF="cwg_defects.html#2620">2620</A>,
<A HREF="cwg_defects.html#2621">2621</A>,
<A HREF="cwg_defects.html#2622">2622</A>,
<A HREF="cwg_active.html#2623">2623</A>,
<A HREF="cwg_defects.html#2624">2624</A>,
<A HREF="cwg_defects.html#2625">2625</A>,
<A HREF="cwg_defects.html#2626">2626</A>,
<A HREF="cwg_defects.html#2627">2627</A>,
<A HREF="cwg_defects.html#2628">2628</A>,
<A HREF="cwg_defects.html#2629">2629</A>,
<A HREF="cwg_defects.html#2630">2630</A>,
<A HREF="cwg_defects.html#2631">2631</A>,
<A HREF="cwg_active.html#2632">2632</A>,
<A HREF="cwg_active.html#2633">2633</A>,
<A HREF="cwg_defects.html#2634">2634</A>,
<A HREF="cwg_defects.html#2635">2635</A>,
<A HREF="cwg_defects.html#2636">2636</A>,
<A HREF="cwg_defects.html#2637">2637</A>,
<A HREF="cwg_defects.html#2638">2638</A>,
<A HREF="cwg_defects.html#2641">2641</A>,
Created issues for the handling of NB comments on the Committee Draft:
<A HREF="cwg_defects.html#2639">2639</A>,
<A HREF="cwg_defects.html#2640">2640</A>,
<A HREF="cwg_defects.html#2642">2642</A>,
<A HREF="cwg_defects.html#2643">2643</A>,
<A HREF="cwg_defects.html#2644">2644</A>,
<A HREF="cwg_defects.html#2645">2645</A>,
<A HREF="cwg_defects.html#2646">2646</A>,
<A HREF="cwg_defects.html#2647">2647</A>,
<A HREF="cwg_defects.html#2648">2648</A>,
<A HREF="cwg_defects.html#2649">2649</A>,
<A HREF="cwg_defects.html#2650">2650</A>,
<A HREF="cwg_defects.html#2651">2651</A>,
<A HREF="cwg_defects.html#2652">2652</A>,
<A HREF="cwg_defects.html#2653">2653</A>,
<A HREF="cwg_defects.html#2654">2654</A>.
Reflected the decisions of the November, 2022 plenary meeting.

</P>

<P><B>Revision 109, 2022-08-07:</B></P>

<P>Added links for section references. Reset status of issues
assigned to people no longer active on the committee.
Reflected the deliberations of the teleconferences.
Reflected the decisions of the July, 2022 plenary meeting.
Added detailed descriptions to issues
<A HREF="cwg_active.html#2187">2187</A>,
<A HREF="cwg_active.html#2188">2188</A>,
<A HREF="cwg_active.html#2189">2189</A>,
<A HREF="cwg_active.html#2190">2190</A>,
<A HREF="cwg_closed.html#2193">2193</A>,
<A HREF="cwg_active.html#2195">2195</A>,
<A HREF="cwg_defects.html#2196">2196</A>,
<A HREF="cwg_defects.html#2197">2197</A>,
<A HREF="cwg_closed.html#2200">2200</A>,
<A HREF="cwg_active.html#2203">2203</A>,
<A HREF="cwg_closed.html#2204">2204</A>,
<A HREF="cwg_defects.html#2211">2211</A>,
<A HREF="cwg_defects.html#2212">2212</A>,
<A HREF="cwg_closed.html#2216">2216</A>,
<A HREF="cwg_defects.html#2221">2221</A>,
<A HREF="cwg_closed.html#2225">2225</A>,
<A HREF="cwg_active.html#2228">2228</A>,
<A HREF="cwg_closed.html#2230">2230</A>,
<A HREF="cwg_closed.html#2231">2231</A>,
<A HREF="cwg_active.html#2236">2236</A>,
<A HREF="cwg_active.html#2245">2245</A>,
<A HREF="cwg_active.html#2246">2246</A>,
<A HREF="cwg_defects.html#2247">2247</A>,
<A HREF="cwg_defects.html#2248">2248</A>,
<A HREF="cwg_active.html#2250">2250</A>,
<A HREF="cwg_defects.html#2251">2251</A>,
<A HREF="cwg_active.html#2258">2258</A>,
<A HREF="cwg_active.html#2263">2263</A>,
<A HREF="cwg_defects.html#2268">2268</A>,
<A HREF="cwg_closed.html#2269">2269</A>,
<A HREF="cwg_closed.html#2270">2270</A>,
<A HREF="cwg_defects.html#2272">2272</A>,
<A HREF="cwg_closed.html#2274">2274</A>,
<A HREF="cwg_active.html#2275">2275</A>,
<A HREF="cwg_defects.html#2276">2276</A>,
<A HREF="cwg_closed.html#2279">2279</A>,
<A HREF="cwg_defects.html#2283">2283</A>,
<A HREF="cwg_active.html#2284">2284</A>,
<A HREF="cwg_closed.html#2286">2286</A>,
<A HREF="cwg_closed.html#2288">2288</A>,
<A HREF="cwg_active.html#2311">2311</A>,
<A HREF="cwg_closed.html#2314">2314</A>,
<A HREF="cwg_active.html#2319">2319</A>, and
<A HREF="cwg_closed.html#2320">2320</A>.
Closed issue
<A HREF="cwg_closed.html#1326">1326</A> and
<A HREF="cwg_closed.html#2420">2420</A>
as duplicates.
Closed issues
<A HREF="cwg_defects.html#476">476</A>,
<A HREF="cwg_closed.html#687">687</A>,
<A HREF="cwg_defects.html#689">689</A>,
<A HREF="cwg_closed.html#728">728</A>,
<A HREF="cwg_closed.html#916">916</A>,
<A HREF="cwg_closed.html#944">944</A>,
<A HREF="cwg_closed.html#1326">1326</A>,
<A HREF="cwg_defects.html#1393">1393</A>,
<A HREF="cwg_defects.html#1469">1469</A>,
<A HREF="cwg_defects.html#1561">1561</A>,
<A HREF="cwg_defects.html#1742">1742</A>,
<A HREF="cwg_defects.html#1912">1912</A>,
<A HREF="cwg_defects.html#1931">1931</A>,
<A HREF="cwg_defects.html#1972">1972</A>,
<A HREF="cwg_defects.html#2212">2212</A>, and
<A HREF="cwg_defects.html#2341">2341</A>.
Dissolved the "concurrency" status in favor of liaison indications,
affecting issues
<A HREF="cwg_active.html#1842">1842</A> and
<A HREF="cwg_active.html#2298">2298</A>.
Reopened issues
<A HREF="cwg_active.html#2169">2169</A> and
<A HREF="cwg_defects.html#2355">2355</A>
after obtaining EWG guidance.
Added new issues
<A HREF="cwg_defects.html#2531">2531</A>,
<A HREF="cwg_active.html#2532">2532</A>,
<A HREF="cwg_defects.html#2533">2533</A>,
<A HREF="cwg_defects.html#2534">2534</A>,
<A HREF="cwg_defects.html#2535">2535</A>,
<A HREF="cwg_active.html#2536">2536</A>,
<A HREF="cwg_active.html#2537">2537</A>,
<A HREF="cwg_defects.html#2538">2538</A>,
<A HREF="cwg_defects.html#2539">2539</A>,
<A HREF="cwg_defects.html#2540">2540</A>,
<A HREF="cwg_active.html#2541">2541</A>,
<A HREF="cwg_defects.html#2542">2542</A>,
<A HREF="cwg_defects.html#2543">2543</A>,
<A HREF="cwg_active.html#2544">2544</A>,
<A HREF="cwg_active.html#2545">2545</A>,
<A HREF="cwg_defects.html#2546">2546</A>,
<A HREF="cwg_defects.html#2547">2547</A>,
<A HREF="cwg_closed.html#2548">2548</A>,
<A HREF="cwg_defects.html#2549">2549</A>,
<A HREF="cwg_defects.html#2550">2550</A>,
<A HREF="cwg_active.html#2551">2551</A>,
<A HREF="cwg_defects.html#2552">2552</A>,
<A HREF="cwg_active.html#2553">2553</A>,
<A HREF="cwg_active.html#2554">2554</A>,
<A HREF="cwg_active.html#2555">2555</A>,
<A HREF="cwg_defects.html#2556">2556</A>,
<A HREF="cwg_active.html#2557">2557</A>,
<A HREF="cwg_defects.html#2558">2558</A>,
<A HREF="cwg_active.html#2559">2559</A>,
<A HREF="cwg_defects.html#2560">2560</A>,
<A HREF="cwg_defects.html#2561">2561</A>,
<A HREF="cwg_active.html#2562">2562</A>,
<A HREF="cwg_active.html#2563">2563</A>,
<A HREF="cwg_active.html#2564">2564</A>,
<A HREF="cwg_active.html#2565">2565</A>,
<A HREF="cwg_active.html#2566">2566</A>,
<A HREF="cwg_closed.html#2567">2567</A>,
<A HREF="cwg_defects.html#2568">2568</A>,
<A HREF="cwg_defects.html#2569">2569</A>,
<A HREF="cwg_defects.html#2570">2570</A>,
<A HREF="cwg_defects.html#2571">2571</A>,
<A HREF="cwg_active.html#2572">2572</A>,
<A HREF="cwg_defects.html#2573">2573</A>,
<A HREF="cwg_defects.html#2574">2574</A>,
<A HREF="cwg_active.html#2575">2575</A>,
<A HREF="cwg_active.html#2576">2576</A>,
<A HREF="cwg_active.html#2577">2577</A>,
<A HREF="cwg_active.html#2578">2578</A>,
<A HREF="cwg_active.html#2579">2579</A>,
<A HREF="cwg_active.html#2580">2580</A>,
<A HREF="cwg_active.html#2581">2581</A>,
<A HREF="cwg_defects.html#2582">2582</A>,
<A HREF="cwg_defects.html#2583">2583</A>,
<A HREF="cwg_active.html#2584">2584</A>,
<A HREF="cwg_defects.html#2585">2585</A>,
<A HREF="cwg_defects.html#2586">2586</A>,
<A HREF="cwg_active.html#2587">2587</A>,
<A HREF="cwg_defects.html#2588">2588</A>,
<A HREF="cwg_active.html#2589">2589</A>,
<A HREF="cwg_defects.html#2591">2591</A>,
<A HREF="cwg_active.html#2592">2592</A>,
<A HREF="cwg_active.html#2593">2593</A>,
<A HREF="cwg_defects.html#2594">2594</A>,
<A HREF="cwg_defects.html#2595">2595</A>,
<A HREF="cwg_active.html#2596">2596</A>,
<A HREF="cwg_defects.html#2597">2597</A>,
<A HREF="cwg_defects.html#2598">2598</A>,
<A HREF="cwg_defects.html#2599">2599</A>,
<A HREF="cwg_defects.html#2600">2600</A>,
<A HREF="cwg_defects.html#2601">2601</A>,
<A HREF="cwg_defects.html#2602">2602</A>,
<A HREF="cwg_defects.html#2603">2603</A>,
<A HREF="cwg_defects.html#2604">2604</A>,
<A HREF="cwg_defects.html#2605">2605</A>,
<A HREF="cwg_defects.html#2606">2606</A>,
<A HREF="cwg_active.html#2607">2607</A>,
<A HREF="cwg_defects.html#2608">2608</A>, and
<A HREF="cwg_active.html#2609">2609</A>.
</P>

<P><B>Revision 108, 2022-01-25:</B></P>

<P>Reflected the deliberations of the January, 2022
teleconferences and the decisions of the February, 2022
plenary meeting. Added new issues
<A HREF="cwg_defects.html#2518">2518</A>,
<A HREF="cwg_defects.html#2519">2519</A>,
<A HREF="cwg_defects.html#2520">2520</A>,
<A HREF="cwg_defects.html#2521">2521</A>,
<A HREF="cwg_active.html#2522">2522</A>,
<A HREF="cwg_defects.html#2523">2523</A>,
<A HREF="cwg_closed.html#2524">2524</A>,
<A HREF="cwg_active.html#2525">2525</A>,
<A HREF="cwg_defects.html#2526">2526</A>,
<A HREF="cwg_closed.html#2527">2527</A>,
<A HREF="cwg_defects.html#2528">2528</A>,
<A HREF="cwg_defects.html#2529">2529</A>, and
<A HREF="cwg_defects.html#2530">2530</A>.
</P>

<P><B>Revision 107, 2021-12-09:</B></P>

<P>Updated the status of issues <A HREF="cwg_defects.html#2482">2482</A>
and <A HREF="cwg_closed.html#2493">2493</A>. Reflected the deliberations
of the December, 2021 CWG teleconference. Added new issues
<A HREF="cwg_defects.html#2506">2506</A>,
<A HREF="cwg_defects.html#2507">2507</A>,
<A HREF="cwg_defects.html#2508">2508</A>,
<A HREF="cwg_defects.html#2509">2509</A>,
<A HREF="cwg_closed.html#2510">2510</A>,
<A HREF="cwg_defects.html#2511">2511</A>,
<A HREF="cwg_closed.html#2512">2512</A>,
<A HREF="cwg_active.html#2513">2513</A>,
<A HREF="cwg_active.html#2514">2514</A>,
<A HREF="cwg_active.html#2515">2515</A>,
<A HREF="cwg_defects.html#2516">2516</A>, and
<A HREF="cwg_defects.html#2517">2517</A>.
</P>

<P><B>Revision 106, 2021-11-22:</B></P>

<P>Reflected the deliberations of CWG teleconferences from
September through November, 2021, and the decisions of the
October, 2021 plenary meeting. Added new issues
<A HREF="cwg_defects.html#2502">2502</A>,
<A HREF="cwg_active.html#2503">2503</A>,
<A HREF="cwg_defects.html#2504">2504</A>, and
<A HREF="cwg_active.html#2505">2505</A>.</P>

<P><B>Revision 105, 2021-06-08:</B></P>

<P>Reflected the deliberations of CWG teleconferences from March
through August, 2021, and the decisions of the June, 2021 plenary
meeting. Added new issues
<A HREF="cwg_defects.html#2481">2481</A>,
<A HREF="cwg_defects.html#2482">2482</A>,
<A HREF="cwg_defects.html#2483">2483</A>,
<A HREF="cwg_defects.html#2484">2484</A>,
<A HREF="cwg_defects.html#2485">2485</A>,
<A HREF="cwg_defects.html#2486">2486</A>,
<A HREF="cwg_active.html#2487">2487</A>,
<A HREF="cwg_active.html#2488">2488</A>,
<A HREF="cwg_defects.html#2489">2489</A>,
<A HREF="cwg_defects.html#2490">2490</A>,
<A HREF="cwg_defects.html#2491">2491</A>,
<A HREF="cwg_active.html#2492">2492</A>,
<A HREF="cwg_closed.html#2493">2493</A>,
<A HREF="cwg_defects.html#2494">2494</A>,
<A HREF="cwg_active.html#2495">2495</A>,
<A HREF="cwg_defects.html#2496">2496</A>,
<A HREF="cwg_active.html#2497">2497</A>,
<A HREF="cwg_active.html#2498">2498</A>,
<A HREF="cwg_defects.html#2499">2499</A>,
<A HREF="cwg_closed.html#2500">2500</A>, and
<A HREF="cwg_active.html#2501">2501</A>.
</P>

<P><B>Revision 104, 2021-02-24:</B></P>

<P>Reflected the decisions of the February, 2021 meeting.
Updated the status of issues <A HREF="cwg_defects.html#1332">1332</A>
and <A HREF="cwg_defects.html#2402">2402</A>, which were previously
resolved by editorial action and adoption of a paper,
respectively. Added new issue
<A HREF="cwg_active.html#2480">2480</A>.</P>

<P><B>Revision 103, 2021-02-17:</B></P>

<P>Updated the status of a number of issues that were resolved or
rendered moot by other issue resolutions or papers, including issues
<A HREF="cwg_closed.html#156">156</A>,
<A HREF="cwg_closed.html#192">192</A>,
<A HREF="cwg_closed.html#278">278</A>,
<A HREF="cwg_closed.html#297">297</A>,
<A HREF="cwg_defects.html#555">555</A>,
<A HREF="cwg_closed.html#560">560</A>,
<A HREF="cwg_closed.html#617">617</A>,
<A HREF="cwg_defects.html#670">670</A>,
<A HREF="cwg_closed.html#1230">1230</A>,
<A HREF="cwg_closed.html#1285">1285</A>,
<A HREF="cwg_defects.html#1331">1331</A>,
<A HREF="cwg_defects.html#1426">1426</A>,
<A HREF="cwg_defects.html#1451">1451</A>,
<A HREF="cwg_closed.html#1452">1452</A>,
<A HREF="cwg_closed.html#1545">1545</A>,
<A HREF="cwg_defects.html#1640">1640</A>,
<A HREF="cwg_closed.html#1644">1644</A>,
<A HREF="cwg_defects.html#1646">1646</A>,
<A HREF="cwg_closed.html#1713">1713</A>,
<A HREF="cwg_defects.html#1801">1801</A>,
<A HREF="cwg_defects.html#1857">1857</A>,
<A HREF="cwg_defects.html#1859">1859</A>,
<A HREF="cwg_defects.html#1880">1880</A>,
<A HREF="cwg_closed.html#1917">1917</A>,
<A HREF="cwg_defects.html#1943">1943</A>,
<A HREF="cwg_closed.html#1974">1974</A>,
<A HREF="cwg_defects.html#2045">2045</A>,
<A HREF="cwg_defects.html#2080">2080</A>,
<A HREF="cwg_defects.html#2112">2112</A>,
<A HREF="cwg_defects.html#2121">2121</A>,
<A HREF="cwg_defects.html#2215">2215</A>,
<A HREF="cwg_defects.html#2295">2295</A>,
<A HREF="cwg_defects.html#2343">2343</A>,
<A HREF="cwg_closed.html#2364">2364</A>,
<A HREF="cwg_closed.html#2367">2367</A>,
<A HREF="cwg_defects.html#2371">2371</A>, and
<A HREF="cwg_defects.html#2411">2411</A>.
Reflected the deliberations of the February, 2021 teleconference.
Added new issues
<A HREF="cwg_defects.html#2470">2470</A>,
<A HREF="cwg_active.html#2471">2471</A>,
<A HREF="cwg_closed.html#2472">2472</A>,
<A HREF="cwg_active.html#2473">2473</A>,
<A HREF="cwg_defects.html#2474">2474</A>,
<A HREF="cwg_defects.html#2475">2475</A>,
<A HREF="cwg_defects.html#2476">2476</A>,
<A HREF="cwg_defects.html#2477">2477</A>,
<A HREF="cwg_defects.html#2478">2478</A>, and
<A HREF="cwg_defects.html#2479">2479</A>.
</P>

<P>
<B>Revision 102, 2020-12-15:</B> Changed
<A HREF="cwg_defects.html#2331">issue 2331</A> back to "drafting"
status after problems were found with the proposed
resolution. Fixed transcription errors in the proposed
resolution for <A HREF="cwg_defects.html#2020">issue 2020</A>.
Corrected the date for resolutions approved at the
February, 2019 meeting (they previously indicated approval
at the &#8220;November, 2019&#8221; meeting).
Reflected actions at committee meetings and teleconferences.
Added new issues
<A HREF="cwg_active.html#2403">2403</A>,
<A HREF="cwg_defects.html#2404">2404</A>,
<A HREF="cwg_defects.html#2405">2405</A>,
<A HREF="cwg_defects.html#2406">2406</A>,
<A HREF="cwg_defects.html#2407">2407</A>,
<A HREF="cwg_closed.html#2408">2408</A>,
<A HREF="cwg_active.html#2409">2409</A>,
<A HREF="cwg_defects.html#2410">2410</A>,
<A HREF="cwg_defects.html#2411">2411</A>,
<A HREF="cwg_active.html#2412">2412</A>,
<A HREF="cwg_defects.html#2413">2413</A>,
<A HREF="cwg_defects.html#2414">2414</A>,
<A HREF="cwg_closed.html#2415">2415</A>,
<A HREF="cwg_defects.html#2416">2416</A>,
<A HREF="cwg_active.html#2417">2417</A>,
<A HREF="cwg_defects.html#2418">2418</A>,
<A HREF="cwg_defects.html#2419">2419</A>,
<A HREF="cwg_closed.html#2420">2420</A>,
<A HREF="cwg_active.html#2421">2421</A>,
<A HREF="cwg_defects.html#2422">2422</A>,
<A HREF="cwg_closed.html#2423">2423</A>,
<A HREF="cwg_defects.html#2424">2424</A>,
<A HREF="cwg_active.html#2425">2425</A>,
<A HREF="cwg_defects.html#2426">2426</A>,
<A HREF="cwg_defects.html#2427">2427</A>,
<A HREF="cwg_defects.html#2428">2428</A>,
<A HREF="cwg_defects.html#2429">2429</A>,
<A HREF="cwg_defects.html#2430">2430</A>,
<A HREF="cwg_defects.html#2431">2431</A>,
<A HREF="cwg_defects.html#2432">2432</A>,
<A HREF="cwg_defects.html#2433">2433</A>,
<A HREF="cwg_active.html#2434">2434</A>,
<A HREF="cwg_active.html#2435">2435</A>,
<A HREF="cwg_defects.html#2436">2436</A>,
<A HREF="cwg_defects.html#2437">2437</A>,
<A HREF="cwg_active.html#2438">2438</A>,
<A HREF="cwg_defects.html#2439">2439</A>,
<A HREF="cwg_defects.html#2440">2440</A>,
<A HREF="cwg_defects.html#2441">2441</A>,
<A HREF="cwg_defects.html#2442">2442</A>,
<A HREF="cwg_defects.html#2443">2443</A>,
<A HREF="cwg_active.html#2444">2444</A>,
<A HREF="cwg_defects.html#2445">2445</A>,
<A HREF="cwg_defects.html#2446">2446</A>,
<A HREF="cwg_defects.html#2447">2447</A>,
<A HREF="cwg_defects.html#2448">2448</A>,
<A HREF="cwg_closed.html#2449">2449</A>,
<A HREF="cwg_defects.html#2450">2450</A>,
<A HREF="cwg_defects.html#2451">2451</A>,
<A HREF="cwg_defects.html#2452">2452</A>,
<A HREF="cwg_closed.html#2453">2453</A>,
<A HREF="cwg_closed.html#2454">2454</A>,
<A HREF="cwg_defects.html#2455">2455</A>,
<A HREF="cwg_active.html#2456">2456</A>,
<A HREF="cwg_defects.html#2457">2457</A>,
<A HREF="cwg_defects.html#2458">2458</A>,
<A HREF="cwg_defects.html#2459">2459</A>,
<A HREF="cwg_defects.html#2460">2460</A>,
<A HREF="cwg_defects.html#2461">2461</A>,
<A HREF="cwg_active.html#2462">2462</A>,
<A HREF="cwg_active.html#2463">2463</A>,
<A HREF="cwg_defects.html#2464">2464</A>,
<A HREF="cwg_defects.html#2465">2465</A>,
<A HREF="cwg_defects.html#2466">2466</A>,
<A HREF="cwg_active.html#2467">2467</A>,
<A HREF="cwg_active.html#2468">2468</A>, and
<A HREF="cwg_active.html#2469">2469</A>.</P>

<P>
<B>Revision 101, 2019-02-27:</B>
Reflected actions at committee meetings and teleconferences. Added new issues
<A HREF="cwg_defects.html#2366">2366</A>,
<A HREF="cwg_closed.html#2367">2367</A>,
<A HREF="cwg_defects.html#2368">2368</A>,
<A HREF="cwg_defects.html#2369">2369</A>,
<A HREF="cwg_defects.html#2370">2370</A>,
<A HREF="cwg_defects.html#2371">2371</A>,
<A HREF="cwg_defects.html#2372">2372</A>,
<A HREF="cwg_defects.html#2373">2373</A>,
<A HREF="cwg_defects.html#2374">2374</A>,
<A HREF="cwg_closed.html#2375">2375</A>,
<A HREF="cwg_defects.html#2376">2376</A>,
<A HREF="cwg_closed.html#2377">2377</A>,
<A HREF="cwg_defects.html#2378">2378</A>,
<A HREF="cwg_defects.html#2379">2379</A>,
<A HREF="cwg_defects.html#2380">2380</A>,
<A HREF="cwg_defects.html#2381">2381</A>,
<A HREF="cwg_defects.html#2382">2382</A>,
<A HREF="cwg_closed.html#2383">2383</A>,
<A HREF="cwg_defects.html#2384">2384</A>,
<A HREF="cwg_defects.html#2385">2385</A>,
<A HREF="cwg_defects.html#2386">2386</A>,
<A HREF="cwg_defects.html#2387">2387</A>,
<A HREF="cwg_closed.html#2388">2388</A>,
<A HREF="cwg_defects.html#2389">2389</A>,
<A HREF="cwg_defects.html#2390">2390</A>,
<A HREF="cwg_closed.html#2391">2391</A>,
<A HREF="cwg_defects.html#2392">2392</A>,
<A HREF="cwg_closed.html#2393">2393</A>,
<A HREF="cwg_defects.html#2394">2394</A>,
<A HREF="cwg_active.html#2395">2395</A>,
<A HREF="cwg_defects.html#2396">2396</A>,
<A HREF="cwg_defects.html#2397">2397</A>,
<A HREF="cwg_active.html#2398">2398</A>,
<A HREF="cwg_defects.html#2399">2399</A>,
<A HREF="cwg_defects.html#2400">2400</A>,
<A HREF="cwg_active.html#2401">2401</A>, and
<A HREF="cwg_defects.html#2402">2402</A>,.
</P>

<P>
<B>Revision 100, 2018-04-11:</B>
Reflected actions at the March, 2018 committee meeting and the April, 2018
teleconference. Added new issues
<A HREF="cwg_closed.html#2357">2357</A>,
<A HREF="cwg_defects.html#2358">2358</A>,
<A HREF="cwg_defects.html#2359">2359</A>,
<A HREF="cwg_defects.html#2360">2360</A>,
<A HREF="cwg_active.html#2361">2361</A>,
<A HREF="cwg_active.html#2362">2362</A>,
<A HREF="cwg_closed.html#2363">2363</A>,
<A HREF="cwg_closed.html#2364">2364</A>, and
<A HREF="cwg_defects.html#2365">2365</A>.
</P>

<P>
<B>Revision 99, 2018-02-27:</B>
Reflected actions of committee meetings and teleconferences. Added new
C++17 status and moved issues incorporated in that IS to have that status.

Added new issues
<A HREF="cwg_defects.html#2278">2278</A>,
<A HREF="cwg_closed.html#2279">2279</A>,
<A HREF="cwg_defects.html#2280">2280</A>,
<A HREF="cwg_active.html#2281">2281</A>,
<A HREF="cwg_defects.html#2282">2282</A>,
<A HREF="cwg_defects.html#2283">2283</A>,
<A HREF="cwg_active.html#2284">2284</A>,
<A HREF="cwg_defects.html#2285">2285</A>,
<A HREF="cwg_closed.html#2286">2286</A>,
<A HREF="cwg_defects.html#2287">2287</A>,
<A HREF="cwg_closed.html#2288">2288</A>,
<A HREF="cwg_defects.html#2289">2289</A>,
<A HREF="cwg_defects.html#2290">2290</A>,
<A HREF="cwg_closed.html#2291">2291</A>,
<A HREF="cwg_defects.html#2292">2292</A>,
<A HREF="cwg_defects.html#2293">2293</A>,
<A HREF="cwg_defects.html#2294">2294</A>,
<A HREF="cwg_defects.html#2295">2295</A>,
<A HREF="cwg_active.html#2296">2296</A>,
<A HREF="cwg_active.html#2297">2297</A>,
<A HREF="cwg_active.html#2298">2298</A>,
<A HREF="cwg_defects.html#2299">2299</A>,
<A HREF="cwg_defects.html#2300">2300</A>,
<A HREF="cwg_active.html#2301">2301</A>,
<A HREF="cwg_closed.html#2302">2302</A>,
<A HREF="cwg_defects.html#2303">2303</A>,
<A HREF="cwg_closed.html#2304">2304</A>,
<A HREF="cwg_defects.html#2305">2305</A>,
<A HREF="cwg_closed.html#2306">2306</A>,
<A HREF="cwg_defects.html#2307">2307</A>,
<A HREF="cwg_closed.html#2308">2308</A>,
<A HREF="cwg_defects.html#2309">2309</A>,
<A HREF="cwg_defects.html#2310">2310</A>,
<A HREF="cwg_active.html#2311">2311</A>,
<A HREF="cwg_defects.html#2312">2312</A>,
<A HREF="cwg_defects.html#2313">2313</A>,
<A HREF="cwg_closed.html#2314">2314</A>,
<A HREF="cwg_defects.html#2315">2315</A>,
<A HREF="cwg_active.html#2316">2316</A>,
<A HREF="cwg_defects.html#2317">2317</A>,
<A HREF="cwg_defects.html#2318">2318</A>,
<A HREF="cwg_active.html#2319">2319</A>,
<A HREF="cwg_closed.html#2320">2320</A>,
<A HREF="cwg_defects.html#2321">2321</A>,
<A HREF="cwg_defects.html#2322">2322</A>,
<A HREF="cwg_defects.html#2323">2323</A>,
<A HREF="cwg_active.html#2324">2324</A>,
<A HREF="cwg_active.html#2325">2325</A>,
<A HREF="cwg_closed.html#2326">2326</A>,
<A HREF="cwg_active.html#2327">2327</A>,
<A HREF="cwg_active.html#2328">2328</A>,
<A HREF="cwg_active.html#2329">2329</A>,
<A HREF="cwg_defects.html#2330">2330</A>,
<A HREF="cwg_defects.html#2331">2331</A>,
<A HREF="cwg_defects.html#2332">2332</A>,
<A HREF="cwg_defects.html#2333">2333</A>,
<A HREF="cwg_active.html#2334">2334</A>,
<A HREF="cwg_active.html#2335">2335</A>,
<A HREF="cwg_defects.html#2336">2336</A>,
<A HREF="cwg_active.html#2337">2337</A>,
<A HREF="cwg_defects.html#2338">2338</A>,
<A HREF="cwg_defects.html#2339">2339</A>,
<A HREF="cwg_active.html#2340">2340</A>,
<A HREF="cwg_defects.html#2341">2341</A>,
<A HREF="cwg_defects.html#2342">2342</A>,
<A HREF="cwg_defects.html#2343">2343</A>,
<A HREF="cwg_closed.html#2344">2344</A>,
<A HREF="cwg_defects.html#2345">2345</A>,
<A HREF="cwg_defects.html#2346">2346</A>,
<A HREF="cwg_defects.html#2347">2347</A>,
<A HREF="cwg_closed.html#2348">2348</A>,
<A HREF="cwg_closed.html#2349">2349</A>,
<A HREF="cwg_closed.html#2350">2350</A>,
<A HREF="cwg_defects.html#2351">2351</A>,
<A HREF="cwg_defects.html#2352">2352</A>,
<A HREF="cwg_defects.html#2353">2353</A>,
<A HREF="cwg_defects.html#2354">2354</A>,
<A HREF="cwg_defects.html#2355">2355</A>, and
<A HREF="cwg_defects.html#2356">2356</A>.
</P>

<P>
<B>Revision 98, 2017-03-20:</B> Reflected the deliberations of the
February-March, 2017 Committee meeting.
</P>

<P>
<B>Revision 97, 2017-02-07:</B> Reflected the deliberations of
the 2016 Committee meetings and teleconferences. Added new issues
<A HREF="cwg_active.html#2123">2123</A>,
<A HREF="cwg_defects.html#2124">2124</A>,
<A HREF="cwg_closed.html#2125">2125</A>,
<A HREF="cwg_defects.html#2126">2126</A>,
<A HREF="cwg_active.html#2127">2127</A>,
<A HREF="cwg_active.html#2128">2128</A>,
<A HREF="cwg_defects.html#2129">2129</A>,
<A HREF="cwg_defects.html#2130">2130</A>,
<A HREF="cwg_active.html#2131">2131</A>,
<A HREF="cwg_closed.html#2132">2132</A>,
<A HREF="cwg_defects.html#2133">2133</A>,
<A HREF="cwg_closed.html#2134">2134</A>,
<A HREF="cwg_closed.html#2135">2135</A>,
<A HREF="cwg_closed.html#2136">2136</A>,
<A HREF="cwg_defects.html#2137">2137</A>,
<A HREF="cwg_closed.html#2138">2138</A>,
<A HREF="cwg_closed.html#2139">2139</A>,
<A HREF="cwg_defects.html#2140">2140</A>,
<A HREF="cwg_defects.html#2141">2141</A>,
<A HREF="cwg_closed.html#2142">2142</A>,
<A HREF="cwg_defects.html#2143">2143</A>,
<A HREF="cwg_defects.html#2144">2144</A>,
<A HREF="cwg_defects.html#2145">2145</A>,
<A HREF="cwg_defects.html#2146">2146</A>,
<A HREF="cwg_defects.html#2147">2147</A>,
<A HREF="cwg_active.html#2148">2148</A>,
<A HREF="cwg_defects.html#2149">2149</A>,
<A HREF="cwg_defects.html#2150">2150</A>,
<A HREF="cwg_defects.html#2151">2151</A>,
<A HREF="cwg_closed.html#2152">2152</A>,
<A HREF="cwg_defects.html#2153">2153</A>,
<A HREF="cwg_defects.html#2154">2154</A>,
<A HREF="cwg_defects.html#2155">2155</A>,
<A HREF="cwg_defects.html#2156">2156</A>,
<A HREF="cwg_defects.html#2157">2157</A>,
<A HREF="cwg_active.html#2158">2158</A>,
<A HREF="cwg_closed.html#2159">2159</A>,
<A HREF="cwg_active.html#2160">2160</A>,
<A HREF="cwg_closed.html#2161">2161</A>,
<A HREF="cwg_defects.html#2162">2162</A>,
<A HREF="cwg_defects.html#2163">2163</A>,
<A HREF="cwg_defects.html#2164">2164</A>,
<A HREF="cwg_defects.html#2165">2165</A>,
<A HREF="cwg_active.html#2166">2166</A>,
<A HREF="cwg_defects.html#2167">2167</A>,
<A HREF="cwg_active.html#2168">2168</A>,
<A HREF="cwg_active.html#2169">2169</A>,
<A HREF="cwg_defects.html#2170">2170</A>,
<A HREF="cwg_defects.html#2171">2171</A>,
<A HREF="cwg_active.html#2172">2172</A>,
<A HREF="cwg_active.html#2173">2173</A>,
<A HREF="cwg_defects.html#2174">2174</A>,
<A HREF="cwg_defects.html#2175">2175</A>,
<A HREF="cwg_defects.html#2176">2176</A>,
<A HREF="cwg_defects.html#2177">2177</A>,
<A HREF="cwg_closed.html#2178">2178</A>,
<A HREF="cwg_active.html#2179">2179</A>,
<A HREF="cwg_defects.html#2180">2180</A>,
<A HREF="cwg_defects.html#2181">2181</A>,
<A HREF="cwg_active.html#2182">2182</A>,
<A HREF="cwg_closed.html#2183">2183</A>,
<A HREF="cwg_defects.html#2184">2184</A>,
<A HREF="cwg_defects.html#2185">2185</A>,
<A HREF="cwg_defects.html#2186">2186</A>,
<A HREF="cwg_active.html#2187">2187</A>,
<A HREF="cwg_active.html#2188">2188</A>,
<A HREF="cwg_active.html#2189">2189</A>,
<A HREF="cwg_active.html#2190">2190</A>,
<A HREF="cwg_defects.html#2191">2191</A>,
<A HREF="cwg_active.html#2192">2192</A>,
<A HREF="cwg_closed.html#2193">2193</A>,
<A HREF="cwg_active.html#2194">2194</A>,
<A HREF="cwg_active.html#2195">2195</A>,
<A HREF="cwg_defects.html#2196">2196</A>,
<A HREF="cwg_defects.html#2197">2197</A>,
<A HREF="cwg_defects.html#2198">2198</A>,
<A HREF="cwg_defects.html#2199">2199</A>,
<A HREF="cwg_closed.html#2200">2200</A>,
<A HREF="cwg_defects.html#2201">2201</A>,
<A HREF="cwg_active.html#2202">2202</A>,
<A HREF="cwg_active.html#2203">2203</A>,
<A HREF="cwg_closed.html#2204">2204</A>,
<A HREF="cwg_defects.html#2205">2205</A>,
<A HREF="cwg_defects.html#2206">2206</A>,
<A HREF="cwg_defects.html#2207">2207</A>,
<A HREF="cwg_closed.html#2208">2208</A>,
<A HREF="cwg_closed.html#2209">2209</A>,
<A HREF="cwg_closed.html#2210">2210</A>,
<A HREF="cwg_defects.html#2211">2211</A>,
<A HREF="cwg_defects.html#2212">2212</A>,
<A HREF="cwg_defects.html#2213">2213</A>,
<A HREF="cwg_defects.html#2214">2214</A>,
<A HREF="cwg_defects.html#2215">2215</A>,
<A HREF="cwg_closed.html#2216">2216</A>,
<A HREF="cwg_closed.html#2217">2217</A>,
<A HREF="cwg_defects.html#2218">2218</A>,
<A HREF="cwg_active.html#2219">2219</A>,
<A HREF="cwg_defects.html#2220">2220</A>,
<A HREF="cwg_defects.html#2221">2221</A>,
<A HREF="cwg_active.html#2222">2222</A>,
<A HREF="cwg_active.html#2223">2223</A>,
<A HREF="cwg_defects.html#2224">2224</A>,
<A HREF="cwg_closed.html#2225">2225</A>,
<A HREF="cwg_defects.html#2226">2226</A>,
<A HREF="cwg_defects.html#2227">2227</A>,
<A HREF="cwg_active.html#2228">2228</A>,
<A HREF="cwg_defects.html#2229">2229</A>,
<A HREF="cwg_closed.html#2230">2230</A>,
<A HREF="cwg_closed.html#2231">2231</A>,
<A HREF="cwg_active.html#2232">2232</A>,
<A HREF="cwg_defects.html#2233">2233</A>,
<A HREF="cwg_defects.html#2234">2234</A>,
<A HREF="cwg_defects.html#2235">2235</A>,
<A HREF="cwg_active.html#2236">2236</A>,
<A HREF="cwg_defects.html#2237">2237</A>,
<A HREF="cwg_closed.html#2238">2238</A>,
<A HREF="cwg_closed.html#2239">2239</A>,
<A HREF="cwg_closed.html#2240">2240</A>,
<A HREF="cwg_defects.html#2241">2241</A>,
<A HREF="cwg_defects.html#2242">2242</A>,
<A HREF="cwg_active.html#2243">2243</A>,
<A HREF="cwg_active.html#2244">2244</A>,
<A HREF="cwg_active.html#2245">2245</A>,
<A HREF="cwg_active.html#2246">2246</A>,
<A HREF="cwg_defects.html#2247">2247</A>,
<A HREF="cwg_defects.html#2248">2248</A>,
<A HREF="cwg_defects.html#2249">2249</A>,
<A HREF="cwg_active.html#2250">2250</A>,
<A HREF="cwg_defects.html#2251">2251</A>,
<A HREF="cwg_defects.html#2252">2252</A>,
<A HREF="cwg_defects.html#2253">2253</A>,
<A HREF="cwg_defects.html#2254">2254</A>,
<A HREF="cwg_defects.html#2255">2255</A>,
<A HREF="cwg_defects.html#2256">2256</A>,
<A HREF="cwg_defects.html#2257">2257</A>,
<A HREF="cwg_active.html#2258">2258</A>,
<A HREF="cwg_defects.html#2259">2259</A>,
<A HREF="cwg_defects.html#2260">2260</A>,
<A HREF="cwg_closed.html#2261">2261</A>,
<A HREF="cwg_defects.html#2262">2262</A>,
<A HREF="cwg_active.html#2263">2263</A>,
<A HREF="cwg_active.html#2264">2264</A>,
<A HREF="cwg_active.html#2265">2265</A>,
<A HREF="cwg_defects.html#2266">2266</A>,
<A HREF="cwg_defects.html#2267">2267</A>,
<A HREF="cwg_defects.html#2268">2268</A>,
<A HREF="cwg_closed.html#2269">2269</A>,
<A HREF="cwg_closed.html#2270">2270</A>,
<A HREF="cwg_defects.html#2271">2271</A>,
<A HREF="cwg_defects.html#2272">2272</A>,
<A HREF="cwg_defects.html#2273">2273</A>,
<A HREF="cwg_closed.html#2274">2274</A>,
<A HREF="cwg_active.html#2275">2275</A>,
<A HREF="cwg_defects.html#2276">2276</A>, and
<A HREF="cwg_defects.html#2277">2277</A>.
(Note that a number of the new issues have only titles at this point;
full descriptions will be added in the next revision of the list.)
</P>

<P>
<B>Revision 96, 2016-02-15:</B> Changed the status of
<A HREF="cwg_defects.html#2047">issue 2047</A> from "ready" to
"tentatively ready" to reflect revisions to accommodate
changes in the underlying wording after the October, 2015
meeting.  Reflected the results of drafting review
teleconferences held 2016-01-11 and 2016-02-08.
</P>

<P>
<B>Revision 95, 2015-11-10:</B> Reflected the deliberations of
the October, 2015 Committee meeting. Moved
<A HREF="cwg_defects.html#1893">issue 1893</A> back to "drafting"
status; it was incorrectly inadvertently accepted as a DR at the
November, 2014 meeting.XS
<A HREF="cwg_defects.html#1992">Issue 1992</A> was moved back to drafting to
allow application to additional text. Added new issues
<A HREF="cwg_active.html#2123">2123</A>,
<A HREF="cwg_defects.html#2124">2124</A>,
<A HREF="cwg_closed.html#2125">2125</A>,
<A HREF="cwg_defects.html#2126">2126</A>,
<A HREF="cwg_active.html#2127">2127</A>,
<A HREF="cwg_active.html#2128">2128</A>,
<A HREF="cwg_defects.html#2129">2129</A>,
<A HREF="cwg_defects.html#2130">2130</A>,
<A HREF="cwg_active.html#2131">2131</A>,
<A HREF="cwg_closed.html#2132">2132</A>,
<A HREF="cwg_defects.html#2133">2133</A>,
<A HREF="cwg_closed.html#2134">2134</A>,
<A HREF="cwg_closed.html#2135">2135</A>,
<A HREF="cwg_closed.html#2136">2136</A>,
<A HREF="cwg_defects.html#2137">2137</A>,
<A HREF="cwg_closed.html#2138">2138</A>,
<A HREF="cwg_closed.html#2139">2139</A>,
<A HREF="cwg_defects.html#2140">2140</A>,
<A HREF="cwg_defects.html#2141">2141</A>,
<A HREF="cwg_closed.html#2142">2142</A>,
<A HREF="cwg_defects.html#2143">2143</A>,
<A HREF="cwg_defects.html#2144">2144</A>,
<A HREF="cwg_defects.html#2145">2145</A>,
<A HREF="cwg_defects.html#2146">2146</A>,
<A HREF="cwg_defects.html#2147">2147</A>,
<A HREF="cwg_active.html#2148">2148</A>,
<A HREF="cwg_defects.html#2149">2149</A>,
<A HREF="cwg_defects.html#2150">2150</A>,
<A HREF="cwg_defects.html#2151">2151</A>,
<A HREF="cwg_closed.html#2152">2152</A>,
<A HREF="cwg_defects.html#2153">2153</A>,
<A HREF="cwg_defects.html#2154">2154</A>,
<A HREF="cwg_defects.html#2155">2155</A>,
<A HREF="cwg_defects.html#2156">2156</A>,
<A HREF="cwg_defects.html#2157">2157</A>,
<A HREF="cwg_active.html#2158">2158</A>,
<A HREF="cwg_closed.html#2159">2159</A>,
<A HREF="cwg_active.html#2160">2160</A>,
<A HREF="cwg_closed.html#2161">2161</A>,
<A HREF="cwg_defects.html#2162">2162</A>,
<A HREF="cwg_defects.html#2163">2163</A>,
<A HREF="cwg_defects.html#2164">2164</A>,
<A HREF="cwg_defects.html#2165">2165</A>,
<A HREF="cwg_active.html#2166">2166</A>,
<A HREF="cwg_defects.html#2167">2167</A>,
<A HREF="cwg_active.html#2168">2168</A>,
<A HREF="cwg_active.html#2169">2169</A>,
<A HREF="cwg_defects.html#2170">2170</A>,
<A HREF="cwg_defects.html#2171">2171</A>,
<A HREF="cwg_active.html#2172">2172</A>,
<A HREF="cwg_active.html#2173">2173</A>,
<A HREF="cwg_defects.html#2174">2174</A>,
<A HREF="cwg_defects.html#2175">2175</A>,
<A HREF="cwg_defects.html#2176">2176</A>,
<A HREF="cwg_defects.html#2177">2177</A>,
<A HREF="cwg_closed.html#2178">2178</A>,
<A HREF="cwg_active.html#2179">2179</A>,
<A HREF="cwg_defects.html#2180">2180</A>,
<A HREF="cwg_defects.html#2181">2181</A>,
<A HREF="cwg_active.html#2182">2182</A>,
<A HREF="cwg_closed.html#2183">2183</A>,
<A HREF="cwg_defects.html#2184">2184</A>,
<A HREF="cwg_defects.html#2185">2185</A>, and
<A HREF="cwg_defects.html#2186">2186</A>.
</P>

<P>
<B>Revision 94, 2015-05-25:</B> Reflected deliberations of the
May, 2015 meeting.  Moved issues <A HREF="cwg_defects.html#1734">1734</A> and
<A HREF="cwg_closed.html#1928">1928</A> to "extension" status, reflecting
EWG's request to develop a position on trivial special functions
before CWG addresses them. Added new issues
<A HREF="cwg_closed.html#2036">2036</A>,
<A HREF="cwg_active.html#2037">2037</A>,
<A HREF="cwg_defects.html#2038">2038</A>,
<A HREF="cwg_defects.html#2039">2039</A>,
<A HREF="cwg_defects.html#2040">2040</A>,
<A HREF="cwg_defects.html#2041">2041</A>,
<A HREF="cwg_active.html#2042">2042</A>,
<A HREF="cwg_active.html#2043">2043</A>,
<A HREF="cwg_defects.html#2044">2044</A>,
<A HREF="cwg_defects.html#2045">2045</A>,
<A HREF="cwg_defects.html#2046">2046</A>,
<A HREF="cwg_defects.html#2047">2047</A>,
<A HREF="cwg_active.html#2048">2048</A>,
<A HREF="cwg_defects.html#2049">2049</A>,
<A HREF="cwg_closed.html#2050">2050</A>,
<A HREF="cwg_defects.html#2051">2051</A>,
<A HREF="cwg_defects.html#2052">2052</A>,
<A HREF="cwg_defects.html#2053">2053</A>,
<A HREF="cwg_defects.html#2054">2054</A>,
<A HREF="cwg_active.html#2055">2055</A>,
<A HREF="cwg_active.html#2056">2056</A>,
<A HREF="cwg_active.html#2057">2057</A>,
<A HREF="cwg_defects.html#2058">2058</A>,
<A HREF="cwg_defects.html#2059">2059</A>,
<A HREF="cwg_closed.html#2060">2060</A>,
<A HREF="cwg_defects.html#2061">2061</A>,
<A HREF="cwg_defects.html#2062">2062</A>,
<A HREF="cwg_defects.html#2063">2063</A>,
<A HREF="cwg_defects.html#2064">2064</A>,
<A HREF="cwg_defects.html#2065">2065</A>,
<A HREF="cwg_defects.html#2066">2066</A>,
<A HREF="cwg_active.html#2067">2067</A>,
<A HREF="cwg_defects.html#2068">2068</A>,
<A HREF="cwg_defects.html#2069">2069</A>,
<A HREF="cwg_defects.html#2070">2070</A>,
<A HREF="cwg_defects.html#2071">2071</A>,
<A HREF="cwg_defects.html#2072">2072</A>,
<A HREF="cwg_active.html#2073">2073</A>,
<A HREF="cwg_active.html#2074">2074</A>,
<A HREF="cwg_defects.html#2075">2075</A>,
<A HREF="cwg_defects.html#2076">2076</A>,
<A HREF="cwg_active.html#2077">2077</A>,
<A HREF="cwg_closed.html#2078">2078</A>,
<A HREF="cwg_defects.html#2079">2079</A>,
<A HREF="cwg_defects.html#2080">2080</A>,
<A HREF="cwg_defects.html#2081">2081</A>,
<A HREF="cwg_defects.html#2082">2082</A>,
<A HREF="cwg_defects.html#2083">2083</A>,
<A HREF="cwg_defects.html#2084">2084</A>,
<A HREF="cwg_defects.html#2085">2085</A>,
<A HREF="cwg_active.html#2086">2086</A>,
<A HREF="cwg_closed.html#2087">2087</A>,
<A HREF="cwg_defects.html#2088">2088</A>,
<A HREF="cwg_active.html#2089">2089</A>,
<A HREF="cwg_active.html#2090">2090</A>,
<A HREF="cwg_defects.html#2091">2091</A>,
<A HREF="cwg_defects.html#2092">2092</A>,
<A HREF="cwg_defects.html#2093">2093</A>,
<A HREF="cwg_defects.html#2094">2094</A>,
<A HREF="cwg_defects.html#2095">2095</A>,
<A HREF="cwg_defects.html#2096">2096</A>,
<A HREF="cwg_closed.html#2097">2097</A>,
<A HREF="cwg_defects.html#2098">2098</A>,
<A HREF="cwg_defects.html#2099">2099</A>,
<A HREF="cwg_defects.html#2100">2100</A>,
<A HREF="cwg_defects.html#2101">2101</A>,
<A HREF="cwg_defects.html#2102">2102</A>,
<A HREF="cwg_defects.html#2103">2103</A>,
<A HREF="cwg_defects.html#2104">2104</A>,
<A HREF="cwg_active.html#2105">2105</A>,
<A HREF="cwg_defects.html#2106">2106</A>,
<A HREF="cwg_defects.html#2107">2107</A>,
<A HREF="cwg_active.html#2108">2108</A>,
<A HREF="cwg_defects.html#2109">2109</A>,
<A HREF="cwg_active.html#2110">2110</A>,
<A HREF="cwg_closed.html#2111">2111</A>,
<A HREF="cwg_defects.html#2112">2112</A>,
<A HREF="cwg_defects.html#2113">2113</A>,
<A HREF="cwg_defects.html#2114">2114</A>,
<A HREF="cwg_active.html#2115">2115</A>,
<A HREF="cwg_defects.html#2116">2116</A>,
<A HREF="cwg_closed.html#2117">2117</A>,
<A HREF="cwg_active.html#2118">2118</A>,
<A HREF="cwg_closed.html#2119">2119</A>,
<A HREF="cwg_defects.html#2120">2120</A>,
<A HREF="cwg_defects.html#2121">2121</A>, and
<A HREF="cwg_defects.html#2122">2122</A>.
</P>

<P>
<B>Revision 93, 2015-04-13:</B> Incorporated EWG decisions on issues
<A HREF="cwg_defects.html#92">92</A>,
<A HREF="cwg_closed.html#203">203</A>,
<A HREF="cwg_closed.html#622">622</A>,
<A HREF="cwg_closed.html#822">822</A>,
<A HREF="cwg_closed.html#1077">1077</A>,
<A HREF="cwg_closed.html#1259">1259</A>,
<A HREF="cwg_closed.html#1272">1272</A>,
<A HREF="cwg_closed.html#1564">1564</A>,
<A HREF="cwg_closed.html#1577">1577</A>,
<A HREF="cwg_active.html#1582">1582</A>,
<A HREF="cwg_closed.html#1586">1586</A>,
<A HREF="cwg_closed.html#1643">1643</A>,
<A HREF="cwg_closed.html#1754">1754</A>,
<A HREF="cwg_closed.html#1798">1798</A>,
<A HREF="cwg_closed.html#1826">1826</A>, and
<A HREF="cwg_closed.html#1833">1833</A>.  Moved <A HREF="cwg_defects.html#1657">issue 1657</A>
to "accepted" status, reflecting adoption of paper N4266 at the Urbana
meeting. Moved <A HREF="cwg_defects.html#1683">issue 1683</A> to "DRWP" status,
reflecting approval of N4140 as the working paper at the November, 2014
meeting.  Incorporated resolutions from the drafting
review teleconference held 2015-04-06.
</P>

<P>
<B>Revision 92, 2014-11-24:</B> Changed all issues approved
by the Committee since the April, 2013 Committee Draft to "C++14"
status, to reflect the adoption of ISO/IEC 14882:2014. Moved issues
<A HREF="cwg_defects.html#1299">1299</A>, <A HREF="cwg_closed.html#1651">1651</A>,
<A HREF="cwg_defects.html#1893">1893</A>, and <A HREF="cwg_active.html#1817">1817</A>
to "drafting" status, <A HREF="cwg_active.html#1584">1584</A> to
"open" status, and <A HREF="cwg_defects.html#314">314</A>,
<A HREF="cwg_defects.html#343">343</A>, <A HREF="cwg_defects.html#1710">1710</A>,
<A HREF="cwg_defects.html#1794">1794</A>, and <A HREF="cwg_defects.html#1812">1812</A>
to "review" status in light of concerns that were raised with their
proposed resolutions.
Moved <A HREF="cwg_defects.html#1048">issue 1048</A> to "CD3" status to
reflect the fact that it had been addressed by paper N3638, adopted
at the April, 2013 (Bristol) meeting.
Closed issues <A HREF="cwg_closed.html#550">550</A> and
<A HREF="cwg_closed.html#1855">1855</A> as duplicates. Reflected the actions
of the November, 2014 (Urbana) meeting. Added new issues
<A HREF="cwg_closed.html#1948">1948</A>,
<A HREF="cwg_defects.html#1949">1949</A>,
<A HREF="cwg_closed.html#1950">1950</A>,
<A HREF="cwg_defects.html#1951">1951</A>,
<A HREF="cwg_defects.html#1952">1952</A>,
<A HREF="cwg_defects.html#1953">1953</A>,
<A HREF="cwg_defects.html#1954">1954</A>,
<A HREF="cwg_defects.html#1955">1955</A>,
<A HREF="cwg_defects.html#1956">1956</A>,
<A HREF="cwg_closed.html#1957">1957</A>,
<A HREF="cwg_defects.html#1958">1958</A>,
<A HREF="cwg_defects.html#1959">1959</A>,
<A HREF="cwg_closed.html#1960">1960</A>,
<A HREF="cwg_defects.html#1961">1961</A>,
<A HREF="cwg_active.html#1962">1962</A>,
<A HREF="cwg_defects.html#1963">1963</A>,
<A HREF="cwg_closed.html#1964">1964</A>,
<A HREF="cwg_defects.html#1965">1965</A>,
<A HREF="cwg_defects.html#1966">1966</A>,
<A HREF="cwg_defects.html#1967">1967</A>,
<A HREF="cwg_closed.html#1968">1968</A>,
<A HREF="cwg_defects.html#1969">1969</A>,
<A HREF="cwg_closed.html#1970">1970</A>,
<A HREF="cwg_defects.html#1971">1971</A>,
<A HREF="cwg_defects.html#1972">1972</A>,
<A HREF="cwg_defects.html#1973">1973</A>,
<A HREF="cwg_closed.html#1974">1974</A>,
<A HREF="cwg_defects.html#1975">1975</A>,
<A HREF="cwg_closed.html#1976">1976</A>,
<A HREF="cwg_active.html#1977">1977</A>,
<A HREF="cwg_defects.html#1978">1978</A>,
<A HREF="cwg_active.html#1979">1979</A>,
<A HREF="cwg_active.html#1980">1980</A>,
<A HREF="cwg_defects.html#1981">1981</A>,
<A HREF="cwg_closed.html#1982">1982</A>,
<A HREF="cwg_defects.html#1983">1983</A>,
<A HREF="cwg_closed.html#1984">1984</A>,
<A HREF="cwg_closed.html#1985">1985</A>,
<A HREF="cwg_active.html#1986">1986</A>,
<A HREF="cwg_closed.html#1987">1987</A>,
<A HREF="cwg_defects.html#1988">1988</A>,
<A HREF="cwg_active.html#1989">1989</A>,
<A HREF="cwg_defects.html#1990">1990</A>,
<A HREF="cwg_defects.html#1991">1991</A>,
<A HREF="cwg_defects.html#1992">1992</A>,
<A HREF="cwg_active.html#1993">1993</A>,
<A HREF="cwg_closed.html#1994">1994</A>,
<A HREF="cwg_defects.html#1995">1995</A>,
<A HREF="cwg_active.html#1996">1996</A>,
<A HREF="cwg_defects.html#1997">1997</A>,
<A HREF="cwg_closed.html#1998">1998</A>,
<A HREF="cwg_defects.html#1999">1999</A>,
<A HREF="cwg_defects.html#2000">2000</A>,
<A HREF="cwg_defects.html#2001">2001</A>,
<A HREF="cwg_active.html#2002">2002</A>,
<A HREF="cwg_active.html#2003">2003</A>,
<A HREF="cwg_defects.html#2004">2004</A>,
<A HREF="cwg_closed.html#2005">2005</A>,
<A HREF="cwg_defects.html#2006">2006</A>,
<A HREF="cwg_defects.html#2007">2007</A>,
<A HREF="cwg_defects.html#2008">2008</A>,
<A HREF="cwg_defects.html#2009">2009</A>,
<A HREF="cwg_defects.html#2010">2010</A>,
<A HREF="cwg_defects.html#2011">2011</A>,
<A HREF="cwg_defects.html#2012">2012</A>,
<A HREF="cwg_active.html#2013">2013</A>,
<A HREF="cwg_closed.html#2014">2014</A>,
<A HREF="cwg_defects.html#2015">2015</A>,
<A HREF="cwg_defects.html#2016">2016</A>,
<A HREF="cwg_defects.html#2017">2017</A>,
<A HREF="cwg_closed.html#2018">2018</A>,
<A HREF="cwg_defects.html#2019">2019</A>,
<A HREF="cwg_defects.html#2020">2020</A>,
<A HREF="cwg_closed.html#2021">2021</A>,
<A HREF="cwg_defects.html#2022">2022</A>,
<A HREF="cwg_active.html#2023">2023</A>,
<A HREF="cwg_defects.html#2024">2024</A>,
<A HREF="cwg_closed.html#2025">2025</A>,
<A HREF="cwg_defects.html#2026">2026</A>,
<A HREF="cwg_defects.html#2027">2027</A>,
<A HREF="cwg_active.html#2028">2028</A>,
<A HREF="cwg_closed.html#2029">2029</A>,
<A HREF="cwg_closed.html#2030">2030</A>,
<A HREF="cwg_defects.html#2031">2031</A>,
<A HREF="cwg_defects.html#2032">2032</A>,
<A HREF="cwg_defects.html#2033">2033</A>,
<A HREF="cwg_closed.html#2034">2034</A>, and
<A HREF="cwg_defects.html#2035">2035</A>.
</P>

<P>
<B>Revision 91, 2014-10-13:</B> Incorporated deliberations of drafting
review teleconferences held 2014-07-14 and 2014-10-06.  Added new issue
<A HREF="cwg_closed.html#1947">1947</A>.
</P>

<P>
<B>Revision 90, 2014-07-07:</B> <A HREF="cwg_defects.html#1715">Issue 1715</A>
was returned to "drafting" status in light of an alternative suggestion
for its resolution.  <A HREF="cwg_closed.html#1927">Issue 1927</A> was closed
as a duplicate of <A HREF="cwg_closed.html#1695">issue 1695</A>. Reflected the
deliberations of CWG at the 2014-06 (Rapperswil) meeting. Added new issues
<A HREF="cwg_defects.html#1932">1932</A>,
<A HREF="cwg_closed.html#1933">1933</A>,
<A HREF="cwg_closed.html#1934">1934</A>,
<A HREF="cwg_defects.html#1935">1935</A>,
<A HREF="cwg_defects.html#1936">1936</A>,
<A HREF="cwg_defects.html#1937">1937</A>,
<A HREF="cwg_defects.html#1938">1938</A>,
<A HREF="cwg_active.html#1939">1939</A>,
<A HREF="cwg_defects.html#1940">1940</A>,
<A HREF="cwg_defects.html#1941">1941</A>,
<A HREF="cwg_defects.html#1942">1942</A>,
<A HREF="cwg_defects.html#1943">1943</A>,
<A HREF="cwg_active.html#1944">1944</A>,
<A HREF="cwg_defects.html#1945">1945</A>, and
<A HREF="cwg_defects.html#1946">1946</A>.
</P>

<P>
<B>Revision 89, 2014-05-27:</B> Issues <A HREF="cwg_defects.html#1351">1351</A>
<A HREF="cwg_defects.html#1356">1356</A> <A HREF="cwg_defects.html#1465">1465</A>,
<A HREF="cwg_defects.html#1590">1590</A>, <A HREF="cwg_defects.html#1639">1639</A>
<A HREF="cwg_defects.html#1708">1708</A>, and <A HREF="cwg_defects.html#1810">1810</A>
were returned to "review" status for further discussion.  Restored
<A HREF="cwg_defects.html#1397">issue 1397</A> to "ready"; it had incorrectly
been moved back to "drafting" because of a misunderstood comment.
Added new issues
<A HREF="cwg_defects.html#1866">1866</A>,
<A HREF="cwg_closed.html#1867">1867</A>,
<A HREF="cwg_active.html#1868">1868</A>,
<A HREF="cwg_closed.html#1869">1869</A>,
<A HREF="cwg_defects.html#1870">1870</A>,
<A HREF="cwg_closed.html#1871">1871</A>,
<A HREF="cwg_defects.html#1872">1872</A>,
<A HREF="cwg_defects.html#1873">1873</A>,
<A HREF="cwg_defects.html#1874">1874</A>,
<A HREF="cwg_defects.html#1875">1875</A>,
<A HREF="cwg_closed.html#1876">1876</A>,
<A HREF="cwg_defects.html#1877">1877</A>,
<A HREF="cwg_defects.html#1878">1878</A>,
<A HREF="cwg_closed.html#1879">1879</A>,
<A HREF="cwg_defects.html#1880">1880</A>,
<A HREF="cwg_defects.html#1881">1881</A>,
<A HREF="cwg_defects.html#1882">1882</A>,
<A HREF="cwg_active.html#1883">1883</A>,
<A HREF="cwg_defects.html#1884">1884</A>,
<A HREF="cwg_defects.html#1885">1885</A>,
<A HREF="cwg_defects.html#1886">1886</A>,
<A HREF="cwg_defects.html#1887">1887</A>,
<A HREF="cwg_defects.html#1888">1888</A>,
<A HREF="cwg_active.html#1889">1889</A>,
<A HREF="cwg_active.html#1890">1890</A>,
<A HREF="cwg_defects.html#1891">1891</A>,
<A HREF="cwg_defects.html#1892">1892</A>,
<A HREF="cwg_defects.html#1893">1893</A>,
<A HREF="cwg_defects.html#1894">1894</A>,
<A HREF="cwg_defects.html#1895">1895</A>,
<A HREF="cwg_defects.html#1896">1896</A>,
<A HREF="cwg_active.html#1897">1897</A>,
<A HREF="cwg_defects.html#1898">1898</A>,
<A HREF="cwg_defects.html#1899">1899</A>,
<A HREF="cwg_defects.html#1900">1900</A>,
<A HREF="cwg_active.html#1901">1901</A>,
<A HREF="cwg_defects.html#1902">1902</A>,
<A HREF="cwg_defects.html#1903">1903</A>,
<A HREF="cwg_closed.html#1904">1904</A>,
<A HREF="cwg_closed.html#1905">1905</A>,
<A HREF="cwg_closed.html#1906">1906</A>,
<A HREF="cwg_defects.html#1907">1907</A>,
<A HREF="cwg_defects.html#1908">1908</A>,
<A HREF="cwg_defects.html#1909">1909</A>,
<A HREF="cwg_defects.html#1910">1910</A>,
<A HREF="cwg_defects.html#1911">1911</A>,
<A HREF="cwg_defects.html#1912">1912</A>,
<A HREF="cwg_defects.html#1913">1913</A>,
<A HREF="cwg_closed.html#1914">1914</A>,
<A HREF="cwg_active.html#1915">1915</A>,
<A HREF="cwg_defects.html#1916">1916</A>,
<A HREF="cwg_closed.html#1917">1917</A>,
<A HREF="cwg_defects.html#1918">1918</A>,
<A HREF="cwg_active.html#1919">1919</A>,
<A HREF="cwg_defects.html#1920">1920</A>,
<A HREF="cwg_closed.html#1921">1921</A>,
<A HREF="cwg_defects.html#1922">1922</A>,
<A HREF="cwg_closed.html#1923">1923</A>,
<A HREF="cwg_active.html#1924">1924</A>,
<A HREF="cwg_defects.html#1925">1925</A>,
<A HREF="cwg_defects.html#1926">1926</A>,
<A HREF="cwg_closed.html#1927">1927</A>,
<A HREF="cwg_closed.html#1928">1928</A>,
<A HREF="cwg_defects.html#1929">1929</A>,
<A HREF="cwg_defects.html#1930">1930</A>, and
<A HREF="cwg_defects.html#1931">1931</A>.
</P>

<LI>
<B>Revision 88, 2014-03-03:</B> Changed the "FDIS" status to "C++11",
reflecting having voted out a new DIS.  Changed issues in "WP" and
"DRWP" status to "CD3", reflecting the fact that their resolutions were
contained in the Committee Draft approved for balloting at the April, 2013
meeting.  Changed the status of <A HREF="cwg_defects.html#344">issue 344</A> to
"CD3" when it was noticed that it was resolved by the resolution of
<A HREF="cwg_defects.html#1435">issue 1435</A>. Changed the status of
<A HREF="cwg_defects.html#1491">issue 1491</A> to "CD3" when it was noticed that it
was resolved by the resolution of <A HREF="cwg_defects.html#1402">issue 1402</A>.
Reflected the deliberations of the
February, 2014 (Issaquah) meeting.
Added new issues
<A HREF="cwg_defects.html#1837">1837</A>,
<A HREF="cwg_defects.html#1838">1838</A>,
<A HREF="cwg_defects.html#1839">1839</A>,
<A HREF="cwg_active.html#1840">1840</A>,
<A HREF="cwg_defects.html#1841">1841</A>,
<A HREF="cwg_active.html#1842">1842</A>,
<A HREF="cwg_defects.html#1843">1843</A>,
<A HREF="cwg_active.html#1844">1844</A>,
<A HREF="cwg_active.html#1845">1845</A>,
<A HREF="cwg_defects.html#1846">1846</A>,
<A HREF="cwg_defects.html#1847">1847</A>,
<A HREF="cwg_defects.html#1848">1848</A>,
<A HREF="cwg_defects.html#1849">1849</A>,
<A HREF="cwg_defects.html#1850">1850</A>,
<A HREF="cwg_defects.html#1851">1851</A>,
<A HREF="cwg_defects.html#1852">1852</A>,
<A HREF="cwg_closed.html#1853">1853</A>,
<A HREF="cwg_active.html#1854">1854</A>,
<A HREF="cwg_closed.html#1855">1855</A>,
<A HREF="cwg_active.html#1856">1856</A>,
<A HREF="cwg_defects.html#1857">1857</A>,
<A HREF="cwg_defects.html#1858">1858</A>,
<A HREF="cwg_defects.html#1859">1859</A>,
<A HREF="cwg_defects.html#1860">1860</A>,
<A HREF="cwg_defects.html#1861">1861</A>,
<A HREF="cwg_defects.html#1862">1862</A>,
<A HREF="cwg_defects.html#1863">1863</A>,
<A HREF="cwg_closed.html#1864">1864</A>, and
<A HREF="cwg_defects.html#1865">1865</A>.
</LI>

<LI>
<B>Revision 87, 2014-01-20:</B> Incorporated the results of the
drafting review teleconferences held 2013-11-25 and 2014-01-13.
Changed status of <A HREF="cwg_defects.html#1469">issue 1469</A> to
"extension", reflecting the consensus of the 2012-08-13 drafting
review teleconference.  Moved <A HREF="cwg_defects.html#1480">issue 1480</A>
to "WP" status because it was rendered moot by the adoption of N3652
at the April, 2013 meeting.
Added new issues
<A HREF="cwg_defects.html#1796">1796</A>,
<A HREF="cwg_defects.html#1797">1797</A>,
<A HREF="cwg_closed.html#1798">1798</A>,
<A HREF="cwg_defects.html#1799">1799</A>,
<A HREF="cwg_defects.html#1800">1800</A>,
<A HREF="cwg_defects.html#1801">1801</A>,
<A HREF="cwg_defects.html#1802">1802</A>,
<A HREF="cwg_defects.html#1803">1803</A>,
<A HREF="cwg_defects.html#1804">1804</A>,
<A HREF="cwg_defects.html#1805">1805</A>,
<A HREF="cwg_defects.html#1806">1806</A>,
<A HREF="cwg_defects.html#1807">1807</A>,
<A HREF="cwg_active.html#1808">1808</A>,
<A HREF="cwg_defects.html#1809">1809</A>,
<A HREF="cwg_defects.html#1810">1810</A>,
<A HREF="cwg_defects.html#1811">1811</A>,
<A HREF="cwg_defects.html#1812">1812</A>,
<A HREF="cwg_defects.html#1813">1813</A>,
<A HREF="cwg_defects.html#1814">1814</A>,
<A HREF="cwg_defects.html#1815">1815</A>,
<A HREF="cwg_defects.html#1816">1816</A>,
<A HREF="cwg_active.html#1817">1817</A>,
<A HREF="cwg_defects.html#1818">1818</A>,
<A HREF="cwg_defects.html#1819">1819</A>,
<A HREF="cwg_defects.html#1820">1820</A>,
<A HREF="cwg_defects.html#1821">1821</A>,
<A HREF="cwg_defects.html#1822">1822</A>,
<A HREF="cwg_defects.html#1823">1823</A>,
<A HREF="cwg_defects.html#1824">1824</A>,
<A HREF="cwg_defects.html#1825">1825</A>,
<A HREF="cwg_closed.html#1826">1826</A>,
<A HREF="cwg_active.html#1827">1827</A>,
<A HREF="cwg_defects.html#1828">1828</A>,
<A HREF="cwg_defects.html#1829">1829</A>,
<A HREF="cwg_defects.html#1830">1830</A>,
<A HREF="cwg_closed.html#1831">1831</A>,
<A HREF="cwg_defects.html#1832">1832</A>,
<A HREF="cwg_closed.html#1833">1833</A>,
<A HREF="cwg_defects.html#1834">1834</A>,
<A HREF="cwg_defects.html#1835">1835</A>, and
<A HREF="cwg_defects.html#1836">1836</A>.
</LI>

<LI>
<B>Revision 86, 2013-10-14:</B> Reflected the deliberations of the
September, 2013 (Chicago) meeting.  Added new issues
<A HREF="cwg_closed.html#1743">1743</A>,
<A HREF="cwg_defects.html#1744">1744</A>,
<A HREF="cwg_closed.html#1745">1745</A>,
<A HREF="cwg_defects.html#1746">1746</A>,
<A HREF="cwg_defects.html#1747">1747</A>,
<A HREF="cwg_defects.html#1748">1748</A>,
<A HREF="cwg_closed.html#1749">1749</A>,
<A HREF="cwg_defects.html#1750">1750</A>,
<A HREF="cwg_defects.html#1751">1751</A>,
<A HREF="cwg_defects.html#1752">1752</A>,
<A HREF="cwg_defects.html#1753">1753</A>,
<A HREF="cwg_closed.html#1754">1754</A>,
<A HREF="cwg_active.html#1755">1755</A>,
<A HREF="cwg_defects.html#1756">1756</A>,
<A HREF="cwg_defects.html#1757">1757</A>,
<A HREF="cwg_defects.html#1758">1758</A>,
<A HREF="cwg_defects.html#1759">1759</A>,
<A HREF="cwg_defects.html#1760">1760</A>,
<A HREF="cwg_closed.html#1761">1761</A>,
<A HREF="cwg_defects.html#1762">1762</A>,
<A HREF="cwg_active.html#1763">1763</A>,
<A HREF="cwg_defects.html#1764">1764</A>,
<A HREF="cwg_defects.html#1765">1765</A>,
<A HREF="cwg_defects.html#1766">1766</A>,
<A HREF="cwg_defects.html#1767">1767</A>,
<A HREF="cwg_closed.html#1768">1768</A>,
<A HREF="cwg_defects.html#1769">1769</A>,
<A HREF="cwg_defects.html#1770">1770</A>,
<A HREF="cwg_defects.html#1771">1771</A>,
<A HREF="cwg_defects.html#1772">1772</A>,
<A HREF="cwg_defects.html#1773">1773</A>,
<A HREF="cwg_defects.html#1774">1774</A>,
<A HREF="cwg_defects.html#1775">1775</A>,
<A HREF="cwg_defects.html#1776">1776</A>,
<A HREF="cwg_defects.html#1777">1777</A>,
<A HREF="cwg_defects.html#1778">1778</A>,
<A HREF="cwg_defects.html#1779">1779</A>,
<A HREF="cwg_defects.html#1780">1780</A>,
<A HREF="cwg_defects.html#1781">1781</A>,
<A HREF="cwg_defects.html#1782">1782</A>,
<A HREF="cwg_closed.html#1783">1783</A>,
<A HREF="cwg_defects.html#1784">1784</A>,
<A HREF="cwg_closed.html#1785">1785</A>,
<A HREF="cwg_defects.html#1786">1786</A>,
<A HREF="cwg_defects.html#1787">1787</A>,
<A HREF="cwg_defects.html#1788">1788</A>,
<A HREF="cwg_active.html#1789">1789</A>,
<A HREF="cwg_active.html#1790">1790</A>,
<A HREF="cwg_defects.html#1791">1791</A>,
<A HREF="cwg_closed.html#1792">1792</A>,
<A HREF="cwg_defects.html#1793">1793</A>,
<A HREF="cwg_defects.html#1794">1794</A>, and
<A HREF="cwg_defects.html#1795">1795</A>.
</LI>

<LI>
<B>Revision 85, 2013-09-03:</B> Incorporated the results of the
drafting review teleconferences held 2013-06-24 and 2013-08-26. Changed
the status of <A HREF="cwg_defects.html#583">issue 583</A> to "DR" because it
was (silently) addressed by N3624. Changed the status of
<A HREF="cwg_defects.html#1531">issue 1531</A> to "DR" because it had been
inadvertently overlooked in recording the motions of the April, 2013
meeting. Changed the status of <A HREF="cwg_defects.html#1597">issue 1597</A> to
"accepted" because it is moot after the adoption of N3652. Returned
<A HREF="cwg_active.html#1609">issue 1609</A> to "open" status in light of
additional discussion.  Added new information to the description of
<A HREF="cwg_defects.html#1335">issue 1335</A>. Added new issues
<A HREF="cwg_defects.html#1657">1657</A>,
<A HREF="cwg_defects.html#1658">1658</A>,
<A HREF="cwg_active.html#1659">1659</A>,
<A HREF="cwg_defects.html#1660">1660</A>,
<A HREF="cwg_closed.html#1661">1661</A>,
<A HREF="cwg_defects.html#1662">1662</A>,
<A HREF="cwg_closed.html#1663">1663</A>,
<A HREF="cwg_defects.html#1664">1664</A>,
<A HREF="cwg_active.html#1665">1665</A>,
<A HREF="cwg_defects.html#1666">1666</A>,
<A HREF="cwg_closed.html#1667">1667</A>,
<A HREF="cwg_active.html#1668">1668</A>,
<A HREF="cwg_defects.html#1669">1669</A>,
<A HREF="cwg_active.html#1670">1670</A>,
<A HREF="cwg_closed.html#1671">1671</A>,
<A HREF="cwg_defects.html#1672">1672</A>,
<A HREF="cwg_defects.html#1673">1673</A>,
<A HREF="cwg_defects.html#1674">1674</A>,
<A HREF="cwg_closed.html#1675">1675</A>,
<A HREF="cwg_active.html#1676">1676</A>,
<A HREF="cwg_defects.html#1677">1677</A>,
<A HREF="cwg_closed.html#1678">1678</A>,
<A HREF="cwg_closed.html#1679">1679</A>,
<A HREF="cwg_active.html#1680">1680</A>,
<A HREF="cwg_defects.html#1681">1681</A>,
<A HREF="cwg_active.html#1682">1682</A>,
<A HREF="cwg_defects.html#1683">1683</A>,
<A HREF="cwg_defects.html#1684">1684</A>,
<A HREF="cwg_closed.html#1685">1685</A>,
<A HREF="cwg_defects.html#1686">1686</A>,
<A HREF="cwg_defects.html#1687">1687</A>,
<A HREF="cwg_closed.html#1688">1688</A>,
<A HREF="cwg_defects.html#1689">1689</A>,
<A HREF="cwg_defects.html#1690">1690</A>,
<A HREF="cwg_defects.html#1691">1691</A>,
<A HREF="cwg_defects.html#1692">1692</A>,
<A HREF="cwg_defects.html#1693">1693</A>,
<A HREF="cwg_defects.html#1694">1694</A>,
<A HREF="cwg_closed.html#1695">1695</A>,
<A HREF="cwg_defects.html#1696">1696</A>,
<A HREF="cwg_defects.html#1697">1697</A>,
<A HREF="cwg_defects.html#1698">1698</A>,
<A HREF="cwg_active.html#1699">1699</A>,
<A HREF="cwg_closed.html#1700">1700</A>,
<A HREF="cwg_active.html#1701">1701</A>,
<A HREF="cwg_active.html#1702">1702</A>,
<A HREF="cwg_closed.html#1703">1703</A>,
<A HREF="cwg_defects.html#1704">1704</A>,
<A HREF="cwg_defects.html#1705">1705</A>,
<A HREF="cwg_active.html#1706">1706</A>,
<A HREF="cwg_defects.html#1707">1707</A>,
<A HREF="cwg_defects.html#1708">1708</A>,
<A HREF="cwg_active.html#1709">1709</A>,
<A HREF="cwg_defects.html#1710">1710</A>,
<A HREF="cwg_defects.html#1711">1711</A>,
<A HREF="cwg_defects.html#1712">1712</A>,
<A HREF="cwg_closed.html#1713">1713</A>,
<A HREF="cwg_closed.html#1714">1714</A>,
<A HREF="cwg_defects.html#1715">1715</A>,
<A HREF="cwg_defects.html#1716">1716</A>,
<A HREF="cwg_defects.html#1717">1717</A>,
<A HREF="cwg_active.html#1718">1718</A>,
<A HREF="cwg_defects.html#1719">1719</A>,
<A HREF="cwg_closed.html#1720">1720</A>,
<A HREF="cwg_active.html#1721">1721</A>,
<A HREF="cwg_defects.html#1722">1722</A>,
<A HREF="cwg_active.html#1723">1723</A>,
<A HREF="cwg_defects.html#1724">1724</A>,
<A HREF="cwg_closed.html#1725">1725</A>,
<A HREF="cwg_defects.html#1726">1726</A>,
<A HREF="cwg_closed.html#1727">1727</A>,
<A HREF="cwg_defects.html#1728">1728</A>,
<A HREF="cwg_defects.html#1729">1729</A>,
<A HREF="cwg_active.html#1730">1730</A>,
<A HREF="cwg_closed.html#1731">1731</A>,
<A HREF="cwg_defects.html#1732">1732</A>,
<A HREF="cwg_defects.html#1733">1733</A>,
<A HREF="cwg_defects.html#1734">1734</A>,
<A HREF="cwg_active.html#1735">1735</A>,
<A HREF="cwg_defects.html#1736">1736</A>,
<A HREF="cwg_defects.html#1737">1737</A>,
<A HREF="cwg_defects.html#1738">1738</A>,
<A HREF="cwg_defects.html#1739">1739</A>,
<A HREF="cwg_defects.html#1740">1740</A>,
<A HREF="cwg_defects.html#1741">1741</A>, and
<A HREF="cwg_defects.html#1742">1742</A>.
</LI>

<LI>
<B>Revision 84, 2013-05-03:</B> Incorporated the results of the drafting
review teleconference held 2013-03-25 and the deliberations of the April, 2013
(Bristol) meeting.  Changed
<A HREF="cwg_closed.html#1568">issue 1568</A> to "dup" status.  Changed the
status of <A HREF="cwg_defects.html#1492">issue 1492</A> to "drafting" status,
although it was approved as a DR at the meeting, because its resolution
is to be given by another resolution that was not moved.  Similarly,
issues <A HREF="cwg_defects.html#1356">1356</A> and <A HREF="cwg_defects.html#1465">1465</A>
were incorrectly moved as defect reports and have been returned to "review"
status awaiting the adoption of <A HREF="cwg_defects.html#1351">issue 1351</A>.
Also, <A HREF="cwg_defects.html#1531">issue 1531</A> was moved as a DR but was
lacking the proposed resolution in the document in the pre-meeting mailing,
so it has been returned to "ready" status to be moved at the next meeting.
Changed the resolutions of issues <A HREF="cwg_defects.html#1374">1374</A> and
<A HREF="cwg_defects.html#1543">1543</A> to correct
clerical errors transcribing the original proposed resolutions.  Began the
practice of marking proposed resolutions as "[SUPERSEDED]" when a newer
one is added.
Added new issues
<A HREF="cwg_defects.html#1642">1642</A>,
<A HREF="cwg_closed.html#1643">1643</A>,
<A HREF="cwg_closed.html#1644">1644</A>,
<A HREF="cwg_defects.html#1645">1645</A>,
<A HREF="cwg_defects.html#1646">1646</A>,
<A HREF="cwg_active.html#1647">1647</A>,
<A HREF="cwg_defects.html#1648">1648</A>,
<A HREF="cwg_defects.html#1649">1649</A>,
<A HREF="cwg_closed.html#1650">1650</A>,
<A HREF="cwg_closed.html#1651">1651</A>,
<A HREF="cwg_defects.html#1652">1652</A>,
<A HREF="cwg_defects.html#1653">1653</A>,
<A HREF="cwg_closed.html#1654">1654</A>,
<A HREF="cwg_active.html#1655">1655</A>, and
<A HREF="cwg_defects.html#1656">1656</A>.
</LI>

<LI>
<B>Revision 83, 2013-03-18:</B> Incorporated the results of the
drafting review teleconference held 2013-02-04, including moving
<A HREF="cwg_closed.html#1566">issue 1566</A> to "NAD" status.  Moved issues
<A HREF="cwg_defects.html#1417">1417</A> and <A HREF="cwg_defects.html#1460">1460</A> back to
"review" status in light of new questions.  Updated the &#8220;more
information&#8221; link to refer to <TT>isocpp.org</TT>.  Added new issues
<A HREF="cwg_closed.html#1606">1606</A>,
<A HREF="cwg_defects.html#1607">1607</A>,
<A HREF="cwg_defects.html#1608">1608</A>,
<A HREF="cwg_active.html#1609">1609</A>,
<A HREF="cwg_active.html#1610">1610</A>,
<A HREF="cwg_defects.html#1611">1611</A>,
<A HREF="cwg_defects.html#1612">1612</A>,
<A HREF="cwg_defects.html#1613">1613</A>,
<A HREF="cwg_defects.html#1614">1614</A>,
<A HREF="cwg_defects.html#1615">1615</A>,
<A HREF="cwg_defects.html#1616">1616</A>,
<A HREF="cwg_active.html#1617">1617</A>,
<A HREF="cwg_defects.html#1618">1618</A>,
<A HREF="cwg_active.html#1619">1619</A>,
<A HREF="cwg_active.html#1620">1620</A>,
<A HREF="cwg_defects.html#1621">1621</A>,
<A HREF="cwg_defects.html#1622">1622</A>,
<A HREF="cwg_active.html#1623">1623</A>,
<A HREF="cwg_closed.html#1624">1624</A>,
<A HREF="cwg_active.html#1625">1625</A>,
<A HREF="cwg_closed.html#1626">1626</A>,
<A HREF="cwg_closed.html#1627">1627</A>,
<A HREF="cwg_active.html#1628">1628</A>,
<A HREF="cwg_defects.html#1629">1629</A>,
<A HREF="cwg_defects.html#1630">1630</A>,
<A HREF="cwg_defects.html#1631">1631</A>,
<A HREF="cwg_defects.html#1632">1632</A>,
<A HREF="cwg_defects.html#1633">1633</A>,
<A HREF="cwg_active.html#1634">1634</A>,
<A HREF="cwg_active.html#1635">1635</A>,
<A HREF="cwg_defects.html#1636">1636</A>,
<A HREF="cwg_closed.html#1637">1637</A>,
<A HREF="cwg_defects.html#1638">1638</A>,
<A HREF="cwg_defects.html#1639">1639</A>,
<A HREF="cwg_defects.html#1640">1640</A>, and
<A HREF="cwg_closed.html#1641">1641</A>.
</LI>

<LI>
<B>Revision 82, 2013-01-14:</B> Incorporated the results of the
drafting review teleconference held 2012-12-10.  Moved issues
<A HREF="cwg_defects.html#903">903</A>, <A HREF="cwg_defects.html#1213">1213</A>,
<A HREF="cwg_defects.html#1358">1358</A>,
<A HREF="cwg_defects.html#1492">1492</A>, <A HREF="cwg_defects.html#1508">1508</A>,
and <A HREF="cwg_defects.html#1552">1552</A> to "review" status to allow further
consideration in light of subsequent discussion.  Added new issues
<A HREF="cwg_defects.html#1569">1569</A>,
<A HREF="cwg_defects.html#1570">1570</A>,
<A HREF="cwg_defects.html#1571">1571</A>,
<A HREF="cwg_defects.html#1572">1572</A>,
<A HREF="cwg_defects.html#1573">1573</A>,
<A HREF="cwg_closed.html#1574">1574</A>,
<A HREF="cwg_defects.html#1575">1575</A>,
<A HREF="cwg_defects.html#1576">1576</A>,
<A HREF="cwg_closed.html#1577">1577</A>,
<A HREF="cwg_closed.html#1578">1578</A>,
<A HREF="cwg_defects.html#1579">1579</A>,
<A HREF="cwg_active.html#1580">1580</A>,
<A HREF="cwg_defects.html#1581">1581</A>,
<A HREF="cwg_active.html#1582">1582</A>,
<A HREF="cwg_defects.html#1583">1583</A>,
<A HREF="cwg_active.html#1584">1584</A>,
<A HREF="cwg_closed.html#1585">1585</A>,
<A HREF="cwg_closed.html#1586">1586</A>,
<A HREF="cwg_defects.html#1587">1587</A>,
<A HREF="cwg_defects.html#1588">1588</A>,
<A HREF="cwg_defects.html#1589">1589</A>,
<A HREF="cwg_defects.html#1590">1590</A>,
<A HREF="cwg_defects.html#1591">1591</A>,
<A HREF="cwg_defects.html#1592">1592</A>,
<A HREF="cwg_defects.html#1593">1593</A>,
<A HREF="cwg_active.html#1594">1594</A>,
<A HREF="cwg_defects.html#1595">1595</A>,
<A HREF="cwg_defects.html#1596">1596</A>,
<A HREF="cwg_defects.html#1597">1597</A>,
<A HREF="cwg_defects.html#1598">1598</A>,
<A HREF="cwg_defects.html#1599">1599</A>,
<A HREF="cwg_defects.html#1600">1600</A>,
<A HREF="cwg_defects.html#1601">1601</A>,
<A HREF="cwg_active.html#1602">1602</A>,
<A HREF="cwg_defects.html#1603">1603</A>,
<A HREF="cwg_defects.html#1604">1604</A>, and
<A HREF="cwg_defects.html#1605">1605</A>.
</LI>

<LI>
<B>Revision 81, 2012-11-03:</B> Reflected the deliberations of the
October, 2012 (Portland) meeting.
Added new issues
<A HREF="cwg_defects.html#1560">1560</A>,
<A HREF="cwg_defects.html#1561">1561</A>,
<A HREF="cwg_defects.html#1562">1562</A>,
<A HREF="cwg_defects.html#1563">1563</A>,
<A HREF="cwg_closed.html#1564">1564</A>,
<A HREF="cwg_closed.html#1565">1565</A>,
<A HREF="cwg_closed.html#1566">1566</A>,
<A HREF="cwg_defects.html#1567">1567</A>, and
<A HREF="cwg_closed.html#1568">1568</A>.
</LI>

<LI>
<B>Revision 80, 2012-09-24:</B> Added remaining descriptions omitted from
issues added in revision 77.  Corrected status of issues
<A HREF="cwg_defects.html#915">915</A>,
<A HREF="cwg_defects.html#1313">1313</A>, <A HREF="cwg_defects.html#1399">1399</A>, and
<A HREF="cwg_defects.html#1437">1437</A>. Changed the status of issues
<A HREF="cwg_defects.html#616">616</A>, <A HREF="cwg_defects.html#903">903</A>,
<A HREF="cwg_defects.html#1318">1318</A>, <A HREF="cwg_defects.html#1358">1358</A>, and
<A HREF="cwg_defects.html#1402">1402</A> in light of additional discussion.
Incorporated the results of the drafting review teleconference held
2012-08-13.  Moved <A HREF="cwg_closed.html#321">issue 321</A> to "dup" status.
Moved <A HREF="cwg_defects.html#591">issue 591</A> to "open" status after the
discussion in "dup" <A HREF="cwg_closed.html#1526">issue 1526</A>.  Added additional
examples to <A HREF="cwg_closed.html#203">issue 203</A>.
Added new issues
<A HREF="cwg_defects.html#1467">1467</A>,
<A HREF="cwg_defects.html#1468">1468</A>,
<A HREF="cwg_defects.html#1469">1469</A>,
<A HREF="cwg_closed.html#1470">1470</A>,
<A HREF="cwg_defects.html#1471">1471</A>,
<A HREF="cwg_defects.html#1472">1472</A>,
<A HREF="cwg_defects.html#1473">1473</A>,
<A HREF="cwg_closed.html#1474">1474</A>,
<A HREF="cwg_defects.html#1475">1475</A>,
<A HREF="cwg_defects.html#1476">1476</A>,
<A HREF="cwg_defects.html#1477">1477</A>,
<A HREF="cwg_defects.html#1478">1478</A>,
<A HREF="cwg_defects.html#1479">1479</A>,
<A HREF="cwg_defects.html#1480">1480</A>,
<A HREF="cwg_defects.html#1481">1481</A>,
<A HREF="cwg_defects.html#1482">1482</A>,
<A HREF="cwg_closed.html#1483">1483</A>,
<A HREF="cwg_defects.html#1484">1484</A>,
<A HREF="cwg_active.html#1485">1485</A>,
<A HREF="cwg_active.html#1486">1486</A>,
<A HREF="cwg_defects.html#1487">1487</A>,
<A HREF="cwg_active.html#1488">1488</A>,
<A HREF="cwg_defects.html#1489">1489</A>,
<A HREF="cwg_defects.html#1490">1490</A>,
<A HREF="cwg_defects.html#1491">1491</A>,
<A HREF="cwg_defects.html#1492">1492</A>,
<A HREF="cwg_defects.html#1493">1493</A>,
<A HREF="cwg_defects.html#1494">1494</A>,
<A HREF="cwg_defects.html#1495">1495</A>,
<A HREF="cwg_defects.html#1496">1496</A>,
<A HREF="cwg_closed.html#1497">1497</A>,
<A HREF="cwg_closed.html#1498">1498</A>,
<A HREF="cwg_defects.html#1499">1499</A>,
<A HREF="cwg_defects.html#1500">1500</A>,
<A HREF="cwg_closed.html#1501">1501</A>,
<A HREF="cwg_defects.html#1502">1502</A>,
<A HREF="cwg_defects.html#1503">1503</A>,
<A HREF="cwg_defects.html#1504">1504</A>,
<A HREF="cwg_closed.html#1505">1505</A>,
<A HREF="cwg_defects.html#1506">1506</A>,
<A HREF="cwg_defects.html#1507">1507</A>,
<A HREF="cwg_defects.html#1508">1508</A>,
<A HREF="cwg_defects.html#1509">1509</A>,
<A HREF="cwg_defects.html#1510">1510</A>,
<A HREF="cwg_defects.html#1511">1511</A>,
<A HREF="cwg_defects.html#1512">1512</A>,
<A HREF="cwg_active.html#1513">1513</A>,
<A HREF="cwg_defects.html#1514">1514</A>,
<A HREF="cwg_defects.html#1515">1515</A>,
<A HREF="cwg_defects.html#1516">1516</A>,
<A HREF="cwg_active.html#1517">1517</A>,
<A HREF="cwg_defects.html#1518">1518</A>,
<A HREF="cwg_closed.html#1519">1519</A>,
<A HREF="cwg_closed.html#1520">1520</A>,
<A HREF="cwg_closed.html#1521">1521</A>,
<A HREF="cwg_defects.html#1522">1522</A>,
<A HREF="cwg_defects.html#1523">1523</A>,
<A HREF="cwg_active.html#1524">1524</A>,
<A HREF="cwg_closed.html#1525">1525</A>,
<A HREF="cwg_closed.html#1526">1526</A>,
<A HREF="cwg_defects.html#1527">1527</A>,
<A HREF="cwg_defects.html#1528">1528</A>,
<A HREF="cwg_active.html#1529">1529</A>,
<A HREF="cwg_active.html#1530">1530</A>,
<A HREF="cwg_defects.html#1531">1531</A>,
<A HREF="cwg_defects.html#1532">1532</A>,
<A HREF="cwg_defects.html#1533">1533</A>,
<A HREF="cwg_closed.html#1534">1534</A>,
<A HREF="cwg_defects.html#1535">1535</A>,
<A HREF="cwg_active.html#1536">1536</A>,
<A HREF="cwg_defects.html#1537">1537</A>,
<A HREF="cwg_defects.html#1538">1538</A>,
<A HREF="cwg_defects.html#1539">1539</A>,
<A HREF="cwg_closed.html#1540">1540</A>,
<A HREF="cwg_defects.html#1541">1541</A>,
<A HREF="cwg_active.html#1542">1542</A>,
<A HREF="cwg_defects.html#1543">1543</A>,
<A HREF="cwg_defects.html#1544">1544</A>,
<A HREF="cwg_closed.html#1545">1545</A>,
<A HREF="cwg_closed.html#1546">1546</A>,
<A HREF="cwg_closed.html#1547">1547</A>,
<A HREF="cwg_active.html#1548">1548</A>,
<A HREF="cwg_active.html#1549">1549</A>,
<A HREF="cwg_defects.html#1550">1550</A>,
<A HREF="cwg_defects.html#1551">1551</A>,
<A HREF="cwg_defects.html#1552">1552</A>,
<A HREF="cwg_defects.html#1553">1553</A>,
<A HREF="cwg_active.html#1554">1554</A>,
<A HREF="cwg_closed.html#1555">1555</A>,
<A HREF="cwg_defects.html#1556">1556</A>,
<A HREF="cwg_defects.html#1557">1557</A>,
<A HREF="cwg_defects.html#1558">1558</A>, and
<A HREF="cwg_defects.html#1559">1559</A>.
</LI>

<LI>
<B>Revision 79, 2012-02-27:</B> Reflected deliberations at the
February, 2012 (Kona) meeting.
Added descriptions omitted from some issues
added in revision 77.  Moved <A HREF="cwg_closed.html#1427">issue 1427</A> to
"NAD" status. Moved <A HREF="cwg_closed.html#1377">issue 1377</A> to "dup" status
(with respect to <A HREF="cwg_active.html#1279">issue 1279</A>).
Moved <A HREF="cwg_closed.html#1422">issue 1422</A> to "dup"
status (with respect to <A HREF="cwg_defects.html#912">issue 912</A>). Added a
new status, "concurrency", to track issues that will be considered and
resolved by the Concurrency Working Group.
Added new issues
<A HREF="cwg_active.html#1444">1444</A>,
<A HREF="cwg_closed.html#1445">1445</A>,
<A HREF="cwg_defects.html#1446">1446</A>,
<A HREF="cwg_defects.html#1447">1447</A>,
<A HREF="cwg_closed.html#1448">1448</A>,
<A HREF="cwg_defects.html#1449">1449</A>,
<A HREF="cwg_defects.html#1450">1450</A>,
<A HREF="cwg_defects.html#1451">1451</A>,
<A HREF="cwg_closed.html#1452">1452</A>,
<A HREF="cwg_defects.html#1453">1453</A>,
<A HREF="cwg_defects.html#1454">1454</A>,
<A HREF="cwg_defects.html#1455">1455</A>,
<A HREF="cwg_defects.html#1456">1456</A>,
<A HREF="cwg_defects.html#1457">1457</A>,
<A HREF="cwg_defects.html#1458">1458</A>,
<A HREF="cwg_active.html#1459">1459</A>,
<A HREF="cwg_defects.html#1460">1460</A>,
<A HREF="cwg_closed.html#1461">1461</A>,
<A HREF="cwg_defects.html#1462">1462</A>,
<A HREF="cwg_active.html#1463">1463</A>,
<A HREF="cwg_defects.html#1464">1464</A>,
<A HREF="cwg_defects.html#1465">1465</A>, and
<A HREF="cwg_defects.html#1466">1466</A>.
</LI>

<LI>
<B>Revision 78, 2012-01-17:</B> Reflected the results of the
December 5, 2011 teleconference.
Changed the status of issues
<A HREF="cwg_defects.html#496">496</A>,
<A HREF="cwg_defects.html#675">675</A>,
<A HREF="cwg_defects.html#739">739</A>,
<A HREF="cwg_defects.html#1268">1268</A>,
<A HREF="cwg_defects.html#1269">1269</A>,
<A HREF="cwg_defects.html#1287">1287</A>, and
<A HREF="cwg_defects.html#1312">1312</A> from "ready" to "review" in response to
further discussion of the proposed resolutions.
Added new issues
<A HREF="cwg_defects.html#1370">1370</A>,
<A HREF="cwg_closed.html#1371">1371</A>,
<A HREF="cwg_defects.html#1372">1372</A>,
<A HREF="cwg_closed.html#1373">1373</A>,
<A HREF="cwg_defects.html#1374">1374</A>,
<A HREF="cwg_defects.html#1375">1375</A>,
<A HREF="cwg_defects.html#1376">1376</A>,
<A HREF="cwg_closed.html#1377">1377</A>,
<A HREF="cwg_defects.html#1378">1378</A>,
<A HREF="cwg_closed.html#1379">1379</A>,
<A HREF="cwg_defects.html#1380">1380</A>,
<A HREF="cwg_defects.html#1381">1381</A>,
<A HREF="cwg_defects.html#1382">1382</A>,
<A HREF="cwg_defects.html#1383">1383</A>,
<A HREF="cwg_closed.html#1384">1384</A>,
<A HREF="cwg_defects.html#1385">1385</A>,
<A HREF="cwg_closed.html#1386">1386</A>,
<A HREF="cwg_defects.html#1387">1387</A>,
<A HREF="cwg_defects.html#1388">1388</A>,
<A HREF="cwg_closed.html#1389">1389</A>,
<A HREF="cwg_active.html#1390">1390</A>,
<A HREF="cwg_defects.html#1391">1391</A>,
<A HREF="cwg_defects.html#1392">1392</A>,
<A HREF="cwg_defects.html#1393">1393</A>,
<A HREF="cwg_defects.html#1394">1394</A>,
<A HREF="cwg_defects.html#1395">1395</A>,
<A HREF="cwg_defects.html#1396">1396</A>,
<A HREF="cwg_defects.html#1397">1397</A>,
<A HREF="cwg_defects.html#1398">1398</A>,
<A HREF="cwg_defects.html#1399">1399</A>,
<A HREF="cwg_closed.html#1400">1400</A>,
<A HREF="cwg_defects.html#1401">1401</A>,
<A HREF="cwg_defects.html#1402">1402</A>,
<A HREF="cwg_defects.html#1403">1403</A>,
<A HREF="cwg_active.html#1404">1404</A>,
<A HREF="cwg_defects.html#1405">1405</A>,
<A HREF="cwg_defects.html#1406">1406</A>,
<A HREF="cwg_closed.html#1407">1407</A>,
<A HREF="cwg_defects.html#1408">1408</A>,
<A HREF="cwg_defects.html#1409">1409</A>,
<A HREF="cwg_defects.html#1410">1410</A>,
<A HREF="cwg_defects.html#1411">1411</A>,
<A HREF="cwg_defects.html#1412">1412</A>,
<A HREF="cwg_defects.html#1413">1413</A>,
<A HREF="cwg_active.html#1414">1414</A>,
<A HREF="cwg_defects.html#1415">1415</A>,
<A HREF="cwg_defects.html#1416">1416</A>,
<A HREF="cwg_defects.html#1417">1417</A>,
<A HREF="cwg_defects.html#1418">1418</A>,
<A HREF="cwg_closed.html#1419">1419</A>,
<A HREF="cwg_closed.html#1420">1420</A>,
<A HREF="cwg_closed.html#1421">1421</A>,
<A HREF="cwg_closed.html#1422">1422</A>,
<A HREF="cwg_defects.html#1423">1423</A>,
<A HREF="cwg_defects.html#1424">1424</A>,
<A HREF="cwg_defects.html#1425">1425</A>,
<A HREF="cwg_defects.html#1426">1426</A>,
<A HREF="cwg_closed.html#1427">1427</A>,
<A HREF="cwg_defects.html#1428">1428</A>,
<A HREF="cwg_closed.html#1429">1429</A>,
<A HREF="cwg_active.html#1430">1430</A>,
<A HREF="cwg_defects.html#1431">1431</A>,
<A HREF="cwg_active.html#1432">1432</A>,
<A HREF="cwg_closed.html#1433">1433</A>,
<A HREF="cwg_closed.html#1434">1434</A>,
<A HREF="cwg_defects.html#1435">1435</A>,
<A HREF="cwg_active.html#1436">1436</A>,
<A HREF="cwg_defects.html#1437">1437</A>,
<A HREF="cwg_defects.html#1438">1438</A>,
<A HREF="cwg_defects.html#1439">1439</A>,
<A HREF="cwg_defects.html#1440">1440</A>,
<A HREF="cwg_defects.html#1441">1441</A>,
<A HREF="cwg_defects.html#1442">1442</A>, and
<A HREF="cwg_closed.html#1443">1443</A>.
</LI>

<LI>
<B>Revision 77, 2011-09-06:</B> Reflected the deliberations of the
August, 2011 (Bloomington) meeting.  Added new issues
<A HREF="cwg_defects.html#1247">1247</A>,
<A HREF="cwg_active.html#1248">1248</A>,
<A HREF="cwg_defects.html#1249">1249</A>,
<A HREF="cwg_defects.html#1250">1250</A>,
<A HREF="cwg_defects.html#1251">1251</A>,
<A HREF="cwg_defects.html#1252">1252</A>,
<A HREF="cwg_defects.html#1253">1253</A>,
<A HREF="cwg_closed.html#1254">1254</A>,
<A HREF="cwg_active.html#1255">1255</A>,
<A HREF="cwg_active.html#1256">1256</A>,
<A HREF="cwg_active.html#1257">1257</A>,
<A HREF="cwg_defects.html#1258">1258</A>,
<A HREF="cwg_closed.html#1259">1259</A>,
<A HREF="cwg_defects.html#1260">1260</A>,
<A HREF="cwg_defects.html#1261">1261</A>,
<A HREF="cwg_defects.html#1262">1262</A>,
<A HREF="cwg_closed.html#1263">1263</A>,
<A HREF="cwg_defects.html#1264">1264</A>,
<A HREF="cwg_defects.html#1265">1265</A>,
<A HREF="cwg_active.html#1266">1266</A>,
<A HREF="cwg_defects.html#1267">1267</A>,
<A HREF="cwg_defects.html#1268">1268</A>,
<A HREF="cwg_defects.html#1269">1269</A>,
<A HREF="cwg_defects.html#1270">1270</A>,
<A HREF="cwg_defects.html#1271">1271</A>,
<A HREF="cwg_closed.html#1272">1272</A>,
<A HREF="cwg_closed.html#1273">1273</A>,
<A HREF="cwg_defects.html#1274">1274</A>,
<A HREF="cwg_defects.html#1275">1275</A>,
<A HREF="cwg_closed.html#1276">1276</A>,
<A HREF="cwg_closed.html#1277">1277</A>,
<A HREF="cwg_active.html#1278">1278</A>,
<A HREF="cwg_active.html#1279">1279</A>,
<A HREF="cwg_closed.html#1280">1280</A>,
<A HREF="cwg_closed.html#1281">1281</A>,
<A HREF="cwg_defects.html#1282">1282</A>,
<A HREF="cwg_active.html#1283">1283</A>,
<A HREF="cwg_defects.html#1284">1284</A>,
<A HREF="cwg_closed.html#1285">1285</A>,
<A HREF="cwg_active.html#1286">1286</A>,
<A HREF="cwg_defects.html#1287">1287</A>,
<A HREF="cwg_defects.html#1288">1288</A>,
<A HREF="cwg_closed.html#1289">1289</A>,
<A HREF="cwg_defects.html#1290">1290</A>,
<A HREF="cwg_defects.html#1291">1291</A>,
<A HREF="cwg_defects.html#1292">1292</A>,
<A HREF="cwg_defects.html#1293">1293</A>,
<A HREF="cwg_active.html#1294">1294</A>,
<A HREF="cwg_defects.html#1295">1295</A>,
<A HREF="cwg_defects.html#1296">1296</A>,
<A HREF="cwg_defects.html#1297">1297</A>,
<A HREF="cwg_defects.html#1298">1298</A>,
<A HREF="cwg_defects.html#1299">1299</A>,
<A HREF="cwg_closed.html#1300">1300</A>,
<A HREF="cwg_defects.html#1301">1301</A>,
<A HREF="cwg_defects.html#1302">1302</A>,
<A HREF="cwg_closed.html#1303">1303</A>,
<A HREF="cwg_active.html#1304">1304</A>,
<A HREF="cwg_defects.html#1305">1305</A>,
<A HREF="cwg_defects.html#1306">1306</A>,
<A HREF="cwg_defects.html#1307">1307</A>,
<A HREF="cwg_defects.html#1308">1308</A>,
<A HREF="cwg_defects.html#1309">1309</A>,
<A HREF="cwg_defects.html#1310">1310</A>,
<A HREF="cwg_defects.html#1311">1311</A>,
<A HREF="cwg_defects.html#1312">1312</A>,
<A HREF="cwg_defects.html#1313">1313</A>,
<A HREF="cwg_closed.html#1314">1314</A>,
<A HREF="cwg_defects.html#1315">1315</A>,
<A HREF="cwg_closed.html#1316">1316</A>,
<A HREF="cwg_closed.html#1317">1317</A>,
<A HREF="cwg_defects.html#1318">1318</A>,
<A HREF="cwg_closed.html#1319">1319</A>,
<A HREF="cwg_defects.html#1320">1320</A>,
<A HREF="cwg_defects.html#1321">1321</A>,
<A HREF="cwg_active.html#1322">1322</A>,
<A HREF="cwg_closed.html#1323">1323</A>,
<A HREF="cwg_defects.html#1324">1324</A>,
<A HREF="cwg_closed.html#1325">1325</A>,
<A HREF="cwg_closed.html#1326">1326</A>,
<A HREF="cwg_defects.html#1327">1327</A>,
<A HREF="cwg_defects.html#1328">1328</A>,
<A HREF="cwg_defects.html#1329">1329</A>,
<A HREF="cwg_defects.html#1330">1330</A>,
<A HREF="cwg_defects.html#1331">1331</A>,
<A HREF="cwg_defects.html#1332">1332</A>,
<A HREF="cwg_defects.html#1333">1333</A>,
<A HREF="cwg_closed.html#1334">1334</A>,
<A HREF="cwg_defects.html#1335">1335</A>,
<A HREF="cwg_defects.html#1336">1336</A>,
<A HREF="cwg_closed.html#1337">1337</A>,
<A HREF="cwg_defects.html#1338">1338</A>,
<A HREF="cwg_closed.html#1339">1339</A>,
<A HREF="cwg_defects.html#1340">1340</A>,
<A HREF="cwg_closed.html#1341">1341</A>,
<A HREF="cwg_defects.html#1342">1342</A>,
<A HREF="cwg_defects.html#1343">1343</A>,
<A HREF="cwg_defects.html#1344">1344</A>,
<A HREF="cwg_defects.html#1345">1345</A>,
<A HREF="cwg_defects.html#1346">1346</A>,
<A HREF="cwg_defects.html#1347">1347</A>,
<A HREF="cwg_active.html#1348">1348</A>,
<A HREF="cwg_closed.html#1349">1349</A>,
<A HREF="cwg_defects.html#1350">1350</A>,
<A HREF="cwg_defects.html#1351">1351</A>,
<A HREF="cwg_defects.html#1352">1352</A>,
<A HREF="cwg_defects.html#1353">1353</A>,
<A HREF="cwg_defects.html#1354">1354</A>,
<A HREF="cwg_defects.html#1355">1355</A>,
<A HREF="cwg_defects.html#1356">1356</A>,
<A HREF="cwg_defects.html#1357">1357</A>,
<A HREF="cwg_defects.html#1358">1358</A>,
<A HREF="cwg_defects.html#1359">1359</A>,
<A HREF="cwg_defects.html#1360">1360</A>,
<A HREF="cwg_defects.html#1361">1361</A>,
<A HREF="cwg_defects.html#1362">1362</A>,
<A HREF="cwg_defects.html#1363">1363</A>,
<A HREF="cwg_defects.html#1364">1364</A>,
<A HREF="cwg_defects.html#1365">1365</A>,
<A HREF="cwg_defects.html#1366">1366</A>,
<A HREF="cwg_defects.html#1367">1367</A>,
<A HREF="cwg_defects.html#1368">1368</A>, and
<A HREF="cwg_defects.html#1369">1369</A>.
(Note that many of the preceding issues are missing descriptions.
These will be provided in the next revision of the issues list.)
</LI>

<LI>
<B>Revision 76, 2011-04-10:</B> Reflected the results of the March
7, 2011 teleconference and the March, 2011 (Madrid) meeting, including
adding a new status, "FDIS," for issues that are resolved in the draft
advanced at that meeting for FDIS balloting. In respect for ISO rules
governing work during the balloting process, no new issues have been
included in this version of the list.</LI>

<LI>
<B>Revision 75, 2011-02-28:</B> 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_closed.html#109">issue 109</A> in light of recent discussion.  Moved <A HREF="cwg_defects.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_defects.html#1227">1227</A>,
<A HREF="cwg_closed.html#1228">1228</A>,
<A HREF="cwg_defects.html#1229">1229</A>,
<A HREF="cwg_closed.html#1230">1230</A>,
<A HREF="cwg_defects.html#1231">1231</A>,
<A HREF="cwg_defects.html#1232">1232</A>,
<A HREF="cwg_defects.html#1233">1233</A>,
<A HREF="cwg_defects.html#1234">1234</A>,
<A HREF="cwg_defects.html#1235">1235</A>,
<A HREF="cwg_defects.html#1236">1236</A>,
<A HREF="cwg_defects.html#1237">1237</A>,
<A HREF="cwg_defects.html#1238">1238</A>,
<A HREF="cwg_defects.html#1239">1239</A>,
<A HREF="cwg_defects.html#1240">1240</A>,
<A HREF="cwg_defects.html#1241">1241</A>,
<A HREF="cwg_defects.html#1242">1242</A>,
<A HREF="cwg_defects.html#1243">1243</A>,
<A HREF="cwg_defects.html#1244">1244</A>,
<A HREF="cwg_defects.html#1245">1245</A>, and
<A HREF="cwg_defects.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_defects.html#1212">1212</A>,
<A HREF="cwg_defects.html#1213">1213</A>,
<A HREF="cwg_defects.html#1214">1214</A>,
<A HREF="cwg_defects.html#1215">1215</A>,
<A HREF="cwg_defects.html#1216">1216</A>,
<A HREF="cwg_closed.html#1217">1217</A>,
<A HREF="cwg_defects.html#1218">1218</A>,
<A HREF="cwg_defects.html#1219">1219</A>,
<A HREF="cwg_defects.html#1220">1220</A>,
<A HREF="cwg_active.html#1221">1221</A>,
<A HREF="cwg_closed.html#1222">1222</A>,
<A HREF="cwg_defects.html#1223">1223</A>,
<A HREF="cwg_defects.html#1224">1224</A>,
<A HREF="cwg_defects.html#1225">1225</A>, and
<A HREF="cwg_defects.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_closed.html#1058">1058</A>
back to "open" status for potential reconsideration. Added analysis to
<A HREF="cwg_defects.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_defects.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_defects.html#1174">1174</A>,
<A HREF="cwg_defects.html#1175">1175</A>,
<A HREF="cwg_defects.html#1176">1176</A>,
<A HREF="cwg_defects.html#1177">1177</A>,
<A HREF="cwg_defects.html#1178">1178</A>,
<A HREF="cwg_closed.html#1179">1179</A>,
<A HREF="cwg_defects.html#1180">1180</A>,
<A HREF="cwg_defects.html#1181">1181</A>,
<A HREF="cwg_defects.html#1182">1182</A>,
<A HREF="cwg_defects.html#1183">1183</A>,
<A HREF="cwg_defects.html#1184">1184</A>,
<A HREF="cwg_defects.html#1185">1185</A>,
<A HREF="cwg_defects.html#1186">1186</A>,
<A HREF="cwg_defects.html#1187">1187</A>,
<A HREF="cwg_defects.html#1188">1188</A>,
<A HREF="cwg_defects.html#1189">1189</A>,
<A HREF="cwg_defects.html#1190">1190</A>,
<A HREF="cwg_defects.html#1191">1191</A>,
<A HREF="cwg_defects.html#1192">1192</A>,
<A HREF="cwg_defects.html#1193">1193</A>,
<A HREF="cwg_defects.html#1194">1194</A>,
<A HREF="cwg_defects.html#1195">1195</A>,
<A HREF="cwg_defects.html#1196">1196</A>,
<A HREF="cwg_defects.html#1197">1197</A>,
<A HREF="cwg_defects.html#1198">1198</A>,
<A HREF="cwg_defects.html#1199">1199</A>,
<A HREF="cwg_defects.html#1200">1200</A>,
<A HREF="cwg_defects.html#1201">1201</A>,
<A HREF="cwg_defects.html#1202">1202</A>,
<A HREF="cwg_closed.html#1203">1203</A>,
<A HREF="cwg_defects.html#1204">1204</A>,
<A HREF="cwg_closed.html#1205">1205</A>,
<A HREF="cwg_defects.html#1206">1206</A>,
<A HREF="cwg_defects.html#1207">1207</A>,
<A HREF="cwg_defects.html#1208">1208</A>,
<A HREF="cwg_active.html#1209">1209</A>, and
<A HREF="cwg_defects.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_defects.html#1091">1091</A>,
<A HREF="cwg_active.html#1092">1092</A>,
<A HREF="cwg_defects.html#1093">1093</A>,
<A HREF="cwg_defects.html#1094">1094</A>,
<A HREF="cwg_defects.html#1095">1095</A>,
<A HREF="cwg_defects.html#1096">1096</A>,
<A HREF="cwg_closed.html#1097">1097</A>,
<A HREF="cwg_defects.html#1098">1098</A>,
<A HREF="cwg_defects.html#1099">1099</A>,
<A HREF="cwg_defects.html#1100">1100</A>,
<A HREF="cwg_defects.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_closed.html#1108">1108</A>,
<A HREF="cwg_defects.html#1109">1109</A>,
<A HREF="cwg_closed.html#1110">1110</A>,
<A HREF="cwg_defects.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_defects.html#1115">1115</A>,
<A HREF="cwg_defects.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_defects.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_defects.html#1133">1133</A>,
<A HREF="cwg_defects.html#1134">1134</A>,
<A HREF="cwg_defects.html#1135">1135</A>,
<A HREF="cwg_defects.html#1136">1136</A>,
<A HREF="cwg_defects.html#1137">1137</A>,
<A HREF="cwg_defects.html#1138">1138</A>,
<A HREF="cwg_defects.html#1139">1139</A>,
<A HREF="cwg_defects.html#1140">1140</A>,
<A HREF="cwg_closed.html#1141">1141</A>,
<A HREF="cwg_defects.html#1142">1142</A>,
<A HREF="cwg_closed.html#1143">1143</A>,
<A HREF="cwg_defects.html#1144">1144</A>,
<A HREF="cwg_defects.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_defects.html#1149">1149</A>,
<A HREF="cwg_closed.html#1150">1150</A>,
<A HREF="cwg_defects.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_defects.html#1166">1166</A>,
<A HREF="cwg_defects.html#1167">1167</A>,
<A HREF="cwg_defects.html#1168">1168</A>,
<A HREF="cwg_defects.html#1169">1169</A>,
<A HREF="cwg_defects.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_defects.html#1071">1071</A>,
<A HREF="cwg_defects.html#1072">1072</A>,
<A HREF="cwg_defects.html#1073">1073</A>,
<A HREF="cwg_defects.html#1074">1074</A>,
<A HREF="cwg_defects.html#1075">1075</A>,
<A HREF="cwg_defects.html#1076">1076</A>,
<A HREF="cwg_closed.html#1077">1077</A>,
<A HREF="cwg_closed.html#1078">1078</A>,
<A HREF="cwg_defects.html#1079">1079</A>,
<A HREF="cwg_defects.html#1080">1080</A>,
<A HREF="cwg_defects.html#1081">1081</A>,
<A HREF="cwg_defects.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_defects.html#1088">1088</A>,
<A HREF="cwg_active.html#1089">1089</A>, and
<A HREF="cwg_defects.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_defects.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_defects.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_active.html#1001">1001</A>,
<A HREF="cwg_closed.html#1002">1002</A>,
<A HREF="cwg_defects.html#1003">1003</A>,
<A HREF="cwg_defects.html#1004">1004</A>,
<A HREF="cwg_closed.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_defects.html#1013">1013</A>,
<A HREF="cwg_closed.html#1014">1014</A>,
<A HREF="cwg_defects.html#1015">1015</A>,
<A HREF="cwg_defects.html#1016">1016</A>,
<A HREF="cwg_defects.html#1017">1017</A>,
<A HREF="cwg_defects.html#1018">1018</A>,
<A HREF="cwg_closed.html#1019">1019</A>,
<A HREF="cwg_defects.html#1020">1020</A>,
<A HREF="cwg_defects.html#1021">1021</A>,
<A HREF="cwg_defects.html#1022">1022</A>,
<A HREF="cwg_closed.html#1023">1023</A>,
<A HREF="cwg_defects.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_defects.html#1028">1028</A>,
<A HREF="cwg_defects.html#1029">1029</A>,
<A HREF="cwg_defects.html#1030">1030</A>,
<A HREF="cwg_defects.html#1031">1031</A>,
<A HREF="cwg_defects.html#1032">1032</A>,
<A HREF="cwg_defects.html#1033">1033</A>,
<A HREF="cwg_defects.html#1034">1034</A>,
<A HREF="cwg_defects.html#1035">1035</A>,
<A HREF="cwg_defects.html#1036">1036</A>,
<A HREF="cwg_defects.html#1037">1037</A>,
<A HREF="cwg_defects.html#1038">1038</A>,
<A HREF="cwg_closed.html#1039">1039</A>,
<A HREF="cwg_closed.html#1040">1040</A>,
<A HREF="cwg_closed.html#1041">1041</A>,
<A HREF="cwg_defects.html#1042">1042</A>,
<A HREF="cwg_defects.html#1043">1043</A>,
<A HREF="cwg_defects.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_defects.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="cwg_closed.html#1052">1052</A>,
<A HREF="cwg_closed.html#1053">1053</A>,
<A HREF="cwg_defects.html#1054">1054</A>,
<A HREF="cwg_defects.html#1055">1055</A>,
<A HREF="cwg_defects.html#1056">1056</A>,
<A HREF="cwg_defects.html#1057">1057</A>,
<A HREF="cwg_closed.html#1058">1058</A>,
<A HREF="cwg_defects.html#1059">1059</A>,
<A HREF="cwg_defects.html#1060">1060</A>,
<A HREF="cwg_defects.html#1061">1061</A>,
<A HREF="cwg_defects.html#1062">1062</A>,
<A HREF="cwg_defects.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_defects.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_defects.html#974">974</A>,
<A HREF="cwg_defects.html#975">975</A>,
<A HREF="cwg_defects.html#976">976</A>,
<A HREF="cwg_defects.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_defects.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_defects.html#985">985</A>,
<A HREF="cwg_defects.html#986">986</A>,
<A HREF="cwg_defects.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_defects.html#993">993</A>,
<A HREF="cwg_defects.html#994">994</A>,
<A HREF="cwg_defects.html#995">995</A>,
<A HREF="cwg_defects.html#996">996</A>,
<A HREF="cwg_defects.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_defects.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_closed.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_defects.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., <INS>inserted</INS> and <DEL>deleted</DEL>
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_defects.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_defects.html#943">943</A>,
<A HREF="cwg_closed.html#944">944</A>,
<A HREF="cwg_defects.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_defects.html#898">898</A>,
<A HREF="cwg_defects.html#899">899</A>,
<A HREF="cwg_defects.html#900">900</A>,
<A HREF="cwg_active.html#901">901</A>,
<A HREF="cwg_closed.html#902">902</A>,
<A HREF="cwg_defects.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_defects.html#912">912</A>,
<A HREF="cwg_defects.html#913">913</A>,
<A HREF="cwg_active.html#914">914</A>,
<A HREF="cwg_defects.html#915">915</A>,
<A HREF="cwg_closed.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_defects.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_defects.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_defects.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_defects.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_defects.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_defects.html#837">837</A>,
<A HREF="cwg_defects.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_defects.html#755">755</A>,
<A HREF="cwg_defects.html#756">756</A>,
<A HREF="cwg_defects.html#757">757</A>,
<A HREF="cwg_defects.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_defects.html#727">727</A>,
<A HREF="cwg_closed.html#728">728</A>,
<A HREF="cwg_defects.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_defects.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_defects.html#745">745</A>,
<A HREF="cwg_defects.html#746">746</A>,
<A HREF="cwg_closed.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_defects.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_defects.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_closed.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_defects.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_defects.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_defects.html#292">292</A>,
<A HREF="cwg_defects.html#341">341</A>,
<A HREF="cwg_defects.html#539">539</A>,
<A HREF="cwg_defects.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_defects.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_defects.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_defects.html#689">689</A>,
<A HREF="cwg_defects.html#690">690</A>,
<A HREF="cwg_defects.html#691">691</A>,
<A HREF="cwg_defects.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 (Clause 3 [<A href="https://wg21.link/intro.defs">intro.defs</A>],
_N4567_.17.3 [<A href="https://wg21.link/definitions">definitions</A>]) 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_closed.html#512">512</A>,
and <A HREF="cwg_closed.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_closed.html#6">6</A> and <A HREF="cwg_defects.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_defects.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_defects.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_defects.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_closed.html#111">111</A>,
<A HREF="cwg_defects.html#118">118</A>,
<A HREF="cwg_defects.html#141">141</A>,
<A HREF="cwg_defects.html#240">240</A>,
<A HREF="cwg_defects.html#276">276</A>,
<A HREF="cwg_defects.html#309">309</A>,
<A HREF="cwg_defects.html#355">355</A>,
<A HREF="cwg_defects.html#373">373</A>,
<A HREF="cwg_defects.html#378">378</A>,
<A HREF="cwg_defects.html#462">462</A>,
<A HREF="cwg_defects.html#485">485</A>,
<A HREF="cwg_defects.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_defects.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_closed.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_closed.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_defects.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_defects.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_defects.html#616">616</A>,
<A HREF="cwg_closed.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_defects.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_defects.html#607">607</A>,
<A HREF="cwg_defects.html#608">608</A>,
<A HREF="cwg_defects.html#609">609</A>,
<A HREF="cwg_closed.html#610">610</A>, and
<A HREF="cwg_defects.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_defects.html#342">342</A>, and
<A HREF="cwg_defects.html#572">572</A>, and moved them to &#8220;review&#8221;
status.  Added new issues
<A HREF="cwg_closed.html#596">596</A>,
<A HREF="cwg_defects.html#597">597</A>,
<A HREF="cwg_defects.html#598">598</A>,
<A HREF="cwg_defects.html#599">599</A>,
<A HREF="cwg_defects.html#600">600</A>,
<A HREF="cwg_defects.html#601">601</A>, and
<A HREF="cwg_defects.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_defects.html#590">590</A>,
<A HREF="cwg_defects.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_closed.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_defects.html#578">578</A>,
<A HREF="cwg_active.html#579">579</A>,
<A HREF="cwg_defects.html#580">580</A>,
<A HREF="cwg_defects.html#581">581</A>,
<A HREF="cwg_defects.html#582">582</A>,
<A HREF="cwg_defects.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_defects.html#562">562</A>,
<A HREF="cwg_defects.html#563">563</A>,
<A HREF="cwg_defects.html#564">564</A>,
<A HREF="cwg_defects.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_defects.html#572">572</A>,
<A HREF="cwg_defects.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_defects.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_defects.html#453">issue 453</A> to note the need for additional
drafting.  Reopened <A HREF="cwg_closed.html#504">issue 504</A> and broadened
its scope to include object declarations as well.  Updated
<A HREF="cwg_defects.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_defects.html#554">554</A>,
<A HREF="cwg_defects.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_closed.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_defects.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_defects.html#547">547</A>,
<A HREF="cwg_closed.html#548">548</A>,
<A HREF="cwg_active.html#549">549</A>,
<A HREF="cwg_closed.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_defects.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_defects.html#535">535</A>,
<A HREF="cwg_defects.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_closed.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_closed.html#459">459</A> with additional
discussion.  Added new issues
<A HREF="cwg_closed.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_closed.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_closed.html#232">232</A>,
<A HREF="cwg_defects.html#339">339</A>,
<A HREF="cwg_defects.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_defects.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_defects.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_defects.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_defects.html#482">482</A>,
<A HREF="cwg_defects.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_defects.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_closed.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_defects.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_defects.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_defects.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_defects.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_defects.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_closed.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_defects.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
13.9.4 [<A href="https://wg21.link/temp.expl.spec#9">temp.expl.spec</A>] 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
6.5.6 [<A href="https://wg21.link/basic.lookup.elab">basic.lookup.elab</A>];
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_defects.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_defects.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_defects.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_closed.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_defects.html#110">110</A>,
<A HREF="cwg_closed.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%20Status"></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 a change
in the working draft is required, the <I>Proposed Resolution</I> is
correct, and the issue is ready to forward to the full Committee for
ratification.</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 between-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>accepted:</B> Like a DR except that the issue concerns the
wording of the current Working Paper rather than that of the current
International Standard.</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>C++11:</B> A DR issue not resolved in CD2 but included
in ISO/IEC 14882:2011.</P>

<P>
<B>CD3:</B> A DR/DRWP or Accepted/WP issue not resolved
in C++11 but included in the Committee Draft advanceed for
balloting at the April, 2013 WG21 meeting.</P>

<P>
<B>C++14:</B> A DR/DRWP or Accepted/WP issue not resolved
in CD3 but included in ISO/IEC 14882:2014.</P>

<P>
<B>CD4:</B> A DR/DRWP or Accepted/WP issue not resolved in
C++14 but included in the Committee Draft advanced for balloting
at the June, 2016 WG21 meeting.</P>

<P>
<B>C++17:</B> a DR/DRWP or Accepted/WP issue not resolved in
CD4 but included in ISO/IEC 14882:2017.</P>

<P>
<B>CD5:</B> A DR/DRWP or Accepted/WP issue not resolved in
C++17 but included in the Committee Draft advanced for balloting
at the July, 2019 WG21 meeting.</P>

<P>
<B>C++20:</B> a DR/DRWP or Accepted/WP issue not resolved in
CD5 but included in ISO/IEC 14882:2020.</P>

<P>
<B>CD6:</B> A DR/DRWP or Accepted/WP issue not resolved in
C++20 but included in the Committee Draft advanced for balloting
at the July, 2022 WG21 meeting.</P>

<P>
<B>C++23:</B> a DR/DRWP or Accepted/WP issue not resolved in
CD6 but included in ISO/IEC 14882:2024.</P>

<P>
<B>CD7:</B> A DR/DRWP or Accepted/WP issue not resolved in
C++23 but included in the Committee Draft advanced for balloting
at the June, 2025 WG21 meeting.</P>

<P>
<B>DRWP:</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>WP:</B> An accepted issue whose resolution is reflected in
the current Working Paper.</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="Overview"></A><H3>Overview</H3>
<TABLE BORDER="1" CELLSPACING="0" CELLPADDING="4">
<TR>
<TD ALIGN="CENTER"><B>Section</B></TD>
<TD ALIGN="CENTER"><B>Issue</B></TD>
<TD ALIGN="CENTER"><B>Status</B></TD>
<TD ALIGN="CENTER"><B>Liaison</B></TD>
<TD ALIGN="CENTER"><B>Title</B></TD>
</TR>
<TR>
<TD ALIGN="LEFT">3&#160;
  <A href="https://wg21.link/intro.defs">intro.defs</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#783">783</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Definition of &#8220;argument&#8221;
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">3&#160;
  <A href="https://wg21.link/intro.defs">intro.defs</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2632">2632</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
'user-declared' is not defined
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">4.1&#160;
  <A href="https://wg21.link/intro.compliance">intro.compliance</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#949">949</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Requirements for freestanding implementations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">4.1.1&#160;
  <A href="https://wg21.link/intro.compliance.general">intro.compliance.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2776">2776</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Substitution failure and implementation limits
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.3.1&#160;
  <A href="https://wg21.link/lex.charset">lex.charset</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2779">2779</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Restrictions on the ordinary literal encoding
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.5&#160;
  <A href="https://wg21.link/lex.pptoken">lex.pptoken</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#369">369</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Are <TT>new</TT>/<TT>delete</TT> identifiers or <I>preprocessing-op-or-punc</I>?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.5&#160;
  <A href="https://wg21.link/lex.pptoken">lex.pptoken</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1655">1655</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Line endings in raw string literals
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.6&#160;
  <A href="https://wg21.link/lex.header">lex.header</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3019">3019</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Restrictions on character sequences in <I>header-name</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.8&#160;
  <A href="https://wg21.link/lex.operators">lex.operators</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#189">189</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Definition of <I>operator</I> and <I>punctuator</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.9&#160;
  <A href="https://wg21.link/lex.digraph">lex.digraph</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2726">2726</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Alternative tokens appearing as <I>attribute-token</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.10&#160;
  <A href="https://wg21.link/lex.token">lex.token</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1901">1901</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<I>punctuator</I> referenced but not defined
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.13&#160;
  <A href="https://wg21.link/lex.literal">lex.literal</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1924">1924</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER">editor</TD>
<TD ALIGN="LEFT">
Definition of &#8220;literal&#8221; and kinds of literals
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.13.4&#160;
  <A href="https://wg21.link/lex.fcon">lex.fcon</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2752">2752</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Excess-precision floating-point literals
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.13.5&#160;
  <A href="https://wg21.link/lex.string">lex.string</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2766">2766</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Repeated evaluation of a <I>string-literal</I> may yield different
objects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.13.9&#160;
  <A href="https://wg21.link/lex.ext">lex.ext</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1266">1266</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<I>user-defined-integer-literal</I> overflow
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.13.9&#160;
  <A href="https://wg21.link/lex.ext">lex.ext</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1723">1723</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Multicharacter user-defined character literals
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">5.13.9&#160;
  <A href="https://wg21.link/lex.ext">lex.ext</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1735">1735</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Out-of-range literals in <I>user-defined-literal</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.1&#160;
  <A href="https://wg21.link/basic.pre">basic.pre</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1529">1529</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Nomenclature for variable vs reference non-static data member
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.1&#160;
  <A href="https://wg21.link/basic.pre">basic.pre</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2983">2983</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Non-type template parameters are not variables
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.1&#160;
  <A href="https://wg21.link/basic.pre">basic.pre</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2992">2992</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Labels do not have names
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.3&#160;
  <A href="https://wg21.link/basic.def.odr">basic.def.odr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1209">1209</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Is a potentially-evaluated expression in a template definition a &#8220;use?&#8221;
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.3&#160;
  <A href="https://wg21.link/basic.def.odr">basic.def.odr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1897">1897</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
ODR vs alternative tokens
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.3&#160;
  <A href="https://wg21.link/basic.def.odr">basic.def.odr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2781">2781</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear recursion in the one-definition rule
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.3&#160;
  <A href="https://wg21.link/basic.def.odr">basic.def.odr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2782">2782</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Treatment of closure types in the one-definition rule
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.4&#160;
  <A href="https://wg21.link/basic.scope">basic.scope</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2969">2969</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Scopes in the <I>function-try-block</I> of a constructor
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.4.1&#160;
  <A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2488">2488</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overloading virtual functions and functions with trailing <I>requires-clause</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.4.1&#160;
  <A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2788">2788</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Correspondence and redeclarations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.4.1&#160;
  <A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2835">2835</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Name-independent declarations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.4.1&#160;
  <A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3005">3005</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Function parameters should never be name-independent
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.4.3&#160;
  <A href="https://wg21.link/basic.scope.block">basic.scope.block</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2838">2838</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Declaration conflicts in <I>lambda-expression</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.4.3&#160;
  <A href="https://wg21.link/basic.scope.block">basic.scope.block</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3045">3045</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Regularizing environment interactions of expansion statement
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.4.6&#160;
  <A href="https://wg21.link/basic.scope.namespace">basic.scope.namespace</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3033">3033</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Scope after <I>declarator-id</I> before determining correspondence
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.4.9&#160;
  <A href="https://wg21.link/basic.scope.temp">basic.scope.temp</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2965">2965</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Generic lambdas do not have a template parameter scope
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.5.1&#160;
  <A href="https://wg21.link/basic.lookup.general">basic.lookup.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2480">2480</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Lookup for enumerators in modules
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.5.1&#160;
  <A href="https://wg21.link/basic.lookup.general">basic.lookup.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2968">2968</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Name lookup result for <I>typedef-name</I> vs. <I>class-name</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.5.1&#160;
  <A href="https://wg21.link/basic.lookup.general">basic.lookup.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3058">3058</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
"Program point" is not defined
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.5.2&#160;
  <A href="https://wg21.link/class.member.lookup">class.member.lookup</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#380">380</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Definition of "ambiguous base class" missing
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.5.4&#160;
  <A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2888">2888</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Missing cases for reference and array types for argument-dependent lookup
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.5.5.1&#160;
  <A href="https://wg21.link/basic.lookup.qual.general">basic.lookup.qual.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1089">1089</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Template parameters in member selections
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.5.5.1&#160;
  <A href="https://wg21.link/basic.lookup.qual.general">basic.lookup.qual.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2926">2926</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Lookup context for dependent qualified names
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.5.5.1&#160;
  <A href="https://wg21.link/basic.lookup.qual.general">basic.lookup.qual.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2956">2956</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Missing allowance for pseudo-destructors in qualified lookup
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.7&#160;
  <A href="https://wg21.link/basic.link">basic.link</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2670">2670</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Programs and translation units
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.7&#160;
  <A href="https://wg21.link/basic.link">basic.link</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2706">2706</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Repeated structured binding declarations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.7&#160;
  <A href="https://wg21.link/basic.link">basic.link</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2938">2938</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Inheriting linkage from a previous declaration
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.7&#160;
  <A href="https://wg21.link/basic.link">basic.link</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2945">2945</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Redundant constraints on matching function template declarations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.7&#160;
  <A href="https://wg21.link/basic.link">basic.link</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2988">2988</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Is a closure type from a <I>lambda-expression</I> appearing in a <I>concept-definition</I> a TU-local entity?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.2&#160;
  <A href="https://wg21.link/intro.object">intro.object</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2324">2324</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Size of base class subobject
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.2&#160;
  <A href="https://wg21.link/intro.object">intro.object</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2325">2325</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<TT>std::launder</TT> and reuse of character buffers
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.2&#160;
  <A href="https://wg21.link/intro.object">intro.object</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2334">2334</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Creation of objects by <TT>typeid</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.2&#160;
  <A href="https://wg21.link/intro.object">intro.object</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2469">2469</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Implicit object creation vs constant expressions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.2&#160;
  <A href="https://wg21.link/intro.object">intro.object</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2744">2744</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Multiple objects of the same type at the same address
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.2&#160;
  <A href="https://wg21.link/intro.object">intro.object</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2765">2765</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Address comparisons between potentially non-unique objects during constant evaluation
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.2&#160;
  <A href="https://wg21.link/intro.object">intro.object</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2940">2940</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Definition of "object"
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.2&#160;
  <A href="https://wg21.link/intro.object">intro.object</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3039">3039</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Undefined behavior from implicit object creation ignores observable checkpoints
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.3&#160;
  <A href="https://wg21.link/basic.align">basic.align</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1211">1211</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Misaligned lvalues
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.3&#160;
  <A href="https://wg21.link/basic.align">basic.align</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2840">2840</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Missing requirements for fundamental alignments
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.3&#160;
  <A href="https://wg21.link/basic.align">basic.align</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3029">3029</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Confusing note about ordinary character types for aligned memory areas
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#419">419</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Can cast to virtual base class be done on partially-constructed object?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1027">1027</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Type consistency and reallocation of scalar types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1530">1530</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Member access in out-of-lifetime objects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2258">2258</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Storage deallocation during period of destruction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2514">2514</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">SG12</TD>
<TD ALIGN="LEFT">
Modifying const subobjects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2551">2551</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
"Refers to allocated storage" has no meaning
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2676">2676</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Replacing a complete object having base subobjects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2677">2677</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Replacing union subobjects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2821">2821</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Lifetime, zero-initialization, and dynamic initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2863">2863</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear synchronization requirements for object lifetime rules
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2952">2952</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Vacuous initialization for subobjects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2960">2960</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Introduce discontiguous object lifetime
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2986">2986</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Creating objects within a mutable member of a const object
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3001">3001</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Inconsistent restrictions for <TT>static_cast</TT> on pointers to out-of-lifetime objects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.4&#160;
  <A href="https://wg21.link/basic.life">basic.life</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3047">3047</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Calling destructors on out-of-lifetime objects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.6&#160;
  <A href="https://wg21.link/basic.stc">basic.stc</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#365">365</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Storage duration and temporaries
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.6&#160;
  <A href="https://wg21.link/basic.stc">basic.stc</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1634">1634</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Temporary storage duration
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.6.5.2&#160;
  <A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1676">1676</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<TT>auto</TT> return type for allocation and deallocation functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.6.5.2&#160;
  <A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1682">1682</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overly-restrictive rules on function templates as allocation functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.6.5.2&#160;
  <A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2073">2073</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Allocating memory for exception objects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.6.5.3&#160;
  <A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#523">523</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Can a one-past-the-end pointer be invalidated by deleting an adjacent object?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.6.5.3&#160;
  <A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2042">2042</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Exceptions and deallocation functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.6.5.3&#160;
  <A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3025">3025</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Deallocation functions returning void
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.7&#160;
  <A href="https://wg21.link/class.temporary">class.temporary</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2434">2434</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Mandatory copy elision vs non-class objects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.7&#160;
  <A href="https://wg21.link/class.temporary">class.temporary</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2666">2666</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Lifetime extension through <TT>static_cast</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.7&#160;
  <A href="https://wg21.link/class.temporary">class.temporary</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2826">2826</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Missing definition of "temporary expression"
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.7&#160;
  <A href="https://wg21.link/class.temporary">class.temporary</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2832">2832</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Invented temporary variables and temporary objects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.7&#160;
  <A href="https://wg21.link/class.temporary">class.temporary</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2868">2868</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Self-references in trivially copyable objects as function return values
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.7&#160;
  <A href="https://wg21.link/class.temporary">class.temporary</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2941">2941</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Lifetime extension for function-style cast to reference type
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.7&#160;
  <A href="https://wg21.link/class.temporary">class.temporary</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3043">3043</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Lifetime extension for temporaries in expansion statements
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.8.7&#160;
  <A href="https://wg21.link/class.temporary">class.temporary</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3063">3063</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Lifetime extension of temporaries past function return
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.9&#160;
  <A href="https://wg21.link/basic.types">basic.types</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#350">350</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">WG14</TD>
<TD ALIGN="LEFT">
<TT>signed char</TT> underlying representation for objects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.9&#160;
  <A href="https://wg21.link/basic.types">basic.types</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1701">1701</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Array vs sequence in object representation
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.9.1&#160;
  <A href="https://wg21.link/basic.types.general">basic.types.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2953">2953</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Value representation for non-trivially-copyable types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.9.2&#160;
  <A href="https://wg21.link/basic.fundamental">basic.fundamental</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#146">146</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Floating-point zero
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.9.2&#160;
  <A href="https://wg21.link/basic.fundamental">basic.fundamental</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#251">251</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
How many signed integer types are there?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.9.2&#160;
  <A href="https://wg21.link/basic.fundamental">basic.fundamental</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2827">2827</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Representation of unsigned integral types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.9.2&#160;
  <A href="https://wg21.link/basic.fundamental">basic.fundamental</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2966">2966</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Alignment and value representation of <TT>std::nullptr_t</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.9.3&#160;
  <A href="https://wg21.link/basic.extended.fp">basic.extended.fp</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3036">3036</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Extended floating-point types should not be cv-qualified
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.9.4&#160;
  <A href="https://wg21.link/basic.compound">basic.compound</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2544">2544</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Address of past-the-end of a potentially-overlapping subobject
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.1&#160;
  <A href="https://wg21.link/intro.execution">intro.execution</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#698">698</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
The definition of &#8220;sequenced before&#8221; is too narrow
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.1&#160;
  <A href="https://wg21.link/intro.execution">intro.execution</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2955">2955</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unify rules about conflicting unordered accesses
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.2&#160;
  <A href="https://wg21.link/intro.multithread">intro.multithread</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1842">1842</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">SG1</TD>
<TD ALIGN="LEFT">
Unevaluated operands and &#8220;carries a dependency&#8221;
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.2.2&#160;
  <A href="https://wg21.link/intro.races">intro.races</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2297">2297</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear specification of atomic operations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.2.2&#160;
  <A href="https://wg21.link/intro.races">intro.races</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2298">2298</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">SG1</TD>
<TD ALIGN="LEFT">
Actions and expression evaluation
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.2.2&#160;
  <A href="https://wg21.link/intro.races">intro.races</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2587">2587</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Visible side effects and initial value of an object
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.2.3&#160;
  <A href="https://wg21.link/intro.progress">intro.progress</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2816">2816</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear phrasing "may assume ... eventually"
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.2.3&#160;
  <A href="https://wg21.link/intro.progress">intro.progress</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2923">2923</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER">SG1</TD>
<TD ALIGN="LEFT">
Note about infinite loops and execution steps
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.3.1&#160;
  <A href="https://wg21.link/basic.start.main">basic.start.main</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3060">3060</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Change in behavior for <TT>noexcept</TT> <TT>main</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.3.2&#160;
  <A href="https://wg21.link/basic.start.static">basic.start.static</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#371">371</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Interleaving of constructor calls
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.3.2&#160;
  <A href="https://wg21.link/basic.start.static">basic.start.static</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1294">1294</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Side effects in dynamic/static initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.3.2&#160;
  <A href="https://wg21.link/basic.start.static">basic.start.static</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1659">1659</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Initialization order of thread_local template static data members
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.3.2&#160;
  <A href="https://wg21.link/basic.start.static">basic.start.static</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1986">1986</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
odr-use and delayed initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.3.2&#160;
  <A href="https://wg21.link/basic.start.static">basic.start.static</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2148">2148</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Thread storage duration and order of initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.3.2&#160;
  <A href="https://wg21.link/basic.start.static">basic.start.static</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2914">2914</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear order of initialization of static and thread-local variables
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.3.3&#160;
  <A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2444">2444</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Constant expressions in initialization odr-use
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.3.3&#160;
  <A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2684">2684</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
thread_local dynamic initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.3.3&#160;
  <A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2833">2833</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Evaluation of odr-use
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.3.3&#160;
  <A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2928">2928</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
No ordering for initializing thread-local variables
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">6.10.3.4&#160;
  <A href="https://wg21.link/basic.start.term">basic.start.term</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2929">2929</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Lifetime of trivially-destructible static or thread-local objects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.2.1&#160;
  <A href="https://wg21.link/basic.lval">basic.lval</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3042">3042</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Implicit object creation is insufficient to model effective type rule of C
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.3.2&#160;
  <A href="https://wg21.link/conv.lval">conv.lval</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2964">2964</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Reading "invalid pointer values"
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.3.6&#160;
  <A href="https://wg21.link/conv.qual">conv.qual</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2438">2438</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Problems in the specification of qualification conversions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.4&#160;
  <A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2981">2981</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Usual arithmetic conversions and result types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.5.4&#160;
  <A href="https://wg21.link/expr.prim.paren">expr.prim.paren</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2989">2989</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Remove misleading general allowance for parentheses
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.5.5&#160;
  <A href="https://wg21.link/expr.prim.id">expr.prim.id</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2503">2503</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear relationship among name, qualified name, and unqualified name
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.5.5.1&#160;
  <A href="https://wg21.link/expr.prim.id.general">expr.prim.id.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2902">2902</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Implicit <TT>this</TT> transformation outside of permitted contexts
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.5.5.2&#160;
  <A href="https://wg21.link/expr.prim.id.unqual">expr.prim.id.unqual</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2738">2738</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
"denotes a destructor" is missing specification
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.5.5.3&#160;
  <A href="https://wg21.link/expr.prim.id.qual">expr.prim.id.qual</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2972">2972</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Declarative <I>nested-name-specifier</I> naming a partial specialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.5.5.5&#160;
  <A href="https://wg21.link/expr.prim.id.dtor">expr.prim.id.dtor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2473">2473</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Parentheses in pseudo-destructor calls
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.5.6.3&#160;
  <A href="https://wg21.link/expr.prim.lambda.capture">expr.prim.lambda.capture</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2086">2086</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Reference odr-use vs implicit capture
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.5.6.3&#160;
  <A href="https://wg21.link/expr.prim.lambda.capture">expr.prim.lambda.capture</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2737">2737</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Temporary lifetime extension for reference init-captures
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.5.8.1&#160;
  <A href="https://wg21.link/expr.prim.req.general">expr.prim.req.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2565">2565</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Invalid types in the <I>parameter-declaration-clause</I> of a <I>requires-expression</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.5.8.3&#160;
  <A href="https://wg21.link/expr.prim.req.type">expr.prim.req.type</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3056">3056</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Missing semicolons in grammar for <I>type-requirement</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.5.8.5&#160;
  <A href="https://wg21.link/expr.prim.req.nested">expr.prim.req.nested</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2739">2739</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Nested requirement not a constant expression
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.3&#160;
  <A href="https://wg21.link/expr.call">expr.call</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2284">2284</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Sequencing of <I>braced-init-list</I> arguments
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.3&#160;
  <A href="https://wg21.link/expr.call">expr.call</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2515">2515</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Result of a function call
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.3&#160;
  <A href="https://wg21.link/expr.call">expr.call</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2660">2660</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Confusing term "this parameter"
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.3&#160;
  <A href="https://wg21.link/expr.call">expr.call</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2688">2688</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Calling explicit object member functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.3&#160;
  <A href="https://wg21.link/expr.call">expr.call</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3054">3054</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Use of default arguments depending on shape of <I>postfix-expression</I> in a function call
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.4&#160;
  <A href="https://wg21.link/expr.type.conv">expr.type.conv</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#914">914</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Value-initialization of array types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.5&#160;
  <A href="https://wg21.link/expr.ref">expr.ref</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2557">2557</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Class member access referring to an unrelated class
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.5&#160;
  <A href="https://wg21.link/expr.ref">expr.ref</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2705">2705</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Accessing ambiguous subobjects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.5&#160;
  <A href="https://wg21.link/expr.ref">expr.ref</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2957">2957</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Evaluating a reference member should constitute access
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.5&#160;
  <A href="https://wg21.link/expr.ref">expr.ref</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2959">2959</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Naming enumerators in class member access expressions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.6&#160;
  <A href="https://wg21.link/expr.post.incr">expr.post.incr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#742">742</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Postfix increment/decrement with long bit-field operands
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.8&#160;
  <A href="https://wg21.link/expr.typeid">expr.typeid</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#282">282</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Namespace for <TT>extended_type_info</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.9&#160;
  <A href="https://wg21.link/expr.static.cast">expr.static.cast</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2048">2048</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
C-style casts that cast away constness vs <TT>static_cast</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.1.9&#160;
  <A href="https://wg21.link/expr.static.cast">expr.static.cast</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2243">2243</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Incorrect use of implicit conversion sequence
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.2&#160;
  <A href="https://wg21.link/expr.unary.op">expr.unary.op</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3026">3026</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Class for pointer-to-member formation
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.5&#160;
  <A href="https://wg21.link/expr.sizeof">expr.sizeof</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2609">2609</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Padding in class types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.5&#160;
  <A href="https://wg21.link/expr.sizeof">expr.sizeof</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2817">2817</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
sizeof(abstract class) is underspecified
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.8&#160;
  <A href="https://wg21.link/expr.new">expr.new</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#267">267</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Alignment requirement for <I>new-expression</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.8&#160;
  <A href="https://wg21.link/expr.new">expr.new</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#901">901</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Deleted <TT>operator delete</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.8&#160;
  <A href="https://wg21.link/expr.new">expr.new</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1628">1628</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Deallocation function templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.8&#160;
  <A href="https://wg21.link/expr.new">expr.new</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2281">2281</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Consistency of aligned <TT>operator delete</TT> replacement
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.8&#160;
  <A href="https://wg21.link/expr.new">expr.new</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2532">2532</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Kind of pointer value returned by <TT>new T[0]</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.8&#160;
  <A href="https://wg21.link/expr.new">expr.new</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2566">2566</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Matching deallocation for uncaught exception
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.8&#160;
  <A href="https://wg21.link/expr.new">expr.new</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2592">2592</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Missing definition for placement allocation/deallocation function
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.8&#160;
  <A href="https://wg21.link/expr.new">expr.new</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2623">2623</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Invoking destroying <TT>operator delete</TT> for constructor failure
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.8&#160;
  <A href="https://wg21.link/expr.new">expr.new</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2812">2812</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Allocation with explicit alignment
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.8&#160;
  <A href="https://wg21.link/expr.new">expr.new</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2912">2912</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Too-large value for size in array new
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.8&#160;
  <A href="https://wg21.link/expr.new">expr.new</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3011">3011</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Parenthesized aggregate initialization for <I>new-expression</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.9&#160;
  <A href="https://wg21.link/expr.delete">expr.delete</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#196">196</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Arguments to deallocation functions </TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.9&#160;
  <A href="https://wg21.link/expr.delete">expr.delete</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2805">2805</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Underspecified selection of deallocation function
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.2.9&#160;
  <A href="https://wg21.link/expr.delete">expr.delete</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2889">2889</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Requiring an accessible destructor for destroying operator delete
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.3&#160;
  <A href="https://wg21.link/expr.cast">expr.cast</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2878">2878</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
C-style casts to reference types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.4&#160;
  <A href="https://wg21.link/expr.mptr.oper">expr.mptr.oper</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2593">2593</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Insufficient base class restriction for pointer-to-member expression
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.6&#160;
  <A href="https://wg21.link/expr.add">expr.add</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2013">2013</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Pointer subtraction in large array
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.6&#160;
  <A href="https://wg21.link/expr.add">expr.add</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2182">2182</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Pointer arithmetic in array-like containers
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.10&#160;
  <A href="https://wg21.link/expr.eq">expr.eq</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2786">2786</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Comparing pointers to complete objects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.16&#160;
  <A href="https://wg21.link/expr.cond">expr.cond</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2023">2023</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Composite reference result type of conditional operator
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.16&#160;
  <A href="https://wg21.link/expr.cond">expr.cond</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2316">2316</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Simplifying class conversions in conditional expressions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.16&#160;
  <A href="https://wg21.link/expr.cond">expr.cond</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3000">3000</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Handling of cv-qualified class types in conditional operator
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.6.19&#160;
  <A href="https://wg21.link/expr.assign">expr.assign</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1542">1542</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Compound assignment of <I>braced-init-list</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1255">1255</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Definition problems with <TT>constexpr</TT> functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1256">1256</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unevaluated operands are not necessarily constant expressions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2166">2166</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear meaning of &#8220;undefined <TT>constexpr</TT> function&#8221;
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2192">2192</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Constant expressions and order-of-eval undefined behavior
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2301">2301</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Value-initialization and constexpr constructor evaluation
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2456">2456</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Viable user-defined conversions in converted constant expressions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2536">2536</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Partially initialized variables during constant initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2545">2545</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Transparently replacing objects in constant expressions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2559">2559</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Defaulted consteval functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2633">2633</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
typeid of constexpr-unknown dynamic type
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2656">2656</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Converting consteval lambda to function pointer in non-immediate context
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2702">2702</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Constant destruction of reference members
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2734">2734</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Immediate forward-declared function templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2740">2740</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Too many objects have constexpr-unknown type
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2778">2778</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Trivial destructor does not imply constant destruction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2800">2800</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Instantiating constexpr variables for potential constant evaluation
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2962">2962</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Evaluation of destructor call for variable with constant destruction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3004">3004</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Pointer arithmetic on array of unknown bound
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3009">3009</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear rules for constant initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3010">3010</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
constexpr placement-new should require transparent replaceability
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">7.7&#160;
  <A href="https://wg21.link/expr.const">expr.const</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3059">3059</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<TT>throw;</TT> in constant expressions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">8.6.5&#160;
  <A href="https://wg21.link/stmt.ranged">stmt.ranged</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1680">1680</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Including <TT>&lt;initializer_list&gt;</TT> for range-based <TT>for</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">8.7&#160;
  <A href="https://wg21.link/stmt.expand">stmt.expand</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3044">3044</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Iterating expansion statements woes
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">8.7&#160;
  <A href="https://wg21.link/stmt.expand">stmt.expand</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3048">3048</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Empty destructuring expansion statements
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">8.7&#160;
  <A href="https://wg21.link/stmt.expand">stmt.expand</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3061">3061</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Trailing comma in an <I>expansion-init-list</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">8.8&#160;
  <A href="https://wg21.link/stmt.jump">stmt.jump</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2115">2115</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Order of implicit destruction vs release of automatic storage
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">8.8.4&#160;
  <A href="https://wg21.link/stmt.return">stmt.return</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2495">2495</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Glvalue result of a function call
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">8.8.4&#160;
  <A href="https://wg21.link/stmt.return">stmt.return</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2995">2995</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Meaning of flowing off the end of a function
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">8.8.4&#160;
  <A href="https://wg21.link/stmt.return">stmt.return</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3052">3052</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear handling of checks on discarded <TT>return</TT> statements
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">8.10&#160;
  <A href="https://wg21.link/stmt.dcl">stmt.dcl</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2123">2123</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Omitted constant initialization of local static variables
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">8.10&#160;
  <A href="https://wg21.link/stmt.dcl">stmt.dcl</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2976">2976</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Transferring control out of a function
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">8.11&#160;
  <A href="https://wg21.link/stmt.ambig">stmt.ambig</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2963">2963</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Paradoxical variable-or-function declaration
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.1&#160;
  <A href="https://wg21.link/dcl.pre">dcl.pre</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#157">157</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Omitted typedef declarator
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.2.2&#160;
  <A href="https://wg21.link/dcl.stc">dcl.stc</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#498">498</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Storage class specifiers in definitions of class members
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.2.2&#160;
  <A href="https://wg21.link/dcl.stc">dcl.stc</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2232">2232</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<TT>thread_local</TT> anonymous unions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.2.4&#160;
  <A href="https://wg21.link/dcl.typedef">dcl.typedef</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2973">2973</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Does an <I>alias-declaration</I> introduce a name for linkage purposes?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.2.6&#160;
  <A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3012">3012</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Deviating <TT>constexpr</TT> or <TT>consteval</TT> across translation units
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.2.9.2&#160;
  <A href="https://wg21.link/dcl.type.cv">dcl.type.cv</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2195">2195</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unsolicited reading of trailing volatile members
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.2.9.3&#160;
  <A href="https://wg21.link/dcl.type.simple">dcl.type.simple</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3003">3003</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Naming a deducible template for class template argument deduction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.2.9.5&#160;
  <A href="https://wg21.link/dcl.type.elab">dcl.type.elab</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#144">144</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Position of <TT>friend</TT> specifier
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.2.9.7&#160;
  <A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1348">1348</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Use of <TT>auto</TT> in a <I>trailing-return-type</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.2.9.7&#160;
  <A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1670">1670</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
<TT>auto</TT> as <I>conversion-type-id</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.2.9.7&#160;
  <A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1868">1868</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Meaning of &#8220;placeholder type&#8221;
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.2.9.7&#160;
  <A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2412">2412</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
SFINAE vs undeduced placeholder type
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.2&#160;
  <A href="https://wg21.link/dcl.name">dcl.name</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1488">1488</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<I>abstract-pack-declarator</I>s in <I>type-id</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.3&#160;
  <A href="https://wg21.link/dcl.ambig.res">dcl.ambig.res</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2228">2228</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Ambiguity resolution for cast to function type
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.1&#160;
  <A href="https://wg21.link/dcl.meaning.general">dcl.meaning.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2671">2671</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
friend named by a <I>template-id</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.5&#160;
  <A href="https://wg21.link/dcl.array">dcl.array</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3030">3030</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Initializing array prvalues of unknown bound
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.6&#160;
  <A href="https://wg21.link/dcl.fct">dcl.fct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1001">1001</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Parameter type adjustment in dependent parameter types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.6&#160;
  <A href="https://wg21.link/dcl.fct">dcl.fct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1668">1668</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Parameter type determination still not clear enough
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.6&#160;
  <A href="https://wg21.link/dcl.fct">dcl.fct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1790">1790</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Ellipsis following function parameter pack
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.6&#160;
  <A href="https://wg21.link/dcl.fct">dcl.fct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2537">2537</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overbroad grammar for <I>parameter-declaration</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.6&#160;
  <A href="https://wg21.link/dcl.fct">dcl.fct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2553">2553</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Restrictions on explicit object member functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.6&#160;
  <A href="https://wg21.link/dcl.fct">dcl.fct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2802">2802</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Constrained <TT>auto</TT> and redeclaration with non-abbreviated syntax
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.6&#160;
  <A href="https://wg21.link/dcl.fct">dcl.fct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2942">2942</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Packs in a function's parameter-type-list
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.7&#160;
  <A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#325">325</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
When are default arguments parsed?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.7&#160;
  <A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#361">361</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Forward reference to default argument
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.7&#160;
  <A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1580">1580</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Default arguments in explicit instantiations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.7&#160;
  <A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1609">1609</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Default arguments and function parameter packs
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.7&#160;
  <A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2701">2701</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Default arguments in multiple scopes / inheritance of array bounds in the same scope
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.3.4.7&#160;
  <A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3062">3062</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overlapping specification of default template arguments
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.5&#160;
  <A href="https://wg21.link/dcl.init">dcl.init</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2327">2327</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Copy elision for direct-initialization with a conversion function
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.5.1&#160;
  <A href="https://wg21.link/dcl.init.general">dcl.init.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2977">2977</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Initialization with string literals
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.5.1&#160;
  <A href="https://wg21.link/dcl.init.general">dcl.init.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2991">2991</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
"array size" is vague
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.5.2&#160;
  <A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2128">2128</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Imprecise rule for reference member initializer
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.5.3&#160;
  <A href="https://wg21.link/dcl.init.string">dcl.init.string</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1304">1304</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Omitted array bound with string initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.5.4&#160;
  <A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1414">1414</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Binding an rvalue reference to a reference-unrelated lvalue
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.5.4&#160;
  <A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1827">1827</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Reference binding with ambiguous conversions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.5.4&#160;
  <A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2704">2704</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Clarify meaning of "bind directly"
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.5.5&#160;
  <A href="https://wg21.link/dcl.init.list">dcl.init.list</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1996">1996</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Reference list-initialization ignores conversion functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.5.5&#160;
  <A href="https://wg21.link/dcl.init.list">dcl.init.list</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2168">2168</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Narrowing conversions and +/- infinity
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.5.5&#160;
  <A href="https://wg21.link/dcl.init.list">dcl.init.list</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2742">2742</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Guaranteed copy elision for brace-initialization from prvalue
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.5.5&#160;
  <A href="https://wg21.link/dcl.init.list">dcl.init.list</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3023">3023</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Default arguments in list-initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.6.1&#160;
  <A href="https://wg21.link/dcl.fct.def.general">dcl.fct.def.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1962">1962</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Type of <TT>__func__</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.6.1&#160;
  <A href="https://wg21.link/dcl.fct.def.general">dcl.fct.def.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2362">2362</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
<TT>__func__</TT> should be <TT>constexpr</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.6.1&#160;
  <A href="https://wg21.link/dcl.fct.def.general">dcl.fct.def.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2993">2993</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Body of a destructor
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.6.2&#160;
  <A href="https://wg21.link/dcl.fct.def.default">dcl.fct.def.default</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1854">1854</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Disallowing use of implicitly-deleted functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.6.2&#160;
  <A href="https://wg21.link/dcl.fct.def.default">dcl.fct.def.default</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2997">2997</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Defaulted functions with deleted definition
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.6.4&#160;
  <A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2562">2562</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Exceptions thrown during coroutine startup
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.6.4&#160;
  <A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2563">2563</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Initialization of coroutine result object
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.6.4&#160;
  <A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2934">2934</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear semantics of exception escaping from <TT>unhandled_exception</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.6.4&#160;
  <A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2935">2935</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Destroying the coroutine state when initial-await-resume-called is false
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.6.4&#160;
  <A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3040">3040</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Mishandling of lambda coroutines
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.7&#160;
  <A href="https://wg21.link/dcl.struct.bind">dcl.struct.bind</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2340">2340</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Reference collapsing and structured bindings
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.8.1&#160;
  <A href="https://wg21.link/dcl.enum">dcl.enum</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1485">1485</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Out-of-class definition of member unscoped opaque enumeration
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.8.1&#160;
  <A href="https://wg21.link/dcl.enum">dcl.enum</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2131">2131</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Ambiguity with <I>opaque-enum-declaration</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.8.1&#160;
  <A href="https://wg21.link/dcl.enum">dcl.enum</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2932">2932</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Value range of empty enumeration
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.8.1&#160;
  <A href="https://wg21.link/dcl.enum">dcl.enum</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3046">3046</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Enumerations as part of the common initial sequence
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.9.2.2&#160;
  <A href="https://wg21.link/namespace.unnamed">namespace.unnamed</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2505">2505</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Nested unnamed namespace of inline unnamed namespace
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.10&#160;
  <A href="https://wg21.link/namespace.udecl">namespace.udecl</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#813">813</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<TT>typename</TT> in a <I>using-declaration</I> with a non-dependent name
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.10&#160;
  <A href="https://wg21.link/namespace.udecl">namespace.udecl</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2555">2555</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Ineffective redeclaration prevention for <I>using-declarator</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.10&#160;
  <A href="https://wg21.link/namespace.udecl">namespace.udecl</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3028">3028</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
A <I>using-declarator</I> should bind a name
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.10&#160;
  <A href="https://wg21.link/namespace.udecl">namespace.udecl</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3037">3037</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Name lookup results for <I>using-declarator</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.12&#160;
  <A href="https://wg21.link/dcl.link">dcl.link</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1817">1817</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Linkage specifications and nested scopes
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.13&#160;
  <A href="https://wg21.link/dcl.attr">dcl.attr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2866">2866</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Observing the effects of <TT>[[no_unique_address]]</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.13.1&#160;
  <A href="https://wg21.link/dcl.attr.grammar">dcl.attr.grammar</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1706">1706</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<TT>alignas</TT> pack expansion syntax
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.13.1&#160;
  <A href="https://wg21.link/dcl.attr.grammar">dcl.attr.grammar</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3038">3038</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Ignorability of attributes, again
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.13.2&#160;
  <A href="https://wg21.link/dcl.align">dcl.align</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1617">1617</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<TT>alignas</TT> and non-defining declarations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.13.2&#160;
  <A href="https://wg21.link/dcl.align">dcl.align</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2223">2223</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Multiple <TT>alignas</TT> specifiers
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.13.2&#160;
  <A href="https://wg21.link/dcl.align">dcl.align</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3024">3024</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Alignment of references
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">9.13.4&#160;
  <A href="https://wg21.link/dcl.attr.deprecated">dcl.attr.deprecated</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3050">3050</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
[[deprecated]] for class template partial specializations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">10.1&#160;
  <A href="https://wg21.link/module.unit">module.unit</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2541">2541</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Linkage specifications, module purview, and module attachment
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">10.2&#160;
  <A href="https://wg21.link/module.interface">module.interface</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2607">2607</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Visibility of enumerator names
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">10.3&#160;
  <A href="https://wg21.link/module.import">module.import</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2727">2727</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Importing header units synthesized from source files
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">10.4&#160;
  <A href="https://wg21.link/module.global.frag">module.global.frag</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2971">2971</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Specializations for a class are not decl-reachable
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.2&#160;
  <A href="https://wg21.link/class.prop">class.prop</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#511">511</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
POD-structs with template assignment operators
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.2&#160;
  <A href="https://wg21.link/class.prop">class.prop</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2463">2463</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Trivial copyability and unions with non-trivial members
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.2&#160;
  <A href="https://wg21.link/class.prop">class.prop</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2736">2736</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Standard layout class with empty base class also in first member
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.2&#160;
  <A href="https://wg21.link/class.prop">class.prop</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3049">3049</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Implicitly deleted move operation should not disable trivial relocation
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4&#160;
  <A href="https://wg21.link/class.mem">class.mem</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1890">1890</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Member type depending on definition of member function
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.1&#160;
  <A href="https://wg21.link/class.mem.general">class.mem.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2188">2188</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<I>empty-declaration</I> grammar ambiguity
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.1&#160;
  <A href="https://wg21.link/class.mem.general">class.mem.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2852">2852</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Complete-class contexts and class-scope lambdas
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.1&#160;
  <A href="https://wg21.link/class.mem.general">class.mem.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2979">2979</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Duplicate declarations of enumerations in class scope
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.1&#160;
  <A href="https://wg21.link/class.mem.general">class.mem.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3051">3051</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Missing specification for types of member subobjects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.4&#160;
  <A href="https://wg21.link/special">special</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2787">2787</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Kind of explicit object copy/move assignment function
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5&#160;
  <A href="https://wg21.link/class.ctor">class.ctor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1623">1623</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Deleted default union constructor and member initializers
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5&#160;
  <A href="https://wg21.link/class.ctor">class.ctor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1808">1808</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Constructor templates vs default constructors
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5.1&#160;
  <A href="https://wg21.link/class.ctor.general">class.ctor.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2841">2841</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
When do const objects start being const?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5.2&#160;
  <A href="https://wg21.link/class.default.ctor">class.default.ctor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2799">2799</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Inheriting default constructors
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5.2&#160;
  <A href="https://wg21.link/class.default.ctor">class.default.ctor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2885">2885</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER">LWG</TD>
<TD ALIGN="LEFT">
Non-eligible trivial default constructors
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5.2&#160;
  <A href="https://wg21.link/class.default.ctor">class.default.ctor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2999">2999</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Trivial unions changing existing behavior
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5.3&#160;
  <A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1092">1092</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Cycles in overload resolution during instantiation
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5.3&#160;
  <A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1548">1548</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Copy/move construction and conversion functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5.3&#160;
  <A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1594">1594</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Lazy declaration of special members vs overload errors
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5.3&#160;
  <A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2203">2203</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Defaulted copy/move constructors and UDCs
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5.3&#160;
  <A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2264">2264</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Memberwise copying with indeterminate value
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5.3&#160;
  <A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2743">2743</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Copying non-trivial objects nested within a union
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.5.3&#160;
  <A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2837">2837</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Instantiating and inheriting by-value copy constructors
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.6&#160;
  <A href="https://wg21.link/class.copy.assign">class.copy.assign</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2329">2329</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Virtual base classes and generated assignment operators
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.6&#160;
  <A href="https://wg21.link/class.copy.assign">class.copy.assign</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2897">2897</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Copying potentially-overlapping union subobjects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.7&#160;
  <A href="https://wg21.link/class.dtor">class.dtor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1977">1977</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Contradictory results of failed destructor lookup
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.7&#160;
  <A href="https://wg21.link/class.dtor">class.dtor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2158">2158</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Polymorphic behavior during destruction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.7&#160;
  <A href="https://wg21.link/class.dtor">class.dtor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2839">2839</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Explicit destruction of base classes
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.7&#160;
  <A href="https://wg21.link/class.dtor">class.dtor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3022">3022</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Redundant specification of explicit destructor calls
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.7&#160;
  <A href="https://wg21.link/class.dtor">class.dtor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3041">3041</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overly aggressive rule for deleting the destructor of a union
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.8.3&#160;
  <A href="https://wg21.link/class.conv.fct">class.conv.fct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2513">2513</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Ambiguity with <I>requires-clause</I> and <I>operator-function-id</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.9.3&#160;
  <A href="https://wg21.link/class.static.data">class.static.data</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1283">1283</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Static data members of classes with typedef name for linkage purposes
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.9.3&#160;
  <A href="https://wg21.link/class.static.data">class.static.data</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1721">1721</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Diagnosing ODR violations for static data members
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.9.3&#160;
  <A href="https://wg21.link/class.static.data">class.static.data</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2335">2335</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Deduced return types vs member types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.4.10&#160;
  <A href="https://wg21.link/class.bit">class.bit</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2950">2950</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Value preservation in enumeration vs. integer bit-fields
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.5&#160;
  <A href="https://wg21.link/class.union">class.union</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#57">57</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Empty unions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.5&#160;
  <A href="https://wg21.link/class.union">class.union</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1404">1404</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Object reallocation in unions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.5&#160;
  <A href="https://wg21.link/class.union">class.union</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1702">1702</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Rephrasing the definition of &#8220;anonymous union&#8221;
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.5.1&#160;
  <A href="https://wg21.link/class.union.general">class.union.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2675">2675</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<TT>start_lifetime_as</TT>, placement-new, and active union members
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.5.2&#160;
  <A href="https://wg21.link/class.union.anon">class.union.anon</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2767">2767</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Non-defining declarations of anonymous unions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.5.2&#160;
  <A href="https://wg21.link/class.union.anon">class.union.anon</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2773">2773</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Naming anonymous union members as class members
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.5.2&#160;
  <A href="https://wg21.link/class.union.anon">class.union.anon</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3035">3035</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Lambda expressions in anonymous unions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.7.3&#160;
  <A href="https://wg21.link/class.virtual">class.virtual</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2554">2554</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overriding virtual functions, also with explicit object parameters
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.8.3&#160;
  <A href="https://wg21.link/class.access.base">class.access.base</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2246">2246</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Access of indirect virtual base class constructors
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.8.4&#160;
  <A href="https://wg21.link/class.friend">class.friend</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1699">1699</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Does befriending a class befriend its friends?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.8.5&#160;
  <A href="https://wg21.link/class.protected">class.protected</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#472">472</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Casting across protected inheritance
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.8.5&#160;
  <A href="https://wg21.link/class.protected">class.protected</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1883">1883</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Protected access to constructors in <I>mem-initializer</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.8.5&#160;
  <A href="https://wg21.link/class.protected">class.protected</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2187">2187</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Protected members and access via <I>qualified-id</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.8.5&#160;
  <A href="https://wg21.link/class.protected">class.protected</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2244">2244</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Base class access in aggregate initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.9&#160;
  <A href="https://wg21.link/class.init">class.init</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2756">2756</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Completion of initialization by delegating constructor
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.9.3&#160;
  <A href="https://wg21.link/class.base.init">class.base.init</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1915">1915</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Potentially-invoked destructors in non-throwing constructors
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.9.3&#160;
  <A href="https://wg21.link/class.base.init">class.base.init</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2056">2056</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Member function calls in partially-initialized class objects
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.9.3&#160;
  <A href="https://wg21.link/class.base.init">class.base.init</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2403">2403</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Temporary materialization and base/member initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.9.3&#160;
  <A href="https://wg21.link/class.base.init">class.base.init</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2669">2669</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Lifetime extension for aggregate initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.9.5&#160;
  <A href="https://wg21.link/class.cdtor">class.cdtor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1517">1517</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear/missing description of behavior during construction/destruction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.9.5&#160;
  <A href="https://wg21.link/class.cdtor">class.cdtor</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2757">2757</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Deleting or deallocating storage of an object during its construction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.9.6&#160;
  <A href="https://wg21.link/class.copy.elision">class.copy.elision</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1049">1049</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Copy elision through reference parameters of inline functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">11.10.1&#160;
  <A href="https://wg21.link/class.compare.default">class.compare.default</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3007">3007</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Access checking during synthesis of defaulted comparison operator, take 2
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.1&#160;
  <A href="https://wg21.link/over.match.funcs.general">over.match.funcs.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3031">3031</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Finding declarations for conversion operators for access checking
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.2.2&#160;
  <A href="https://wg21.link/over.call.func">over.call.func</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1278">1278</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Incorrect treatment of contrived object
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.2.3&#160;
  <A href="https://wg21.link/over.call.object">over.call.object</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2189">2189</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Surrogate call template
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.2.3&#160;
  <A href="https://wg21.link/over.call.object">over.call.object</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2564">2564</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Conversion to function pointer with an explicit object parameter
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.2.3&#160;
  <A href="https://wg21.link/over.call.object">over.call.object</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3055">3055</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Misleading body for surrogate call function
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.3&#160;
  <A href="https://wg21.link/over.match.oper">over.match.oper</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#545">545</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
User-defined conversions and built-in operator overload resolution
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.3&#160;
  <A href="https://wg21.link/over.match.oper">over.match.oper</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1919">1919</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overload resolution for <TT>!</TT> with explicit conversion operator
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.3&#160;
  <A href="https://wg21.link/over.match.oper">over.match.oper</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2089">2089</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Restricting selection of builtin overloaded operators
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.3&#160;
  <A href="https://wg21.link/over.match.oper">over.match.oper</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2730">2730</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Comparison templates on enumeration types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.3&#160;
  <A href="https://wg21.link/over.match.oper">over.match.oper</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2797">2797</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Meaning of "corresponds" for rewritten operator candidates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.3&#160;
  <A href="https://wg21.link/over.match.oper">over.match.oper</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2804">2804</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Lookup for determining rewrite targets
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.3&#160;
  <A href="https://wg21.link/over.match.oper">over.match.oper</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2844">2844</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Enumerating a finite set of built-in candidates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.7&#160;
  <A href="https://wg21.link/over.match.ref">over.match.ref</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2028">2028</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Converting constructors in rvalue reference initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.7&#160;
  <A href="https://wg21.link/over.match.ref">over.match.ref</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2108">2108</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Conversions to non-class prvalues in reference initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.7&#160;
  <A href="https://wg21.link/over.match.ref">over.match.ref</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2967">2967</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Explicit conversion functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.8&#160;
  <A href="https://wg21.link/over.match.list">over.match.list</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2194">2194</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Impossible case in list initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.8&#160;
  <A href="https://wg21.link/over.match.list">over.match.list</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2311">2311</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Missed case for guaranteed copy elision
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.9&#160;
  <A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2425">2425</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Confusing wording for deduction from a type
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.9&#160;
  <A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2467">2467</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
CTAD for alias templates and the deducible check
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.9&#160;
  <A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2471">2471</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Nested class template argument deduction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.2.9&#160;
  <A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2680">2680</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Class template argument deduction for aggregates with designated initializers
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4&#160;
  <A href="https://wg21.link/over.match.best">over.match.best</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2735">2735</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
List-initialization and conversions in overload resolution
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.2&#160;
  <A href="https://wg21.link/over.best.ics">over.best.ics</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2319">2319</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Nested brace initialization from same type
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.2.1&#160;
  <A href="https://wg21.link/over.best.ics.general">over.best.ics.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2525">2525</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Incorrect definition of implicit conversion sequence
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.2.1&#160;
  <A href="https://wg21.link/over.best.ics.general">over.best.ics.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2679">2679</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Implicit conversion sequence with a null pointer constant
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.2.1&#160;
  <A href="https://wg21.link/over.best.ics.general">over.best.ics.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2829">2829</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Redundant case in restricting user-defined conversion sequences
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.2.3&#160;
  <A href="https://wg21.link/over.ics.user">over.ics.user</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2731">2731</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
List-initialization sequence with a user-defined conversion
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.2.5&#160;
  <A href="https://wg21.link/over.ics.ref">over.ics.ref</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2077">2077</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overload resolution and invalid rvalue-reference initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.2.5&#160;
  <A href="https://wg21.link/over.ics.ref">over.ics.ref</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3057">3057</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Ranking of derived-to-base conversions should ignore reference binding
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.2.6&#160;
  <A href="https://wg21.link/over.ics.list">over.ics.list</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1536">1536</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overload resolution with temporary from initializer list
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.2.6&#160;
  <A href="https://wg21.link/over.ics.list">over.ics.list</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2169">2169</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Narrowing conversions and overload resolution
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.2.6&#160;
  <A href="https://wg21.link/over.ics.list">over.ics.list</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2492">2492</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Comparing user-defined conversion sequences in list-initialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.2.6&#160;
  <A href="https://wg21.link/over.ics.list">over.ics.list</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2741">2741</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Implicit conversion sequence from empty list to array of unknown bound
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.2.6&#160;
  <A href="https://wg21.link/over.ics.list">over.ics.list</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2790">2790</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Aggregate initialization and user-defined conversion sequence
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.3&#160;
  <A href="https://wg21.link/over.ics.rank">over.ics.rank</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1459">1459</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Reference-binding tiebreakers in overload resolution
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.3&#160;
  <A href="https://wg21.link/over.ics.rank">over.ics.rank</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1789">1789</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Array reference vs array decay in overload resolution
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.3&#160;
  <A href="https://wg21.link/over.ics.rank">over.ics.rank</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2110">2110</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overload resolution for base class conversion and reference/non-reference
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.3&#160;
  <A href="https://wg21.link/over.ics.rank">over.ics.rank</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2337">2337</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Incorrect implication of logic ladder for conversion sequence tiebreakers
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.3&#160;
  <A href="https://wg21.link/over.ics.rank">over.ics.rank</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2842">2842</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Preferring an <TT>initializer_list</TT> over a single value
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.2.4.3&#160;
  <A href="https://wg21.link/over.ics.rank">over.ics.rank</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2958">2958</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overload resolution involving lvalue transformation and qualification conversion
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.3&#160;
  <A href="https://wg21.link/over.over">over.over</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2572">2572</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Address of overloaded function with no target
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.3&#160;
  <A href="https://wg21.link/over.over">over.over</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2873">2873</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Taking the address of a function involving template argument deduction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.4&#160;
  <A href="https://wg21.link/over.oper">over.oper</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1989">1989</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Insufficient restrictions on parameters of postfix operators
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.4.3&#160;
  <A href="https://wg21.link/over.binary">over.binary</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1549">1549</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overloaded comma operator with <TT>void</TT> operand
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.5&#160;
  <A href="https://wg21.link/over.built">over.built</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#260">260</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
User-defined conversions and built-in <TT>operator=</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.5&#160;
  <A href="https://wg21.link/over.built">over.built</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#954">954</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Overload resolution of conversion operator templates with built-in types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">12.6&#160;
  <A href="https://wg21.link/over.literal">over.literal</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1620">1620</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
User-defined literals and extended integer types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13&#160;
  <A href="https://wg21.link/temp">temp</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#205">205</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Templates and static data members
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.1&#160;
  <A href="https://wg21.link/temp.pre">temp.pre</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1463">1463</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
<TT>extern "C"</TT> alias templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.1&#160;
  <A href="https://wg21.link/temp.pre">temp.pre</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2862">2862</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear boundaries of template declarations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.1&#160;
  <A href="https://wg21.link/temp.pre">temp.pre</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2904">2904</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Introducing <I>template-name</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.1&#160;
  <A href="https://wg21.link/temp.pre">temp.pre</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2917">2917</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Disallow multiple <I>friend-type-specifier</I>s for a friend template
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.2&#160;
  <A href="https://wg21.link/temp.param">temp.param</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1444">1444</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Type adjustments of non-type template parameters
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.2&#160;
  <A href="https://wg21.link/temp.param">temp.param</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1635">1635</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
How similar are template default arguments to function default arguments?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.2&#160;
  <A href="https://wg21.link/temp.param">temp.param</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2395">2395</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Parameters following a pack expansion
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.2&#160;
  <A href="https://wg21.link/temp.param">temp.param</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2617">2617</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Default template arguments for template members of non-template classes
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.2&#160;
  <A href="https://wg21.link/temp.param">temp.param</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2994">2994</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Allowing template parameters following template parameter packs that are pack expansions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.3&#160;
  <A href="https://wg21.link/temp.names">temp.names</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#579">579</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
What is a &#8220;nested&#8221; <TT>&gt;</TT> or <TT>&gt;&gt;</TT>?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.3&#160;
  <A href="https://wg21.link/temp.names">temp.names</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2903">2903</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Can we omit the <TT>template</TT> disambiguator in <I>nested-name-specifier</I>s in type-only contexts?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.3&#160;
  <A href="https://wg21.link/temp.names">temp.names</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2920">2920</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
The <TT>template</TT> keyword for base classes
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.3&#160;
  <A href="https://wg21.link/temp.names">temp.names</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2980">2980</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Constraints on template template parameters
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.4&#160;
  <A href="https://wg21.link/temp.arg">temp.arg</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2105">2105</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
When do the arguments for a parameter pack end?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.4.1&#160;
  <A href="https://wg21.link/temp.arg.general">temp.arg.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3032">3032</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Template argument disambiguation
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.4.3&#160;
  <A href="https://wg21.link/temp.arg.nontype">temp.arg.nontype</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2043">2043</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Generalized template arguments and array-to-pointer decay
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.4.3&#160;
  <A href="https://wg21.link/temp.arg.nontype">temp.arg.nontype</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2401">2401</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Array decay vs prohibition of subobject non-type arguments
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.4.4&#160;
  <A href="https://wg21.link/temp.arg.template">temp.arg.template</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2057">2057</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Template template arguments with default arguments
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.4.4&#160;
  <A href="https://wg21.link/temp.arg.template">temp.arg.template</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2398">2398</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Template template parameter matching and deduction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.5&#160;
  <A href="https://wg21.link/temp.constr">temp.constr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2961">2961</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Checking of ill-formed types in <I>constraint-expression</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.5.2&#160;
  <A href="https://wg21.link/temp.constr.constr">temp.constr.constr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2686">2686</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Pack expansion into a non-pack parameter of a concept
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.5.2.3&#160;
  <A href="https://wg21.link/temp.constr.atomic">temp.constr.atomic</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2589">2589</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Context of access checks during constraint satisfaction checking
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.5.2.3&#160;
  <A href="https://wg21.link/temp.constr.atomic">temp.constr.atomic</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2996">2996</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Impenetrable definition of atomic constraint
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.5.4&#160;
  <A href="https://wg21.link/temp.constr.normal">temp.constr.normal</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2975">2975</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Effect of concept <I>template-head</I> on parameter mappings
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.5.5&#160;
  <A href="https://wg21.link/temp.constr.order">temp.constr.order</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3021">3021</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Subsumption rules for fold expanded constraints
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.6&#160;
  <A href="https://wg21.link/temp.type">temp.type</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2037">2037</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Alias templates and template declaration matching
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.6&#160;
  <A href="https://wg21.link/temp.type">temp.type</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3027">3027</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Equivalence of <I>pack-index-specifier</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7&#160;
  <A href="https://wg21.link/temp.decls">temp.decls</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1730">1730</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Can a variable template have an unnamed type?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.1&#160;
  <A href="https://wg21.link/temp.decls.general">temp.decls.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2951">2951</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Distinguishing a primary template
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.4&#160;
  <A href="https://wg21.link/temp.variadic">temp.variadic</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1432">1432</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Newly-ambiguous variadic template expansions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.5&#160;
  <A href="https://wg21.link/temp.friend">temp.friend</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2118">2118</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Stateful metaprogramming via friend injection
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.6&#160;
  <A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#708">708</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Partial specialization of member templates of class templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.6&#160;
  <A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1647">1647</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Type agreement of non-type template arguments in partial specializations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.6&#160;
  <A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2127">2127</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Partial specialization and nullptr
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.6&#160;
  <A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2173">2173</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Partial specialization with non-deduced contexts
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.6&#160;
  <A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2916">2916</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Variable template partial specializations should not be declared <TT>static</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.6.1&#160;
  <A href="https://wg21.link/temp.spec.partial.general">temp.spec.partial.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2179">2179</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Required diagnostic for partial specialization after first use
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.6.1&#160;
  <A href="https://wg21.link/temp.spec.partial.general">temp.spec.partial.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2948">2948</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Late ambiguity for partial template specialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.6.2&#160;
  <A href="https://wg21.link/temp.spec.partial.match">temp.spec.partial.match</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#549">549</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Non-deducible parameters in partial specializations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.6.4&#160;
  <A href="https://wg21.link/temp.spec.partial.member">temp.spec.partial.member</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1755">1755</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Out-of-class partial specializations of member templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.7.2&#160;
  <A href="https://wg21.link/temp.over.link">temp.over.link</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#310">310</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Can function templates differing only in parameter cv-qualifiers be overloaded?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.7.2&#160;
  <A href="https://wg21.link/temp.over.link">temp.over.link</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2584">2584</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Equivalent types in function template declarations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.7.2&#160;
  <A href="https://wg21.link/temp.over.link">temp.over.link</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2946">2946</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Dependent call equivalence in non-ADL cases
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.7.3&#160;
  <A href="https://wg21.link/temp.func.order">temp.func.order</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#402">402</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
More on partial ordering of function templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.7.3&#160;
  <A href="https://wg21.link/temp.func.order">temp.func.order</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1157">1157</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Partial ordering of function templates is still underspecified
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.7.3&#160;
  <A href="https://wg21.link/temp.func.order">temp.func.order</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2160">2160</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Issues with partial ordering
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.7.3&#160;
  <A href="https://wg21.link/temp.func.order">temp.func.order</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2834">2834</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Partial ordering and explicit object parameters
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.7.3&#160;
  <A href="https://wg21.link/temp.func.order">temp.func.order</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2949">2949</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Treatment of ellipsis during partial ordering
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.8&#160;
  <A href="https://wg21.link/temp.alias">temp.alias</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1286">1286</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Equivalence of alias templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.8&#160;
  <A href="https://wg21.link/temp.alias">temp.alias</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1430">1430</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Pack expansion into fixed alias template parameter list
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.8&#160;
  <A href="https://wg21.link/temp.alias">temp.alias</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1554">1554</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Access and alias templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.8&#160;
  <A href="https://wg21.link/temp.alias">temp.alias</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1979">1979</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Alias template specialization in template member definition
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.8&#160;
  <A href="https://wg21.link/temp.alias">temp.alias</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1980">1980</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Equivalent but not functionally-equivalent redeclarations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.8&#160;
  <A href="https://wg21.link/temp.alias">temp.alias</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2236">2236</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
When is an alias template specialization dependent?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.7.8&#160;
  <A href="https://wg21.link/temp.alias">temp.alias</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2794">2794</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Uniqueness of lambdas in alias templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8&#160;
  <A href="https://wg21.link/temp.res">temp.res</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1257">1257</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Instantiation via non-dependent references in uninstantiated templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8&#160;
  <A href="https://wg21.link/temp.res">temp.res</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2067">2067</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Generated variadic templates requiring empty pack
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.1&#160;
  <A href="https://wg21.link/temp.res.general">temp.res.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2462">2462</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Problems with the omission of the <TT>typename</TT> keyword
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.1&#160;
  <A href="https://wg21.link/temp.res.general">temp.res.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2468">2468</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Omission of the <TT>typename</TT> keyword in a member template parameter list
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.2&#160;
  <A href="https://wg21.link/temp.local">temp.local</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#186">186</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Name hiding and template <I>template-parameter</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.3.2&#160;
  <A href="https://wg21.link/temp.dep.type">temp.dep.type</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1390">1390</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Dependency of alias template specializations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.3.2&#160;
  <A href="https://wg21.link/temp.dep.type">temp.dep.type</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1524">1524</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Incompletely-defined class template base
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.3.2&#160;
  <A href="https://wg21.link/temp.dep.type">temp.dep.type</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1619">1619</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Definition of current instantiation
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.3.2&#160;
  <A href="https://wg21.link/temp.dep.type">temp.dep.type</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2074">2074</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Type-dependence of local class of function template
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.3.3&#160;
  <A href="https://wg21.link/temp.dep.expr">temp.dep.expr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2275">2275</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Type-dependence of function template
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.3.3&#160;
  <A href="https://wg21.link/temp.dep.expr">temp.dep.expr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2487">2487</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Type dependence of function-style cast to incomplete array type
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.3.4&#160;
  <A href="https://wg21.link/temp.dep.constexpr">temp.dep.constexpr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2774">2774</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Value-dependence of <I>requires-expression</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.3.4&#160;
  <A href="https://wg21.link/temp.dep.constexpr">temp.dep.constexpr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2984">2984</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Value-dependent structured bindings
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.3.7&#160;
  <A href="https://wg21.link/temp.dep.temp">temp.dep.temp</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2090">2090</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Dependency via non-dependent base class
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.3.7&#160;
  <A href="https://wg21.link/temp.dep.temp">temp.dep.temp</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3002">3002</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Template parameter/argument confusion
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.4&#160;
  <A href="https://wg21.link/temp.dep.res">temp.dep.res</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2">2</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
How can dependent names be used in member declarations that appear outside of the class template definition?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.4.1&#160;
  <A href="https://wg21.link/temp.point">temp.point</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#287">287</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Order dependencies in template instantiation
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.4.1&#160;
  <A href="https://wg21.link/temp.point">temp.point</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1845">1845</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Point of instantiation of a variable template specialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.4.1&#160;
  <A href="https://wg21.link/temp.point">temp.point</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2245">2245</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Point of instantiation of incomplete class template
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.4.1&#160;
  <A href="https://wg21.link/temp.point">temp.point</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2250">2250</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Implicit instantiation, destruction, and TUs
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.8.4.1&#160;
  <A href="https://wg21.link/temp.point">temp.point</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2497">2497</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Points of instantiation for constexpr function templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9&#160;
  <A href="https://wg21.link/temp.spec">temp.spec</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2435">2435</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Alias template specializations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.2&#160;
  <A href="https://wg21.link/temp.inst">temp.inst</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1602">1602</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Linkage of specialization vs linkage of template arguments
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.2&#160;
  <A href="https://wg21.link/temp.inst">temp.inst</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1856">1856</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Indirect nested classes of class templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.2&#160;
  <A href="https://wg21.link/temp.inst">temp.inst</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2202">2202</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
When does default argument instantiation occur?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.2&#160;
  <A href="https://wg21.link/temp.inst">temp.inst</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2222">2222</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Additional contexts where instantiation is not required
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.2&#160;
  <A href="https://wg21.link/temp.inst">temp.inst</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2263">2263</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Default argument instantiation for <TT>friend</TT>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.2&#160;
  <A href="https://wg21.link/temp.inst">temp.inst</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2265">2265</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Delayed pack expansion and member redeclarations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.2&#160;
  <A href="https://wg21.link/temp.inst">temp.inst</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2596">2596</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Instantiation of constrained non-template friends
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.2&#160;
  <A href="https://wg21.link/temp.inst">temp.inst</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2808">2808</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Explicit specialization of defaulted special member function
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.2&#160;
  <A href="https://wg21.link/temp.inst">temp.inst</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3034">3034</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Infinite recursion should hit an implementation limit
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.3&#160;
  <A href="https://wg21.link/temp.explicit">temp.explicit</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#293">293</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Syntax of explicit instantiation/specialization too permissive
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.3&#160;
  <A href="https://wg21.link/temp.explicit">temp.explicit</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1046">1046</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
What is a &#8220;use&#8221; of a class specialization?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.3&#160;
  <A href="https://wg21.link/temp.explicit">temp.explicit</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1665">1665</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Declaration matching in explicit instantiations
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.3&#160;
  <A href="https://wg21.link/temp.explicit">temp.explicit</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2421">2421</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Explicit instantiation of constrained member functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.3&#160;
  <A href="https://wg21.link/temp.explicit">temp.explicit</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2501">2501</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Explicit instantiation and trailing <I>requires-clause</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.3&#160;
  <A href="https://wg21.link/temp.explicit">temp.explicit</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3006">3006</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Vague restrictions for explicit instantiations of class templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.4&#160;
  <A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#529">529</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Use of <TT>template&lt;&gt;</TT> with &#8220;explicitly-specialized&#8221; class templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.4&#160;
  <A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1840">1840</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Non-deleted explicit specialization of deleted function template
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.4&#160;
  <A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1993">1993</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Use of <TT>template&lt;&gt;</TT> defining member of explicit specialization
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.4&#160;
  <A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2409">2409</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Explicit specializations of constexpr static data members
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.9.4&#160;
  <A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2847">2847</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Constrained explicit specializations of function templates at class scope
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.2&#160;
  <A href="https://wg21.link/temp.arg.explicit">temp.arg.explicit</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#264">264</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unusable template constructors and conversion functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.2&#160;
  <A href="https://wg21.link/temp.arg.explicit">temp.arg.explicit</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2055">2055</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Explicitly-specified non-deduced parameter packs
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3&#160;
  <A href="https://wg21.link/temp.deduct">temp.deduct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#697">697</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Deduction rules apply to more than functions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3&#160;
  <A href="https://wg21.link/temp.deduct">temp.deduct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1172">1172</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
&#8220;instantiation-dependent&#8221; constructs
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3&#160;
  <A href="https://wg21.link/temp.deduct">temp.deduct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1322">1322</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Function parameter type decay in templates
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3&#160;
  <A href="https://wg21.link/temp.deduct">temp.deduct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1582">1582</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Template default arguments and deduction failure
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3&#160;
  <A href="https://wg21.link/temp.deduct">temp.deduct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1844">1844</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Defining &#8220;immediate context&#8221;
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3&#160;
  <A href="https://wg21.link/temp.deduct">temp.deduct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2296">2296</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Are default argument instantiation failures in the &#8220;immediate context&#8221;?
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3&#160;
  <A href="https://wg21.link/temp.deduct">temp.deduct</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2896">2896</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Template argument deduction involving exception specifications
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.1&#160;
  <A href="https://wg21.link/temp.deduct.general">temp.deduct.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2498">2498</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Partial specialization failure and the immediate context
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.1&#160;
  <A href="https://wg21.link/temp.deduct.general">temp.deduct.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2769">2769</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Substitution into template parameters and default template arguments should be interleaved
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.1&#160;
  <A href="https://wg21.link/temp.deduct.general">temp.deduct.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2770">2770</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Trailing <I>requires-clause</I> can refer to function parameters before they are substituted into
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.2&#160;
  <A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#503">503</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Cv-qualified function types in template argument deduction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.2&#160;
  <A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1513">1513</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<TT>initializer_list</TT> deduction failure
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.2&#160;
  <A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1584">1584</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Deducing function types from cv-qualified types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.2&#160;
  <A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1939">1939</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Argument conversions to nondeduced parameter types revisited
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.2&#160;
  <A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2978">2978</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Deduction involving reference to similar types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.3&#160;
  <A href="https://wg21.link/temp.deduct.funcaddr">temp.deduct.funcaddr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1486">1486</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Base-derived conversion in member pointer deduction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.5&#160;
  <A href="https://wg21.link/temp.deduct.partial">temp.deduct.partial</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1221">1221</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Partial ordering and reference collapsing
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.5&#160;
  <A href="https://wg21.link/temp.deduct.partial">temp.deduct.partial</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1610">1610</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Cv-qualification in deduction of reference to array
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.5&#160;
  <A href="https://wg21.link/temp.deduct.partial">temp.deduct.partial</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2998">2998</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Missing deduction consistency check for partial ordering
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.6&#160;
  <A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1763">1763</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Length mismatch in template type deduction
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.6&#160;
  <A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2328">2328</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear presentation style of template argument deduction rules
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.6&#160;
  <A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2900">2900</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Deduction of non-type template arguments with placeholder types
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">13.10.3.6&#160;
  <A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2974">2974</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Non-deduced context for <I>qualified-id</I> naming a template
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">14.4&#160;
  <A href="https://wg21.link/except.handle">except.handle</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2172">2172</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Multiple exceptions with one exception object
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">14.4&#160;
  <A href="https://wg21.link/except.handle">except.handle</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2219">2219</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Dynamically-unreachable handlers
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">14.5&#160;
  <A href="https://wg21.link/except.spec">except.spec</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2417">2417</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Explicit instantiation and exception specifications
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.1&#160;
  <A href="https://wg21.link/cpp.pre">cpp.pre</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2002">2002</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">WG14</TD>
<TD ALIGN="LEFT">
White space within preprocessing directives
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.2&#160;
  <A href="https://wg21.link/cpp.cond">cpp.cond</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#925">925</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Type of character literals in preprocessor expressions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.2&#160;
  <A href="https://wg21.link/cpp.cond">cpp.cond</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1436">1436</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Interaction of constant expression changes with preprocessor expressions
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.2&#160;
  <A href="https://wg21.link/cpp.cond">cpp.cond</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2190">2190</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Insufficient specification of <TT>__has_include</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.2&#160;
  <A href="https://wg21.link/cpp.cond">cpp.cond</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2575">2575</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">SG12</TD>
<TD ALIGN="LEFT">
Undefined behavior when macro-replacing "defined" operator
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.2&#160;
  <A href="https://wg21.link/cpp.cond">cpp.cond</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3017">3017</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Commas in controlling expression of conditional inclusion
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.3&#160;
  <A href="https://wg21.link/cpp.include">cpp.include</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2576">2576</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">SG12</TD>
<TD ALIGN="LEFT">
Undefined behavior with macro-expanded <TT>#include</TT> directives
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.5&#160;
  <A href="https://wg21.link/cpp.module">cpp.module</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2947">2947</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Limiting macro expansion in <I>pp-module</I>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.7&#160;
  <A href="https://wg21.link/cpp.replace">cpp.replace</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1718">1718</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">WG14</TD>
<TD ALIGN="LEFT">
Macro invocation spanning end-of-file
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.7&#160;
  <A href="https://wg21.link/cpp.replace">cpp.replace</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2003">2003</A></TD>
<TD ALIGN="CENTER">drafting</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Zero-argument macros incorrectly specified
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.7.1&#160;
  <A href="https://wg21.link/cpp.replace.general">cpp.replace.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2577">2577</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">SG12</TD>
<TD ALIGN="LEFT">
Undefined behavior for preprocessing directives in macro arguments
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.7.1&#160;
  <A href="https://wg21.link/cpp.replace.general">cpp.replace.general</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3053">3053</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Allowing <TT>#undef likely</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.7.3&#160;
  <A href="https://wg21.link/cpp.stringize">cpp.stringize</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1625">1625</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">WG14</TD>
<TD ALIGN="LEFT">
Adding spaces between tokens in stringizing
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.7.3&#160;
  <A href="https://wg21.link/cpp.stringize">cpp.stringize</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1709">1709</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Stringizing raw string literals containing newline
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.7.3&#160;
  <A href="https://wg21.link/cpp.stringize">cpp.stringize</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2578">2578</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">SG12</TD>
<TD ALIGN="LEFT">
Undefined behavior when creating an invalid string literal via stringizing
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.7.4&#160;
  <A href="https://wg21.link/cpp.concat">cpp.concat</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2522">2522</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">WG14</TD>
<TD ALIGN="LEFT">
Removing placemarker tokens and retention of whitespace
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.7.4&#160;
  <A href="https://wg21.link/cpp.concat">cpp.concat</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2579">2579</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">SG12</TD>
<TD ALIGN="LEFT">
Undefined behavior when token pasting does not create a preprocessing token
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.7.5&#160;
  <A href="https://wg21.link/cpp.rescan">cpp.rescan</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#268">268</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">WG14</TD>
<TD ALIGN="LEFT">
Macro name suppression in rescanned replacement text
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.8&#160;
  <A href="https://wg21.link/cpp.line">cpp.line</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2580">2580</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">SG12</TD>
<TD ALIGN="LEFT">
Undefined behavior with <TT>#line</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.8&#160;
  <A href="https://wg21.link/cpp.line">cpp.line</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2693">2693</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">WG14</TD>
<TD ALIGN="LEFT">
Escape sequences for the <I>string-literal</I> of <TT>#line</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.10&#160;
  <A href="https://wg21.link/cpp.pragma">cpp.pragma</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1889">1889</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear effect of <TT>#pragma</TT> on conformance
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.12&#160;
  <A href="https://wg21.link/cpp.predefined">cpp.predefined</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2581">2581</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">SG12</TD>
<TD ALIGN="LEFT">
Undefined behavior for predefined macros
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.13&#160;
  <A href="https://wg21.link/cpp.pragma.op">cpp.pragma.op</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#897">897</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
<TT>_Pragma</TT> and extended <I>string-literal</I>s
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">15.13&#160;
  <A href="https://wg21.link/cpp.pragma.op">cpp.pragma.op</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2694">2694</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">WG14</TD>
<TD ALIGN="LEFT">
<I>string-literal</I>s of the <TT>_Pragma</TT> operator
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">17.2.4&#160;
  <A href="https://wg21.link/support.types.layout">support.types.layout</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2784">2784</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER">EWG</TD>
<TD ALIGN="LEFT">
Unclear definition of <I>member-designator</I> for <TT>offsetof</TT>
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">17.14.3&#160;
  <A href="https://wg21.link/csetjmp.syn">csetjmp.syn</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2361">2361</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Unclear description of <TT>longjmp</TT> undefined behavior
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">Annex C&#160;
  <A href="https://wg21.link/diff">diff</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1944">1944</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
New C incompatibilities
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">C.6&#160;
  <A href="https://wg21.link/diff.cpp03">diff.cpp03</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1279">1279</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Additional differences between C++ 2003 and C++ 2011
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">C.7&#160;
  <A href="https://wg21.link/diff.iso">diff.iso</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#1248">1248</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Updating Annex C to C99 and C23
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">C.7.4&#160;
  <A href="https://wg21.link/diff.expr">diff.expr</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#2875">2875</A></TD>
<TD ALIGN="CENTER">review</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Missing support for round-tripping null pointer values through indirection/address operators
</TD>
</TR>
<TR>
<TD ALIGN="LEFT">C.7.6&#160;
  <A href="https://wg21.link/diff.dcl">diff.dcl</A>
</TD>
<TD ALIGN="RIGHT"><A HREF="#3008">3008</A></TD>
<TD ALIGN="CENTER">open</TD>
<TD ALIGN="CENTER"></TD>
<TD ALIGN="LEFT">
Missing Annex C entry for <TT>void</TT> object declarations
</TD>
</TR>
</TABLE>
<BR><BR><HR>
<A NAME="Ready%20Status"></A><H3>Issues with "Ready" Status</H3>
<BR><BR><HR>
<A NAME="Tentatively%20Ready%20Status"></A><H3>Issues with "Tentatively Ready" Status</H3>
<BR><BR><HR>
<A NAME="Review%20Status"></A><H3>Issues with "Review" Status</H3>
<HR>
<A NAME="2726"></A><H4>2726.
  
Alternative tokens appearing as <I>attribute-token</I>s
</H4>
<B>Section: </B>5.9&#160; [<A href="https://wg21.link/lex.digraph">lex.digraph</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2023-03-16
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>Subclause 5.9 [<A href="https://wg21.link/lex.digraph#2">lex.digraph</A>] paragraph 2 specifies:</P>

<BLOCKQUOTE>

In all respects of the language, each alternative token behaves the
same, respectively, as its primary token, except for its spelling. [
Footnote: ... ]

</BLOCKQUOTE>

<P>However, 9.13.1 [<A href="https://wg21.link/dcl.attr.grammar#4">dcl.attr.grammar</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

... If a keyword (5.12 [<A href="https://wg21.link/lex.key">lex.key</A>]) or an alternative token
(5.9 [<A href="https://wg21.link/lex.digraph">lex.digraph</A>]) that satisfies the syntactic requirements
of an identifier (5.11 [<A href="https://wg21.link/lex.name">lex.name</A>]) is contained in
an <I>attribute-token</I>, it is considered an identifier. ...

</BLOCKQUOTE>

<P>It seems an alternative token (say, <TT>or</TT>) is treated the
same as the operator <TT>||</TT>, yet only the alternative token is
considered an identifier, not the operator, when appearing in
an <I>attribute-token</I>.  That seems contradictory.</P>

<P><B>Proposed resolution (approved by CWG 2023-05-12):</B></P>

<OL>

<LI>
<P>Change in 5.2 [<A href="https://wg21.link/lex.phases#2">lex.phases</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

Whitespace characters separating tokens are no longer
significant. Each preprocessing token is converted into a token
(5.10 [<A href="https://wg21.link/lex.token">lex.token</A>])<INS>, replacing each alternative token
by its corresponding primary token (5.9 [<A href="https://wg21.link/lex.digraph">lex.digraph</A>])</INS>.
The resulting tokens constitute a translation unit and are
syntactically and semantically analyzed and translated.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.13.1 [<A href="https://wg21.link/dcl.attr.grammar#4">dcl.attr.grammar</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

... If a keyword (5.12 [<A href="https://wg21.link/lex.key">lex.key</A>]) <DEL>or an alternative
token (5.9 [<A href="https://wg21.link/lex.digraph">lex.digraph</A>])</DEL> that satisfies the syntactic
requirements of an identifier (5.11 [<A href="https://wg21.link/lex.name">lex.name</A>]) is contained
in an <I>attribute-token</I>, it is considered an identifier. ...

</BLOCKQUOTE>
</LI>

</OL>

<P>This resolution also addresses <A HREF="cwg_active.html#1897">issue 1897</A>.</P>

<P><B>Additional notes (May, 2023)</B></P>



<P>During additional discussion on the EWG reflector, Alisdair
Meredith expressed that he intends to propose that some alternative
tokens be treated as full keywords in phase 7, to prevent <TT>and</TT>
from being used as an rvalue reference and <TT>compl</TT> from being
used for naming destructors.  That would reverse the above direction.</P>

<P>
Furthermore, an idea was floated to treat all alternative tokens as
full keywords in phase 7 and as identifiers in phase 4, amending the
grammar productions for expressions as necessary.  This removes the
special treatment of alternative tokens entirely, however the
treatment of examples such as <TT>#define and blah</TT> would change
from ill-formed to well-formed.  Some opposition was voiced against
changing the phase 4 treatment of alternative tokens.
</P>

<P><B>CWG 2023-06-16</B></P>

<P>Forwarded to EWG with paper issue
<A HREF="https://github.com/cplusplus/papers/issues/1581">#1581</A>.</P>

<BR><BR><HR>
<A NAME="1924"></A><H4>1924.
  
Definition of &#8220;literal&#8221; and kinds of literals
</H4>
<B>Section: </B>5.13&#160; [<A href="https://wg21.link/lex.literal">lex.literal</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Saeed Amrollah Boyouki
 &#160;&#160;&#160;

 <B>Date: </B>2014-05-12
  &#160;&#160;&#160;
  <B>Liaison: </B>editor<BR>




<P>The term &#8220;literal&#8221; is used without definition except
the implicit connection with the syntactic nonterminal <I>literal</I>.
The relationships of English terms to syntactic nonterminals (such
as &#8220;integer literal&#8221; and <I>integer-literal</I>) should
be examined throughout 5.13 [<A href="https://wg21.link/lex.literal">lex.literal</A>] and its subsections.</P>

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

<P>This issue will be handled editorially. It is being placed in
"review" status until that point.</P>

<BR><BR><HR>
<A NAME="1897"></A><H4>1897.
  
ODR vs alternative tokens
</H4>
<B>Section: </B>6.3&#160; [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

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




<P>According to 5.9 [<A href="https://wg21.link/lex.digraph#2">lex.digraph</A>] paragraph 2,</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>However, the primary and alternative tokens are different tokens,
which runs afoul of the ODR requirement in 6.3 [<A href="https://wg21.link/basic.def.odr#6">basic.def.odr</A>] paragraph 6
that the definitions consist of the &#8220;same
sequence of tokens.&#8221;  This wording should be amended to allow
for use of primary and alternative tokens.</P>

<P><B>CWG 2023-05-12</B></P>

<P>Addressed by <A HREF="cwg_active.html#2726">issue 2726</A>.</P>

<BR><BR><HR>
<A NAME="2888"></A><H4>2888.
  
Missing cases for reference and array types for argument-dependent lookup
</H4>
<B>Section: </B>6.5.4&#160; [<A href="https://wg21.link/basic.lookup.argdep">basic.lookup.argdep</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Lewis Baker
 &#160;&#160;&#160;

 <B>Date: </B>2024-04-30<BR>




<P>The specification for associated entities in argument-dependent
lookup recurses into template argument types, but misses handling
reference and array cases.  Those cannot appear for function
arguments.  For example:

<PRE>
  namespace N {
    template&lt;typename T&gt;
    struct A {
      operator T() const noexcept;
    };
  }
  namespace M {
    struct B {};
    void f(B&amp;);
  }

  void caller() {
    N::A&lt;M::B&amp;&gt; arg;
    f(arg);
  }
</PRE>
</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.5.4 [<A href="https://wg21.link/basic.lookup.argdep#3">basic.lookup.argdep</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

For each argument <DEL>type T</DEL> in the function call, there is a
set of zero or more associated entities to be considered.  The set of
entities is determined entirely by the types of the function arguments
(and any template template arguments). Any <I>typedef-name</I>s
and <I>using-declaration</I>s used to specify the types do not
contribute to this set.  The set of <INS>associated</INS>
entities <INS>for a type <I>cv</I> <TT>T</TT></INS> is determined in the
following way:
<UL>
<LI>If T is a fundamental type, its <DEL>associated</DEL> set
of <INS>associated</INS> entities is empty.</LI>
<LI>If T is a class type (including unions), its associated entities
are: the class itself; the class of which it is a member, if any; and,
if it is a complete type, its direct and indirect base
classes. Furthermore, if T is a class template specialization, its
associated entities also include: the entities associated with the
types of the template arguments provided for template type parameters;
the templates used as template template arguments; and the classes of
which any member templates used as template template arguments are
members.  [<I>Note 2:</I> Non-type template arguments do not
contribute to the set of associated entities. &#8212;<I>end
note</I>]</LI>
<LI>If T is an enumeration type, its associated entities are T and, if
it is a class member, the member's class.</LI>
<LI>If T is a pointer to U<INS>, a reference to <TT>U</TT>,</INS> or
an array of U, its associated entities are those associated with
U.</LI>
<LI>If T is a function type, its associated entities are those
associated with the function parameter types and those associated with
the return type.</LI>
<LI>If T is a pointer to a member function of a class X, its
associated entities are those associated with the function parameter
types and return type, together with those associated with X.</LI>
<LI>If T is a pointer to a data member of class X, its associated
entities are those associated with the member type together with those
associated with X.</LI>
</UL>

<DEL>In addition, if the argument is an overload set or the
address of such a set, its associated entities are the union of those
associated with each of the members of the set, i.e., the entities
associated with its parameter types and return type. Additionally,</DEL>

<INS>The associated entities of a function call are the associated
entities of each argument <I>A</I> of the call, consisting of
</INS>
<UL>
<LI class="ins">if <I>A</I> is an <I>id-expression</I> whose terminal
name refers to an overload set <I>O</I>, the union of the associated
entities of the function types of the members of <I>O</I>, and</LI>
<LI>if 
<DEL>the aforementioned overload set is named with</DEL> <INS>A
is</INS> a <I>template-id</I> <INS><I>I</I> whose terminal name refers
to an overload set</INS>, <DEL>its associated entities also
include its</DEL> <INS>the</INS> template <I>template-argument</I>s
<INS>of <I>I</I></INS> and <DEL>those</DEL> <INS>the</INS>
associated <DEL>with its</DEL> <INS>entities of each</INS> type
<DEL><I>template-argument</I>s.</DEL> <INS><I>template-argument</I>
of <I>I</I>, and</INS>
</LI>
<LI class="ins">
otherwise, if <I>A</I> has a type, the associated entities of the type
of <I>A</I>,
</LI>
<LI class="ins">
otherwise, <I>A</I> has no associated entities.
</LI>
</UL>
</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2940"></A><H4>2940.
  
Definition of "object"
</H4>
<B>Section: </B>6.8.2&#160; [<A href="https://wg21.link/intro.object">intro.object</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Roman Jasmann
 &#160;&#160;&#160;

 <B>Date: </B>2024-09-22<BR>




<P>Prior to
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0137r1.html">P0137R1</A>,
the term "object" was defined to be "a region of storage".  Currently,
the term "object" appears to be missing a definition.  The submitter
suggests to restore wording similar to "An object is a region of
storage that is occupied or released, associated with an object type
and certain properties." and disagrees with the resolutions suggested
below.</P>

<P><U>Possible resolution (option 1) [SUPERSEDED]:</U></P>

<P>Change in 6.8.2 [<A href="https://wg21.link/intro.object#1">intro.object</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<INS>An <I>object</I> is a logical element of the execution model of
the abstract machine (4.1.2 [<A href="https://wg21.link/intro.abstract">intro.abstract</A>]).</INS> The
constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An <DEL><I>object</I></DEL> <INS>object</INS> is
created by a definition (6.2 [<A href="https://wg21.link/basic.def">basic.def</A>]), by
a <I>new-expression</I> (7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]), by an
operation that implicitly creates objects (see below), when implicitly
changing the active member of a union (11.5 [<A href="https://wg21.link/class.union">class.union</A>]), or
when a temporary object is created (7.3.5 [<A href="https://wg21.link/conv.rval">conv.rval</A>],
6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>]). An object occupies a region of storage in
its period of construction (11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]), throughout
its lifetime (6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]), and in its period of
destruction (11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]).  [<I>Note 1:</I> A function
is not an object, regardless of whether or not it occupies storage in
the way that objects do.  &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P><U>Possible resolution (option 2) [SUPERSEDED]:</U></P>

<P>Change in 6.8.2 [<A href="https://wg21.link/intro.object#1">intro.object</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<INS>An <I>object</I> is an element of the execution representation of
the program in the abstract machine (4.1.2 [<A href="https://wg21.link/intro.abstract">intro.abstract</A>]) that
represents an instance of an object type.</INS> The constructs in a
C++ program create, destroy, refer to, access, and manipulate
objects. An <DEL><I>object</I></DEL>
<INS>object</INS> is created by a definition
(6.2 [<A href="https://wg21.link/basic.def">basic.def</A>]), by a <I>new-expression</I>
(7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]), by an operation that implicitly
creates objects (see below), when implicitly changing the active
member of a union (11.5 [<A href="https://wg21.link/class.union">class.union</A>]), or when a temporary
object is created (7.3.5 [<A href="https://wg21.link/conv.rval">conv.rval</A>],
6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>]). An object occupies a region of storage in
its period of construction (11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]), throughout
its lifetime (6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]), and in its period of
destruction (11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]).  [<I>Note 1:</I> A function
is not an object, regardless of whether or not it occupies storage in
the way that objects do.  &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P><B>CWG 2024-11-08</B></P>

<P>An alternative phrasing was suggested.</P>

<P>Update 2025-01-13: The submitter of the issue conveys his agreement
with this phrasing.</P>

<P><U>Possible resolution [SUPERSEDED]:</U></P>

<P>Change in 6.8.2 [<A href="https://wg21.link/intro.object#1">intro.object</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<INS>An <I>object</I> is a logical unit of data that occupies storage
in the abstract machine (4.1.2 [<A href="https://wg21.link/intro.abstract">intro.abstract</A>]).</INS> The
constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An <DEL><I>object</I></DEL>
<INS>object</INS> is created by a definition
(6.2 [<A href="https://wg21.link/basic.def">basic.def</A>]), by a <I>new-expression</I>
(7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]), by an operation that implicitly
creates objects (see below), when implicitly changing the active
member of a union (11.5 [<A href="https://wg21.link/class.union">class.union</A>]), or when a temporary
object is created (7.3.5 [<A href="https://wg21.link/conv.rval">conv.rval</A>],
6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>]). <DEL>An object occupies a region of storage in
its period of construction (11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]), throughout
its lifetime (6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]), and in its period of
destruction (11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]).</DEL>  [<I>Note 1:</I> A function
is not an object, regardless of whether or not it occupies storage in
the way that objects do.  &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P><B>Additional notes (January, 2025)</B></P>



<P>Objects may be of zero sizes; those do not occupy storage at all.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.8.2 [<A href="https://wg21.link/intro.object#1">intro.object</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<INS>An <I>object</I> is a logical unit of data that has an
address (see below) in the storage of the abstract machine
(4.1.2 [<A href="https://wg21.link/intro.abstract">intro.abstract</A>]).</INS> The constructs in a C++ program
create, destroy, refer to, access, and manipulate
objects. An <DEL><I>object</I></DEL>
<INS>object</INS> is created by a definition
(6.2 [<A href="https://wg21.link/basic.def">basic.def</A>]), by a <I>new-expression</I>
(7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]), by an operation that implicitly
creates objects (see below), when implicitly changing the active
member of a union (11.5 [<A href="https://wg21.link/class.union">class.union</A>]), or when a temporary
object is created (7.3.5 [<A href="https://wg21.link/conv.rval">conv.rval</A>],
6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>]).  An object occupies a region of storage
in its period of construction (11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]),
throughout its lifetime (6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]), and in its
period of destruction (11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]).  [<I>Note 1:</I>
A function is not an object, regardless of whether or not it occupies
storage in the way that objects do.  &#8212;<I>end note</I>]

</BLOCKQUOTE>
<BR><BR><HR>
<A NAME="1027"></A><H4>1027.
  
Type consistency and reallocation of scalar types
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#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,
6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>] 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>(See also issues <A HREF="cwg_defects.html#1116">1116</A> and
<A HREF="cwg_defects.html#1338">1338</A>.)</P>

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

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

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#6">basic.life</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

Before the lifetime of an object has started but after the storage
which the object will occupy has been allocated [ Footnote:
... ]<INS>,</INS> or<DEL>,</DEL> after the lifetime of an object has
ended and before the storage which the object occupied is <DEL>reused
or</DEL> released, any pointer that represents the address of the
storage location where the object will be or was located may be used
but only in limited ways. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

Similarly, before the lifetime of an object has started but after the
storage which the object will occupy has been allocated<INS>,</INS>
or<DEL>,</DEL> after the lifetime of an object has ended and before
the storage which the object occupied is <DEL>reused or</DEL>
released, any glvalue that refers to the original object may be used
but only in limited ways. ...

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2551"></A><H4>2551.
  
"Refers to allocated storage" has no meaning
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Andrey Erokhin
 &#160;&#160;&#160;

 <B>Date: </B>2020-09-07<BR>




<P>6.8.4 [<A href="https://wg21.link/basic.life#6">basic.life</A>] paragraph 6 specifies:</P>

<BLOCKQUOTE>

Before the lifetime of an object has started but after the storage
which the object will occupy has been allocated or, after the lifetime
of an object has ended and before the storage which the object
occupied is reused or released, any pointer that represents the
address of the storage location where the object will be or was
located may be used but only in limited ways. For an object under
construction or destruction, see 11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>].
Otherwise, such a pointer refers to allocated storage
(6.8.6.5.2 [<A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>]), and using the pointer as if the
pointer were of type <TT>void*</TT> is well-defined.

</BLOCKQUOTE>

<P>Similarly, 6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7 specifies:</P>

<BLOCKQUOTE>

Similarly, before the lifetime of an object has started but after the
storage which the object will occupy has been allocated or, after the
lifetime of an object has ended and before the storage which the
object occupied is reused or released, any glvalue that refers to the
original object may be used but only in limited ways.  For an object
under construction or destruction, see 11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>].
Otherwise, such a glvalue refers to allocated storage
(6.8.6.5.2 [<A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>]), and using the properties of the
glvalue that do not depend on its value is well-defined.

</BLOCKQUOTE>

<P>In either case, it is unclear what "refers to allocated storage"
means, beyond the properties ascribed to an object in
6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>].</P>

<P>See also <A HREF="cwg_closed.html#1853">issue 1853</A>.</P>

<P><B>Proposed resolution:</B></P>

<OL>
<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#6">basic.life</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

For an object under construction or destruction, see
11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>].  Otherwise, <DEL>such a pointer refers to
allocated storage (6.8.6.5.2 [<A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>]), and</DEL>
using <DEL>the</DEL> <INS>such a</INS> pointer as if the pointer were
of type <TT>void*</TT> is well-defined.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

For an object under construction or destruction, see
11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>].  Otherwise, <DEL>such a glvalue refers to
allocated storage (6.8.6.5.2 [<A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>]), and</DEL> using
the properties of <DEL>the</DEL> <INS>such a</INS> glvalue that do not
depend on its value is well-defined.

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="2677"></A><H4>2677.
  
Replacing union subobjects
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2022-12-06<BR>


<P>The resolution to NB comment US 041 (C++20 CD) does not seem to have fully
addressed the original issue, allowing:</P>

<PRE>
  union U { int i, j; };
  U u;
  new (&amp;u) U{.i = 5};
  int k = u.j;  //<SPAN CLASS="cmnt"> OK! New </SPAN>U::i<SPAN CLASS="cmnt"> transparently replaces existing </SPAN>u.j<SPAN CLASS="cmnt">!</SPAN>
</PRE>

<P>The suggestion is to allow a newly-created complete object to
transparently replace any object of the same type in the same storage,
except for a potentially-overlapping subobject or a const complete
object, and to allow a newly-created subobject to transparently
replace only a corresponding subobject of an existing object.</P>

<P><U>Suggested resolution [SUPERSEDED]:</U></P>

<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#8">basic.life</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

... An object o1 is transparently replaceable by an object o2 if:
<UL>

<LI>
<INS>o2 is a complete object and:</INS>

<UL>

<LI>the storage that o2 occupies exactly overlays the storage that o1
occupied, and</LI>

<LI>o1 and o2 are of the same type (ignoring the
top-level cv-qualifiers), and</LI>

<LI>o1 is not a const, complete object, and</LI>

<LI>
<DEL>neither</DEL> o1 <DEL>nor o2</DEL> is <INS>not</INS> a
potentially-overlapping subobject (6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]),
<DEL>and</DEL> <INS>or</INS>
</LI>

</UL>

</LI>

<LI>
<DEL>either o1 and o2 are both complete objects, or</DEL> o1 and
o2 are <INS>corresponding</INS> direct subobjects of objects p1 and
p2, respectively, and p1 is transparently replaceable by p2.</LI>

</UL>

</BLOCKQUOTE>

<P><B>Additional notes (February, 2023)</B></P>

<P>The suggested resolution above does not handle the additional
example in <A HREF="cwg_active.html#2676">issue 2676</A>.</P>

<P><U>Suggested resolution:</U></P>

<OL>

<LI>
<P>Change in 6.8.2 [<A href="https://wg21.link/intro.object#2">intro.object</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

Objects can contain other objects, called subobjects. A subobject can
be a member subobject (11.4 [<A href="https://wg21.link/class.mem">class.mem</A>]), a base class
subobject (11.7 [<A href="https://wg21.link/class.derived">class.derived</A>]), or an array element. An object
that is not a subobject of any other object is called a <I>complete
object</I>. If an object is created in storage associated with
a <DEL>member subobject or array element</DEL> <INS>subobject</INS> e
(which may or may not be within its lifetime), the created object is a
subobject of e's containing object if:
<UL>
<LI>the lifetime of e's containing object has begun and not
ended, and</LI>
<LI>the storage for the new object exactly overlays the
storage location associated with e, and</LI>
<LI>
<INS>e is not a potentially-overlapping subobject, and</INS>
</LI>
<LI>the new object is of
the same type as e (ignoring cv-qualification).</LI>
</UL>
<INS>In this case, e and the created object are <I>corresponding
direct subobjects</I>.</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#8">basic.life</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

... An object o1 is transparently replaceable by an object o2
if <INS>either</INS>
<UL>
<LI>
<INS>o1 and o2 are complete objects for which:</INS>
<UL>
<LI>
<INS>o1 is not const,</INS>
</LI>
<LI>the storage that o2 occupies exactly overlays the storage that o1
occupied, and</LI>
<LI>o1 and o2 are of the same type (ignoring the top-level
cv-qualifiers), <DEL>and</DEL> <INS>or</INS>
</LI>
<LI><DEL>o1 is not a const, complete
object, and</DEL></LI>
<LI><DEL>neither o1 nor o2 is a potentially-overlapping
subobject (6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]), and</DEL></LI>
</UL>
</LI>

<LI>
<DEL>either o1 and o2 are both complete objects, or</DEL>
o1 and o2 are <INS>corresponding</INS> direct subobjects <DEL>of objects p1 and p2, respectively, and p1 is
transparently replaceable by p2</DEL> <INS>(6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>])
for which:</INS>
<UL>
<LI><INS>the complete object of o1 is not const or</INS></LI>
<LI>
<INS>o1 is a mutable member subobject or a subobject thereof</INS>.</LI>
</UL>
</LI>
</UL>

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2821"></A><H4>2821.
  
Lifetime, zero-initialization, and dynamic initialization
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jan Schultke
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-24<BR>




<P>Consider:</P>

<PRE>
  int i = i;
</PRE>

<P>According to 6.10.3.2 [<A href="https://wg21.link/basic.start.static#2">basic.start.static</A>] paragraph 2, <TT>i</TT> is
zero-initialized and then dynamic initialization is applied.  However,
it is unclear whether the lifetime of <TT>i</TT> has started at the
point when the dynamic initialization occurs. According to
6.8.4 [<A href="https://wg21.link/basic.life#1">basic.life</A>] paragraph 1:</P>

<BLOCKQUOTE>

... 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>its
initialization (if any) is complete (including vacuous initialization)
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]),</LI>
</UL>
except ...

</BLOCKQUOTE>

<P>Possible directions:</P>

<UL>
<LI>Zero-initialization starts the lifetime, and the dynamic
initialization just modifies the value, similar to a delegating
constructor.</LI>

<LI>The lifetime doesn't begin until the dynamic initialization is
complete, but we allow scalar objects to be "under construction"
(11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]).
</LI>

<LI>Zero-initialization starts the lifetime, and dynamic
initialization transparently replaces the object.</LI>
</UL>

<P>The example in 6.10.3.2 [<A href="https://wg21.link/basic.start.static#3">basic.start.static</A>] paragraph 3 suggests the
first option.</P>

<P><B>CWG 2024-01-19</B></P>

<P>The first option is is intended.</P>

<P><U>Possible resolution:</U></P>

<P>Split and change 6.8.4 [<A href="https://wg21.link/basic.life#1">basic.life</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<P>
... 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>
<DEL>its</DEL> <INS>any</INS> initialization <DEL>(if any)</DEL>
is complete (including vacuous initialization)
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]),</LI>
</UL>
except that if the object is a union member or subobject thereof, its
lifetime only begins if that union member is the initialized member in
the union (9.5.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>], 11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]),
or as described in 11.5 [<A href="https://wg21.link/class.union">class.union</A>],
11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>], and 11.4.6 [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>], and
except as described in 20.2.10.2 [<A href="https://wg21.link/allocator.members">allocator.members</A>].
<INS>[ Note: In particular, the lifetime of a complete class object
begins when the non-delegating constructor returns
(11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]).  The lifetime of a complete object with
static or thread storage duration begins when static initialization is
complete (6.10.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]). -- end note ]</INS>
</P>

<P>
The lifetime of an object o of type T ends when:  ...
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2434"></A><H4>2434.
  
Mandatory copy elision vs non-class objects
</H4>
<B>Section: </B>6.8.7&#160; [<A href="https://wg21.link/class.temporary">class.temporary</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2019-09-30<BR>


<P>In the following example,</P>

<PRE>
  int f() {
    X x;
    return 4;
  }
  int a = f();
</PRE>

<P>
<TT>a</TT> must be directly initialized in the return statement
of <TT>f()</TT> because the exception permitting temporaries for
function arguments and return types in 6.8.7 [<A href="https://wg21.link/class.temporary#3">class.temporary</A>] paragraph 3
applies only to certain class types:</P>

<BLOCKQUOTE>

When an object of class type <TT>X</TT> is passed to or
returned from a function, if <TT>X</TT> has at least one
eligible copy or move constructor
(11.4.4 [<A href="https://wg21.link/special">special</A>]), each such constructor is
trivial, and the destructor of <TT>X</TT> is either trivial
or deleted, implementations are permitted to create a
temporary object to hold the function parameter or result
object. The temporary object is constructed from the
function argument or return value, respectively, and the
function's parameter or return object is initialized as if
by using the eligible trivial constructor to copy the
temporary (even if that constructor is inaccessible or would
not be selected by overload resolution to perform a copy or
move of the object). [<I>Note:</I> This latitude is granted
to allow objects of class type to be passed to or returned
from functions in registers. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>This requirement is observable, since the destructor of
<TT>X</TT> in the example could inspect the value
of <TT>a</TT>.</P>

<P>The permissions in this paragraph should also apply to all
non-class types.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.8.7 [<A href="https://wg21.link/class.temporary#3">class.temporary</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

When an object of class type X is passed to or returned from a
function, if X has at least one eligible copy or move constructor
(11.4.4 [<A href="https://wg21.link/special">special</A>]), each such constructor is trivial, and
the destructor of X is either trivial or deleted, implementations are
permitted to create a temporary object to hold the function parameter
or result object. The temporary object is constructed from the
function argument or return value, respectively, and the function's
parameter or return object is initialized as if by using the eligible
trivial constructor to copy the temporary (even if that constructor is
inaccessible or would not be selected by overload resolution to
perform a copy or move of the object). <INS>Similarly, implementations
are permitted to create a temporary object of scalar type to hold a
function parameter or result object.</INS> [<I>Note 4:</I> This
latitude is granted to allow objects of <INS>scalar or</INS> class
type to be passed to or returned from functions in registers.
&#8212;<I>end note</I>]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2827"></A><H4>2827.
  
Representation of unsigned integral types
</H4>
<B>Section: </B>6.9.2&#160; [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>David Detweiler
 &#160;&#160;&#160;

 <B>Date: </B>2021-09-12<BR>


<P>(From editorial issue
<A HREF="https://github.com/cplusplus/draft/issues/4893">4893</A>.)</P>

<P>It is unclear whether the representation of unsigned integral types
is unspecified or implementation-defined.</P>

<P><B>Proposed resolution [SUPERSEDED]:</B></P>

<P>Change in 6.9.2 [<A href="https://wg21.link/basic.fundamental#17">basic.fundamental</A>] paragraph 17 as follows:</P>

<BLOCKQUOTE>

The types described in this subclause are called <I>fundamental types</I>.
<INS>The representation of a fundamental type is unspecified except as
stated in this subclause.</INS>

</BLOCKQUOTE>

<P><B>CWG 2023-12-01</B></P>

<P>Since there is no requirement for "implementation-defined" in the
specification, the representation is unspecified by omission.  It was
noted that "unspecified behavior" has well-defined (and narrow)
meaning, whereas the not-specified property here is static throughout
the instance of the abstract machine.  In that sense, it is similar to
implementation-defined, abent the documentation requirement.  It might
be worthwhile to have a defined term for such properties.</P>

<P><B>Proposed resolution:</B></P>

<P>Change in 6.9.2 [<A href="https://wg21.link/basic.fundamental#17">basic.fundamental</A>] paragraph 17 as follows:</P>

<BLOCKQUOTE>

The types described in this subclause are called <I>fundamental types</I>.
<INS>The representation of a fundamental type is implementation-defined, subject to the constraints in this subclause.</INS>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2587"></A><H4>2587.
  
Visible side effects and initial value of an object
</H4>
<B>Section: </B>6.10.2.2&#160; [<A href="https://wg21.link/intro.races">intro.races</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Andrey Erokhin
 &#160;&#160;&#160;

 <B>Date: </B>2022-05-10<BR>


<P>Subclause 6.10.2.2 [<A href="https://wg21.link/intro.races#13">intro.races</A>] paragraph 13 specifies:</P>

<BLOCKQUOTE>

A <I>visible side effect</I> A on a scalar object or bit-field M with
respect to a value computation B of M satisfies the conditions:

<UL>
<LI>A happens before B and
</LI>

<LI>there is no other side effect X to M such that A happens before X
and X happens before B.
</LI>
</UL>

The value of a non-atomic scalar object or bit-field M, as determined
by evaluation B, shall be the value stored by the visible side effect
A.

</BLOCKQUOTE>

<P>However, a side effect is defined as 6.10.1 [<A href="https://wg21.link/intro.execution#7">intro.execution</A>] paragraph 7:</P>

<BLOCKQUOTE>

Reading an object designated by a volatile glvalue
(7.2.1 [<A href="https://wg21.link/basic.lval">basic.lval</A>]), modifying an object, calling a library
I/O function, or calling a function that does any of those operations
are all <I>side effects</I>, which are changes in the state of the
execution environment.

</BLOCKQUOTE>

<P>It seems that initialization of an object is not a side effect, and
thus the value of an scalar object can never be the value obtained
during initialization.</P>

<P><B>Proposed resolution:</B></P>

<P>Change in 6.10.1 [<A href="https://wg21.link/intro.execution#7">intro.execution</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

Reading an object designated by a volatile glvalue
(7.2.1 [<A href="https://wg21.link/basic.lval">basic.lval</A>]), modifying an object <INS>(including
initialization)</INS>, calling a library I/O function, or calling a
function that does any of those operations are all side effects, which
are changes in the state of the execution environment. ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2816"></A><H4>2816.
  
Unclear phrasing "may assume ... eventually"
</H4>
<B>Section: </B>6.10.2.3&#160; [<A href="https://wg21.link/intro.progress">intro.progress</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2023-04-26<BR>


<P>Subclause 6.10.2.3 [<A href="https://wg21.link/intro.progress#1">intro.progress</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

The implementation may assume that any thread will eventually do one
of the following:
<UL>
<LI>terminate,</LI>
<LI>make a call to a library I/O function,</LI>
<LI>perform an access through a volatile glvalue, or</LI>
<LI>perform a synchronization operation or an atomic operation.</LI>
</UL>

</BLOCKQUOTE>

<P>This formulation has two issues.  First, what are the consequences
of the user violation the assumption?  It should be clearly specified
that undefined behavior results.  Second, what does "eventually" mean?
The wording gives the impression that the requirement is satisfied if
a thread performs some I/O operation at its beginning and then goes
into an empty infinite loop.</P>

<P>It was also noted that that 6.10.2.3 [<A href="https://wg21.link/intro.progress#3">intro.progress</A>] paragraph 3
is a near-duplicate of paragraph 1.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Remove 6.10.2.3 [<A href="https://wg21.link/intro.progress#1">intro.progress</A>] paragraph 1:</P>

<BLOCKQUOTE class="del">

The implementation may assume that any thread will eventually do one
of the following:

<UL>
<LI>terminate,</LI>
<LI>make a call to a library I/O function,</LI>
<LI>perform an access through a volatile glvalue, or</LI>
<LI>perform a synchronization operation or an atomic operation.</LI>
</UL>

[<I>Note 1:</I> This is intended to allow compiler transformations
such as removal of empty loops, even when termination cannot be
proven. &#8212;<I>end note</I>]

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.10.2.3 [<A href="https://wg21.link/intro.progress#5">intro.progress</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<INS>The behavior is undefined if a thread of execution that has not
terminated stops making execution steps.</INS>

[<I>Note:</I> <INS>This is intended to allow compiler transformations
such as removal of empty loops, even when termination cannot be
proven.</INS> <DEL>Because of this and the preceding requirement
regarding what threads of execution have to perform eventually,
it</DEL> <INS>It</INS> follows that no thread of execution can execute
forever without an execution step occurring. &#8212;<I>end note</I>]

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2923"></A><H4>2923.
  
Note about infinite loops and execution steps
</H4>
<B>Section: </B>6.10.2.3&#160; [<A href="https://wg21.link/intro.progress">intro.progress</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Simon Cooksey
 &#160;&#160;&#160;

 <B>Date: </B>2024-08-12
  &#160;&#160;&#160;
  <B>Liaison: </B>SG1<BR>


<P>Given that certain infinite loops are no longer undefined behavior
(see P2809R3 (Trivial infinite loops are not Undefined Behavior),
adopted in March 2024), the note in 6.10.2.3 [<A href="https://wg21.link/intro.progress#5">intro.progress</A>] paragraph 5 claiming there are no executions without eventual execution
steps should be struck.</P>

<P><B>Proposed resolution (approved by CWG 2024-09-13):</B></P>

<P>Remove 6.10.2.3 [<A href="https://wg21.link/intro.progress#5">intro.progress</A>] paragraph 5:</P>

<BLOCKQUOTE class="del">

[<I>Note 4:</I> Because of this and the preceding requirement
regarding what threads of execution have to perform eventually, it
follows that no thread of execution can execute forever without an
execution step occurring. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P><B>CWG 2024-11-19</B></P>

<P>The definition of "execution step" in 6.10.2.3 [<A href="https://wg21.link/intro.progress#3">intro.progress</A>] paragraph 3 does not include the invocation
of <TT>std::this_thread::yield</TT>.  However, trivial infinite loops
do nothing but yield, and are not undefined behavior.  Therefore, the
note is believed to be factually wrong.  CWG seeks advice from SG1 for
resolving the inconsistency, via
<A HREF="https://github.com/cplusplus/papers/issues/2139">paper issue #2139</A>.</P>

<BR><BR><HR>
<A NAME="2914"></A><H4>2914.
  
Unclear order of initialization of static and thread-local variables
</H4>
<B>Section: </B>6.10.3.2&#160; [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2024-06-20<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/559">#559</A>.)</P>

<P>Specification is missing that clarifies that non-local variables
with static storage duration are initialized before those with thread
storage duration.</P>

<P><U>Suggested resolution:</U></P>

<OL>
<LI>
<P>Change in 6.10.3.2 [<A href="https://wg21.link/basic.start.static#1">basic.start.static</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Variables with static storage duration are initialized as a
consequence of program initiation. Variables with thread storage
duration are initialized as a consequence of thread execution.
<INS>
If the program does not start a thread (6.10.2 [<A href="https://wg21.link/intro.multithread">intro.multithread</A>])
other than the main thread (6.10.3.1 [<A href="https://wg21.link/basic.start.main">basic.start.main</A>]) before the
completion of all non-deferred (6.10.3.3 [<A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>])
initialization of non-block variables with static storage duration,
then all non-deferred initialization (if any) of non-block variables
with static storage duration strongly happens before any non-deferred
initialization of non-block variables with thread storage duration.
</INS>
Within each of these phases of initiation, initialization occurs as follows.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.10.3.3 [<A href="https://wg21.link/basic.start.dynamic#5">basic.start.dynamic</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

It is implementation-defined whether the dynamic initialization of a
non-block non-inline variable <INS><I>o</I></INS> with static storage
duration is sequenced before the first statement of main or is
deferred. If it is deferred, it strongly happens before any
non-initialization odr-use of any non-inline function or non-inline
variable defined in the same translation unit as <DEL>the variable to
be initialized</DEL> <INS><I>o</I> and any deferred initialiation of
non-inline non-block variables with thread storage duration defined in
the same translation unit as <I>o</I></INS>. [ Footnote: ... ] It is
implementation-defined in which threads and at which points in the
program such deferred dynamic initialization occurs.

</BLOCKQUOTE>

</LI>
</OL>
<BR><BR><HR>
<A NAME="2833"></A><H4>2833.
  
Evaluation of odr-use
</H4>
<B>Section: </B>6.10.3.3&#160; [<A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2023-12-01<BR>




<P>The concept of odr-use is a static program property, independent of runtime control flow.  For example,</P>

<PRE>
void f() {
  if (false)
    g();          // <SPAN CLASS="cmnt">unconditionally odr-uses </SPAN>g
}
</PRE>

<P>Yet, some parts of the standard talk about an odr-use participating
in the happens-before relation, which is a category error.</P>

<P><B>Proposed resolution [SUPERSEDED]:</B></P>

<OL>
<LI>
<P>Change in 6.3 [<A href="https://wg21.link/basic.def.odr#6">basic.def.odr</A>] paragraph 6 through 8 as follows:</P>

<BLOCKQUOTE>

<P>
A structured binding is odr-used <DEL>if it appears as</DEL>
<INS>by</INS> a potentially-evaluated expression <INS><I>E</I> if it
is named by <I>E</I></INS>.
</P>

<P>*this is odr-used if this appears
as a potentially-evaluated expression (including as the result of the
implicit transformation in the body of a non-static member function
(11.4.3 [<A href="https://wg21.link/class.mfct.non.static">class.mfct.non.static</A>])).
</P>

<P>
A virtual member function is odr-used if it is not pure. A function is
odr-used <INS>by</INS> <DEL>if it is named by</DEL> a
potentially-evaluated expression or conversion <INS><I>E</I> if it is
named by <I>E</I></INS>. A non-placement allocation or deallocation
function for a class is odr-used by the definition of a constructor of
that class. A non-placement deallocation function for a class is
odr-used by the definition of the destructor of that class, or by
being selected by the lookup at the point of definition of a virtual
destructor (11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]). [ Footnote: ... ]
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.10.3.3 [<A href="https://wg21.link/basic.start.dynamic#4">basic.start.dynamic</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

A <I>non-initialization odr-use</I> <INS>of an entity</INS>
is <INS>the evaluation of an expression that odr-uses</INS>
<DEL>an odr-use</DEL> (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>])
<INS>the entity where the evaluation is</INS> not caused directly or
indirectly by the initialization of a non-block static or thread
storage duration variable.

</BLOCKQUOTE>
</LI>
</OL>

<P><B>CWG 2024-01-19</B></P>

<P>Since "odr-use" is a category error here, use the term
"non-initialization use" instead.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 6.3 [<A href="https://wg21.link/basic.def.odr#6">basic.def.odr</A>] paragraph 6 through 8 as follows:</P>

<BLOCKQUOTE>

<P>
A structured binding is odr-used <DEL>if it appears as</DEL>
<INS>by</INS> a potentially-evaluated expression <INS><I>E</I> if it
is named by <I>E</I></INS>.
</P>

<P>*this is odr-used if this appears
as a potentially-evaluated expression (including as the result of the
implicit transformation in the body of a non-static member function
(11.4.3 [<A href="https://wg21.link/class.mfct.non.static">class.mfct.non.static</A>])).
</P>

<P>
A virtual member function is odr-used if it is not pure. A function is
odr-used <INS>by</INS> <DEL>if it is named by</DEL> a
potentially-evaluated expression or conversion <INS><I>E</I> if it is
named by <I>E</I></INS>. A non-placement allocation or deallocation
function for a class is odr-used by the definition of a constructor of
that class. A non-placement deallocation function for a class is
odr-used by the definition of the destructor of that class, or by
being selected by the lookup at the point of definition of a virtual
destructor (11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]). [ Footnote: ... ]
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.10.3.3 [<A href="https://wg21.link/basic.start.dynamic#4">basic.start.dynamic</A>] paragraph 4 through 7 as follows:</P>

<BLOCKQUOTE>

<P>
A <I>non-initialization <DEL>odr-use</DEL> <INS>use</INS></I> <INS>of an entity</INS>
is <INS>the evaluation of an expression that odr-uses</INS>
<DEL>an odr-use</DEL> (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>])
<INS>the entity where the evaluation is</INS> not caused directly or
indirectly by the initialization of a non-block static or thread
storage duration variable.
</P>

<P>...If it is deferred, it strongly happens before any
non-initialization <DEL>odr-use</DEL> <INS>use</INS> of any non-inline
function or non-inline variable defined in the same translation unit
as the variable to be initialized. [ Footnote: ... ] ...  [ Example:
...  It is implementation-defined whether either a or b is initialized
before main is entered or whether the initializations are delayed
until a is first <DEL>odr-used</DEL> <INS>used</INS> in main. In
particular, if a is initialized before main is entered, it is not
guaranteed that b will be initialized before it
is <DEL>odr-used</DEL> <INS>used</INS> by the initialization of a,
that is, before A::A is called. If, however, a is initialized at some
point after the first statement of main, b will be initialized prior
to its use in A::A. -- end example ]
</P>

<P>
... If it is deferred, it strongly happens before any non-initialization
<DEL>odr-use</DEL> <INS>use</INS> of that variable. ...
</P>

<P>
... If it is deferred, the initialization associated with the entity for
thread t is sequenced before the first
non-initialization <DEL>odr-use</DEL> <INS>use</INS> by t of any
non-inline variable with thread storage duration ...
</P>

<P>

</P>

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2929"></A><H4>2929.
  
Lifetime of trivially-destructible static or thread-local objects
</H4>
<B>Section: </B>6.10.3.4&#160; [<A href="https://wg21.link/basic.start.term">basic.start.term</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mathias Stearn
 &#160;&#160;&#160;

 <B>Date: </B>2024-08-05<BR>




<P>
<A HREF="cwg_defects.html#2256">Issue 2256</A> (adopted in February, 2019)
changed the rules such that the lifetimes of objects do not depend on
whether the destructor is trivial or not.  However, the motivation of
that issue mentioned only objects with automatic storage duration.  To
be able to avoid order-of-destruction issues across translation units,
it would be useful to never end the lifetime of trivially-destructible
objects with static storage duration and to delay the end of the
lifetime of such objects with thread storage duration as long as
possible.</P>

<P><U>Possible resolution [SUPERSEDED]:</U></P>

<OL>
<LI>
<P>Change in 6.10.3.4 [<A href="https://wg21.link/basic.start.term#1">basic.start.term</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Constructed <INS>class</INS> objects (9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) with
static storage duration <INS>and having a non-trivial destructor
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>])</INS> are destroyed and functions
registered with std::atexit are called as part of a call to std::exit
(17.5 [<A href="https://wg21.link/support.start.term">support.start.term</A>]). The call to std::exit is sequenced before
the destructions and the registered functions.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.10.3.4 [<A href="https://wg21.link/basic.start.term#2">basic.start.term</A>] paragraph 2 as follows:</P>
<BLOCKQUOTE>

Constructed <INS>class</INS> objects with thread storage duration
within a given thread <INS>and having a non-trivial destructor
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>])</INS> are destroyed as a result of
returning from the initial function of that thread and as a result of
that thread calling std::exit. The destruction
of <DEL>all</DEL> <INS>those</INS> constructed objects with thread
storage duration within that thread strongly happens before
<INS>releasing the storage for objects with thread storage duration
within that thread, which in turn strongly happens before</INS>
destroying any object with static storage duration.

</BLOCKQUOTE>
</LI>
</OL>

<P><B>CWG 2024-09-27</B></P>

<P>Also allow for constant destruction, consider arrays of class type,
and adjust the happens-before requirements.</P>

<P><B>Proposed resolution (approved by CWG 2024-10-11) [SUPERSEDED]:</B></P>

<OL>
<LI>
<P>Change in 6.10.3.4 [<A href="https://wg21.link/basic.start.term#1">basic.start.term</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Constructed <INS>complete</INS> objects
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) with static storage
duration <INS>and not having constant destruction
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>])</INS> are destroyed and functions
registered with std::atexit are called as part of a call to std::exit
(17.5 [<A href="https://wg21.link/support.start.term">support.start.term</A>]). The call to std::exit is sequenced before
the destructions and the registered functions.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.10.3.4 [<A href="https://wg21.link/basic.start.term#2">basic.start.term</A>] paragraph 2 as follows:</P>
<BLOCKQUOTE>

Constructed <INS>complete</INS> objects with thread storage duration
within a given thread <INS>and not having constant destruction
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>])</INS> are destroyed as a result of
returning from the initial function of that thread and as a result of
that thread calling std::exit. <INS>The destruction of those
constructed objects within that thread is sequenced before releasing
the storage for all objects with thread storage duration within that
thread (6.8.6.3 [<A href="https://wg21.link/basic.stc.thread">basic.stc.thread</A>]).  Also, the</INS> <DEL>The</DEL>
destruction of <DEL>all</DEL> <INS>those</INS> constructed
objects <DEL>with thread storage duration</DEL> within that thread
strongly happens before destroying any object with static storage
duration.

</BLOCKQUOTE>
</LI>
</OL>

<P><B>CWG 2024-11-22</B></P>

<P>Continue to actually destroy constant-destruction objects, but do
so after all dynamic destruction is done.</P>

<P><B>Proposed resolution:</B></P>

<OL>
<LI>
<P>Change in 6.10.3.4 [<A href="https://wg21.link/basic.start.term#1">basic.start.term</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Constructed <INS>complete</INS> objects (9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>])
with static storage duration are destroyed and functions registered
with std::atexit are called as part of a call to std::exit
(17.5 [<A href="https://wg21.link/support.start.term">support.start.term</A>]). The call to std::exit is sequenced before
the destructions and the registered functions.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.10.3.4 [<A href="https://wg21.link/basic.start.term#2">basic.start.term</A>] paragraph 2 as follows:</P>
<BLOCKQUOTE>

Constructed <INS>complete</INS> objects with thread storage duration
within a given thread are destroyed as a result of returning from the
initial function of that thread and as a result of that thread calling
std::exit. <INS>The destruction of those constructed objects is
sequenced before releasing the storage for any object with thread
storage duration within that thread (6.8.6.3 [<A href="https://wg21.link/basic.stc.thread">basic.stc.thread</A>]).
The</INS> <DEL>The</DEL> destruction of <DEL>all</DEL>
<INS>those</INS> constructed objects <DEL>with thread storage duration
within that thread</DEL> strongly happens before destroying any object
with static storage duration.

</BLOCKQUOTE>
</LI>

<LI>
<P>Add a paragraph after 6.10.3.4 [<A href="https://wg21.link/basic.start.term#2">basic.start.term</A>] paragraph 2:</P>

<BLOCKQUOTE class="ins">

The destruction of an object with thread storage duration within a
given thread and having constant destruction (7.7 [expr.const]) is
sequenced after the destruction of any other object with thread
storage duration within the thread.  The destruction of an object with
static storage duration and having constant destruction is sequenced
after the destruction of any other object with static storage duration
and after any call to a function passed to <TT>std::atexit</TT>.  The
sequencing rules in the remainder of this subclause apply only to
objects not having constant destruction.

</BLOCKQUOTE>
</LI>

<LI>
<P>Do not change in 6.10.3.4 [<A href="https://wg21.link/basic.start.term#3">basic.start.term</A>] paragraph 3:</P>

<BLOCKQUOTE>

If the completion of the constructor or dynamic initialization of an
object with static storage duration strongly happens before that of
another, the completion of the destructor of the second is sequenced
before the initiation of the destructor of the first. If the
completion of the constructor or dynamic initialization of an object
with thread storage duration is sequenced before that of another, the
completion of the destructor of the second is sequenced before the
initiation of the destructor of the first. If an object is initialized
statically, the object is destroyed in the same order as if the object
was dynamically initialized. For an object of array or class type, all
subobjects of that object are destroyed before any block variable with
static storage duration initialized during the construction of the
subobjects is destroyed. If the destruction of an object with static
or thread storage duration exits via an exception, the function
std::terminate is called (14.6.2 [<A href="https://wg21.link/except.terminate">except.terminate</A>]).

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2902"></A><H4>2902.
  
Implicit <TT>this</TT> transformation outside of permitted contexts
</H4>
<B>Section: </B>7.5.5.1&#160; [<A href="https://wg21.link/expr.prim.id.general">expr.prim.id.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Vincent X
 &#160;&#160;&#160;

 <B>Date: </B>2024-06-14<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/553">#553</A>.)</P>

<P>Subclause 7.5.5.1 [<A href="https://wg21.link/expr.prim.id.general#2">expr.prim.id.general</A>] paragraph 2 specifies:</P>

<BLOCKQUOTE>

If an <I>id-expression</I> E denotes a non-static non-type member of
some class C at a point where the current class
(7.5.3 [<A href="https://wg21.link/expr.prim.this">expr.prim.this</A>]) is X and
<UL>
<LI>E is potentially
evaluated or C is X or a base class of X, and</LI>
<LI>E is not
the <I>id-expression</I> of a class member access expression
(7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]), and</LI>
<LI>if E is a <I>qualified-id</I>, E is not the un-parenthesized
operand of the unary &amp; operator
(7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]),</LI>
</UL>
the <I>id-expression</I> is transformed into a class member access
expression using (*this) as the object expression.

</BLOCKQUOTE>

<P>This rule transforms the following valid code (according to the
example in 7.5.3 [<A href="https://wg21.link/expr.prim.this#5">expr.prim.this</A>] paragraph 5) into invalid code:</P>

<PRE>
  struct A {
   int x;
   int a[sizeof(x)];
   decltype(x) f();
  };
</PRE>

<P>This is a regression introduced by 
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html">P1787R6</A>
(Declarations and where to find them).</P>

<P><B>Proposed resolution (reviewed by CWG 2024-06-14) [SUPERSEDED]:</B></P>

<P>Change in 7.5.5.1 [<A href="https://wg21.link/expr.prim.id.general#2">expr.prim.id.general</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If an <I>id-expression</I> E denotes a non-static non-type member of
some class C at a point where the current class
(7.5.3 [<A href="https://wg21.link/expr.prim.this">expr.prim.this</A>]) is X and
<UL>
<LI class="ins">the point is in a context where
7.5.3 [<A href="https://wg21.link/expr.prim.this">expr.prim.this</A>] specifies a type for <TT>this</TT>,
and</LI>
<LI>E is potentially evaluated or C is X or a base class of X,
and</LI>
<LI>E is not the <I>id-expression</I> of a class member access
expression (7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]), and</LI>
<LI>if E is a <I>qualified-id</I>, E is not the un-parenthesized
operand of the unary &amp; operator
(7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]),</LI>
</UL>
the <I>id-expression</I> is transformed into a class member access
expression using (*this) as the object expression.

</BLOCKQUOTE>

<P><B>Additional notes (June, 2024)</B></P>

<P>Unevaluated uses in static member functions are valid (and should
not be transformed).  However, the resolution above does not address
the status quo which does perform the transformation.</P>

<P><B>Additional notes (July, 2024)</B></P>

<P>Per <A HREF="https://github.com/cplusplus/CWG/issues/573">#573</A>
and
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0847r7.html">P0847R7</A> (Deducing this),
the intent was that explicit object member functions
have naming restrictions similar to other non-static member functions.
For example,
</P>

<PRE>
  struct C {
    int f(this C);
  };

  using T = decltype(C::f); //<SPAN CLASS="cmnt"> error</SPAN>
  int g = C::f(42); //<SPAN CLASS="cmnt"> error</SPAN>
</PRE>

<P>The status quo wording does not reflect that desired outcome.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 7.5.5.1 [<A href="https://wg21.link/expr.prim.id.general#2">expr.prim.id.general</A>] paragraph 2 through 4 as follows:</P>

<BLOCKQUOTE>

If an <I>id-expression</I> E denotes a non-static non-type member of
some class C <DEL>at a point where the current class
(7.5.3 [<A href="https://wg21.link/expr.prim.this">expr.prim.this</A>]) is X and</DEL> <INS>, the following rules
apply.

E is said to <I>refer to a local member</I> of some class X if E
appears at a point where X is the current class and C is X or a base
class of X.

E has the following <I>associated cv-qualification</I> relative to
some class X:
</INS>
<UL class="ins">
<LI>If E appears in a <I>function-definition</I>,
<I>member-declarator</I>, or <I>declarator</I> that declares a member
function or member function template of X, at a point after the
optional <I>cv-qualifier-seq</I>, the associated cv-qualification is
the <I>cv-qualifier-seq</I>, if present, and otherwise empty.</LI>
<LI>Otherwise, if E appears in a <I>member-declarator</I> declaring a
non-static data member of X, at a point within the optional default
member initializer, the associated cv-qualification is empty.</LI>
<LI>Otherwise, E has no associated cv-qualification.</LI>
</UL>

<P class="ins">E has the following meaning:</P>

<UL class="ins">
<LI>If E is the <I>id-expression</I> of a class member access, see
7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>].</LI>
<LI>Otherwise, if E is a <I>qualified-id</I> that is the
un-parenthesized operand of the unary &amp; operator, see
7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>].</LI>
<LI>Otherwise, if E denotes a non-static data member with declared
type <TT>T</TT> and E is not potentially evaluated, the result is an
lvalue of type <I>cv</I> <TT>T</TT> where <I>cv</I> is empty unless E
refers to a local member of some class X, in which case <I>cv</I> is
the associated cv-qualification relative to X (if any).
[ Example:
<PRE>
  template&lt;int n&gt; class R { };
  struct S {
    int m;
    char g(int&amp;);         // <SPAN CLASS="cmnt">#1</SPAN>
    int g(const int&amp;);    // <SPAN CLASS="cmnt">#2</SPAN>
    auto f() const -&gt; R&lt;sizeof(g(m))&gt;;     // <SPAN CLASS="cmnt">OK, return type is </SPAN>R&lt;sizeof(int)&gt;
  };
  int j = sizeof(S::m + 42); //<SPAN CLASS="cmnt"> OK</SPAN>
</PRE>
-- end example ]</LI>
<LI>Otherwise, if E is refers to a local member of some class X:
<UL>
<LI>If E appears in an implicit object member function, is
potentially evaluated, and has a (possibly empty) associated
cv-qualification relative to X, E is transformed into a class member
access expression using <TT>(*this)</TT> as the object expression.
This transformation does not apply in the template definition context
(13.8.3.2 [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]).</LI>
<LI>Otherwise, E shall not be potentially evaluated; the type and
value category of the result is as specified in
7.5.5.2 [<A href="https://wg21.link/expr.prim.id.unqual">expr.prim.id.unqual</A>] and 7.5.5.3 [<A href="https://wg21.link/expr.prim.id.qual">expr.prim.id.qual</A>].</LI>
</UL>
</LI>

<LI>Otherwise, if E denotes a member enumerator, the result is as
specified in 7.5.5.2 [<A href="https://wg21.link/expr.prim.id.unqual">expr.prim.id.unqual</A>] and
7.5.5.3 [<A href="https://wg21.link/expr.prim.id.qual">expr.prim.id.qual</A>].</LI>

<LI>Otherwise, the program is ill-formed.</LI>
</UL>

<UL class="del">
<LI>E is potentially evaluated or C is X or a base class of X,
and</LI>
<LI>E is not the <I>id-expression</I> of a class member access
expression (7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]), and</LI>
<LI>if E is a <I>qualified-id</I>, E is not the un-parenthesized
operand of the unary &amp; operator
(7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]),</LI>
</UL>
<P class="del">the <I>id-expression</I> is transformed into a class
member access expression using <TT>(*this)</TT> as the object
expression.  [<I>Note 2:</I> If C is not X or a base class of X, the
class member access expression is ill-formed. Also, if
the <I>id-expression</I> occurs within a static or explicit object
member function, the class member access is ill-formed. &#8212;<I>end
note</I>] This transformation does not apply in the template
definition context (13.8.3.2 [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]).</P>

<P>
If an <I>id-expression</I> E denotes a member M of an anonymous union
(11.5.2 [<A href="https://wg21.link/class.union.anon">class.union.anon</A>]) U:
<UL>
<LI>If U is a non-static data member, E refers to M as a member of
the lookup context of the terminal name of E (after any implicit
transformation to a class member access expression).  [<I>Example
1:</I> o.x is interpreted as o.u.x, where u names the anonymous union
member. &#8212;<I>end example</I>]</LI>
<LI>Otherwise, E is interpreted
as a class member access (7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]) that
designates the member subobject M of the anonymous union variable for
U.  [<I>Note 3:</I> Under this interpretation, E no longer denotes a
non-static data member. &#8212;<I>end note</I>] [<I>Example 2:</I>
N::x is interpreted as N::u.x, where u names the anonymous union
variable. &#8212;<I>end example</I>]</LI>
</UL>
</P>

<P class="del">An <I>id-expression</I> that denotes a non-static data member or
implicit object member function of a class can only be used:
<UL class="del">
<LI>as part of a class member access
(after any implicit transformation (see above)) in which the object
expression refers to the member's class or a class derived from that
class, or</LI>
<LI>to form a pointer to member
(7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]), or</LI>
<LI>if that <I>id-expression</I>
denotes a non-static data member and it appears in an unevaluated
operand.  [<I>Example 3:</I>
<PRE>
  struct S { int m; };
  int i = sizeof(S::m);      //<SPAN CLASS="cmnt"> OK</SPAN>
  int j = sizeof(S::m + 42); //<SPAN CLASS="cmnt"> OK</SPAN>
</PRE>
&#8212;<I>end example</I>]</LI>
</UL>
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.1.5 [<A href="https://wg21.link/expr.ref#5">expr.ref</A>] paragraph 5 as follow:</P>

<BLOCKQUOTE>

Otherwise, the object expression shall be of class type. The class
type shall be complete unless the class member access appears in the
definition of that class.  <INS><TT>E2</TT> shall denote a member
of that class.</INS> [<I>Note 3:</I> The program is ill-formed if
the result differs from that when the class is complete
(6.5.2 [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]). &#8212;<I>end note</I>] [<I>Note 4:</I>
6.5.5 [<A href="https://wg21.link/basic.lookup.qual">basic.lookup.qual</A>] describes how names are looked up after the
. and -&gt; operators. &#8212;<I>end note</I>]

</BLOCKQUOTE>
</LI>
</OL>
<BR><BR><HR>
<A NAME="2738"></A><H4>2738.
  
"denotes a destructor" is missing specification
</H4>
<B>Section: </B>7.5.5.2&#160; [<A href="https://wg21.link/expr.prim.id.unqual">expr.prim.id.unqual</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2022-05-22<BR>


<P>Subclause 7.5.5.2 [<A href="https://wg21.link/expr.prim.id.unqual#1">expr.prim.id.unqual</A>] paragraph 1 has a note that
lacks a corresponding normative specification:</P>

<BLOCKQUOTE>

[<I>Note 1:</I> For <I>operator-function-id</I>s, see
12.4 [<A href="https://wg21.link/over.oper">over.oper</A>]; for <I>conversion-function-id</I>s, see
11.4.8.3 [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>]; for <I>literal-operator-id</I>s, see
12.6 [<A href="https://wg21.link/over.literal">over.literal</A>]; for <I>template-ids</I>, see
13.3 [<A href="https://wg21.link/temp.names">temp.names</A>]. A <I>type-name</I>
or <I>decltype-specifier</I> prefixed by ~ denotes the destructor of
the type so named; see 7.5.5.5 [<A href="https://wg21.link/expr.prim.id.dtor">expr.prim.id.dtor</A>]. Within the
definition of a non-static member function, an identifier that names a
non-static member is transformed to a class member access expression
(11.4.3 [<A href="https://wg21.link/class.mfct.non.static">class.mfct.non.static</A>]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P><B>Proposed resolution:</B></P>

<P>Change in 7.5.5.2 [<A href="https://wg21.link/expr.prim.id.unqual#1">expr.prim.id.unqual</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<INS>A <I>type-name</I>
or <I>decltype-specifier</I> prefixed by <TT>~</TT> denotes the destructor of
the named type; see 7.5.5.5 [<A href="https://wg21.link/expr.prim.id.dtor">expr.prim.id.dtor</A>].</INS>
[<I>Note 1:</I> For <I>operator-function-id</I>s, see
12.4 [<A href="https://wg21.link/over.oper">over.oper</A>]; for <I>conversion-function-id</I>s, see
11.4.8.3 [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>]; for <I>literal-operator-id</I>s, see
12.6 [<A href="https://wg21.link/over.literal">over.literal</A>]; for <I>template-ids</I>, see
13.3 [<A href="https://wg21.link/temp.names">temp.names</A>]. <DEL>A <I>type-name</I>
or <I>decltype-specifier</I> prefixed by ~ denotes the destructor of
the type so named; see 7.5.5.5 [<A href="https://wg21.link/expr.prim.id.dtor">expr.prim.id.dtor</A>].</DEL> Within the
definition of a non-static member function, an identifier that names a
non-static member is transformed to a class member access expression
(11.4.3 [<A href="https://wg21.link/class.mfct.non.static">class.mfct.non.static</A>]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2737"></A><H4>2737.
  
Temporary lifetime extension for reference init-captures
</H4>
<B>Section: </B>7.5.6.3&#160; [<A href="https://wg21.link/expr.prim.lambda.capture">expr.prim.lambda.capture</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Tomasz Kami&#324;ski
 &#160;&#160;&#160;

 <B>Date: </B>2023-05-23<BR>


<P>Consider:</P>

<PRE>
  struct S {};
  const S f();
  auto x = [&amp;ref = f()] { return ref; }
</PRE>

<P>Subclause 7.5.6.3 [<A href="https://wg21.link/expr.prim.lambda.capture#6">expr.prim.lambda.capture</A>] paragraph 6 specifies:</P>

<BLOCKQUOTE>

An <I>init-capture</I> inhabits the lambda scope
(6.4.5 [<A href="https://wg21.link/basic.scope.lambda">basic.scope.lambda</A>]) of the <I>lambda-expression</I>.
An <I>init-capture</I> without ellipsis behaves as if it declares and
explicitly captures a variable of the form
<TT>&#8220;auto <I>init-capture</I> ;&#8221;</TT>, except that:

<UL>
<LI>if the capture is by copy (see below), the non-static data member
declared for the capture and the variable are treated as two different
ways of referring to the same object, which has the lifetime of the
non-static data member, and no additional copy and destruction is
performed, and
</LI>
<LI>if the capture is by reference, the variable's lifetime ends when
the closure object's lifetime ends.
</LI>
</UL>

</BLOCKQUOTE>

<P>It is unclear whether the temporary returned by <TT>f()</TT> is
lifetime-extended by being bound to a reference init-capture.</P>

<P>There is implementation divergence: gcc rejects the example; clang
accepts and extends the lifetime of the temporary; MSVC and EDG accept
and do not extend the lifetime.</P>

<P><B>Proposed resolution (reviewed by CWG 2024-03-01):</B></P>

<P>Change in 7.5.6.3 [<A href="https://wg21.link/expr.prim.lambda.capture#6">expr.prim.lambda.capture</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

An <I>init-capture</I> inhabits the lambda scope
(6.4.5 [<A href="https://wg21.link/basic.scope.lambda">basic.scope.lambda</A>]) of the <I>lambda-expression</I>.
An <I>init-capture</I> without ellipsis behaves as if it declares and
explicitly captures a variable of the form
<TT>&#8220;auto <I>init-capture</I> ;&#8221;</TT>, except that:

<UL>
<LI>if the capture is by copy (see below), the non-static data member
declared for the capture and the variable are treated as two different
ways of referring to the same object, which has the lifetime of the
non-static data member, and no additional copy and destruction is
performed, and
</LI>
<LI class="ins">
if the capture is by reference and the reference would bind to an
object that is the result of a temporary expression, the program is
ill-formed, and
</LI>
<LI>if the capture is by reference, the variable's lifetime ends when
the closure object's lifetime ends.
</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2557"></A><H4>2557.
  
Class member access referring to an unrelated class
</H4>
<B>Section: </B>7.6.1.5&#160; [<A href="https://wg21.link/expr.ref">expr.ref</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2022-03-25<BR>




<P>Consider:</P>

<PRE>
  struct A {
    static int x;
  };

  struct B {
    using type = A;
  };

  int y = B().type::x;
</PRE>

<P>There seems to be no requirement that the member named in a class
member access actually is a member of the class of the object
expression. Subclause 7.5.5.1 [<A href="https://wg21.link/expr.prim.id.general#3">expr.prim.id.general</A>] paragraph 3 does not cover static members:</P>

<BLOCKQUOTE>

An <I>id-expression</I> that denotes a non-static data member or
non-static member function of a class can only be used:
<UL>
<LI>
as part of a class member access in which the object expression refers
to the member's class or a class derived from that class, or
</LI>

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

</BLOCKQUOTE>

<P><U>Suggested resolution:</U></P>

<OL>
<LI>
<P>Change in 7.6.1.5 [<A href="https://wg21.link/expr.ref#5">expr.ref</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<P>
Otherwise, the object expression shall be of class type. The class
type shall be complete unless the class member access appears in the
definition of that class.<br> [<I>Note</I>: The program is ill-formed
if the result differs from that when the class is complete
(6.5.2 [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]). &#8212;<I>end note</I>]<br>
[<I>Note</I>: 6.5.5 [<A href="https://wg21.link/basic.lookup.qual">basic.lookup.qual</A>] describes how names are
looked up after the <TT>.</TT> and <TT>-&gt;</TT> operators. &#8212;<I>end note</I>]
<INS>If <TT>E2</TT> is a <I>qualified-id</I>, the terminal name of
its <I>nested-name-specifier</I> shall denote the type of <TT>E1</TT>
or a base class thereof.</INS>

</P>

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

<PRE class="ins">
  struct A {
    static int x;
  };

  struct B {
    static int x;
  };

  struct D : B {
    using type = A;
  };

  int y1 = D().B::x;         //<SPAN CLASS="cmnt"> OK, </SPAN>B<SPAN CLASS="cmnt"> is a base class of </SPAN>D
  int y2 = D().type::x;      //<SPAN CLASS="cmnt"> error: </SPAN>A<SPAN CLASS="cmnt"> is not a base class of </SPAN>D
  int y3 = D::type::x;       //<SPAN CLASS="cmnt"> OK, evaluates </SPAN>A::x
</PRE>
<P><INS>&#8212;<I>end example</I> ]</INS></P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.1.5 [<A href="https://wg21.link/expr.ref#7.5">expr.ref</A>] bullet 7.5 as follows:</P>

<UL>
<LI>...</LI>
<LI>
If <TT>E2</TT> is <DEL>a member</DEL> <INS>an</INS> enumerator and
the type of <TT>E2</TT> is <TT>T</TT>, the expression <TT>E1.E2</TT>
is a prvalue. The type of <TT>E1.E2</TT> is <TT>T</TT>.

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

<PRE class="ins">
  enum E { e };
  struct X {
    using E::e;
  };
  int f(X x) {
    return x.e;
  }
</PRE>
<P><INS>&#8212;<I>end example</I> ]</INS></P>

</LI>
</UL>

</LI>

<LI>

<P>Change in 7.5.5.1 [<A href="https://wg21.link/expr.prim.id.general#4">expr.prim.id.general</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

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

<UL>

<LI>as part of a class member access (7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>])
<DEL>in which the object expression refers to the member's class</DEL>
[ Footnote: ... ] <DEL>or a class derived from that class</DEL>, or
</LI>

<LI>to form a pointer to member (7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]), or
</LI>

<LI>if that <I>id-expression</I> denotes a non-static data member and
it appears in an unevaluated operand.
</LI>

</UL>

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="2566"></A><H4>2566.
  
Matching deallocation for uncaught exception
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2022-04-13<BR>


<P>Initialization of an object may terminate via an exception, in
which case any dynamically-allocated memory is freed, per
7.6.2.8 [<A href="https://wg21.link/expr.new#26">expr.new</A>] paragraph 26:</P>

<BLOCKQUOTE>

If any part of the object initialization described above [ Footnote:
... ] terminates by throwing an exception and a suitable deallocation
function can be found, the deallocation function is called to free the
memory in which the object was being constructed, after which the
exception continues to propagate in the context of
the <I>new-expression</I>.  If no unambiguous matching deallocation
function can be found, propagating the exception does not cause the
object's memory to be freed.

</BLOCKQUOTE>

<P>However, implementations do not consistently support this provision
in case the exception remains uncaught:</P>

<PRE>
  #include &lt;iostream&gt;
  struct C {
    void* operator new(std::size_t n) {
      std::cout &lt;&lt; "malloc\n";
      return malloc(n);
    }
    void operator delete(void* ptr) {
      std::cout &lt;&lt; "free\n";
      free(ptr);
    }
    C() {
      throw 0;
    }
  };
  int main() {
    auto ptr = new C;
  }
</PRE>

<P>Both clang and GCC do not free the memory in this example; they do
so if the exception is caught in <TT>main</TT>.</P>

<P>Maybe a similar provision as used for stack unwinding in
14.4 [<A href="https://wg21.link/except.handle#9">except.handle</A>] paragraph 9 is desirable:</P>

<BLOCKQUOTE>

If no matching handler is found, the function <TT>std::terminate</TT> is
invoked; whether or not the stack is unwound before this invocation of
<TT>std::terminate</TT> is implementation-defined
(14.6.2 [<A href="https://wg21.link/except.terminate">except.terminate</A>]).

</BLOCKQUOTE>

<P><U>Suggested resolution:</U></P>

<P>Integrate freeing dynamically-allocated memory with stack unwinding
(14.3 [<A href="https://wg21.link/except.ctor">except.ctor</A>]), since this is what implementations
actually do.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 7.6.2.8 [<A href="https://wg21.link/expr.new#26">expr.new</A>] paragraph 26, 27, and 28 as follows:</P>


<BLOCKQUOTE>

<P><DEL>If any part of the object initialization described above [
Footnote: This can include evaluating a <I>new-initializer</I> and/or
calling a constructor. ] terminates by throwing an exception and a
suitable deallocation function can be found, the deallocation function
is called to free the memory in which the object was being
constructed, after which the exception continues to propagate in the
context of the <I>new-expression</I>.  If no unambiguous matching
deallocation function can be found, propagating the exception does not
cause the object's memory to be freed.  [<I>Note 13:</I> This is
appropriate when the called allocation function does not allocate
memory; otherwise, it is likely to result in a memory
leak. &#8212;<I>end note</I>]</DEL></P>

<P>
<INS>For purposes of stack unwinding (14.3 [<A href="https://wg21.link/except.ctor">except.ctor</A>]), the <I>matching deallocation function</I> is determined as follows:</INS>
If the <I>new-expression</I> does not begin with a unary ::
operator and the allocated type is a class type T or an array thereof,
a search is performed for the deallocation function's name in the
scope of T. Otherwise, or if nothing is found, the deallocation
function's name is looked up by searching for it in the global scope.</P>

<P>A declaration of a placement deallocation function matches the
declaration of a placement allocation function if it has the same
number of parameters and, after parameter transformations
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]), all parameter types except the first
are identical. If the lookup finds a single matching deallocation
function, that function <DEL>will be called</DEL> <INS>is the matching
deallocation function</INS>; otherwise, <DEL>no deallocation function
will be called</DEL> <INS>there is no matching deallocation
function</INS>. If the lookup finds a usual deallocation function and
that function, considered as a placement deallocation function, would
have been selected as a match for the allocation function, the program
is ill-formed. For a non-placement allocation function, the normal
deallocation function lookup is used to find the matching deallocation
function (7.6.2.9 [<A href="https://wg21.link/expr.delete">expr.delete</A>]).</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 14.3 [<A href="https://wg21.link/except.ctor#1">except.ctor</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

As control passes from the point where an exception is thrown to a
handler, objects are destroyed <INS>and deallocation functions are
invoked</INS> by a process, specified in this subclause,
called <I>stack unwinding</I>.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 14.3 [<A href="https://wg21.link/except.ctor#5">except.ctor</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<DEL>[<I>Note 4:</I> If the object was allocated by a <I>new-expression</I>
(7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]),</DEL>
<INS>If the evaluation of a <I>new-expression</I> other than the
invocation of the allocation function is terminated by an
exception,</INS> the matching deallocation function
<DEL>(6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>])</DEL>, if any, is
called <INS>(7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>])</INS>
<DEL>to free the storage occupied by the
object</DEL>. <DEL>&#8212;<I>end note</I>]</DEL>

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2593"></A><H4>2593.
  
Insufficient base class restriction for pointer-to-member expression
</H4>
<B>Section: </B>7.6.4&#160; [<A href="https://wg21.link/expr.mptr.oper">expr.mptr.oper</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2022-06-04<BR>


<P>Consider:</P>

<PRE>
  struct A {};
  struct AA : A { int y; };
  struct B : A { int x; };
  struct C : AA, B {};

  constexpr int f(const A &amp;a) {
    int A::*mp = static_cast&lt;int A::*&gt;(&amp;B::x);
    return a.*mp;
  }

  extern char x[f(static_cast&lt;const AA &amp;&gt;(C{{{}, 13}, {{}, 42}}))];
  extern char x[13];
</PRE>

<P>Subclause 7.6.4 [<A href="https://wg21.link/expr.mptr.oper#4">expr.mptr.oper</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

Abbreviating <I>pm-expression</I>.*<I>cast-expression</I> as E1.*E2,
E1 is called the <I>object expression</I>.  If the dynamic type of E1 does
not contain the member to which E2 refers, the behavior is undefined.

</BLOCKQUOTE>

<P>In the example, the dynamic type of <TT>a</TT> is <TT>C</TT>, which
does contain <TT>B::x</TT>, and the undefined behavior provision does
not trigger.  Thus the call to <TT>f</TT> is required to yield 42;
however common implementations produce 13.  The behavior for this case
ought to be undefined.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 7.6.4 [<A href="https://wg21.link/expr.mptr.oper#4">expr.mptr.oper</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

Abbreviating <I>pm-expression</I>.*<I>cast-expression</I> as E1.*E2,
E1 is called the <I>object expression</I>.
<DEL>If the dynamic type of E1 does not contain the member to which E2
refers,</DEL>
<INS>Where the type of E2 is "pointer to member of T", C is the
(unique) class of which the member to which E2 refers is a direct
member, and B is the object of type T that either is the result of E1
or is the uniquely so-typed base subobject thereof, if B is neither of
type C nor a base class subobject of an object of type C, then
</INS>
the behavior is undefined.

</BLOCKQUOTE>
<BR><BR><HR>
<A NAME="2778"></A><H4>2778.
  
Trivial destructor does not imply constant destruction
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-27<BR>


<P>Consider:</P>

<PRE>
  struct Foo {};
  struct Bar {
    mutable Foo f;
  };
  constexpr Bar b{};     //<SPAN CLASS="cmnt"> #1</SPAN>
</PRE>

<P>In C++20, Foo and Bar are literal types, and #1 is well-formed.  In
C++23, the requirement for the variable <TT>b</TT> changed to
"constant destruction".  However, <TT>Bar</TT> does not have constant
destruction, because its mutable member violates
7.7 [<A href="https://wg21.link/expr.const#5.17">expr.const</A>] bullet 5.17:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>
an invocation of a destructor (11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]) or a
function call whose <I>postfix-expression</I> names a
pseudo-destructor (7.6.1.3 [<A href="https://wg21.link/expr.call">expr.call</A>]), in either case for
an object whose lifetime did not begin within the evaluation of E;
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>This is because the mutable member is considered to have its
lifetime begin outside of E per 7.7 [<A href="https://wg21.link/expr.const#9">expr.const</A>] paragraph 9:</P>

<BLOCKQUOTE>

An object a is said to have constant destruction if:
<UL>
<LI>it is not
of class type nor (possibly multidimensional) array thereof, or
</LI>
<LI>
it is of class type or (possibly multidimensional) array thereof, that
class type has a constexpr destructor, and for a hypothetical
expression E whose only effect is to destroy a, E would be a core
constant expression if the lifetime of a and its non-mutable
subobjects (but not its mutable subobjects) were considered to start
within E.
</LI>
</UL>

</BLOCKQUOTE>

<P><B>Proposed resolution (reviewed by CWG 2024-03-01):</B></P>

<P>Change in 7.7 [<A href="https://wg21.link/expr.const#10">expr.const</A>] paragraph 10 as follows:</P>

<BLOCKQUOTE>

An object a is said to have constant destruction if:
<UL>
<LI>it is not
of class type nor (possibly multidimensional) array thereof, or
</LI>
<LI>
it is of class type or (possibly multidimensional) array thereof, that
class type has a constexpr destructor, and for a hypothetical
expression E whose only effect is to destroy a, E would be a core
constant expression
<INS>if any invocation of a trivial destructor for a mutable subobject
is ignored and</INS> if the lifetime of a and its non-mutable
subobjects (but not its mutable subobjects) were considered to start
within E.
</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2800"></A><H4>2800.
  
Instantiating constexpr variables for potential constant evaluation
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Shafik Yaghmour
 &#160;&#160;&#160;

 <B>Date: </B>2023-09-22<BR>




<P>Consider:</P>

<PRE>
  template &lt;typename T&gt;
  struct A {
    T data;

    static const A a;
  };
  template &lt;typename T&gt;
  inline constexpr A&lt;T&gt; A&lt;T&gt;::a {42};

  static_assert(A&lt;int&gt;::a.data == 42);
</PRE>

<P>This ought to be well-formed, but there is no rule that would cause
instantiation of <TT>A&lt;int&gt;::a</TT>.</P>

<P>Also consider:</P>

<PRE>
  template&lt;typename T&gt; struct A {
    static T x;
  };
  template&lt;typename T&gt; T A&lt;T&gt;::x = (std::cout &lt;&lt; "constructed", T());
  template&lt;typename T&gt; void b(decltype(&amp;A&lt;int&gt;::x));
</PRE>

<P>For the second example, it is undesirable to
instantiate <TT>A&lt;int&gt;</TT>.</P>

<P><U>Possible resolution [SUPERSEDED]:</U></P>

<P>Change in 7.7 [<A href="https://wg21.link/expr.const#3">expr.const</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

A variable is <I>potentially-constant</I> if it is constexpr or it has
reference or non-volatile const-qualified integral or enumeration
type <INS>or, for a templated variable, if the definition that would
be instantiated if the variable were needed for constant evaluation
uses the <TT>constexpr</TT> <I>decl-specifier</I>
(13.7.6.2 [<A href="https://wg21.link/temp.spec.partial.match">temp.spec.partial.match</A>])</INS>.

</BLOCKQUOTE>

<P><B>CWG 2023-10-20</B></P>

<P>The phrasing suggests that <TT>const int</TT> variables
instantiated from a variable template are no longer
potentially-constant.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 7.7 [<A href="https://wg21.link/expr.const#3">expr.const</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

A variable is <I>potentially-constant</I> if it is
<DEL>constexpr</DEL> <INS>declared with the
<TT>constexpr</TT> <I>decl-specifier</I></INS> or it has reference
or non-volatile const-qualified integral or enumeration type.
<INS>Such a variable may be instantiated from a templated variable, in
which case the definition that would be instantiated if the variable
were needed for constant evaluation is considered
(13.7.6.2 [<A href="https://wg21.link/temp.spec.partial.match">temp.spec.partial.match</A>])</INS>.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2976"></A><H4>2976.
  
Transferring control out of a function
</H4>
<B>Section: </B>8.10&#160; [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Artem Koton
 &#160;&#160;&#160;

 <B>Date: </B>2024-12-20<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/656">#656</A>.)
</P>

<P>Subclause 8.10 [<A href="https://wg21.link/stmt.dcl#2">stmt.dcl</A>] paragraph 2 specifies:</P>

<BLOCKQUOTE>

... Upon each transfer of control (including sequential execution of
statements) within a function from point P to point Q, all block
variables with automatic storage duration that are active at P and not
at Q are destroyed in the reverse order of their construction. ...;
when a function returns, Q is after its body.

</BLOCKQUOTE>

<P>The phrasing "within a function" can be misread as not applying to
transfers out of a function (e.g. execution of a <TT>return</TT>
statement).</P>

<P><U>Possible resolution:</U></P>

<P>Change in 8.10 [<A href="https://wg21.link/stmt.dcl#2">stmt.dcl</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A block variable with automatic storage duration
(6.8.6.4 [<A href="https://wg21.link/basic.stc.auto">basic.stc.auto</A>]) is active everywhere in the scope to
which it belongs after its <I>init-declarator</I> . Upon each transfer
of control (including sequential execution of statements)
within <INS>or out of</INS> a function from point P to point Q, all
block variables with automatic storage duration that are active at P
and not at Q are destroyed in the reverse order of their
construction. Then, all block variables with automatic storage
duration that are active at Q but not at P are initialized in
declaration order; unless all such variables have vacuous
initialization (6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]), the transfer of control
shall not be a jump. [ Footnote: ...] When
a <I>declaration-statement</I> is executed, P and Q are the points
immediately before and after it; when a function returns, Q is after
its body.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1670"></A><H4>1670.
  
<TT>auto</TT> as <I>conversion-type-id</I>
</H4>
<B>Section: </B>9.2.9.7&#160; [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-26
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR><BR>


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



<P>(See also submission
<A HREF="https://github.com/cplusplus/CWG/issues/736">#736</A>.)</P>

<P>The current wording allows something like</P>

<PRE>
  struct S {
    operator auto() { return 0; }
  };
</PRE>

<P>If it is intended to be permitted, the details of its handling
are not clear.  Also, a similar syntax has been discussed as a
possible future extension for dealing with proxy types in deduction
which, if adopted, could cause confusion.</P>

<P><B>Additional note, November, 2013:</B></P>

<P>Doubt was expressed during the 2013-11-25 drafting review
teleconference as to the usefulness of this provision.  It is therefore
being left open for further consideration after C++14 is finalized.</P>

<P><B>Notes from the February, 2014 meeting:</B></P>

<P>CWG continued to express doubt as to the usefulness of this construct
but felt that if it is permitted, the rules need
clarification.</P>

<P><B>Additional note (December, 2021):</B></P>

<P>See duplicate issue <A HREF="cwg_closed.html#2493">2493</A> for
additional details.</P>

<P><B>Additional note (August, 2025):</B></P>

<P>CWG appears to be leaning towards making declarations
of <TT>operator auto</TT> ill-formed.  Forwarding to EWG for
approval of that direction via
<A HREF="https://github.com/cplusplus/papers/issues/2409">paper issue #2409</A>,
by decision of the CWG chair.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 9.2.9.7.1 [<A href="https://wg21.link/dcl.spec.auto.general#4">dcl.spec.auto.general</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

A placeholder type can appear in the <I>decl-specifier-seq</I>
or <I>type-specifier-seq</I> in the declared return type of a function
declarator that declares a function <INS>other than a conversion
function (11.4.8.3 [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>])</INS>; the return type of the
function is deduced from non-discarded return statements, if any, in
the body of the function (8.5.2 [<A href="https://wg21.link/stmt.if">stmt.if</A>]).

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2412"></A><H4>2412.
  
SFINAE vs undeduced placeholder type
</H4>
<B>Section: </B>9.2.9.7&#160; [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

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


<P>The status of the following example is not clear:</P>

<PRE>
  template &lt;typename T&gt; auto foo(T);  //<SPAN CLASS="cmnt"> Not defined</SPAN>

  template &lt;typename T&gt; struct FooCallable {
    template&lt;class U&gt;
    static constexpr bool check_foo_callable(...) { return false; }

    template&lt;class U, class = decltype(foo(U{})) &gt;
    static constexpr bool check_foo_callable(int) { return true; }

    static constexpr bool value = check_foo_callable&lt;T&gt;(0);
  };
  static_assert(FooCallable&lt;int&gt;::value == false, "");
</PRE>

<P>The <TT>static_assert</TT> causes the evaluation of the default
template argument <TT>decltype(foo&lt;int&gt;(int{}))</TT>. However,
<TT>foo</TT> is not defined, leaving it with an undeduced
placeholder return type. This situation could conceivably be
handled in two different ways. According to
9.2.9.7 [<A href="https://wg21.link/dcl.spec.auto#9">dcl.spec.auto</A>] paragraph 9,</P>

<BLOCKQUOTE>

If the name of an entity with an undeduced placeholder type appears in an
expression, the program is ill-formed.

</BLOCKQUOTE>

<P>This would thus appear to be an invalid expression
resulting from substitution in the immediate context of the
declaration and thus a substitution failure.</P>

<P>The other alternative would be to treat the presence of an
undeduced placeholder type for a function template as satisfying
the requirements of 13.9.2 [<A href="https://wg21.link/temp.inst#4">temp.inst</A>] paragraph 4,</P>

<BLOCKQUOTE>

Unless a function template specialization has been explicitly instantiated
or explicitly specialized, the function template specialization is
implicitly instantiated when the specialization is referenced in a context
that requires a function definition to exist or if the existence of the
definition affects the semantics of the program.

</BLOCKQUOTE>

<P>and attempt to instantiate <TT>foo&lt;int&gt;</TT>. That
instantiation fails because the definition is not provided,
which would then be an error outside the immediate context
of the declaration and thus a hard error instead of
substitution failure.</P>

<P><B>CWG 2022-11-10</B></P>

<P>There is no implementation divergence on the handling of this
example.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 9.2.9.7.1 [<A href="https://wg21.link/dcl.spec.auto.general#11">dcl.spec.auto.general</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

If a variable or function with an undeduced placeholder type is named
by an expression (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]), the program is
ill-formed. Once a non-discarded return statement has been seen in a
function, however, the return type deduced from that statement can be
used in the rest of the function, including in other return
statements.
[ Example:
  ...
<PRE class="ins">
  template &lt;typename T&gt; auto f(T);     //<SPAN CLASS="cmnt"> not defined</SPAN>

  template &lt;typename T&gt; struct F {
    template&lt;class U&gt;
    static constexpr bool g(...) { return false; }

    template&lt;class U, class = decltype(f(U{})) &gt;
    static constexpr bool g(int) { return true; }

    static constexpr bool value = g&lt;T&gt;(0);
  };
  static_assert(F&lt;int&gt;::value == false, "");
</PRE>
-- end example ]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2228"></A><H4>2228.
  
Ambiguity resolution for cast to function type
</H4>
<B>Section: </B>9.3.3&#160; [<A href="https://wg21.link/dcl.ambig.res">dcl.ambig.res</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2016-02-02
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Consider:</P>

<PRE>
  int x = (int()) + 5; 
</PRE>

<P>This is ill-formed, because 9.3.3 [<A href="https://wg21.link/dcl.ambig.res#2">dcl.ambig.res</A>] paragraph 2 specifies:</P>

<BLOCKQUOTE>

An ambiguity can arise from the similarity between a function-style
cast and a <I>type-id</I>. The resolution is that any construct that
could possibly be a <I>type-id</I> in its syntactic context shall be
considered a <I>type-id</I>.

</BLOCKQUOTE>

<P>and thus <TT>int()</TT> is interpreted as a <I>type-id</I> instead
of as a function-style cast, so this is an ill-formed cast to a
function type.</P>

<P>This seems to be the wrong disambiguation for all cases where there
is a choice between a C-style cast and a parenthesized expression: in
all those cases, the C-style cast interpretation results in a cast to
a function type, which is always ill-formed.</P>

<P>Further, there is implementation divergence in the handling of this example:</P>

<PRE>
  struct T { int operator++(int); T operator[](int); };
  int a = (T()[3])++; //<SPAN CLASS="cmnt"> not a cast</SPAN>
</PRE>



<P><B>EWG 2022-11-11</B></P>

<P>This is tracked in github issue
<A HREF="https://github.com/cplusplus/papers/issues/1376">cplusplus/papers#1376</A>.</P>

<P><B>Additional notes (May, 2025)</B></P>



<P>Also consider this example:</P>

<PRE>
  (S())[]-&gt;A&lt;int&gt;;              //<SPAN CLASS="cmnt"> OK, constructor call</SPAN>
  (S())[]-&gt;A&lt;int&gt; {return {};}; //<SPAN CLASS="cmnt"> error: C-style cast of lambda</SPAN>
</PRE>

<P>Without the suggested simple rule that <TT>(T())</TT> is never a
conversion to a function type (which is always semantically
ill-formed), syntactic disambiguation would require analysis whether
the thing after the arrow is a type (i.e. a trailing return type) or
an expression (for <TT>operator-&gt;</TT>).</P>

<P><U>Suggested resolution (2019-01-02):</U></P>

<OL>
<LI>
<P>Change in 7.6.2 [<A href="https://wg21.link/expr.unary#1">expr.unary</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>
<PRE>
<I>unary-expression :
  postfix-expression
  unary-operator cast-expression
  ++ cast-expression
  -- cast-expression
  await-expression
  sizeof unary-expression
  sizeof ( <INS>nofun-</INS>type-id )
  sizeof ... ( identifier )
  alignof ( <INS>nofun-</INS>type-id )
  noexcept-expression
  new-expression
  delete-expression</I>
</PRE>
</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.2.5 [<A href="https://wg21.link/expr.sizeof#1">expr.sizeof</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The operand is either an expression, which is an unevaluated operand
(7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>]), or a
parenthesized <I><INS>nofun-</INS>type-id</I>.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.2.6 [<A href="https://wg21.link/expr.alignof#1">expr.alignof</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The operand shall be a <I><INS>nofun-</INS>type-id</I> representing a
complete object type, or an array thereof, or a reference to one of
those types.

</BLOCKQUOTE>
</LI>

<LI>
<P>Replace <I>type-id</I> with <I>nofun-type-id</I> throughout
7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>], for example in paragraph 1:</P>

<BLOCKQUOTE>
<PRE>
  <I>new-expression :
    ::<SUB>opt</SUB> new new-placement<SUB>opt</SUB> new-type-id new-initializer<SUB>opt</SUB>
    ::<SUB>opt</SUB> new new-placement<SUB>opt</SUB> ( <INS>nofun-</INS>type-id ) new-initializer<SUB>opt</SUB></I>
</PRE>
</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.3 [<A href="https://wg21.link/expr.cast#2">expr.cast</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>
<PRE>
  <I>cast-expression :
    unary-expression
    ( <INS>nofun-</INS>type-id ) cast-expression</I>
</PRE>
</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.2.9.7.1 [<A href="https://wg21.link/dcl.spec.auto.general#6">dcl.spec.auto.general</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

A placeholder type can also be used in the <I>type-specifier-seq</I>
of the <I>new-type-id</I> or in the <I><INS>nofun-</INS>type-id</I> of
a <I>new-expression</I> (7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]). In such a
<I><INS>nofun-</INS>type-id</I>, the placeholder type shall appear as
one of the <I>type-specifier</I>s in the <I>type-specifier-seq</I> or
as one of the <I>type-specifier</I>s in a <I>trailing-return-type</I>
that specifies the type that replaces such a <I>type-specifier</I> .

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.2.9.7.2 [<A href="https://wg21.link/dcl.type.auto.deduct#2">dcl.type.auto.deduct</A>] paragraph 2 as follows:</P>


<BLOCKQUOTE>

A placeholder for a deduced class type can also be used in
the <I>type-specifier-seq</I> in the
<I>new-type-id</I> or <INS>nofun-</INS><I>type-id</I> of
a <I>new-expression</I> (7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]), as
the <I>simple-type-specifier</I> in an explicit type conversion
(functional notation) (7.6.1.4 [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>]), or as
the <I>type-specifier</I> in the <I>parameter-declaration</I> of
a <I>template-parameter</I> (13.2 [<A href="https://wg21.link/temp.param">temp.param</A>]). A placeholder
for a deduced class type shall not appear in any other context.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.3.1 [<A href="https://wg21.link/dcl.decl.general#6">dcl.decl.general</A>] paragraph 6 as follows, to
fix <TT> auto (*p)() -&gt; int(X());</TT> (now a function pointer
initialized by <TT>X()</TT>):</P>

<BLOCKQUOTE>
<PRE>
  <I>trailing-return-type :
    -&gt; <INS>nofun-</INS>type-id</I>
</PRE>
</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.3.2 [<A href="https://wg21.link/dcl.name#1">dcl.name</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>
<PRE class="ins">
  <I>nofun-type-id:
    type-specifier-seq nofun-declarator<SUB>opt</SUB>

  nofun-declarator:
    ptr-nofun-declarator
    noptr-nofun-declarator parameters-and-qualifiers trailing-return-type

  ptr-nofun-declarator:
    noptr-nofun-declarator
    ptr-operator ptr-nofun-declarator<SUB>opt</SUB>

  noptr-nofun-declarator:
    noptr-nofun-declarator parameters-and-qualifiers
    noptr-nofun-declarator<SUB>opt</SUB> [ constant-expression<SUB>opt</SUB> ] attribute-specifier-seq<SUB>opt</SUB>
    ( ptr-nofun-declarator )</I>
</PRE>

<P>It is possible to identify uniquely the location in
the <I>abstract-declarator</I> <INS>or <I>nofun-declarator</I></INS>
where the identifier would appear if the construction were a
declarator in a declaration. The named type is then the same as the
type of the hypothetical identifier.</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.3.3 [<A href="https://wg21.link/dcl.ambig.res#2">dcl.ambig.res</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

An ambiguity can arise from the similarity between
a function-style cast and a <I>type-id</I>. The resolution is
that any construct that could possibly be a <I>type-id</I> in its
syntactic context shall be considered a <I>type-id</I>.

<INS>[ Note: No such ambiguity can arise between an expression and
a <I>nofun-type-id</I>. -- end note ]</INS>

However, a construct that can syntactically be a <I>type-id</I> whose
outermost <I>abstract-declarator</I> would match the grammar of
an <I>abstract-declarator</I> with a <I>trailing-return-type</I> is
considered a <I>type-id</I> only if it starts with auto.


[Example 2 :
<PRE>
  template &lt;class T&gt; struct X {};
  template &lt;int N&gt; struct Y {};
  X&lt;int()&gt; a;   //<SPAN CLASS="cmnt"> type-id</SPAN>
  X&lt;int(1)&gt; b;  //<SPAN CLASS="cmnt"> expression (ill-formed)</SPAN>
  Y&lt;int()&gt; c;   //<SPAN CLASS="cmnt"> type-id (ill-formed)</SPAN>
  Y&lt;int(1)&gt; d;  //<SPAN CLASS="cmnt"> expression</SPAN>
  void foo(signed char a) {
    sizeof(int());    //<SPAN CLASS="cmnt"> <DEL>type-id (ill-formed)</DEL> <INS>expression</INS></SPAN>
    sizeof(int(a));   //<SPAN CLASS="cmnt"> expression</SPAN>
    sizeof(int(unsigned(a)));    //<SPAN CLASS="cmnt"> <DEL>type-id (ill-formed)</DEL> <INS>expression</INS></SPAN>
    (int())+1;              //<SPAN CLASS="cmnt"> <DEL>type-id (ill-formed)</DEL> <INS>expression</INS></SPAN>
    (int(a))+1;             //<SPAN CLASS="cmnt"> expression</SPAN>
    (int(unsigned(a)))+1;   //<SPAN CLASS="cmnt"> <DEL>type-id (ill-formed)</DEL> <INS>expression</INS></SPAN>
  }
  typedef struct BB { int C[2]; } *B, C;
  void g() {
  sizeof(B()-&gt;C[1]);     //<SPAN CLASS="cmnt"> OK, sizeof(expression)</SPAN>
  sizeof(auto()-&gt;C[1]);  //<SPAN CLASS="cmnt"> error: sizeof of a function returning an array</SPAN>
}
</PRE>
-- end example ]
</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.13.1 [<A href="https://wg21.link/dcl.attr.grammar#1">dcl.attr.grammar</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>
<PRE>
<I>alignment-specifier :
  alignas ( <INS>nofun-</INS>type-id ...<SUB>opt</SUB> )
  alignas ( constant-expression ...<SUB>opt</SUB> )</I>
</PRE>
</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 9.13.2 [<A href="https://wg21.link/dcl.align#3">dcl.align</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

An <I>alignment-specifier</I> of the
form <TT>alignas( <I><INS>nofun-</INS>type-id</I> )</TT> has the same
effect as <TT>alignas(alignof( <I><INS>nofun-</INS>type-id</I> ))</TT>
(7.6.2.6 [<A href="https://wg21.link/expr.alignof">expr.alignof</A>]).

</BLOCKQUOTE>
</LI>

<LI>
<P>Do not change 13.8.1 [<A href="https://wg21.link/temp.res.general#4">temp.res.general</A>] paragraph 4.</P>
</LI>

<LI>
<P>Change in 13.8.3.3 [<A href="https://wg21.link/temp.dep.expr#3">temp.dep.expr</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

Expressions of the following forms are type-dependent only if the type
specified by the <I>type-id</I>, <INS><I>nofun-type-id</I>,</INS>
<I>simple-type-specifier</I>, <I>typename-specifier</I>,
or <I>new-type-id</I> is dependent, even if any subexpression is
type-dependent:
<PRE>
  <I>simple-type-specifier ( expression-list<SUB>opt</SUB> )
  simple-type-specifier braced-init-list
  typename-specifier ( expression-list<SUB>opt</SUB> )
  typename-specifier braced-init-list
  ::opt new new-placement<SUB>opt</SUB> new-type-id new-initializeropt
  ::opt new new-placement<SUB>opt</SUB> ( <INS>nofun-</INS>type-id ) new-initializer<SUB>opt</SUB>
  dynamic_cast &lt; type-id &gt; ( expression )
  static_cast &lt; type-id &gt; ( expression )
  const_cast &lt; type-id &gt; ( expression )
  reinterpret_cast &lt; type-id &gt; ( expression )
  ( <INS>nofun-</INS>type-id ) cast-expression</I>
</PRE>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.8.3.3 [<A href="https://wg21.link/temp.dep.expr#4">temp.dep.expr</A>] paragraph 4 as follows:</P>
<BLOCKQUOTE>
<PRE>
  <I>literal
  sizeof unary-expression
  sizeof ( <INS>nofun-</INS>type-id )
  sizeof ... ( identifier )
  alignof ( <INS>nofun-</INS>type-id )
  typeid ( expression )
  typeid ( type-id )
  ::opt delete cast-expression
  ::opt delete [ ] cast-expression
  throw assignment-expressionopt
  noexcept ( expression )
  requires-expression</I>
</PRE>
</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.8.3.4 [<A href="https://wg21.link/temp.dep.constexpr#2">temp.dep.constexpr</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

Expressions of the following form are value-dependent if
the <I>unary-expression</I> or expression is type-dependent or
the <I>type-id</I> <INS>or <I>nofun-type-id</I></INS> is dependent:
<PRE>
  <I>sizeof unary-expression
  sizeof ( <INS>nofun-</INS>type-id )
  typeid ( expression )
  typeid ( type-id )
  alignof ( <INS>nofun-</INS>type-id )</I>
</PRE>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.8.3.4 [<A href="https://wg21.link/temp.dep.constexpr#3">temp.dep.constexpr</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

Expressions of the following form are value-dependent if either
the <I>type-id</I>, <INS><I>nofun-type-id</I>,</INS>
<I>simple-type-specifier</I>, or <I>typename-specifier</I> is
dependent or the <I>expression</I> or <I>cast-expression</I> is
value-dependent or any expression in the <I>expression-list</I> is
value-dependent or any <I>assignment-expression</I> in
the <I>braced-init-list</I> is value-dependent:

<PRE>
  <I>simple-type-specifier ( expression-list<SUB>opt</SUB> )
  typename-specifier ( expression-list<SUB>opt</SUB> )
  simple-type-specifier braced-init-list
  typename-specifier braced-init-list
  static_cast &lt; type-id &gt; ( expression )
  const_cast &lt; type-id &gt; ( expression )
  reinterpret_cast &lt; type-id &gt; ( expression )
  dynamic_cast &lt; type-id &gt; ( expression )
  ( <INS>nofun-</INS>type-id ) cast-expression</I>
</PRE>

</BLOCKQUOTE>
</LI>
</OL>

<P><B>EWG 2025-06-16</B></P>

<P>EWG agrees with the direction represented by the wording for the
May, 2025 notes, above.</P>

<BR><BR><HR>
<A NAME="1001"></A><H4>1001.
  
Parameter type adjustment in dependent parameter types
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2009-11-08<BR>




<P>According to 9.3.4.6 [<A href="https://wg21.link/dcl.fct#5">dcl.fct</A>] paragraph 5,
top-level cv-qualifiers on parameter types are deleted when
determining the function type.  It is not clear how or whether
this adjustment should be applied to parameters of function
templates when the parameter has a dependent type, however.  For
example:</P>

<PRE>
    template&lt;class T&gt; struct A {
       typedef T arr[3];
    };

    template&lt;class T&gt; void f(const typename A&lt;T&gt;::arr) { } // #1

    template void f&lt;int&gt;(const A&lt;int&gt;::arr);

    template &lt;class T&gt; struct B {
       void g(T);
    };

    template &lt;class T&gt; void B&lt;T&gt;::g(const T) { } // #2
</PRE>

<P>If the <TT>const</TT> in #1 is dropped, <TT>f&lt;int&gt;</TT> has
a parameter type of <TT>A*</TT> rather than the <TT>const A*</TT>
specified in the explicit instantiation.  If the <TT>const</TT> in
#2 is <I>not</I> dropped, we fail to match the definition of
<TT>B::g</TT> to its declaration.
</P>

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

<P>The CWG agreed that this behavior is intrinsic to the different
ways cv-qualification applies to array types and non-array types.
</P>

<P><B>Notes, January, 2012:</B></P>

<P>Additional discussion of this issue arose regarding the following
example:</P>

<PRE>
    template&lt;class T&gt; struct A {
      typedef double Point[2];
      virtual double calculate(const Point point) const = 0;
    };

    template&lt;class T&gt; struct B : public A&lt;T&gt; {
      virtual double calculate(const typename A&lt;T&gt;::Point point) const {
        return point[0];
      }
    };

    int main() {
      B&lt;int&gt; b;
      return 0;
    }
</PRE>

<P>The question is whether the member function in
<TT>B&lt;int&gt;</TT> has the same type as that in
<TT>A&lt;int&gt;</TT>: is the parameter-type-list instantiated
directly (i.e., using the adjusted types) or regenerated from the
individual parameter types? </P>

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

<P><B>Additional notes (February, 2024)</B></P>

<P>There is implementation divergence for the following example (clang
and EDG accept, gcc and MSVC reject):</P>

<PRE>
  template&lt;typename U&gt;
  int f(const U t);

  int v;
  auto test = f(v);

  template&lt;typename U&gt;
  int f(U t) {
   static_assert(std::is_const&lt;decltype(t)&gt;::value, "t should be non-const");
   return 0;
  }
</PRE>

<P><U>Possible resolution (option 1):</U></P>

<P>Change in 9.3.4.6 [<A href="https://wg21.link/dcl.fct#4">dcl.fct</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

The type of a function is determined using the following rules. The
type of each parameter (including function parameter packs) is
determined from its own <I>parameter-declaration</I>
(9.3 [<A href="https://wg21.link/dcl.decl">dcl.decl</A>]). After determining the type of each
parameter, any parameter of type &#8220;array of T&#8221; or of
function type T is adjusted to be &#8220;pointer to T&#8221;. After
producing the list of parameter types, any top-level
<I>cv-qualifier</I>s modifying a <INS>non-dependent</INS> parameter
type are deleted when forming the function type. The resulting list of
transformed parameter types and the presence or absence of the
ellipsis or a function parameter pack is the
function's <I>parameter-type-list</I>.
...

</BLOCKQUOTE>

<P><B>Additional notes (December, 2024)</B></P>

<P>The resolution suggested above causes errors in ostensibly more
common situations such as this one, requiring an Annex C entry:</P>

<PRE>
  template &lt;class T&gt;
  void f(T*);                 //<SPAN CLASS="cmnt"> #1</SPAN>

  template &lt;class T&gt;
  void f(T* const) {}         //<SPAN CLASS="cmnt"> redeclaration of #2?</SPAN>

  int main() {
    f((int*)0);               //<SPAN CLASS="cmnt"> was ok, becomes ambiguous</SPAN>
  }
</PRE>



<P><U>Possible resolution (option 2):</U></P>

<OL>
<LI>
<P>Change in 9.3.4.6 [<A href="https://wg21.link/dcl.fct#4">dcl.fct</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

The type of a function is determined using the following rules. The
type of each parameter (including function parameter packs) is
determined from its own <I>parameter-declaration</I>
(9.3 [<A href="https://wg21.link/dcl.decl">dcl.decl</A>]). After determining the type of each
parameter, any parameter of type &#8220;array of T&#8221; or of
function type T is adjusted to be &#8220;pointer to T&#8221;.
<INS>
If a function parameter type is adjusted from "array of <TT>T</TT>" and
acquires the array type through a dependent type, and any top-level
cv-qualifier modifies the dependent parameter type in any declaration
of the templated function, the program is ill-formed; no diagnostic is
required unless a cv-qualifier modifies the parameter type in a
reachable definition of the function.
</INS>
After producing the list of parameter types, any top-level
<I>cv-qualifier</I>s modifying a parameter type are deleted when
forming the function type. The resulting list of transformed parameter
types and the presence or absence of the ellipsis or a function
parameter pack is the function's <I>parameter-type-list</I>.  ...

<P>[ Example:</P>
...
<PRE>
  void h(int x(const int));   //<SPAN CLASS="cmnt"> #3</SPAN>
  void h(int (*)(int)) {}     //<SPAN CLASS="cmnt"> defines #3</SPAN>

<INS>  template&lt;class T&gt;
  int i(T);                   //<SPAN CLASS="cmnt"> #4</SPAN>
  template&lt;class T&gt;
  int i(const T) {}           //<SPAN CLASS="cmnt"> defines #4</SPAN>
  int v = i&lt;int[]&gt;(0);        //<SPAN CLASS="cmnt"> error: cv-qualified array parameter type in definition of template</SPAN></INS>
</PRE>
<P>-- end example]</P>
</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.2 [<A href="https://wg21.link/temp.param#6">temp.param</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

A non-type <I>template-parameter</I> shall have one of the following
(possibly cv-qualified) types:
<UL>
<LI>a structural type (see below),</LI>
<LI>a type that contains a placeholder type
(9.2.9.7 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]), or</LI>
<LI>a placeholder for a deduced class type
(9.2.9.8 [<A href="https://wg21.link/dcl.type.class.deduct">dcl.type.class.deduct</A>]).</LI>
</UL>
<DEL>The top-level <I>cv-qualifier</I>s on
the <I>template-parameter</I> are ignored when determining its
type.</DEL>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 13.2 [<A href="https://wg21.link/temp.param#10">temp.param</A>] paragraph 10 as follows:</P>

<BLOCKQUOTE>

A non-type <I>template-parameter</I> of type &#8220;array of T&#8221;
or of function type T is adjusted to be of type &#8220;pointer to
T&#8221;.  <INS>If the type of a non-type <I>template-parameter</I> is
adjusted from "array of T" and acquires the array type through a
dependent type, and any top-level cv-qualifier modifies the dependent
type in any declaration of the template, the program is ill-formed; no
diagnostic is required unless a cv-qualifier modifies the type of
the <I>template-parameter</I> in a reachable definition of the
template.</INS>

[ Example:

<PRE>
  template&lt;int* a&gt;
  struct R { /* ... */ };
  template&lt;int b[5]&gt; struct S { /* ... */ };
  int p;
  R&lt;&amp;p&gt; w;      //<SPAN CLASS="cmnt"> OK</SPAN>
  S&lt;&amp;p&gt; x;      //<SPAN CLASS="cmnt"> OK due to parameter adjustment</SPAN>
  int v[5];
  R&lt;v&gt; y;       //<SPAN CLASS="cmnt"> OK due to implicit argument conversion</SPAN>
  S&lt;v&gt; z;       //<SPAN CLASS="cmnt"> OK due to both adjustment and conversion</SPAN>

<INS>  template&lt;class T, const T x&gt;
  struct U { /* ... */ };
  U&lt;int[], nullptr&gt; u;   //<SPAN CLASS="cmnt"> error: const array adjustment</SPAN></INS>
</PRE>
-- end example ]

<P class="ins">The top-level cv-qualifiers on the (possibly adjusted)
type of a template parameter are ignored.</P>
</BLOCKQUOTE>

</LI>
</OL>

<P><B>Additional notes (January, 2025)</B></P>

<P>
<A HREF="cwg_defects.html#1321">Issue 1321</A> resolved to requiring
substitution into the first (or, nowadays, a first) declaration
(13.8.1 [<A href="https://wg21.link/temp.res.general#1">temp.res.general</A>] paragraph 1), which conflicts with
special-casing the defining declaration here.</P>

<BR><BR><HR>
<A NAME="2553"></A><H4>2553.
  
Restrictions on explicit object member functions
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2021-12-10<BR>




<P>Subclause 9.3.4.6 [<A href="https://wg21.link/dcl.fct#6">dcl.fct</A>] paragraph 6 specifies</P>

<BLOCKQUOTE>

A <I>member-declarator</I> with
an <I>explicit-object-parameter-declaration</I> shall not include
a <I>ref-qualifier</I> or a <I>cv-qualifier-seq</I> and shall not be
declared <TT>static</TT> or <TT>virtual</TT>.

</BLOCKQUOTE>

<P>This does not address the situation when an explicit object member
function becomes implicitly virtual by overriding an implicit object
member function.  That should be prevented.</P>

<P>This also does not address class-specific allocation and
deallocation functions, which are implicitly <TT>static</TT>.</P>

<P><B>Proposed resolution (approved by CWG 2023-06-15) [SUPERSEDED]:</B></P>

<OL>
<LI>
<P>Change in 9.3.4.6 [<A href="https://wg21.link/dcl.fct#6">dcl.fct</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

A <I>member-declarator</I> with
an <I>explicit-object-parameter-declaration</I> shall not include
a <I>ref-qualifier</I> or a <I>cv-qualifier-seq</I> and shall not be
declared <TT>static</TT> <DEL>or <TT>virtual</TT></DEL>.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 9.3.4.6 [<A href="https://wg21.link/dcl.fct#7">dcl.fct</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

... An <I>implicit object member function</I> is a non-static member
function without an explicit object parameter.
<INS>[ <I>Note:</I> An explicit object member function cannot be
virtual (11.7.3 [<A href="https://wg21.link/class.virtual">class.virtual</A>]). -- <I>end note</I> ]</INS>

</BLOCKQUOTE>

</LI>

<LI>
<P>Add a new paragraph before 11.7.3 [<A href="https://wg21.link/class.virtual#7">class.virtual</A>] paragraph 7 as
follows:</P>

<BLOCKQUOTE>

<P><INS>A virtual function shall not be an explicit object member
function (9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]).</INS></P>

<P><INS>[ <I>Example:</I></INS></P>
<PRE class="ins">
  struct B {
    virtual void g(); // #1
  };
  struct D : B {
    virtual void f(this D&amp;);  //<SPAN CLASS="cmnt"> error: explicit object member function cannot be virtual</SPAN>
    void g(this D&amp;);          //<SPAN CLASS="cmnt"> error: overrides #1; explicit object member function cannot be virtual</SPAN>
  };
</PRE>
<P><INS>-- <I>end example</I>]</INS></P>

<P>The <I>ref-qualifier</I>, or lack thereof, ...</P>

</BLOCKQUOTE>

</LI>

</OL>

<P><B>Proposed resolution (approved by CWG 2023-07-14):</B></P>

<OL>
<LI>
<P>Change in 9.3.4.6 [<A href="https://wg21.link/dcl.fct#6">dcl.fct</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

A <I>member-declarator</I> with
an <I>explicit-object-parameter-declaration</I> shall not include
a <I>ref-qualifier</I> or a <I>cv-qualifier-seq</I> and shall not be
declared <TT>static</TT> <DEL>or <TT>virtual</TT></DEL>.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 9.3.4.6 [<A href="https://wg21.link/dcl.fct#7">dcl.fct</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

... An <I>implicit object member function</I> is a non-static member
function without an explicit object parameter.
<INS>[ <I>Note:</I> An explicit object member function cannot be
virtual (11.7.3 [<A href="https://wg21.link/class.virtual">class.virtual</A>]). -- <I>end note</I> ]</INS>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 11.4.11 [<A href="https://wg21.link/class.free#1">class.free</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Any allocation function for a class T is a static member (even if not
explicitly declared static)<INS>; it shall not have an explicit object
parameter</INS>.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 11.4.11 [<A href="https://wg21.link/class.free#3">class.free</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

Any deallocation function for a class T is a static member (even if not
explicitly declared static)<INS>; it shall not have an explicit object
parameter</INS>.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 11.4.11 [<A href="https://wg21.link/class.free#4">class.free</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<INS>[ Note:</INS> Since member allocation and deallocation functions
are static they cannot be virtual. <INS>-- end note ]</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Add a new paragraph before 11.7.3 [<A href="https://wg21.link/class.virtual#7">class.virtual</A>] paragraph 7 as
follows:</P>

<BLOCKQUOTE>

<P><INS>A virtual function shall not be an explicit object member
function (9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]).</INS></P>

<P><INS>[ <I>Example:</I></INS></P>
<PRE class="ins">
  struct B {
    virtual void g(); // #1
  };
  struct D : B {
    virtual void f(this D&amp;);  //<SPAN CLASS="cmnt"> error: explicit object member function cannot be virtual</SPAN>
    void g(this D&amp;);          //<SPAN CLASS="cmnt"> error: overrides #1; explicit object member function cannot be virtual</SPAN>
  };
</PRE>
<P><INS>-- <I>end example</I>]</INS></P>

<P>The <I>ref-qualifier</I>, or lack thereof, ...</P>

</BLOCKQUOTE>

</LI>

</OL>

<P><B>CWG 2023-11-09</B></P>

<P>Progress of this issue is blocked on <A HREF="cwg_active.html#2554">issue 2554</A>.</P>

<BR><BR><HR>
<A NAME="2977"></A><H4>2977.
  
Initialization with string literals
</H4>
<B>Section: </B>9.5.1&#160; [<A href="https://wg21.link/dcl.init.general">dcl.init.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2024-12-27<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/661">#661</A>.)
</P>

<P>Subclause 9.5.1 [<A href="https://wg21.link/dcl.init.general#16.3">dcl.init.general</A>] bullet 16.3 specifies:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>If the destination type is an array of characters, an array of
char8_t, an array of char16_t, an array of char32_t, or an array of
wchar_t, and the initializer is a <I>string-literal</I>, see
9.5.3 [<A href="https://wg21.link/dcl.init.string">dcl.init.string</A>].</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>However, the <I>initializer</I> will be of the
form <TT>= <I>string-literal</I></TT> or
<TT>(<I>string-literal</I>)</TT>, neither of which is
a <I>string-literal</I>, obviously.</P>

<P>On a slightly related note, implementations other than gcc in
strict modes support parenthesized string literals, e.g.</P>
<PRE>
  const char s1[] = ("foo");
  const char s2[] = {("foo")};
</PRE>

<P>The latter is clearly not covered by 9.5.5 [<A href="https://wg21.link/dcl.init.list#3.3">dcl.init.list</A>] bullet 3.3:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>Otherwise, if T is a character array and the initializer list has
a single element that is an appropriately-typed <I>string-literal</I>
(9.5.3 [<A href="https://wg21.link/dcl.init.string">dcl.init.string</A>]), initialization is performed as described
in that subclause.</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P><U>Possible resolution [SUPERSEDED]:</U></P>

<P>Change in 9.5.1 [<A href="https://wg21.link/dcl.init.general#16.3">dcl.init.general</A>] bullet 16.3 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>If the destination type is an array of characters, an array of
char8_t, an array of char16_t, an array of char32_t, or an array of
wchar_t, and the <DEL>initializer</DEL> <INS><I>initializer</I></INS>
is <DEL>a <I>string-literal</I></DEL> <INS>of the
form <TT>= <I>string-literal</I></TT> or of the
form <TT>( <I>string-literal</I> )</TT></INS>, see
9.5.3 [<A href="https://wg21.link/dcl.init.string">dcl.init.string</A>].</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P><B>Additional notes (January 2025)</B></P>



<P>The resolution above does not allow this example:</P>
<PRE>
  S s = {"abc"};
</PRE>
<P>This recurses back from 9.5.2 [<A href="https://wg21.link/dcl.init.aggr#4.3">dcl.init.aggr</A>] bullet 4.3 to
9.5.1 [<A href="https://wg21.link/dcl.init.general">dcl.init.general</A>].</P>

<P><U>Possible resolution:</U></P>

<P>Change in 9.5.1 [<A href="https://wg21.link/dcl.init.general#16.3">dcl.init.general</A>] bullet 16.3 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>If the destination type is an array of characters, an array of
char8_t, an array of char16_t, an array of char32_t, or an array of
wchar_t, and the <DEL>initializer</DEL> <INS>initialization</INS>
is <INS>from</INS> <DEL>a</DEL> <INS>an
unparenthesized</INS> <I>string-literal</I>, see
9.5.3 [<A href="https://wg21.link/dcl.init.string">dcl.init.string</A>].</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2563"></A><H4>2563.
  
Initialization of coroutine result object
</H4>
<B>Section: </B>9.6.4&#160; [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Tomasz Kami&#324;ski
 &#160;&#160;&#160;

 <B>Date: </B>2022-04-06
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Subclause 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#7">dcl.fct.def.coroutine</A>] paragraph 7 specifies:</P>

<BLOCKQUOTE>

The expression <TT><I>promise</I>.get_return_object()</TT> is used to
initialize the returned reference or prvalue result object of a call
to a coroutine. The call to <TT>get_return_object</TT> is sequenced
before the call to <I>initial-suspend</I> and is invoked at most once.

</BLOCKQUOTE>

<P>It is unclear:</P>
<UL>
<LI>whether <TT>get_return_object()</TT> is invoked inside or outside
of the <I>try-block</I> shown in paragraph 5 (see
<A HREF="cwg_active.html#2562">issue 2562</A>),
</LI>

<LI>whether the prvalue result object may be initialized later
(e.g. before the first actual suspension), and
</LI>

<LI>if the initialization does occur later, by what mechanism the prvalue
result of <TT>get_return_object</TT> is forwarded to that
initialization.
</LI>

</UL>

<P>There is implementation divergence.</P>

<P>Note that a user-defined conversion may be involved in the
initialization of the coroutine's prvalue result object
from <TT>get_return_object()</TT>.  Note also that the return type
of <TT>get_return_object</TT> might be non-copyable and
non-movable. However, there are certain programming patterns that
would benefit from a late-initialized return value.</P>

<P>See also <A HREF="https://godbolt.org/z/fqxb67nnx">compiler explorer</A>.</P>

<P><U>Suggested resolution [SUPERSEDED]:</U></P>

<P>Change in 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#7">dcl.fct.def.coroutine</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

<DEL>The expression <TT><I>promise</I>.get_return_object()</TT> is
used to initialize the</DEL> <INS>The</INS> returned reference or
prvalue result object of a call to a coroutine <INS>is
copy-initialized with
<TT><I>promise</I>.get_return_object()</TT></INS>.  The <DEL>call
to <TT>get_return_object</TT></DEL> <INS>initialization</INS> is
sequenced before the call to <I>initial-suspend</I> <DEL>and is
invoked at most once</DEL>.

</BLOCKQUOTE>

<P><B>Additional notes (January, 2023)</B></P>

<P>See also
<A HREF="https://github.com/llvm/llvm-project/issues/56532">clang bug report #56532</A>.</P>

<P>Forwarded to EWG with
<A HREF="https://github.com/cplusplus/papers/issues/1414">paper issue 1414</A>,
by decision of the CWG chair.
</P>

<P><B>EWG 2023-02-06</B></P>

<P>EWG agrees that <TT>get_return_object</TT> is invoked outside of
the try-block and that, if a conversion is needed, the return value
of <TT>get_return_object</TT> is considered an xvalue that is later
converted to the result object.</P>

<P><B>Proposed resolution (May, 2025):</B></P>

<OL>
<LI>
<P>Change in 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#5">dcl.fct.def.coroutine</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

A coroutine behaves as if the top-level cv-qualifiers in
all <I>parameter-declaration</I>s in the declarator of
its <I>function-definition</I> were removed and
its <I>function-body</I> were replaced by the following replacement
body:

<PRE>
  {
    promise-type promise promise-constructor-arguments ;
<INS>    <I>get-return-object-invocation</I> ;</INS>
    try {
      co_await promise .initial_suspend() ;
      function-body
    } catch ( ... ) {
      if (!initial-await-resume-called )
        throw ;
      promise .unhandled_exception() ;
    }
  final-suspend :
    co_await promise .final_suspend() ;
  }
</PRE>

where

<UL>
<LI>...</LI>
<LI>
<I>promise-constructor-arguments</I> is determined as follows: ...</LI>
<LI class="ins">
<I>get-return-object-invocation</I> is as follows:
<UL>
<LI>if the return type <TT>R</TT>
of <TT><I>promise</I>.get_return_object()</TT>
is <I>cv</I> <TT>void</TT>, then <I>get-return-object-invocation</I>
is <TT><I>promise</I>.get_return_object()</TT>, and the return type of
the coroutine shall also be <I>cv</I> <TT>void</TT>;</LI>
<LI>otherwise, if <TT>R</TT> is the same
class type as the return type of the coroutine (ignoring
cv-qualification), and the implementation does not create a
temporary to hold the result object (6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>]),
then <I>get-return-object-invocation</I> initializes the
prvalue result object of the call to the coroutine from
<TT><I>promise</I>.get_return_object()</TT>;
</LI>
<LI>otherwise, <I>get-return-object-invocation</I> initializes a
variable with the exposition-only name <TT><I>gro</I></TT> as if by
<PRE>
  decltype(auto) <I>gro</I> = <I>promise</I>.get_return_object();
</PRE>
</LI>
</UL>
</LI>
<LI>a coroutine is suspended at the <I>initial suspend point</I> if
...</LI>
</UL>
</BLOCKQUOTE>
</LI>

<LI>
<P>Replace 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#8">dcl.fct.def.coroutine</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

<P class="del">The expression promise.get_return_object() is used to
initialize the returned reference or prvalue result object of a call
to a coroutine. The call to get_return_object is sequenced before the
call to initial-suspeend and is invoked at most once.</P>
<P class="ins">If <I>get-return-object-invocation</I> defines a
variable <TT><I>gro</I></TT> and the coroutine returns to its caller,
whether by suspending (7.6.2.4 [<A href="https://wg21.link/expr.await">expr.await</A>]) or completing
without ever suspending (8.8.5 [<A href="https://wg21.link/stmt.return.coroutine">stmt.return.coroutine</A>]), it is as if
by <TT>return <I>gro</I></TT>. This return exits the scope
of <TT><I>gro</I></TT>. It exits the scope of <TT><I>promise</I></TT>
only if the coroutine completed without suspending. [Note: The operand
of the return might be move-eligible
(7.5.5.2 [<A href="https://wg21.link/expr.prim.id.unqual">expr.prim.id.unqual</A>]). --end note]
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#11">dcl.fct.def.coroutine</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

... If the allocation function returns nullptr, the coroutine
transfers control to the caller of the coroutine <DEL>and the return
value is obtained by a call to</DEL>
<INS>as if by <TT>return</TT></INS>
<TT>T::get_return_object_on_allocation_failure();</TT>,
where <TT>T</TT> is the promise type. ...

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="2932"></A><H4>2932.
  
Value range of empty enumeration
</H4>
<B>Section: </B>9.8.1&#160; [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Benjamin Sch.
 &#160;&#160;&#160;

 <B>Date: </B>2024-08-31
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/604">#604</A>.)</P>

<P>Consider:</P>

<PRE>
  enum E { };
  constexpr auto x = static_cast&lt;E&gt;(-1);
</PRE>

<P>It is unclear whether the hypothetical integer type for <TT>E</TT>
is a signed integer type of width 1 or an unsigned integer type of
width 0, which does not have a signed counterpart and thus does not
exist.  The former choice makes the example well-formed, the latter
one ill-formed.  Before P1236, the specification was clear.</P>

<P><B>Proposed resolution:</B></P>

<P>Change in 9.8.1 [<A href="https://wg21.link/dcl.enum#8">dcl.enum</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

For an enumeration whose underlying type is fixed, the values of the
enumeration are the values of the underlying type. Otherwise, the
values of the enumeration are the values representable
by a hypothetical integer type with minimal width M such that all
enumerators can be represented<INS>; if <INS>if
the <I>enumerator-list</I> is empty or</INS> all enumerators have
value 0, the values of the enumeration consist of the single value 0
and <I>M</I> is 0</INS>. The width of the smallest bit-field large
enough to hold all the values of the enumeration type is <INS>the
maximum of 1 and</INS> M.
<INS>[ Note: </INS> It is possible to define an enumeration that has
values not defined by any of its enumerators. <INS>-- end note ]</INS>
<DEL>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.</DEL> [Footnote: ... ]

</BLOCKQUOTE>

<P><B>CWG 2024-10-25</B></P>

<P>A value needs at least one bit to be represented, which always
allows to differentiate two values.  Thus, having the "values of an
enumeration" be a single value makes no sense.</P>

<P>The wording in C++17 [dcl.enum] p8 said:</P>

<BLOCKQUOTE>

For an enumeration whose underlying type is fixed, the values of the
enumeration are the values of the underlying type. Otherwise, for an
enumeration where e<SUB>min</SUB> is the smallest enumerator and
e<SUB>max</SUB> is the largest, the values of the enumeration are the
values in the range b<SUB>min</SUB> to b<SUB>max</SUB>, defined as
follows: Let K be 1 for a two's complement representation and 0 for a
ones' complement or sign-magnitude representation. b<SUB>max</SUB> is
the smallest value greater than or equal to max(|e<SUB>min</SUB>| - K,
|e<SUB>max</SUB>|) and equal to 2<SUP>M</SUP> - 1, where M is a
non-negative integer. b<SUB>min</SUB> is zero if e<SUB>min</SUB> is
non-negative and -(b<SUB>max</SUB> + K) otherwise. The size of the
smallest bit-field large enough to hold all the values of the
enumeration type is max(M, 1) if b<SUB>min</SUB> is zero and M + 1
otherwise. It is possible to define an enumeration that has values not
defined by any of its enumerators. If the enumerator-list is empty,
the values of the enumeration are as if the enumeration had a single
enumerator with value 0.

</BLOCKQUOTE>

<P>If there is a single enumerator with value 0, e<SUB>min</SUB> = 0
and e<SUB>max</SUB> = 0. A two's complement representation is now
required, thus K=1.  b<SUB>max</SUB> is 0 with M = 0.  b<SUB>min</SUB>
is 0.
</P>

<P><B>CWG 2025-11-08</B></P>

<P>The wording in the proposed resolution restores the C++17
situation.  However, both clang and gcc agree that the values of an
empty enumeration or one with all enumerators having value 0 are
actually 0 and 1, reflecting the single bit of storage needed for the
representation.  CWG observed that empty classes also occupy one byte
of storage, even though they hold no values at all.</P>

<P>
EWG should decide whether to keep the C++17 rule or adjust the wording to reflect the implementation practice. Forwarded to EWG via
<A HREF="https://github.com/cplusplus/papers/issues/2138">paper issue 2138</A>.</P>

<BR><BR><HR>
<A NAME="2885"></A><H4>2885.
  
Non-eligible trivial default constructors
</H4>
<B>Section: </B>11.4.5.2&#160; [<A href="https://wg21.link/class.default.ctor">class.default.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Roy Jacobson
 &#160;&#160;&#160;

 <B>Date: </B>2022-11-26
  &#160;&#160;&#160;
  <B>Liaison: </B>LWG<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/521">#521</A>.)</P>

<P>Consider:</P>

<PRE>
  template &lt;class T&gt;
  struct A {
    A() requires (false) = default;
    A() : t(42) {}
    T t;
  };

  struct B : A&lt;int&gt; {};
</PRE>

<P>According to the current wording, class <TT>B</TT> has a trivial
default constructor, which is undesirable.</P>

<P><B>Proposed resolution (approved by CWG 2024-05-31):</B></P>

<P>Change in 11.4.5.2 [<A href="https://wg21.link/class.default.ctor#3">class.default.ctor</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

A default constructor <INS>for class <TT>X</TT></INS> is <I>trivial</I>
if it is not user-provided and if:
<UL>
<LI>
<DEL>its class</DEL> <INS><TT>X</TT></INS> has no virtual
functions (11.7.3 [<A href="https://wg21.link/class.virtual">class.virtual</A>]) and no virtual base classes
(11.7.2 [<A href="https://wg21.link/class.mi">class.mi</A>]), and</LI>
<LI>no non-static data member of <DEL>its
class</DEL> <INS><TT>X</TT></INS> has a default member initializer
(11.4 [<A href="https://wg21.link/class.mem">class.mem</A>]), and</LI>
<LI class="del">all the direct base classes of its class have trivial
default constructors, and</LI>
<LI class="ins">the constructor selected to default-initialize each
direct base class subobject of <TT>X</TT> is trivial,</LI>
<LI class="del">for all the non-static data members of its class that are of
class type (or array thereof), each such class has a trivial default
constructor.</LI>
<LI class="ins">for each direct non-static data member of <TT>X</TT>
that is of class type (or array thereof), the constructor selected to
default-initialize that member (or an array element of that member) is
trivial.</LI>

</UL>
Otherwise, the default constructor is <I>non-trivial</I>.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3022"></A><H4>3022.
  
Redundant specification of explicit destructor calls
</H4>
<B>Section: </B>11.4.7&#160; [<A href="https://wg21.link/class.dtor">class.dtor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Timur Doumler
 &#160;&#160;&#160;

 <B>Date: </B>2025-04-13<BR>




<P>Subclause 11.4.7 [<A href="https://wg21.link/class.dtor#16">class.dtor</A>] paragraph 16 explains explicit
destructor calls, but that is redundant with
7.5.5.2 [<A href="https://wg21.link/expr.prim.id.unqual">expr.prim.id.unqual</A>], 7.5.5.5 [<A href="https://wg21.link/expr.prim.id.dtor">expr.prim.id.dtor</A>], and the
usual rules for function calls (7.6.1.3 [<A href="https://wg21.link/expr.call">expr.call</A>]).</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 7.5.5.2 [<A href="https://wg21.link/expr.prim.id.unqual#1">expr.prim.id.unqual</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

An identifier is only an <I>id-expression</I> if it has been suitably
declared (Clause Clause 9 [<A href="https://wg21.link/dcl">dcl</A>]) or if it appears as part of
a <I>declarator-id</I> (9.3 [<A href="https://wg21.link/dcl.decl">dcl.decl</A>]).  [<I>Note 1:</I>
For <I>operator-function-id</I>s, see 12.4 [<A href="https://wg21.link/over.oper">over.oper</A>];
for <I>conversion-function-id</I>s, see 11.4.8.3 [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>];
for <I>literal-operator-id</I>s, see 12.6 [<A href="https://wg21.link/over.literal">over.literal</A>];
for <I>template-id</I>s, see
13.3 [<A href="https://wg21.link/temp.names">temp.names</A>]. <INS>&#8212;<I>end note</I>]</INS>
A <I>type-name</I> or <I>computed-type-specifier</I> prefixed
by <TT>~</TT> denotes the destructor of the type so named; see
7.5.5.5 [<A href="https://wg21.link/expr.prim.id.dtor">expr.prim.id.dtor</A>]. <DEL>&#8212;<I>end note</I>]</DEL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.7 [<A href="https://wg21.link/class.dtor#16">class.dtor</A>] paragraph 16 as follows:</P>

<BLOCKQUOTE>

<INS>[ Note:</INS> In an explicit destructor call, the destructor is
specified by a ~ followed by a <I>type-name</I>
or <I>computed-type-specifier</I> that denotes the destructor's class
type <INS>(7.5.5.2 [<A href="https://wg21.link/expr.prim.id.unqual">expr.prim.id.unqual</A>])</INS>. <DEL>The invocation of a
destructor is subject to the usual rules for member functions
(11.4.2 [<A href="https://wg21.link/class.mfct">class.mfct</A>]); that is, if the object is
not of the destructor's class type and not of a class derived from the
destructor's class type (including when the destructor is invoked via
a null pointer value), the program has undefined behavior.
[<I>Note 7:</I></DEL> Invoking delete on a null pointer does not
call the destructor; see
7.6.2.9 [<A href="https://wg21.link/expr.delete">expr.delete</A>]. <DEL>&#8212;<I>end note</I>]</DEL>
[<I>Example:</I> ... -- end example]
<INS>&#8212;<I>end note</I>]</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.4.1 [<A href="https://wg21.link/temp.arg.general#6">temp.arg.general</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

<INS>[ Note:</INS> An explicit destructor call
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]) for an object that has a type that is a
class template specialization <DEL>may</DEL> <INS>can</INS> explicitly
specify the <I>template-argument</I>s. [ Example: ... -- end example
] <INS>-- end note]</INS>

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="1721"></A><H4>1721.
  
Diagnosing ODR violations for static data members
</H4>
<B>Section: </B>11.4.9.3&#160; [<A href="https://wg21.link/class.static.data">class.static.data</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-31<BR>




<P>Describing the handling of static data members with
<I>brace-or-equal-initializer</I>s, 11.4.9.3 [<A href="https://wg21.link/class.static.data#4">class.static.data</A>] paragraph 4
says,</P>

<BLOCKQUOTE>

The member shall still be defined in a namespace scope if it is odr-used
(6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]) in the program and the namespace scope
definition shall not contain an initializer.

</BLOCKQUOTE>

<P>The word &#8220;shall&#8221; implies a required diagnostic, but this
is describing an ODR violation (the static data member might be defined
in a different translation unit) and thus should be &#8220;no diagnostic
required.&#8221;</P>

<P><B>Additional notes (March, 2024)</B></P>

<P>This paragraph has more issues and is largely redundant with
6.2 [<A href="https://wg21.link/basic.def#2.3">basic.def</A>] paragraph 2.3 and paragraph 2.4.</P>

<P><U>Possible resolution [SUPERSEDED]:</U></P>

<P>Change 11.4.9.3 [<A href="https://wg21.link/class.static.data#4">class.static.data</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE class="del">

If a non-volatile non-inline const static data member is of integral
or enumeration 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
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]). The member shall still be defined in a
namespace scope if it is odr-used (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]) in the
program and the namespace scope definition shall not contain an
initializer . The declaration of an inline static data member (which
is a definition) may specify a <I>brace-or-equal-initializer</I> .  If
the member is declared with the constexpr specifier, it may be
redeclared in namespace scope with no initializer (this usage is
deprecated; see D.7 [<A href="https://wg21.link/depr.static.constexpr">depr.static.constexpr</A>]). Declarations of other
static data members shall not specify a
<I>brace-or-equal-initializer</I>.

</BLOCKQUOTE>

<BLOCKQUOTE class="ins">

If a declaration of a non-inline static data member in a class
definition specifies a <I>brace-or-equal-initializer</I>, the member
shall be of non-volatile const integral or enumeration type and shall
be constant-initialized (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]), and the definition
(if any) shall not specify a <I>brace-or-equal-initializer</I>.

</BLOCKQUOTE>

<P><B>Additional notes (December, 2024)</B></P>

<P>9.5.1 [<A href="https://wg21.link/dcl.init.general#2">dcl.init.general</A>] paragraph 2 and paragraph 3 serve no
normative purpose and should be struck.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Remove 9.5.1 [<A href="https://wg21.link/dcl.init.general#2">dcl.init.general</A>] paragraph 2 and paragraph 3:</P>

<BLOCKQUOTE class="del">

<P>
Except for objects declared with the constexpr specifier, for which
see 9.2.6 [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>], an initializer in the definition of a
variable can consist of arbitrary expressions involving literals and
previously declared variables and functions, regardless of the
variable's storage duration.  [<I>Example 1</I>: ... &#8212;<I>end
example</I>]
</P>

<P>
[<I>Note 2:</I> Default arguments are more restricted; see
9.3.4.7 [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]. &#8212;<I>end note</I>]
</P>
</BLOCKQUOTE>
</LI>

<LI>
<P>Change 11.4.9.3 [<A href="https://wg21.link/class.static.data#4">class.static.data</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE class="del">

If a non-volatile non-inline const static data member is of integral
or enumeration 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
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]). The member shall still be defined in a
namespace scope if it is odr-used (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]) in the
program and the namespace scope definition shall not contain an
initializer . The declaration of an inline static data member (which
is a definition) may specify a <I>brace-or-equal-initializer</I> .  If
the member is declared with the constexpr specifier, it may be
redeclared in namespace scope with no initializer (this usage is
deprecated; see D.7 [<A href="https://wg21.link/depr.static.constexpr">depr.static.constexpr</A>]). Declarations of other
static data members shall not specify a
<I>brace-or-equal-initializer</I>.

</BLOCKQUOTE>

<BLOCKQUOTE class="ins">

If a declaration of a non-inline static data member in a class
definition specifies a <I>brace-or-equal-initializer</I>, the member
shall be of non-volatile const integral or enumeration type and shall
be constant-initialized (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]), and the definition
(if any) shall not specify a <I>brace-or-equal-initializer</I>.

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2554"></A><H4>2554.
  
Overriding virtual functions, also with explicit object parameters
</H4>
<B>Section: </B>11.7.3&#160; [<A href="https://wg21.link/class.virtual">class.virtual</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2021-12-10<BR>




<P>Consider:</P>

<PRE>
  struct B {
    virtual void f();   //<SPAN CLASS="cmnt"> #1</SPAN>
  };

  struct D : B {
    void f();           //<SPAN CLASS="cmnt"> #2</SPAN>
  };
</PRE>

<P>Subclause 11.7.3 [<A href="https://wg21.link/class.virtual#2">class.virtual</A>] paragraph 2 says:</P>

<BLOCKQUOTE>

If a virtual member function F is declared in a class B, and, in a
class D derived (directly or indirectly) from B, a declaration of a
member function G corresponds (6.4.1 [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]) to a
declaration of F, ignoring trailing <I>requires-clause</I>s, then G
<I>overrides</I> [ <I>Footnote:</I> ... ] F .

</BLOCKQUOTE>

<P>Subclause 6.4.1 [<A href="https://wg21.link/basic.scope.scope#4">basic.scope.scope</A>] paragraph 4 defines "corresponds"
as follows:</P>

<BLOCKQUOTE>

Two declarations correspond if they (re)introduce the same name, both
declare constructors, or both declare destructors, unless

<UL>
<LI>...</LI>
<LI>
each declares a function or function template,
except when
<UL>
<LI>both declare functions with
the same non-object-parameter-type-list, equivalent
(13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]) trailing <I>requires-clause</I>s (if
any, except as specified in 13.7.5 [<A href="https://wg21.link/temp.friend">temp.friend</A>]), and, if both
are non-static members, they have corresponding object parameters, or
</LI>
<LI>
both declare function templates with...
</LI>
</UL>
</LI>
</UL>

</BLOCKQUOTE>

<P>Subclause 6.4.1 [<A href="https://wg21.link/basic.scope.scope#3">basic.scope.scope</A>] paragraph 3 defines "corresponding object
parameters" as follows:</P>

<BLOCKQUOTE>

Two non-static member functions have corresponding object parameters
if:
<UL>
<LI>
exactly one is an implicit object member function with
no <I>ref-qualifier</I> and the types of their object parameters
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]), after removing top-level references,
are the same, or
</LI>

<LI>their object parameters have the same type.</LI>
</UL>

</BLOCKQUOTE>

<P>In the example, <TT>B::f</TT> has an object parameter of
type <TT>B</TT>, but <TT>D::f</TT> has an object parameter of
type <TT>D</TT>.  Thus, the two functions do not correspond, and
thus <TT>D::f</TT> does not override <TT>B::f</TT>.  That is an
unintended alteration of the status quo ante.</P>

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

<P><B>Proposed resolution:</B></P>

<OL>
<LI>
<P>Change in 11.7.3 [<A href="https://wg21.link/class.virtual#2">class.virtual</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If a virtual member function F is declared in a class B, and, in a
class D derived (directly or indirectly) from B, a declaration of a
member function G corresponds (6.4.1 [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]) to a
declaration of F
<INS>as if declared in D (12.2.2.1 [<A href="https://wg21.link/over.match.funcs.general">over.match.funcs.general</A>])</INS>,
ignoring trailing <I>requires-clause</I>s,
<INS>and, if G is an explicit object member function, ignoring object
parameters, and, if G is an implicit object member function, F and G
have the same <I>ref-qualifier</I> (or absence thereof),
</INS>
then G <I>overrides</I> [ <I>Footnote:</I> ... ] F .

</BLOCKQUOTE>
</LI>

<LI>
<P>Remove 11.7.3 [<A href="https://wg21.link/class.virtual#7">class.virtual</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

<DEL>The <I>ref-qualifier</I> , or lack thereof, of an overriding function
shall be the same as that of the overridden function.</DEL>

</BLOCKQUOTE>

</LI>
</OL>


<BR><BR><HR>
<A NAME="1883"></A><H4>1883.
  
Protected access to constructors in <I>mem-initializer</I>s
</H4>
<B>Section: </B>11.8.5&#160; [<A href="https://wg21.link/class.protected">class.protected</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-02-26<BR>


<P>According to 11.8.5 [<A href="https://wg21.link/class.protected#1">class.protected</A>] paragraph 1, except when
forming a pointer to member,</P>

<BLOCKQUOTE>

All other accesses involve a (possibly implicit) object expression
(7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]).

</BLOCKQUOTE>

<P>It is not clear that this is strictly true for the invocation of
a base class constructor from a <I>mem-initializer</I>.  A wording
tweak may be advisable.</P>

<P><B>Proposed resolution (March, 2025):</B></P>

<P>Change in 11.8.5 [<A href="https://wg21.link/class.protected#1">class.protected</A>] paragraph 1 as follows and move
the example to a separate numbered paragraph:</P>

<BLOCKQUOTE>

<P>An additional access check beyond those described earlier in
11.8 [<A href="https://wg21.link/class.access">class.access</A>] is applied when a non-static data member or
non-static member function is a protected member of its naming class
(11.8.3 [<A href="https://wg21.link/class.access.base">class.access.base</A>]). [ Footnote: ... ] As described earlier,
access to a protected member is granted because the reference occurs
in a friend or direct member of some class C. If the access is to form
a pointer to member (7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]),
the <I>nested-name-specifier</I> shall denote C or a class derived
from C.
<INS>Otherwise, if the member is a constructor, either C shall be the
naming class or the access shall be the constructor call for a base
class subobject of C performed by a constructor of C as described in
11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>].</INS> All other accesses involve a
(possibly implicit) object expression
(7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]).  <DEL>In this case</DEL>
<INS>Unless the access is an implicit destructor call for a base class
subobject by a destructor of C (11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>])</INS>,
the class of the object expression shall be C or a class derived from
C.</P>

<P>
[Example 1 :

<PRE>
  class B {
  protected:
    int i;
    static int j;
<INS>    B(int = 0);
    ~B();</INS>
  };
  class D1 : public B {
<INS>    D1() : B(1) {                 //<SPAN CLASS="cmnt"> OK</SPAN>
      B b(*this);                 //<SPAN CLASS="cmnt"> error: destructor of </SPAN>B<SPAN CLASS="cmnt"> is protected</SPAN>
    }
    ~D1() = default;              //<SPAN CLASS="cmnt"> OK</SPAN></INS>
  };
</PRE>
... -- end example ]
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2756"></A><H4>2756.
  
Completion of initialization by delegating constructor
</H4>
<B>Section: </B>11.9&#160; [<A href="https://wg21.link/class.init">class.init</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2023-06-20<BR>




<P>Subclause 6.8.4 [<A href="https://wg21.link/basic.life#1">basic.life</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

... 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>its initialization (if any) is complete (including vacuous
initialization) (9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]),</LI>
</UL>

except that ...

</BLOCKQUOTE>

<P>It is unclear whether initialization is considered complete when
the (ultimate) target constructor completes, or when the outermost
delegating constructor completes.  Subclause 14.3 [<A href="https://wg21.link/except.ctor#4">except.ctor</A>] paragraph 4 suggests it is the former:</P>

<BLOCKQUOTE>

If the <I>compound-statement</I> of the <I>function-body</I> of a
delegating constructor for an object exits via an exception, the
object's destructor is invoked. ...

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-07-14) [SUPERSEDED]:</B></P>

<OL>
<LI>
<P>Split and change 11.9.3 [<A href="https://wg21.link/class.base.init#9">class.base.init</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

<P>[Note 3: An abstract class ... -- end note ]
<DEL>An attempt to initialize more than one non-static data member of a
union renders the program ill-formed.</DEL>
[Note 4: After the call to a constructor for class X ... -- end note ]
[Example 6: ... -- end example ]</P>

<P class="ins">
An attempt to initialize more than one non-static data
member of a union renders the program ill-formed.</P>

<P class="ins">
An object's initialization is considered complete when a
non-delegating constructor for that object returns. [Note: Therefore,
an object's lifetime can begin (6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]) before all
delegating constructors have completed. -- end note]</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#1.2">basic.life</A>] bullet 1.2 as follows:</P>

<BLOCKQUOTE>

... 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>its initialization (if any) is complete (including vacuous
initialization) (9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]<INS>,
11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]</INS>),</LI>
</UL>

except that ...

</BLOCKQUOTE>

</LI>
</OL>

<P><B>CWG 2023-10-20</B></P>

<P>Utterances about "during construction or destruction" in
11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>] need to be adjusted.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Split and change 11.9.3 [<A href="https://wg21.link/class.base.init#9">class.base.init</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

<P>[Note 3: An abstract class ... -- end note ]
<DEL>An attempt to initialize more than one non-static data member of a
union renders the program ill-formed.</DEL>
[Note 4: After the call to a constructor for class X ... -- end note ]
[Example 6: ... -- end example ]</P>

<P class="ins">
An attempt to initialize more than one non-static data
member of a union renders the program ill-formed.</P>

<P class="ins">
An object's initialization is considered complete when a
non-delegating constructor for that object returns. [Note: Therefore,
an object's lifetime can begin (6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]) before all
delegating constructors have completed. -- end note]</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#1.2">basic.life</A>] bullet 1.2 as follows:</P>

<BLOCKQUOTE>

... 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>its initialization (if any) is complete (including vacuous
initialization) (9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]<INS>,
11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]</INS>),</LI>
</UL>

except that ...

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 11.9.5 [<A href="https://wg21.link/class.cdtor#2">class.cdtor</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

During the <DEL>construction</DEL> <INS>initialization</INS> of an
object, if the value of the object or any of its subobjects is
accessed through a glvalue that is not obtained, directly or
indirectly, from the constructor's this pointer, the value of the
object or subobject thus obtained is unspecified.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.9.5 [<A href="https://wg21.link/class.cdtor#4">class.cdtor</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

Member functions, including virtual functions
(11.7.3 [<A href="https://wg21.link/class.virtual">class.virtual</A>]), can be called during construction or
destruction (11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]).  When a virtual function is
called directly or indirectly from a constructor or from a destructor,
including during the <DEL>construction</DEL> <INS>initialization</INS>
or destruction of the class's non-static data members, and the object
to which the call applies is the object (call it x) <DEL>under
construction or destruction</DEL> <INS>being initialized or
destroyed</INS>, the function called is the final overrider in the
constructor's or destructor's class and not one overriding it in a
more-derived class. If the virtual function call uses an explicit
class member access (7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]) and the object
expression refers to the complete object of x or one of that object's
base class subobjects but not x or one of its base class subobjects,
the behavior is undefined.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.9.5 [<A href="https://wg21.link/class.cdtor#5">class.cdtor</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

The typeid operator (7.6.1.8 [<A href="https://wg21.link/expr.typeid">expr.typeid</A>]) can be used during
construction or destruction (11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]). When typeid
is used in a constructor (including the <I>mem-initializer</I> or
default member initializer (11.4 [<A href="https://wg21.link/class.mem">class.mem</A>]) for a
non-static data member) or in a destructor, or used in a function
called (directly or indirectly) from a constructor or destructor, if
the operand of typeid refers to the object <DEL>under construction or
destruction</DEL> <INS>being initialized or destroyed</INS>, typeid
yields the std::type_info object representing the constructor or
destructor's class. If the operand of typeid refers to the
object <DEL>under construction or destruction</DEL> <INS>being
initialized or destroyed</INS> and the static type of the operand is
neither the constructor or destructor's class nor one of its bases,
the behavior is undefined.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.9.5 [<A href="https://wg21.link/class.cdtor#6">class.cdtor</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

dynamic_casts (7.6.1.7 [<A href="https://wg21.link/expr.dynamic.cast">expr.dynamic.cast</A>]) can be used during
construction or destruction (11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]). When a
dynamic_cast is used in a constructor (including
the <I>mem-initializer</I> or default member initializer for a
non-static data member) or in a destructor, or used in a function
called (directly or indirectly) from a constructor or destructor, if
the operand of the dynamic_cast refers to the object <DEL>under
construction or destruction</DEL> <INS>being initialized or
destroyed</INS>, this object is considered to be a most derived object
that has the type of the constructor or destructor's class. If the
operand of the dynamic_cast refers to the object <DEL>under
construction or destruction</DEL> <INS>being initialized or
destroyed</INS> and the static type of the operand is not a pointer to
or object of the constructor or destructor's own class or one of its
bases, the dynamic_cast results in undefined behavior.

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2757"></A><H4>2757.
  
Deleting or deallocating storage of an object during its construction
</H4>
<B>Section: </B>11.9.5&#160; [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2023-06-14<BR>


<P>Subclause 6.8.4 [<A href="https://wg21.link/basic.life#6">basic.life</A>] paragraph 6 specifies:</P>

<BLOCKQUOTE>

... For an object under construction or destruction, see
11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]. Otherwise, ...

</BLOCKQUOTE>

<P>However, the referenced subclause does not discuss deleting the
object or deallocating its storage.</P>

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

<P><B>Proposed resolution (reviewed by CWG 2023-10-20):</B></P>

<OL>
<LI>
<P>Insert before 11.9.5 [<A href="https://wg21.link/class.cdtor#2">class.cdtor</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<P class="ins">
During the initialization or destruction of an object, invoking the
destructor for the object or releasing or reusing
(6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]) the storage which the object occupies
results in undefined behavior. [ Note: Creating an object nested
within some object <I>o</I> does not reuse the storage
for <I>o</I>. -- end note ] [ Example:</P>

<PRE class="ins">
  struct A() {
    A() {
      ::operator delete(this);
    }
  };

  A *p1 = new A;  //<SPAN CLASS="cmnt"> undefined behavior</SPAN>

  struct B() {
    B() {
      delete this;
    }
  };

  B *p2 = new B;  //<SPAN CLASS="cmnt"> undefined behavior</SPAN>

  struct S {
    constexpr S() { this-&gt;~S(); }
    constexpr S(int) {}
  };

  constexpr int f() {
    S s(0);
    s.~S();
    std::construct_at(&amp;s);  // <SPAN CLASS="cmnt">#1</SPAN>
    return 0;
  }

  constexpr int x = f();  // <SPAN CLASS="cmnt">error: undefined behavior at #1</SPAN>
</PRE>
<P class="ins">-- end example ]</P>

<P>During the construction of an object, if the value of the object ...</P>
</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.9.5 [<A href="https://wg21.link/class.cdtor#4">class.cdtor</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

Member functions<DEL>, including virtual functions
(11.7.3 [<A href="https://wg21.link/class.virtual">class.virtual</A>]),</DEL> <INS>other than the
destructor</INS> can be called during construction or destruction
(11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]).  When a virtual
function <INS>(11.7.3 [<A href="https://wg21.link/class.virtual">class.virtual</A>])</INS> is called directly or
indirectly from a constructor or from a destructor, including during
the construction or destruction of the class's non-static data
members, and ...

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2797"></A><H4>2797.
  
Meaning of "corresponds" for rewritten operator candidates
</H4>
<B>Section: </B>12.2.2.3&#160; [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

 <B>Date: </B>2023-09-17
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Subclause 12.2.2.3 [<A href="https://wg21.link/over.match.oper#4">over.match.oper</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

A non-template function or function template F named operator== is a
rewrite target with first operand o unless a search for the name
operator!= in the scope S from the instantiation context of the
operator expression finds a function or function template that would
correspond (6.4.1 [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]) to F if its name were
operator==, where S is the scope of the class type of o if F is a
class member, and the namespace scope of which F is a member
otherwise. A function template specialization named operator== is a
rewrite target if its function template is a rewrite target.

</BLOCKQUOTE>

<P>The meaning of "corresponds" has changed with paper P0847 such that
this example from the Working Paper is now ill-formed:</P>

<PRE>
  struct B {
    bool operator==(const B&amp;);
  };
  struct C : B {
    C();
    C(B);
    bool operator!=(const B&amp;);
  };
  bool c1 = B() == C();    // was OK, now ill-formed
</PRE>

<P>The reason is that the definition of "corresponds" now also
considers the object parameters, which are different in the example
above.</P>

<P><U>Possible resolution [SUPERSEDED]:</U></P>

<OL>
<LI>
<P>Change and split in 6.4.1 [<A href="https://wg21.link/basic.scope.scope#3">basic.scope.scope</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>
<P>...</P>

<P>
<INS>Two functions have <I>corresponding non-object signatures</I> if
they have the same non-object-parameter-type-list. </INS> Two function
templates have <I>corresponding <INS>non-object</INS> signatures</I>
if their <I>template-parameter-list</I>s have the same length, their
corresponding <I>template-parameter</I> s are
equivalent, <INS>and</INS> they have equivalent
non-object-parameter-type-lists and return types (if any)<DEL>, and,
if both are non-static members, they have corresponding object
parameters</DEL>.
<INS>Two functions or function templates have <I>corresponding
signatures</I> if they have corresponding non-object signatures and,
if both are non-static members, they have corresponding object
parameters.</INS>
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.4.1 [<A href="https://wg21.link/basic.scope.scope#4">basic.scope.scope</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>
Two declarations <I>correspond</I> if they (re)introduce the
same name, both declare constructors, or both declare destructors,
unless
<UL>
<LI>either is a <I>using-declarator</I> , or</LI>
<LI>one declares a type (not a typedef-name) and the other declares a
variable, non-static data member other than of an anonymous union
(11.5.2 [<A href="https://wg21.link/class.union.anon">class.union.anon</A>]), enumerator, function, or function
template, or</LI>
<LI>each declares a function or function template and they do not
declare corresponding overloads.</LI>
</UL>

Two function or function template declarations
declare <I>corresponding overloads</I> if:
<UL>
<LI>
both declare functions with <DEL>the same
non-object-parameter-type-list, equivalent
(13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]) trailing <I>requires-clause</I>s (if
any, except as specified in 13.7.5 [<A href="https://wg21.link/temp.friend">temp.friend</A>]), and, if both
are non-static members, they have corresponding object
parameters,</DEL> <INS>corresponding signatures</INS> or
both declare function templates with corresponding signatures and
<DEL>equivalent <I>template-head</I>s and trailing <I>requires-clause</I>s
(if any).</DEL>
</LI>
<LI class="ins">
both have equivalent (13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>])
<I>template-head</I>s and trailing <I>requires-clause</I>s (if any,
except as specified in 13.7.5 [<A href="https://wg21.link/temp.friend">temp.friend</A>]).
</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.2.2.3 [<A href="https://wg21.link/over.match.oper#4">over.match.oper</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

A non-template function or function template F named operator== is a
rewrite target with first operand o unless a search for the name
operator!= in the scope S from the instantiation context of the
operator expression finds a function or function
template <INS><TT>F2</TT> such</INS> that <DEL>would
correspond</DEL> <INS><TT>F</TT> and <TT>F2</TT> have corresponding
non-object signatures</INS> (6.4.1 [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]) <DEL>to F if
its name were operator==</DEL>, where S is the scope of the class type
of o if F is a class member, and the namespace scope of which F is a
member otherwise. A function template specialization named operator==
is a rewrite target if its function template is a rewrite target.

</BLOCKQUOTE>

</LI>
</OL>

<P><B>CWG 2023-10-06</B></P>

<P>CWG raised the question to EWG whether the special rule that allows
the example in this issue for backward compatibility should be
extended to member functions with explicit object parameters.
This is tracked via
<A HREF="https://github.com/cplusplus/papers/issues/1645">paper issue 1645</A>.</P>

<P><B>EWG 2024-03-18</B></P>

<P>EWG has no consensus to extend the rules to explicit object parameters.</P>

<P><U>Possible resolutionv [SUPERSEDED]:</U></P>

<OL>
<LI>
<P>Change and split in 6.4.1 [<A href="https://wg21.link/basic.scope.scope#3">basic.scope.scope</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>
<P>...</P>

<P>
<INS>Two functions have <I>corresponding non-object signatures</I> if
they have the same non-object-parameter-type-list. </INS> Two function
templates have <I>corresponding <INS>non-object</INS> signatures</I>
if their <I>template-parameter-list</I>s have the same length, their
corresponding <I>template-parameter</I> s are
equivalent, <INS>and</INS> they have equivalent
non-object-parameter-type-lists and return types (if any)<DEL>, and,
if both are non-static members, they have corresponding object
parameters</DEL>.
<INS>Two functions or function templates have <I>corresponding
signatures</I> if they have corresponding non-object signatures and,
if both are non-static members, they have corresponding object
parameters.</INS>
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.4.1 [<A href="https://wg21.link/basic.scope.scope#4">basic.scope.scope</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>
Two declarations <I>correspond</I> if they (re)introduce the
same name, both declare constructors, or both declare destructors,
unless
<UL>
<LI>either is a <I>using-declarator</I> , or</LI>
<LI>one declares a type (not a typedef-name) and the other declares a
variable, non-static data member other than of an anonymous union
(11.5.2 [<A href="https://wg21.link/class.union.anon">class.union.anon</A>]), enumerator, function, or function
template, or</LI>
<LI>each declares a function or function template and they do not
declare corresponding overloads.</LI>
</UL>

Two function or function template declarations
declare <I>corresponding overloads</I> if:
<UL>
<LI>
both declare functions with <DEL>the same
non-object-parameter-type-list, equivalent
(13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]) trailing <I>requires-clause</I>s (if
any, except as specified in 13.7.5 [<A href="https://wg21.link/temp.friend">temp.friend</A>]), and, if both
are non-static members, they have corresponding object
parameters,</DEL> <INS>corresponding signatures</INS> or
both declare function templates with corresponding signatures and
<DEL>equivalent <I>template-head</I>s and trailing <I>requires-clause</I>s
(if any).</DEL>
</LI>
<LI class="ins">
both have equivalent (13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>])
<I>template-head</I>s and trailing <I>requires-clause</I>s (if any,
except as specified in 13.7.5 [<A href="https://wg21.link/temp.friend">temp.friend</A>]).
</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.2.2.3 [<A href="https://wg21.link/over.match.oper#4">over.match.oper</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

A non-template function or function template F named operator== is a
rewrite target with first operand o unless a search for the name
operator!= in the scope S from the instantiation context of the
operator expression finds a function or function
template <INS><TT>F2</TT> such</INS> that <DEL>would
correspond</DEL> <INS><TT>F2</TT> is an implicit object member
function and <TT>F</TT> and <TT>F2</TT> have corresponding non-object
signatures</INS> (6.4.1 [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]) <DEL>to F if its name
were operator==</DEL>, where S is the scope of the class type of o if
F is a class member, and the namespace scope of which F is a member
otherwise. A function template specialization named operator== is a
rewrite target if its function template is a rewrite target.

</BLOCKQUOTE>

</LI>
</OL>

<P><B>CWG 2024-11-18</B></P>

<P>Subclause 9.10 [<A href="https://wg21.link/namespace.udecl#11">namespace.udecl</A>] paragraph 11 needs to change. Limit
to both F and F2 being implicit object member functions.</P>

<P><U>Possible resolution [SUPERSEDED]:</U></P>

<OL>
<LI>
<P>Change and split in 6.4.1 [<A href="https://wg21.link/basic.scope.scope#3">basic.scope.scope</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>
<P>...</P>

<P>
<INS>Two functions have <I>corresponding non-object signatures</I> if
they have the same non-object-parameter-type-list. </INS> Two function
templates have <I>corresponding <INS>non-object</INS> signatures</I>
if their <I>template-parameter-list</I>s have the same length, their
corresponding <I>template-parameter</I> s are
equivalent, <INS>and</INS> they have equivalent
non-object-parameter-type-lists and return types (if any)<DEL>, and,
if both are non-static members, they have corresponding object
parameters</DEL>.
<INS>Two functions or function templates have <I>corresponding
signatures</I> if they have corresponding non-object signatures and,
if both are non-static members, they have corresponding object
parameters.</INS>
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.4.1 [<A href="https://wg21.link/basic.scope.scope#4">basic.scope.scope</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>
Two declarations <I>correspond</I> if they (re)introduce the
same name, both declare constructors, or both declare destructors,
unless
<UL>
<LI>either is a <I>using-declarator</I> , or</LI>
<LI>one declares a type (not a typedef-name) and the other declares a
variable, non-static data member other than of an anonymous union
(11.5.2 [<A href="https://wg21.link/class.union.anon">class.union.anon</A>]), enumerator, function, or function
template, or</LI>
<LI>each declares a function or function template and they do not
declare corresponding overloads.</LI>
</UL>

Two function or function template declarations
declare <I>corresponding overloads</I> if:
<UL>
<LI>
both declare functions with <DEL>the same
non-object-parameter-type-list, equivalent
(13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]) trailing <I>requires-clause</I>s (if
any, except as specified in 13.7.5 [<A href="https://wg21.link/temp.friend">temp.friend</A>]), and, if both
are non-static members, they have corresponding object
parameters,</DEL> <INS>corresponding signatures</INS> or
both declare function templates with corresponding signatures and
<DEL>equivalent <I>template-head</I>s and trailing <I>requires-clause</I>s
(if any).</DEL>
</LI>
<LI class="ins">
both have equivalent (13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>])
<I>template-head</I>s and trailing <I>requires-clause</I>s (if any,
except as specified in 13.7.5 [<A href="https://wg21.link/temp.friend">temp.friend</A>]).
</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.10 [<A href="https://wg21.link/namespace.udecl#11">namespace.udecl</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

The set of declarations named by a <I>using-declarator</I> that
inhabits a class C does not include member functions and member
function templates of a base class that<INS>, when declared
in <TT>C</TT>, would</INS> correspond to (and thus would conflict
with) a declaration of a function or function template in C.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.2.2.3 [<A href="https://wg21.link/over.match.oper#4">over.match.oper</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

A non-template function or function template F named operator== is a
rewrite target with first operand o unless <INS><TT>F</TT> is not an
implicit object function and</INS> search for the name operator!= in
the scope S from the instantiation context of the operator expression
finds a function or function template <INS><TT>F2</TT> such</INS>
that <DEL>would correspond</DEL> <INS><TT>F2</TT> is an implicit
object member function and <TT>F</TT> and <TT>F2</TT> have
corresponding non-object signatures</INS>
(6.4.1 [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]) <DEL>to F if its name were
operator==</DEL>, where S is the scope of the class type of o if F is
a class member, and the namespace scope of which F is a member
otherwise. A function template specialization named operator== is a
rewrite target if its function template is a rewrite target.

</BLOCKQUOTE>

</LI>
</OL>

<P><B>Additional notes (November, 2024)</B></P>

<P>Both 9.10 [<A href="https://wg21.link/namespace.udecl#11">namespace.udecl</A>] paragraph 11 (see <A HREF="cwg_active.html#2555">issue 2555</A>) and 11.7.3 [<A href="https://wg21.link/class.virtual">class.virtual</A>] (see
<A HREF="cwg_active.html#2554">issue 2554</A>) as well as the present issue
would benefit from defining "corresponds" such that the type of the
implicit object parameter (beyond ref-/cv-qualification) is not
considered.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 6.4.1 [<A href="https://wg21.link/basic.scope.scope#3">basic.scope.scope</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

Two non-static member functions have <I>corresponding object
parameters</I> if<INS>, considering them to be declared in the same
class,</INS>
<UL>
<LI>exactly one is an implicit object member function with
no <I>ref-qualifier</I> and the types of their object parameters
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]), after removing references, are the
same, or</LI>
<LI>their object parameters have the same type.</LI>
</UL>
Two non-static member function templates <I>have corresponding object
parameters</I> if<INS>, considering them to be declared in the same
class,</INS>
<UL>
<LI>exactly one is an implicit object member function with
no <I>ref-qualifier</I> and the types of their object parameters,
after removing any references, are equivalent, or</LI>
<LI>the types of their object parameters are equivalent.</LI>
</UL>
Two function templates have <I>corresponding signatures</I> if
their <I>template-parameter-list</I>s have the same length, their
corresponding <I>template-parameter</I> s are equivalent, they have
equivalent non-object-parameter-type-lists and return types (if any),
and, if both are non-static members, they have corresponding object
parameters.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.2.2.3 [<A href="https://wg21.link/over.match.oper#4">over.match.oper</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

A non-template function or function template F named operator== is a
rewrite target with first operand o unless <INS><TT>F</TT> is not an
explicit object member function and</INS> search for the name
operator!= in the scope S from the instantiation context of the
operator expression finds a function or function
template <INS><TT>F2</TT> such</INS> that <DEL>would
correspond</DEL> <INS><TT>F2</TT> is not an explicit object member
function and <TT>F</TT> and <TT>F2</TT> are corresponding
overloads</INS> (6.4.1 [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]) <DEL>to F if its name
were operator==</DEL>, where S is the scope of the class type of o if
F is a class member, and the namespace scope of which F is a member
otherwise. A function template specialization named operator== is a
rewrite target if its function template is a rewrite target.

</BLOCKQUOTE>

</LI>
</OL>

<P>This resolution also resolves <A HREF="cwg_active.html#2555">issue 2555</A>.</P>

<BR><BR><HR>
<A NAME="2572"></A><H4>2572.
  
Address of overloaded function with no target
</H4>
<B>Section: </B>12.3&#160; [<A href="https://wg21.link/over.over">over.over</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2022-04-26<BR>


<P>Consider:</P>

<PRE>
  template &lt;class T&gt; T f(T);   //<SPAN CLASS="cmnt"> #1</SPAN>
  template &lt;class T&gt; T* f(T*); //<SPAN CLASS="cmnt"> #2</SPAN>
  auto p = &amp;f&lt;int&gt;;
</PRE>

<P>Accoring to 12.3 [<A href="https://wg21.link/over.over#3">over.over</A>] paragraph 3 and 12.3 [<A href="https://wg21.link/over.over#5">over.over</A>] paragraph 5:</P>

<BLOCKQUOTE>

<P>
The specialization, if any, generated by template argument deduction
(13.10.4 [<A href="https://wg21.link/temp.over">temp.over</A>], 13.10.3.3 [<A href="https://wg21.link/temp.deduct.funcaddr">temp.deduct.funcaddr</A>],
13.10.2 [<A href="https://wg21.link/temp.arg.explicit">temp.arg.explicit</A>]) for each function template named is
added to the set of selected functions considered.
</P>

[...]

<P>
Any given function template specialization F1 is eliminated if the set
contains a second function template specialization whose function
template is more specialized than the function template of F1
according to the partial ordering rules of
13.7.7.3 [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]. After such eliminations, if any, there
shall remain exactly one selected function.
</P>

</BLOCKQUOTE>

<P>Major implementations reject the example as ambiguous, yet the
wording specifies to unambiguously choose #2.</P>

<P><U>Suggested resolution [SUPERSEDED]:</U></P>

<P>Change in 12.3 [<A href="https://wg21.link/over.over#5">over.over</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

Any given function template specialization F1 is eliminated if the set
contains a second function template specialization whose function
template is <DEL>more specialized</DEL> <INS>better</INS> than the
function template of F1<INS>. If there is no target, a function
template is better than another if it is more constrained than the
other; otherwise a function template is better than another if it is
more specialized than the other</INS> according to the partial
ordering rules of 13.7.7.3 [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]. After such
eliminations, if any, there shall remain exactly one selected
function.

</BLOCKQUOTE>

<P><B>Proposed resolution:</B></P>

<P>Change in 12.3 [<A href="https://wg21.link/over.over#5">over.over</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<DEL>Any</DEL> <INS>If there is a target, any</INS> given function template specialization F1 is eliminated if the set
contains a second function template specialization whose function
template is more specialized than the function template of F1
according to the partial ordering rules of
13.7.7.3 [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]. After such eliminations, if any, there
shall remain exactly one selected function.

</BLOCKQUOTE>

<P><B>Additional notes (July, 2024)</B></P>

<P>The example in this issue is resolved by <A HREF="cwg_defects.html#2918">issue 2918</A> by suitably ordering placeholder type deduction before
the address operation.</P>

<BR><BR><HR>
<A NAME="2862"></A><H4>2862.
  
Unclear boundaries of template declarations
</H4>
<B>Section: </B>13.1&#160; [<A href="https://wg21.link/temp.pre">temp.pre</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jan Schultke
 &#160;&#160;&#160;

 <B>Date: </B>2024-02-21<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/506">#506</A>.)</P>

<P>Consider:</P>

<PRE>
  template &lt;int&gt;
  struct S {} v;
</PRE>

<P>Is this a declaration of a class template or a declaration of a
variable template, or neither?  Implementations uniformly reject.</P>

<P>Another example:</P>

<PRE>
  template&lt;class T&gt;
  typedef struct C F; 
</PRE>

<P><B>Proposed resolution (approved by CWG 2024-04-05) [SUPERSEDED]:</B></P>

<P>Change in 13.1 [<A href="https://wg21.link/temp.pre#2">temp.pre</A>] paragraph 2 through 5 as follows:</P>

<BLOCKQUOTE>

<P>The <I>declaration</I> in a <I>template-declaration</I> (if any) shall
<UL>
<LI>declare or define a function, a class, or a variable, or</LI>
<LI>define a member function, a member class, a member enumeration, or
a static data member of a class template or of a class nested within a
class template, or</LI>
<LI>define a member template of a class or class template, or</LI>
<LI>be a <I>deduction-guide</I>, or</LI>
<LI>be an <I>alias-declaration</I>. </LI>
</UL>
<INS>The <I>declaration</I> shall not be an <I>export-declaration</I>
or a <I>simple-declaration</I>
whose <I>decl-specifier-seq</I> contains <TT>typedef</TT>.</INS>
</P>

<P>
<DEL>A <I>template-declaration</I> is a <I>declaration</I>.</DEL>
<INS>
If</INS>
<UL class="ins">
<LI>the <I>declaration</I> in a <I>template-declaration</I> introduces
an entity using a declarative <I>nested-name-specifier</I>
(7.5.5.3 [<A href="https://wg21.link/expr.prim.id.qual">expr.prim.id.qual</A>]) that is dependent and equivalent to the
injected-class-name of a class template or class template partial
specialization <TT>C</TT>, and</LI>
<LI>the <I>template-head</I> of
the <I>template-declaration</I> is equivalent to that of <TT>C</TT>,</LI>
</UL>
<INS>the <I>template-declaration</I> declares a member of <TT>C</TT>, and
the <I>nested-name-specifier</I> is treated as a non-dependent
reference to <TT>C</TT> for the purpose of further interpreting the
declaration. Otherwise:</INS>
<UL class="ins">
<LI>A <I>class template</I> is introduced by
a <I>template-declaration</I> whose <I>declaration</I> is
a <I>simple-declaration</I> that either contains
a <I>class-specifier</I> in its <I>decl-specifier-seq</I> or consists
solely of an <I>elaborated-type-specifier</I>.</LI>
<LI>A <I>function template</I> is introduced by a
<I>template-declaration</I> whose <I>declaration</I> declares a
function.</LI>
<LI>An <I>alias template</I> is introduced by a
<I>template-declaration</I> whose <I>declaration</I> is
an <I>alias-declaration</I>.</LI>
<LI>A <I>variable template</I> is introduced by a
<I>template-declaration</I> whose <I>declaration</I> declares a
variable.</LI>
</UL>
<INS>[ Example:</INS>
<PRE class="ins">
  template&lt;typename T&gt; struct A {
    template&lt;typename U&gt; struct B;
    template&lt;typename U&gt; struct B&lt;U*&gt; {
      template&lt;typename V&gt; void f();
    };
  };
  template&lt;typename T&gt; //<SPAN CLASS="cmnt"> #1</SPAN>
  template&lt;typename U&gt; //<SPAN CLASS="cmnt"> #2</SPAN>
  template&lt;typename V&gt; //<SPAN CLASS="cmnt"> #3</SPAN>
  void A&lt;T&gt;::B&lt;U*&gt;::f() {}
</PRE>
<INS>
The <I>template-declaration</I> #1 declares a member of the class
template <TT>A</TT>, because <TT>A&lt;T&gt;</TT> is equivalent to the
injected-class-name of <TT>A</TT>.  The <I>template-declaration</I> #2
declares a member of the class template partial specialization
<TT>A&lt;T&gt;::B&lt;U*&gt;</TT>,
because <TT>A&lt;T&gt;::B&lt;U*&gt;</TT> is equivalent to the
injected-class-name of the partial specialization when <TT>A&lt;T&gt;</TT> is
treated as a non-dependent reference to the primary template <TT>A</TT>.
The <I>template-declaration</I> #3 declares a function template that
is a member of the class template partial specialization.

-- end example ]
</INS>

<DEL>A declaration introduced by a template declaration of a variable
is a <I>variable template</I>.</DEL> A variable template at class
scope is a <I>static data member template</I>. [ Example: ... ]</P>

<P>
[<I>Note 2:</I> A <I>template-declaration</I> can appear only as a
namespace scope or class scope declaration. &#8212;<I>end note</I>]
<DEL>Its <I>declaration</I> shall not be an
<I>export-declaration</I>.</DEL> <INS>A <I>template-declaration</I>
shall declare exactly one template or member of a template.</INS>
<INS>[ Example:</INS>
<PRE class="ins">
template &lt;int&gt;
struct S {} v;    // <SPAN CLASS="cmnt">error: declares both a class template and a variable template</SPAN>
template &lt;int&gt;
struct V *v;      // <SPAN CLASS="cmnt">OK: declares a variable template</SPAN>
</PRE>
<INS>-- end example ]</INS>

In a function template
declaration, the <I>unqualified-id</I> of the <I>declarator-id</I>
shall be a name.  [<I>Note 3:</I> A class or variable template
declaration of a <I>simple-template-id</I> declares a partial
specialization (13.7.6 [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]).  &#8212;<I>end
note</I>]</P>

<P>In a <I>template-declaration</I>, explicit specialization, or
explicit instantiation, the <I>init-declarator-list</I> in the
declaration shall contain at most one declarator. <INS>[ Note:</INS>
When such a declaration is used to declare a class template, no
declarator is permitted<INS>, because the declarator would be
considered to declare a variable or function template in addition to
the class template</INS>. <INS>-- end note ]</INS>
</P>

</BLOCKQUOTE>

<P><B>CWG 2024-06-26</B></P>

<P>This drafting lacks the required positional association of
<I>template-head</I>s with the respective component of the
<I>nested-name-specifier</I>.</P>

<P><U>Possible resolution (rebased on the current Working Draft) [SUPERSEDED]:</U></P>

<P>Change in 13.1 [<A href="https://wg21.link/temp.pre#2">temp.pre</A>] paragraph 2 through 5 as follows:</P>

<BLOCKQUOTE>

<P>The <I>declaration</I> in a <I>template-declaration</I> (if any) shall
<UL>
<LI>declare or define a function, a class, or a variable, or</LI>
<LI>define a member function, a member class, a member enumeration, or
a static data member of a class template or of a class nested within a
class template, or</LI>
<LI>define a member template of a class or class template, or</LI>
<LI>be a <I>friend-type-declaration</I>, or</LI>
<LI>be a <I>deduction-guide</I>, or</LI>
<LI>be an <I>alias-declaration</I>. </LI>
</UL>
<INS>The <I>declaration</I> shall not be an <I>export-declaration</I>
or a <I>simple-declaration</I>
whose <I>decl-specifier-seq</I> contains <TT>typedef</TT>.</INS>
</P>

<P>
<DEL>A <I>template-declaration</I> is a <I>declaration</I>.</DEL>
<INS>
If</INS>
<UL class="ins">
<LI>the <I>declaration</I> in a <I>template-declaration</I> introduces
an entity using a declarative <I>nested-name-specifier</I>
(7.5.5.3 [<A href="https://wg21.link/expr.prim.id.qual">expr.prim.id.qual</A>]) that is dependent and equivalent to the
injected-class-name of a class template or class template partial
specialization <TT>C</TT>, and</LI>
<LI>the <I>template-head</I> of
the <I>template-declaration</I> is equivalent to that of <TT>C</TT>,</LI>
</UL>
<INS>the <I>template-declaration</I> declares a member of <TT>C</TT>, and
the <I>nested-name-specifier</I> is treated as a non-dependent
reference to <TT>C</TT> for the purpose of further interpreting the
declaration.

Otherwise:</INS>
<UL class="ins">
<LI>A <I>class template</I> is introduced by
a <I>template-declaration</I> whose <I>declaration</I> is
a <I>simple-declaration</I> that either contains
a <I>class-specifier</I> in its <I>decl-specifier-seq</I> or consists
solely of an <I>elaborated-type-specifier</I>.</LI>
<LI>A <I>function template</I> is introduced by a
<I>template-declaration</I> whose <I>declaration</I> declares a
function.</LI>
<LI>An <I>alias template</I> is introduced by a
<I>template-declaration</I> whose <I>declaration</I> is
an <I>alias-declaration</I>.</LI>
<LI>A <I>variable template</I> is introduced by a
<I>template-declaration</I> whose <I>declaration</I> declares a
variable.</LI>
</UL>
<INS>[ Example:</INS>
<PRE class="ins">
  template&lt;typename T&gt; struct A {
    template&lt;typename U&gt; struct B;
    template&lt;typename U&gt; struct B&lt;U*&gt; {
      template&lt;typename V&gt; void f();
    };
  };
  template&lt;typename T&gt; //<SPAN CLASS="cmnt"> #1</SPAN>
  template&lt;typename U&gt; //<SPAN CLASS="cmnt"> #2</SPAN>
  template&lt;typename V&gt; //<SPAN CLASS="cmnt"> #3</SPAN>
  void A&lt;T&gt;::B&lt;U*&gt;::f() {}
</PRE>
<INS>
The <I>template-declaration</I> #1 declares a member of the class
template <TT>A</TT>, because <TT>A&lt;T&gt;</TT> is equivalent to the
injected-class-name of <TT>A</TT>.  The <I>template-declaration</I> #2
declares a member of the class template partial specialization
<TT>A&lt;T&gt;::B&lt;U*&gt;</TT>,
because <TT>A&lt;T&gt;::B&lt;U*&gt;</TT> is equivalent to the
injected-class-name of the partial specialization when <TT>A&lt;T&gt;</TT> is
treated as a non-dependent reference to the primary template <TT>A</TT>.
The <I>template-declaration</I> #3 declares a function template that
is a member of the class template partial specialization.

-- end example ]
</INS>

<DEL>A declaration introduced by a template declaration of a variable
is a <I>variable template</I>.</DEL> A variable template at class
scope is a <I>static data member template</I>. [ Example: ... ]</P>

<P>
[<I>Note 2:</I> A <I>template-declaration</I> can appear only as a
namespace scope or class scope declaration. &#8212;<I>end note</I>]
<DEL>Its <I>declaration</I> shall not be an
<I>export-declaration</I>.</DEL>
<INS>A <I>template-declaration</I> shall declare exactly one
<FONT color="#0000ff">templated entity (not considering declarations
inhabiting scopes nested therein)</FONT>.</INS>
<INS>[ Example:</INS>
<PRE class="ins">
template &lt;int&gt;
struct S {} v;    // <SPAN CLASS="cmnt">error: declares both a class template and a variable template</SPAN>
template &lt;int&gt;
struct V *v;      // <SPAN CLASS="cmnt">OK, declares a variable template</SPAN>
</PRE>
<INS>-- end example ]</INS>

In a function template
declaration, the <I>unqualified-id</I> of the <I>declarator-id</I>
shall be a name.  [<I>Note 3:</I> A class or variable template
declaration of a <I>simple-template-id</I> declares a partial
specialization (13.7.6 [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]).  &#8212;<I>end
note</I>]</P>

<P>In a <I>template-declaration</I>, explicit specialization, or
explicit instantiation, the <I>init-declarator-list</I> in the
declaration shall contain at most one declarator. <INS>[ Note:</INS>
When such a declaration is used to declare a class template, no
declarator is permitted<INS>, because the declarator would be
considered to declare a variable or function template in addition to
the class template</INS>. <INS>-- end note ]</INS>
</P>

</BLOCKQUOTE>

<P><B>Additional notes (December, 2024)</B></P>

<P>Subclause 7.5.5.3 [<A href="https://wg21.link/expr.prim.id.qual#3">expr.prim.id.qual</A>] paragraph 3 already interprets
declarative <I>nested-name-specifier</I>s.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 13.1 [<A href="https://wg21.link/temp.pre#2">temp.pre</A>] paragraph 2 through 5 as follows:</P>

<BLOCKQUOTE>

<P>The <I>declaration</I> in a <I>template-declaration</I> (if any) shall
<UL>
<LI>declare or define a function, a class, or a variable, or</LI>
<LI>define a member function, a member class, a member enumeration, or
a static data member of a class template or of a class nested within a
class template, or</LI>
<LI>define a member template of a class or class template, or</LI>
<LI>be a <I>friend-type-declaration</I>, or</LI>
<LI>be a <I>deduction-guide</I>, or</LI>
<LI>be an <I>alias-declaration</I>. </LI>
</UL>
<INS>The <I>declaration</I> shall not be an <I>export-declaration</I>
or a <I>simple-declaration</I>
whose <I>decl-specifier-seq</I> contains <TT>typedef</TT>.</INS>
</P>

<P>
<DEL>A <I>template-declaration</I> is a <I>declaration</I>.</DEL>
<INS>
If the <I>declaration</I> in a <I>template-declaration</I> introduces
an entity using a declarative <I>nested-name-specifier</I> that
nominates a primary class template or class template partial
specialization <TT>C</TT> (7.5.5.3 [<A href="https://wg21.link/expr.prim.id.qual">expr.prim.id.qual</A>]),
the <I>template-declaration</I> declares a member of <TT>C</TT>, and
the <I>nested-name-specifier</I> is treated as a non-dependent
reference to <TT>C</TT> for the purpose of further interpreting the
declaration.

Otherwise:</INS>
<UL class="ins">
<LI>A <I>class template</I> is introduced by
a <I>template-declaration</I> whose <I>declaration</I> is
a <I>simple-declaration</I> that either contains
a <I>class-specifier</I> in its <I>decl-specifier-seq</I> or consists
solely of an <I>elaborated-type-specifier</I>.</LI>
<LI>A <I>function template</I> is introduced by a
<I>template-declaration</I> whose <I>declaration</I> declares a
function.</LI>
<LI>An <I>alias template</I> is introduced by a
<I>template-declaration</I> whose <I>declaration</I> is
an <I>alias-declaration</I>.</LI>
<LI>A <I>variable template</I> is introduced by a
<I>template-declaration</I> whose <I>declaration</I> declares a
variable.</LI>
</UL>
<INS>[ Example:</INS>
<PRE class="ins">
  template&lt;typename T&gt; struct A {
    template&lt;typename U&gt; struct B;
    template&lt;typename U&gt; struct B&lt;U*&gt; {
      template&lt;typename V&gt; void f();
    };
  };
  template&lt;typename T&gt; //<SPAN CLASS="cmnt"> #1</SPAN>
  template&lt;typename U&gt; //<SPAN CLASS="cmnt"> #2</SPAN>
  template&lt;typename V&gt; //<SPAN CLASS="cmnt"> #3</SPAN>
  void A&lt;T&gt;::B&lt;U*&gt;::f() {}
</PRE>
<INS>
The <I>template-declaration</I> #1 declares a member of the class
template <TT>A</TT>, because <TT>A&lt;T&gt;</TT> nominates the primary
template <TT>A</TT>.  The <I>template-declaration</I> #2 declares a
member of the class template partial specialization
<TT>A&lt;T&gt;::B&lt;U*&gt;</TT>, because
<TT>A&lt;T&gt;::B&lt;U*&gt;</TT> nominates the class template
partial specialization.  The <I>template-declaration</I> #3 declares
a function template that is a member of the class template partial
specialization.

-- end example ]
</INS>

<DEL>A declaration introduced by a template declaration of a variable
is a <I>variable template</I>.</DEL> A variable template at class
scope is a <I>static data member template</I>. [ Example: ... ]</P>

<P>
[<I>Note 2:</I> A <I>template-declaration</I> can appear only as a
namespace scope or class scope declaration. &#8212;<I>end note</I>]
<DEL>Its <I>declaration</I> shall not be an
<I>export-declaration</I>.</DEL>
<INS>A <I>template-declaration</I> shall declare exactly one
<FONT color="#0000ff">templated entity (not considering declarations
inhabiting scopes nested therein)</FONT>.</INS>
<INS>[ Example:</INS>
<PRE class="ins">
template &lt;int&gt;
struct S {} v;    // <SPAN CLASS="cmnt">error: declares both a class template and a variable template</SPAN>
template &lt;int&gt;
struct V *v;      // <SPAN CLASS="cmnt">OK, declares a variable template</SPAN>
</PRE>
<INS>-- end example ]</INS>

In a function template
declaration, the <I>unqualified-id</I> of the <I>declarator-id</I>
shall be a name.  [<I>Note 3:</I> A class or variable template
declaration of a <I>simple-template-id</I> declares a partial
specialization (13.7.6 [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]).  &#8212;<I>end
note</I>]</P>

<P>In a <I>template-declaration</I>, explicit specialization, or
explicit instantiation, the <I>init-declarator-list</I> in the
declaration shall contain at most one declarator. <INS>[ Note:</INS>
When such a declaration is used to declare a class template, no
declarator is permitted<INS>, because the declarator would be
considered to declare a variable or function template in addition to
the class template</INS>. <INS>-- end note ]</INS>
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2917"></A><H4>2917.
  
Disallow multiple <I>friend-type-specifier</I>s for a friend template
</H4>
<B>Section: </B>13.1&#160; [<A href="https://wg21.link/temp.pre">temp.pre</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Ambrose T
 &#160;&#160;&#160;

 <B>Date: </B>2024-07-30
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>(From submissions
<A HREF="https://github.com/cplusplus/CWG/issues/586">#586</A> and
<A HREF="https://github.com/cplusplus/CWG/issues/593">#593</A>.)</P>

<P>Consider:</P>

<PRE>
struct C {
  template &lt;typename&gt;
  friend class Foo, int;
};
</PRE>

<P>This is obviously nonsense, but is not prohibited by the wording.</P>

<P>Also consider:</P>

<PRE>
  struct S {
    template &lt;typename T&gt;
    friend class Foo&lt;T&gt;::Nested;       //<SPAN CLASS="cmnt"> OK; see 13.7.5 [<A href="https://wg21.link/temp.friend#5">temp.friend</A>] paragraph 5</SPAN>

    template &lt;typename ...Ts&gt;
    friend class Foo&lt;Ts&gt;::Nested...;   //<SPAN CLASS="cmnt"> makes no sense</SPAN>
  };
</PRE>

<P><U>Suggested resolution (2024-07-30):</U></P>

<P>Change in 13.1 [<A href="https://wg21.link/temp.pre#5">temp.pre</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

In a <I>template-declaration</I>, explicit specialization, or explicit
instantiation, the <I>init-declarator-list</I> in the declaration
shall contain at most one declarator. When such a declaration is used
to declare a class template, no declarator is permitted.
<INS>In a <I>template-declaration</I> whose <I>declaration</I> is
a <I>friend-type-declaration</I>, the
<I>friend-type-specifier-list</I> shall consist of exactly
one <I>friend-type-specifier</I>; if it is a pack expansion
(13.7.4 [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]), any packs expanded by that pack
expansion shall not have been introduced by the
<I>template-declaration</I>. [ Example:</INS>

<PRE class="ins">
template&lt;class ...&gt;
struct C {
  struct Nested { };
};

template&lt;class ... Us&gt;
struct S {
  template &lt;typename ...Ts&gt;
  friend class C&lt;Ts&gt;::Nested...;     //<SPAN CLASS="cmnt"> error</SPAN>
  friend class C&lt;Us&gt;::Nested...;     // <SPAN CLASS="cmnt">OK</SPAN>
};
</PRE>

<INS>-- end example ]</INS>

</BLOCKQUOTE>

<P>The above resolution allows the following example:</P>

<PRE>
  template&lt;class ... Us&gt;
  struct S {
   template&lt;class T&gt;
   friend class C&lt;T, Us&gt;::Nested...;
  };
</PRE>

<P>CWG was not convinced the above example was intended to be
supported by paper P2893R3, which introduced pack expansions for
friend declarations.</P>

<P><B>Proposed resolution (2024-08-16):</B></P>

<P>(This is not a DR.)</P>

<P>(<A HREF="cwg_active.html#2862">Issue 2862</A> modifies the same paragraph.)</P>

<P>Change in 13.1 [<A href="https://wg21.link/temp.pre#5">temp.pre</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

In a <I>template-declaration</I>, explicit specialization, or explicit
instantiation, the <I>init-declarator-list</I> in the declaration
shall contain at most one declarator. When such a declaration is used
to declare a class template, no declarator is permitted.
<INS>In a <I>template-declaration</I> whose <I>declaration</I> is
a <I>friend-type-declaration</I>,
the <I>friend-type-specifier-list</I> shall consist of exactly
one <I>friend-type-specifier</I> that is not a pack expansion.  [
Example:</INS>

<PRE class="ins">
template&lt;class ...&gt;
struct C {
  struct Nested { };
};

template&lt;class ... Us&gt;
struct S {
  template &lt;typename ...Ts&gt;
  friend class C&lt;Ts&gt;::Nested...;     //<SPAN CLASS="cmnt"> error</SPAN>
  friend class C&lt;Us&gt;::Nested...;     // <SPAN CLASS="cmnt">OK</SPAN>
};
</PRE>

<INS>-- end example ]</INS>

</BLOCKQUOTE>

<P><B>CWG 2024-08-16</B></P>

<P>The proposed resolution above disallows a few examples from paper
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2893r3.html">P2893R3</A>
(Variadic friends), such as
</P>

<PRE>
  template&lt;class... Ts&gt;
  struct VS {
    template&lt;class U&gt;
    friend class C&lt;Ts&gt;::Nested...; //<SPAN CLASS="cmnt"> now ill-formed</SPAN>
  };
</PRE>

<P>The adopted wording for P2893R3 makes
the <I>friend-type-specifier</I> (not the
entire <I>template-declaration</I>) the pattern that is expanded by
the pack expansion, leading to the expansion
</P>

<PRE>
  struct VS&lt;T1, T2, T3&gt; {
    template&lt;class U&gt;
    friend class C&lt;T1&gt;::Nested, class C&lt;T2&gt;::Nested, class C&lt;T3&gt;::Nested;
  };
</PRE>

<P>However, that violates the principle that
a <I>template-declaration</I> declares exactly one entity
(see <A HREF="cwg_active.html#2862">issue 2862</A>).</P>

<P>As an aside, the paper as adopted misrepresents the status of
members of dependent types, which are covered by
13.7.5 [<A href="https://wg21.link/temp.friend#5">temp.friend</A>] paragraph 5.</P>

<P>CWG welcomes a paper making the template friend cases valid, but
such a facility would appear to require substantial changes to the
normative wording, which a core issue is not equipped for.</P>

<P>CWG asks EWG to consent to the reduction in scope for the variadic
friends facility, via paper issue
<A HREF="https://github.com/cplusplus/papers/issues/2032">cplusplus/papers#2032</A>.</P>

<P><B>CWG 2025-06-16</B></P>

<P>EWG agrees with the reduction in scope for the variadic friends
facility, as proposed above.</P>

<BR><BR><HR>
<A NAME="2617"></A><H4>2617.
  
Default template arguments for template members of non-template classes
</H4>
<B>Section: </B>13.2&#160; [<A href="https://wg21.link/temp.param">temp.param</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2022-08-22<BR>




<P>Consider:</P>

<PRE>
struct S {
  template&lt;typename&gt; void f();
};

template&lt;typename = int&gt; void S::f() { }   // ok?
</PRE>

<P>There is implementation divergence in the treatment of this
example. The relevant wording appears to be 13.2 [<A href="https://wg21.link/temp.param#12">temp.param</A>] paragraph 12:</P>

<BLOCKQUOTE>

A default <I>template-argument</I> shall not be specified in
the <I>template-parameter-list</I>s of the definition of a member of a
class template that appears outside of the member's class.

</BLOCKQUOTE>

<P>However, the example above deals with a member of an ordinary
class, not a class template, but it is not clear why there should be a
difference between a member template of a class template and a member
template of a non-template class.</P>

<P>Alternatively, it is not clear why the example above should be
treated differently from a non-member function template, e.g.,</P>

<PRE>
template&lt;typename&gt; void f();
template&lt;typename = int&gt; void f() { }
</PRE>

<P>which is explicitly permitted.</P>

<P><B>Proposed resolution:</B></P>

<P>Change in 13.2 [<A href="https://wg21.link/temp.param#10">temp.param</A>] paragraph 10 as follows:</P>

<BLOCKQUOTE>

... A default <I>template-argument</I> may be specified in a template
declaration.  A default <I>template-argument</I> shall not be
specified in the <I>template-parameter-list</I>s of the definition of
a member of a <DEL>class template</DEL> <INS>templated class C</INS>
that appears outside of the <DEL>member's class</DEL>
<INS><I>class-specifier</I> of C</INS>.  A default
<I>template-argument</I> shall not be specified in a friend class
template declaration. If a friend function template declaration D
specifies a default <I>template-argument</I>, that declaration shall
be a definition and there shall be no other declaration of the
function template which is reachable from D or from which D is
reachable.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2589"></A><H4>2589.
  
Context of access checks during constraint satisfaction checking
</H4>
<B>Section: </B>13.5.2.3&#160; [<A href="https://wg21.link/temp.constr.atomic">temp.constr.atomic</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2019-10-02<BR>




<P>Consider:</P>

<PRE>
  template&lt;class T&gt; concept ctible = requires { T(); };

  class A {
    template &lt;class T&gt; friend struct B;
    A();
  };

  template &lt;class T&gt; struct B;
  template &lt;ctible T&gt; struct B&lt;T&gt; { T t; };
  B&lt;A&gt; b;  // #1

  template &lt;class T&gt; struct C { };
  template &lt;ctible T&gt; struct C&lt;T&gt; { T t; };
  C&lt;A&gt; c;  // #2
</PRE>

<P>Should the context of instantiation be considered for satisfaction
checking? If satisfaction checking were always performed in an unrelated
context, neither partial specialization is used, and #1 would be
ill-formed (because <TT>B</TT> is incomplete), but #2 would be
well-formed. If the satisfaction checking were performed in the context
of the constrained declaration, #1 would be well-formed and #2 would
be ill-formed, no diagnostic required, because the validity
of <TT>A()</TT> is different in that context.  That rule, however,
could also consider the context, in which case #2 would also be
well-formed.</P>

<P>The decision affects the amount of caching that an implementation
can perform.</P>

<P>Subclause 13.5.2.3 [<A href="https://wg21.link/temp.constr.atomic#3">temp.constr.atomic</A>] paragraph 3 should be
clarified one way or another:</P>

<BLOCKQUOTE>

To determine if an atomic constraint is satisfied, the parameter
mapping and template arguments are first substituted into its
expression. If substitution results in an invalid type or expression,
the constraint is not satisfied. Otherwise, the lvalue-to-rvalue
conversion (7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]) is performed if necessary, and
E shall be a constant expression of type bool. The constraint is
satisfied if and only if evaluation of E results in true.  If, at
different points in the program, the satisfaction result is different
for identical atomic constraints and template arguments, the program
is ill-formed, no diagnostic required.

</BLOCKQUOTE>

<P><B>Proposed resolution [SUPERSEDED]:</B></P>

<P>Change in 13.5.2.3 [<A href="https://wg21.link/temp.constr.atomic#3">temp.constr.atomic</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

To determine if an atomic constraint is <I>satisfied</I>, the
parameter mapping and template arguments are first substituted into
its expression. If substitution results in an invalid type or
expression, the constraint is not satisfied<INS>; access checking is
performed in the context in which the <I>constraint-expression</I>
or <I>requires-expression</I> appears</INS>. Otherwise, the
lvalue-to-rvalue conversion (7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]) is performed
if necessary, and E shall be a constant expression of type bool. ...

</BLOCKQUOTE>

<P><B>Additional notes (December, 2024)</B></P>

<P>Reflector review yielded an improved resolution.

</P>

<P><B>Proposed resolution [SUPERSEDED]:</B></P>

<P>Append a new paragraph after 11.8.1 [<A href="https://wg21.link/class.access.general#9">class.access.general</A>] paragraph 9:</P>

<BLOCKQUOTE>

<P>Access for a default template-argument (13.2 [<A href="https://wg21.link/temp.param">temp.param</A>]) is
checked in the context in which it appears rather than at any points
of use of it.  [<I>Example 5:</I> ... &#8212;<I>end example</I>]</P>

<P class="ins">

Access for an atomic constraint is checked in the context in which its
expression appears, or for an immediately-declared constraint, in the
context where its <I>type-constraint</I> appears, rather than at any point
where its satisfaction is checked.
[ Example:</P>
<PRE class="ins">
  template&lt;class T&gt; concept ctible = requires { T(); };

  class A {
    template&lt;class T&gt; friend struct B;
    A();
  };

  template&lt;class T&gt; struct B;
  template&lt;ctible T&gt; struct B&lt;T&gt; { T t; };
  B&lt;A&gt; b;                    //<SPAN CLASS="cmnt"> error: uses incomplete primary template of </SPAN>B

  template&lt;class T&gt; struct C { };
  template&lt;ctible T&gt; struct C&lt;T&gt; { T t; };
  C&lt;A&gt; c;                    //<SPAN CLASS="cmnt"> OK, not using the partial specialization</SPAN>

  template&lt;typename T, bool b&gt; concept C = b;
  class U { static constexpr bool enabled = true; friend struct X; };
  struct X {
   template&lt;typename U, C&lt;U::enabled&gt; V&gt; struct A {};
  };
  struct Y {
   template&lt;typename U, C&lt;U::enabled&gt; V&gt; struct A {};
  };
  X::A&lt;U, int&gt; x;    // <SPAN CLASS="cmnt">OK</SPAN>
  Y::A&lt;U, int&gt; y;    // <SPAN CLASS="cmnt">error: cannot access </SPAN>U::enabled
</PRE>
<P class="ins">--end example ]</P>
</BLOCKQUOTE>

<P><B>Additional notes (December, 2024)</B></P>

<P>The resolution was amended.</P>

<P><B>Proposed resolution [SUPERSEDED]:</B></P>

<P>Append a new paragraph after 11.8.1 [<A href="https://wg21.link/class.access.general#9">class.access.general</A>] paragraph 9:</P>

<BLOCKQUOTE>

<P>Access for a default template-argument (13.2 [<A href="https://wg21.link/temp.param">temp.param</A>]) is
checked in the context in which it appears rather than at any points
of use of it.  [<I>Example 5:</I> ... &#8212;<I>end example</I>]</P>

<P class="ins">

Access for an atomic constraint is checked in a context unrelated to
any class or function.
[ Example:</P>
<PRE class="ins">
  template&lt;bool B&gt; concept C = B;

  struct A {
    template&lt;typename T&gt; void f() requires C&lt;T::value&gt;;
  };
  struct B : A {
    using A::f;
    template&lt;typename T&gt; void f() requires C&lt;T::value&gt; &amp;&amp; true;
  };

  class X { static constexpr bool value = true; friend struct A; };
  void g() {
    B().f&lt;X&gt;();    // error: no viable function
  }
</PRE>
<P class="ins">--end example ]</P>
</BLOCKQUOTE>

<P><B>Additional notes (January, 2025)</B></P>



<P>See also <A HREF="cwg_defects.html#2789">issue 2789</A>, but that issue applies to
non-templates only.</P>

<P><U>Possible resolution:</U></P>

<P>Append a new paragraph after 11.8.1 [<A href="https://wg21.link/class.access.general#9">class.access.general</A>] paragraph 9:</P>

<BLOCKQUOTE>

<P>Access for a default template-argument (13.2 [<A href="https://wg21.link/temp.param">temp.param</A>]) is
checked in the context in which it appears rather than at any points
of use of it.  [<I>Example 5:</I> ... &#8212;<I>end example</I>]</P>

<P class="ins">

Access for a parameter mapping is checked in a context unrelated to
any class or function.
[ Example:</P>
<PRE class="ins">
  template&lt;bool B&gt; concept C = B;

  struct A {
    template&lt;typename T&gt; void f() requires C&lt;T::value&gt;;
  };
  struct B : A {
    using A::f;
    template&lt;typename T&gt; void f() requires C&lt;T::value&gt; &amp;&amp; true;
  };

  class X { static constexpr bool value = true; friend struct A; };
  void g() {
    B().f&lt;X&gt;();    // error: no viable function
  }
</PRE>
<P class="ins">--end example ]</P>
</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2916"></A><H4>2916.
  
Variable template partial specializations should not be declared <TT>static</TT>
</H4>
<B>Section: </B>13.7.6&#160; [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2024-07-24<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/580">#580</A>.)</P>



<P>
There appears to be no prohibition on applying the <TT>static</TT>
storage class specifier to a variable template partial specialization.
However, 6.7 [<A href="https://wg21.link/basic.link">basic.link</A>] clearly says that the name of the
template has linkage (not its specializations).  Implementations give
specializations instantiated from a <TT>static</TT> partial
specialization internal linkage even if the template has external
linkage.  This is undesirable.
</P>

<P><B>Proposed resolution (approved by CWG 2024-08-16): [SUPERSEDED]</B></P>

<P>Add before 13.7.6.1 [<A href="https://wg21.link/temp.spec.partial.general#10">temp.spec.partial.general</A>] paragraph 10 as follows:</P>

<BLOCKQUOTE>

<P class="ins">
A partial specialization declaration for a variable template shall not
have the <I>storage-class-specifier</I> <TT>static</TT>.
</P>

<P>
The usual access checking rules do not apply to non-dependent names
used to specify template arguments of the <I>simple-template-id</I> of
the partial specialization. ...
</P>
</BLOCKQUOTE>

<P><B>Additional notes (August, 2024)</B></P>

<P>If the primary template is declared <TT>static</TT>, the least
breakage of existing code occurs if the partial specialization is
required to also be declared <TT>static</TT>.</P>

<P><U>Possible resolution:</U></P>

<P>Add before 13.7.6.1 [<A href="https://wg21.link/temp.spec.partial.general#10">temp.spec.partial.general</A>] paragraph 10 as follows:</P>

<BLOCKQUOTE>

<P class="ins">
A partial specialization declaration for a variable template shall
give its name the same linkage as the declaration of the primary
template.  A partial specialization declaration for a static data
member template shall have the <I>storage-class-specifier</I>
<TT>static</TT>.
</P>

<P>
The usual access checking rules do not apply to non-dependent names
used to specify template arguments of the <I>simple-template-id</I> of
the partial specialization. ...
</P>
</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2834"></A><H4>2834.
  
Partial ordering and explicit object parameters
</H4>
<B>Section: </B>13.7.7.3&#160; [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-12-02<BR>




<P>Consider:</P>

<PRE>
  template &lt;typename T&gt;
  struct A {
    T f(this auto, auto);   //<SPAN CLASS="cmnt"> #1</SPAN>
    int f(auto);            //<SPAN CLASS="cmnt"> #2</SPAN>
  };
  int main() {
    A&lt;int&gt;().f(42);
  }
</PRE>

<P>There is implementation divergence in the handling of this example:
Clang and MSVC consider the example ambiguous, EDG chooses #1.</P>

<P><B>Proposed resolution (reviewed by CWG 2024-01-19):</B></P>

<P>Change in 13.7.7.3 [<A href="https://wg21.link/temp.func.order#3">temp.func.order</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

Each function template M that is a member function <INS>with no
explicit object parameter</INS> is considered to have a new first
parameter of type X(M), described below, inserted in its function
parameter list. If exactly one of the function templates was
considered by overload resolution via a rewritten candidate
(12.2.2.3 [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]) with a reversed order of parameters,
then the order of the function parameters in its transformed template
is reversed. For a function template M with <I>cv-qualifier</I>s cv
that is a <INS>non-static</INS> member of a class A:

<UL>
<LI>The type X(M) is &#8220;rvalue reference to cv A&#8221; if the
optional <I>ref-qualifier</I> of M is &amp;&amp; or if M has
no <I>ref-qualifier</I> and the positionally-corresponding parameter
of the other transformed template has rvalue reference type; if this
determination depends recursively upon whether X(M) is an rvalue
reference type, it is not considered to have rvalue reference
type.</LI>
<LI>Otherwise, X(M) is &#8220;lvalue reference to cv A&#8221;.</LI>
</UL>

<INS>For a function template M that is a static member of a class A:</INS>
<UL class="ins">
<LI>The type X(M) is the type of the object parameter of the other
transformed template, if any.</LI>
<LI>Otherwise, no new first parameter is inserted.</LI>
</UL>

[<I>Note 2:</I> This allows a non-static member to be ordered with
respect to a <INS>static or</INS> non-member function and for the
results to be equivalent to the ordering of two equivalent
non-members. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P><B>CWG 2024-01-19</B></P>

<P>It seems #2 should be chosen, because it is more specialized than #1.</P>

<BR><BR><HR>
<A NAME="1602"></A><H4>1602.
  
Linkage of specialization vs linkage of template arguments
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-09<BR>




<P>The Standard does not appear to specify the linkage of a template
specialization.  13.9.2 [<A href="https://wg21.link/temp.inst#11">temp.inst</A>] paragraph 11 does say,</P>

<BLOCKQUOTE>

Implicitly instantiated class and function template specializations
are placed in the namespace where the template is defined.

</BLOCKQUOTE>

<P>which could be read as implying that the specialization has the
same linkage as the template itself.  Implementation practice seems to
be that the weakst linkage of the template and the arguments is used
for the specialization.</P>

<P><B>Additional notes (February, 2023)</B></P>

<P>Template specializations do not have linkage.</P>

<BR><BR><HR>
<A NAME="2808"></A><H4>2808.
  
Explicit specialization of defaulted special member function
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2023-09-21<BR>




<P>Consider:</P>

<PRE>
  template&lt;typename T&gt; struct S {
    S(const S&amp;) = default;
    S&amp; operator=(const S&amp;) = default;
    int n;
  };

  //<SPAN CLASS="cmnt"> Are the explicit specializations OK?</SPAN>
  template&lt;&gt; S&lt;int&gt;::S(const S&amp;) noexcept { }
  template&lt;&gt; S&lt;int&gt;&amp; S&lt;int&gt;::operator=(const S&amp; other) noexcept {
    return *this;
  }
</PRE>

<P>If the explicit specialization were allowed, would the answer
to <TT>std::is_trivially_copyable&lt;S&lt;int&gt;&gt;</TT> change?
What is <TT>decltype(&amp;S::operator=)</TT> (the defaulted definition
is <TT>noexcept</TT>, yet no instantiation or implicit definition is
triggered)?</P>

<P><B>Proposed resolution (2023-10-20) [SUPERSEDED]:</B></P>

<P>Change in 13.9.2 [<A href="https://wg21.link/temp.inst#3">temp.inst</A>] paragraph 3 and add bullets as follows:</P>

<BLOCKQUOTE>

The implicit instantiation of a class template specialization causes
<UL>
<LI>the implicit instantiation of the declarations, but not of the
definitions, of the <DEL>non-deleted</DEL> <INS>user-provided</INS>
class member functions, member classes, scoped member enumerations,
static data members, member templates, and friends; and
</LI>

<LI>the implicit instantiation of the definitions of
<UL>
<LI>
<INS>defaulted and</INS> deleted member functions <INS>as
defaulted (9.6.2 [<A href="https://wg21.link/dcl.fct.def.default">dcl.fct.def.default</A>]) or deleted
(9.6.3 [<A href="https://wg21.link/dcl.fct.def.delete">dcl.fct.def.delete</A>])</INS>,</LI>
<LI>unscoped member enumerations, and</LI>
<LI>member anonymous unions.</LI>
</UL>
<INS>[ Note: The implicit instantiation determines whether a defaulted
function is deleted, but a non-deleted defaulted function is
implicitly defined only when it is odr-used or needed for constant
evaluation. -- end note ]</INS>
</LI>
</UL>
The implicit instantiation of a class template specialization does not
cause the implicit instantiation of default arguments
or <I>noexcept-specifier</I>s of the class member functions.

</BLOCKQUOTE>

<P><B>Additional notes (October, 2023)</B></P>

<P>It is desirable to require a diagnostic for such attempted explicit
specializations.</P>

<P>Furthermore, there are situations where the "potentially-throwing"
property of a non-deleted function is queried:</P>

<PRE>
  template&lt;int...&gt;
  struct C {
    //<SPAN CLASS="cmnt"> This class has no eligible copy assignment operator at all.</SPAN>
    void operator=(const C&amp;) requires false;
    void operator=(int) noexcept;
    operator int() const;
  };

  void f(C&lt;&gt; &amp;c) {
    c = c;        //<SPAN CLASS="cmnt"> Convert to int, then construct from int.</SPAN>
  }

  struct D {
    C&lt;&gt; c;
  };

  bool g(D d) {
    return noexcept(d = d);     //<SPAN CLASS="cmnt"> #1. If this is valid, what does it return?</SPAN>
  }

  struct E {
    C&lt;&gt; c;
    E &amp;operator=(const E &amp;o) { c = o.c; }
  };
</PRE>

<P>All major implementations agree that <TT>E</TT> is valid. However,
clang, gcc, and EDG delete the copy assignment operator of <TT>D</TT>,
thus sidestepping the question at #1.  (MSVC accepts, but #1 returns
true despite the potentially-throwing conversion to <TT>int</TT>.)
Apparently, user-defined conversions for the first argument
of <TT>C</TT>'s assignment operator are ignored in implementations
other than MSVC. However, the specification is silent on that.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 13.9.2 [<A href="https://wg21.link/temp.inst#3">temp.inst</A>] paragraph 3 and add bullets as follows:</P>

<BLOCKQUOTE>

The implicit instantiation of a class template specialization causes
<UL>
<LI>the implicit instantiation of the declarations, but not of the
definitions, of the <DEL>non-deleted</DEL> <INS>user-provided</INS>
class member functions, member classes, scoped member enumerations,
static data members, member templates, and friends; and
</LI>

<LI>the implicit instantiation of the definitions of
<UL>
<LI>
<INS>defaulted and</INS> deleted member functions <INS>as
defaulted (9.6.2 [<A href="https://wg21.link/dcl.fct.def.default">dcl.fct.def.default</A>]) or deleted
(9.6.3 [<A href="https://wg21.link/dcl.fct.def.delete">dcl.fct.def.delete</A>])</INS>,</LI>
<LI>unscoped member enumerations, and</LI>
<LI>member anonymous unions.</LI>
</UL>
<INS>[ Note: The implicit instantiation determines whether a defaulted
function is deleted, but a non-deleted defaulted function is
implicitly defined only when it is odr-used or needed for constant
evaluation. -- end note ]</INS>
</LI>
</UL>
The implicit instantiation of a class template specialization does not
cause the implicit instantiation of default arguments
or <I>noexcept-specifier</I>s of the class member functions.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.9.4 [<A href="https://wg21.link/temp.expl.spec#7">temp.expl.spec</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

If a template, a member template or a member of a <INS>templated</INS>
class <DEL>template</DEL> is explicitly specialized, a declaration of
that specialization shall be reachable from every use of that
specialization that would cause an implicit instantiation to take
place, in every translation unit in which such a use occurs; no
diagnostic is required <INS>unless the specialization is for a member
of a templated class whose definition is implicitly instantiated as a
result of the implicit instantiation of the class
(13.9.2 [<A href="https://wg21.link/temp.inst">temp.inst</A>])</INS>. ...

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2847"></A><H4>2847.
  
Constrained explicit specializations of function templates at class scope
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Krystian Stasiowski
 &#160;&#160;&#160;

 <B>Date: </B>2023-12-15<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/482">#482</A>.)</P>

<P>Consider:</P>

<PRE>
  template&lt;typename T&gt;
  concept C = sizeof(T) &gt; sizeof(char);
  template&lt;typename T&gt;
  concept D = sizeof(T) &gt; sizeof(int) ;

  template&lt;typename T&gt;
  struct A 
  {
    template&lt;typename U&gt;
    constexpr int f(U) requires C&lt;U&gt; { return 0; }

    template&lt;&gt;
    constexpr int f(int) requires D&lt;T&gt; { return 1; }
  };

  static_assert(A&lt;int&gt;().f(0) == 0);   // <SPAN CLASS="cmnt">#1</SPAN>
</PRE>

<P>There is substantial implementation variance: GCC does not allow
explicit specializations of function templates at class scope
(contrary to the rule change introduced by <A HREF="cwg_defects.html#727">issue 727</A>), clang rejects them if a <I>trailing-requires-clause</I>
is present, and EDG accepts, but ignores the constraint, causing #1 to
fail.</P>

<P><B>Proposed resolution (reviewed by CWG 2024-03-01) [SUPERSEDED]:</B></P>

<OL>
<LI>
<P>Add a new paragraph before 13.9.4 [<A href="https://wg21.link/temp.expl.spec#8">temp.expl.spec</A>] paragraph 8 as
follows:</P>

<BLOCKQUOTE>

<P class="ins">
An explicit specialization of a function shall not have a
trailing <I>requires-clause</I> (9.3.1 [<A href="https://wg21.link/dcl.decl.general">dcl.decl.general</A>]).  [
Example:</P>

<PRE class="ins">
  template&lt;typename T&gt;
  concept C = sizeof(T) &lt;= sizeof(int);

  template&lt;typename T&gt;
  struct A {
    template&lt;typename U&gt;
    void f(U) requires C&lt;U&gt;;

    template&lt;&gt;
    void f(char);    //<SPAN CLASS="cmnt"> OK</SPAN>

    template&lt;&gt;
    void f(short) requires (sizeof(T) &gt;= 1); //<SPAN CLASS="cmnt"> error: trailing <I>requires-clause</I> not allowed</SPAN>
  };

  template&lt;&gt;
  template&lt;typename U&gt;
  void A&lt;int&gt;::f(U) requires C&lt;U&gt; {} //<SPAN CLASS="cmnt"> OK, explicit specialization is a template</SPAN>
</PRE>

<P class="ins">-- end example ]
</P>

<P>The placement of explicit specialization declarations for function
templates ...</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Add another example at the end of 13.9.4 [<A href="https://wg21.link/temp.expl.spec#15">temp.expl.spec</A>] paragraph 15 as follows:</P>

<BLOCKQUOTE class="ins">

<P>[ Example:</P>

<PRE>
   template&lt;typename T&gt;
   struct D {
     template&lt;typename U&gt;
     static constexpr int f(U);          //<SPAN CLASS="cmnt"> #1</SPAN>

     template&lt;typename U&gt;
     static constexpr int f(U) requires (sizeof(T) == 1);    //<SPAN CLASS="cmnt"> #2</SPAN>

     template&lt;&gt;
     constexpr int f(int)                //<SPAN CLASS="cmnt"> #3</SPAN>
     { return 1; }
   };

   template&lt;&gt; template&lt;typename U&gt;
   constexpr int D&lt;signed char&gt;::f(U) requires (sizeof(signed char) == 1)  //<SPAN CLASS="cmnt"> #4</SPAN> 
   { return 0; }

   static_assert(D&lt;char&gt;::f(0) == 1);          // <SPAN CLASS="cmnt">overload resolution selects #2; #3 is a specialization for #2</SPAN>
   static_assert(D&lt;char[2]&gt;::f(0) == 1);       // <SPAN CLASS="cmnt">overload resolution selects #1; #3 is a specialization for #1</SPAN>
   static_assert(D&lt;signed char&gt;::f(0) == 1);   // <SPAN CLASS="cmnt">overload resolution selects #2; #3 is a specialization for #2</SPAN>
   static_assert(D&lt;signed char&gt;::f(0.0) == 0); // <SPAN CLASS="cmnt">overload resolution selects #2; #4 is a specialization for #2</SPAN>
</PRE>
<P>-- end example ]</P>

</BLOCKQUOTE>
</LI>
</OL>

<P><B>Additional notes (April, 2024)</B></P>

<P>The phrasing "an explicit specialization of a function" does not make sense.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Add a new paragraph before 13.9.4 [<A href="https://wg21.link/temp.expl.spec#8">temp.expl.spec</A>] paragraph 8 as
follows:</P>

<BLOCKQUOTE>

<P class="ins">
An explicit specialization that declares a function shall not have a
trailing <I>requires-clause</I> (9.3.1 [<A href="https://wg21.link/dcl.decl.general">dcl.decl.general</A>]).  [
Example:</P>

<PRE class="ins">
  template&lt;typename T&gt;
  concept C = sizeof(T) &lt;= sizeof(int);

  template&lt;typename T&gt;
  struct A {
    template&lt;typename U&gt;
    void f(U) requires C&lt;U&gt;;

    template&lt;&gt;
    void f(char);    //<SPAN CLASS="cmnt"> OK</SPAN>

    template&lt;&gt;
    void f(short) requires (sizeof(T) &gt;= 1); //<SPAN CLASS="cmnt"> error: trailing <I>requires-clause</I> not allowed</SPAN>
  };

  template&lt;&gt;
  template&lt;typename U&gt;
  void A&lt;int&gt;::f(U) requires C&lt;U&gt; {} //<SPAN CLASS="cmnt"> OK, explicit specialization is a template</SPAN>

  template&lt;&gt;
  template&lt;&gt;
  void A&lt;short&gt;::f(int) requires C&lt;int&gt; {} //<SPAN CLASS="cmnt"> error: trailing <I>requires-clause</I> for a declaration of a non-templated function</SPAN>
</PRE>

<P class="ins">-- end example ]
</P>

<P>The placement of explicit specialization declarations for function
templates ...</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Add another example at the end of 13.9.4 [<A href="https://wg21.link/temp.expl.spec#15">temp.expl.spec</A>] paragraph 15 as follows:</P>

<BLOCKQUOTE class="ins">

<P>[ Example:</P>

<PRE>
   template&lt;typename T&gt;
   struct D {
     template&lt;typename U&gt;
     static constexpr int f(U);          //<SPAN CLASS="cmnt"> #1</SPAN>

     template&lt;typename U&gt;
     static constexpr int f(U) requires (sizeof(T) == 1);    //<SPAN CLASS="cmnt"> #2</SPAN>

     template&lt;&gt;
     constexpr int f(int)                //<SPAN CLASS="cmnt"> #3</SPAN>
     { return 1; }
   };

   template&lt;&gt; template&lt;typename U&gt;
   constexpr int D&lt;signed char&gt;::f(U) requires (sizeof(signed char) == 1)  //<SPAN CLASS="cmnt"> #4</SPAN> 
   { return 0; }

   static_assert(D&lt;char&gt;::f(0) == 1);          // <SPAN CLASS="cmnt">overload resolution selects #2; #3 is a specialization for #2</SPAN>
   static_assert(D&lt;char[2]&gt;::f(0) == 1);       // <SPAN CLASS="cmnt">overload resolution selects #1; #3 is a specialization for #1</SPAN>
   static_assert(D&lt;signed char&gt;::f(0) == 1);   // <SPAN CLASS="cmnt">overload resolution selects #2; #3 is a specialization for #2</SPAN>
   static_assert(D&lt;signed char&gt;::f(0.0) == 0); // <SPAN CLASS="cmnt">overload resolution selects #2; #4 is a specialization for #2</SPAN>
</PRE>
<P>-- end example ]</P>

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2896"></A><H4>2896.
  
Template argument deduction involving exception specifications
</H4>
<B>Section: </B>13.10.3&#160; [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Krystian Stasiowski
 &#160;&#160;&#160;

 <B>Date: </B>2024-05-15<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/537">#537</A>.)</P>

<P>
<A HREF="cwg_defects.html#2355">Core issue 2355</A> added support for
deducing the exception specification of a function template.  However,
implementations uniformly reject the following example:</P>

<PRE>
  template&lt;bool B&gt;
  void f() noexcept(B);   // <SPAN CLASS="cmnt">#1</SPAN>

  template&lt;&gt;
  void f() noexcept;      // <SPAN CLASS="cmnt">explicit specialization of #1?</SPAN>
</PRE>

<P>This is arguably the correct approach, because exception
specifications are instantiated separately and do not cause
substitution failure in the immediate context
(13.10.3.1 [<A href="https://wg21.link/temp.deduct.general">temp.deduct.general</A>]).  For class-scope explicit
specializations, the <I>noexcept-specifier</I> has not even been
parsed, yet.  If we exclude such deduction from function declarations,
we also need to avoid considering the exception specification for partial
ordering, otherwise partial ordering would always fail.</P>

<P>A similar consideration applies to the address-of-function-template case:</P>

<PRE>
  struct A { 
    static constexpr bool x = true;
  };

  template&lt;typename T, typename U&gt;
  void f(T, U*) noexcept(T::x);   //<SPAN CLASS="cmnt"> #1</SPAN>

  template&lt;typename T, typename U&gt;
  void f(T, U) noexcept(T::y);    //<SPAN CLASS="cmnt"> #2</SPAN>

  void(&amp;g)(A, int*) noexcept = f;  // <SPAN CLASS="cmnt">selects #1; not a hard error during deduction for #2</SPAN>
</PRE>

<P><U>Suggested resolution [SUPERSEDED]:</U></P>

<OL>
<LI>
<P>Change in 13.10.3.7 [<A href="https://wg21.link/temp.deduct.decl#1">temp.deduct.decl</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

... In all these cases, P is the <INS>function</INS> type of the
function template being considered as a potential match and A is
either the function type from the declaration or the type of the
deallocation function that would match the placement operator new as
described in
7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>] <INS>, in all cases ignoring the <I>noexcept-specifier</I> (if any) of the function types</INS>.
The deduction is done as described in 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>].

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.10.3.5 [<A href="https://wg21.link/temp.deduct.partial#3">temp.deduct.partial</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

The types used to determine the ordering depend on the context in
which the partial ordering is done:
<UL>
<LI>In the context of a
function call, the types used are those function parameter types for
which the function call has arguments. [ Footnote: ... ]</LI>
<LI>In the context of a
call to a conversion function, the return types of the conversion
function templates are used.</LI>
<LI>In other contexts (13.7.7.3 [<A href="https://wg21.link/temp.func.order">temp.func.order</A>])<INS>,</INS> the
function template's function type <INS>outside of
the <I>noexcept-specifier</I></INS> is used.
</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.10.3.3 [<A href="https://wg21.link/temp.deduct.funcaddr#1">temp.deduct.funcaddr</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Template arguments can be deduced from the type specified when taking
the address of an overload set (12.3 [<A href="https://wg21.link/over.over">over.over</A>]).  If there
is a target, the function template's function type and the target type
are used as the types of P and A, <INS>ignoring the
<I>noexcept-specifier</I> (if any) of both function types,</INS>
and the deduction is done as described in
13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>].  Otherwise, deduction is performed
with empty sets of types P and A.

</BLOCKQUOTE>
</LI>
</OL>

<P><B>CWG 2024-06-14</B></P>

<P>For the last case (address of overload set), the following example
is currently well-formed, but is rendered ill-formed by the suggested
resolution:</P>

<PRE>
  void f(T*);           //<SPAN CLASS="cmnt"> #1</SPAN>
  void f(T) noexcept;   //<SPAN CLASS="cmnt"> #2</SPAN>
  void (&amp;g)(int*) noexcept = f;   //<SPAN CLASS="cmnt"> status quo: selects #2; suggested resolution: selects #1 (more specialized) and fails the initialization</SPAN>
</PRE>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 12.3 [<A href="https://wg21.link/over.over#5">over.over</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

All functions with associated constraints that are not satisfied
(13.5.3 [<A href="https://wg21.link/temp.constr.decl">temp.constr.decl</A>]) are eliminated from the set of selected
functions. <INS>Any function template specialization whose exception
specification is originally non-dependent is eliminated from the set
unless the function type of the specialization (after possibly
applying the function pointer conversion (7.3.14 [<A href="https://wg21.link/conv.fctptr">conv.fctptr</A>]))
is identical to the function type of the target type.</INS> If more
than one function in the set remains, all function template
specializations in the set are eliminated if the set also contains a
function that is not a function template specialization. Any given
non-template function F0 is eliminated if the set contains a second
non-template function that is more constrained than F0 according to
the partial ordering rules of 13.5.5 [<A href="https://wg21.link/temp.constr.order">temp.constr.order</A>]. Any given
function template specialization F1 is eliminated if the set contains
a second function template specialization whose function template is
more specialized than the function template of F1 according to the
partial ordering rules of 13.7.7.3 [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]. After such
eliminations, if any, there shall remain exactly one selected
function.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.10.3.7 [<A href="https://wg21.link/temp.deduct.decl#1">temp.deduct.decl</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

... In all these cases, P is the <INS>function</INS> type of the
function template being considered as a potential match and A is
either the function type from the declaration or the type of the
deallocation function that would match the placement operator new as
described in
7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>] <INS>, in all cases ignoring the <I>noexcept-specifier</I> (if any) of the function types</INS>.
The deduction is done as described in 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>].

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.10.3.5 [<A href="https://wg21.link/temp.deduct.partial#3">temp.deduct.partial</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

The types used to determine the ordering depend on the context in
which the partial ordering is done:
<UL>
<LI>In the context of a
function call, the types used are those function parameter types for
which the function call has arguments. [ Footnote: ... ]</LI>
<LI>In the context of a
call to a conversion function, the return types of the conversion
function templates are used.</LI>
<LI>In other contexts (13.7.7.3 [<A href="https://wg21.link/temp.func.order">temp.func.order</A>])<INS>,</INS> the
function template's function type <INS>outside of
the <I>noexcept-specifier</I></INS> is used.
</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.10.3.3 [<A href="https://wg21.link/temp.deduct.funcaddr#1">temp.deduct.funcaddr</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Template arguments can be deduced from the type specified when taking
the address of an overload set (12.3 [<A href="https://wg21.link/over.over">over.over</A>]).  If there
is a target, the function template's function type and the target type
are used as the types of P and A, <INS>ignoring the
<I>noexcept-specifier</I> (if any) of both function types,</INS>
and the deduction is done as described in
13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>].  Otherwise, deduction is performed
with empty sets of types P and A.

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2875"></A><H4>2875.
  
Missing support for round-tripping null pointer values through indirection/address operators
</H4>
<B>Section: </B>C.7.4&#160; [<A href="https://wg21.link/diff.expr">diff.expr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

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




<P>C supports the following, C++ does not (see issues
<A HREF="cwg_closed.html#232">232</A> and <A HREF="cwg_defects.html#2823">2823</A>):</P>
<PRE>
  void f() {
    char *p = 0;
    char *p2 = &amp;*p;       // <SPAN CLASS="cmnt">OK in C, undefined behavior in C++</SPAN>
    int a[5];
    int *q = &amp;a[5];       // <SPAN CLASS="cmnt">OK in C, undefined behavior in C++</SPAN>
  }
</PRE>

<P>This incompatibility should be documented in Annex C.</P>

<P><B>Proposed resolution (approved by CWG 2024-06-26):</B></P>

<P>Add a new paragraph to C.7.4 [<A href="https://wg21.link/diff.expr">diff.expr</A>] as follows:</P>

<BLOCKQUOTE class="ins">

<B>Affected subclause:</B> 7.6.2.2 [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]<BR>
<B>Change:</B> In certain contexts, taking the address of a
dereferenced null or past-the-end pointer value is well-defined in C
(and yields the original pointer value), but results in undefined
behavior in C++.
For example:
<PRE>
  void f() {
    char *p = 0;
    char *p2 = &amp;*p;   // <SPAN CLASS="cmnt">well-defined in C, undefined behavior in C++</SPAN>
    char *p3 = &amp;p[0]; // <SPAN CLASS="cmnt">well-defined in C, undefined behavior in C++</SPAN>
    int a[5];
    int *q = &amp;a[5];   // <SPAN CLASS="cmnt">well-defined in C, undefined behavior in C++</SPAN>
  }
</PRE>
<B>Rationale:</B> Consistent treatment of lvalues in C++.<BR>
<B>Effect on original feature:</B> Well-formed and well-defined C code exhibits undefined behavior in C++.<BR>
<B>Difficulty of converting:</B> Syntactic transformation to pointer arithmetic and
possible addition of a check for null pointer values.<BR>
<B>How widely used:</B> Occasionally.
</BLOCKQUOTE>

<P><B>CWG 2024-06-26</B></P>

<P>Implementations are required to diagnose undefined behavior in
constant expressions.  The issue is kept in review status to allow
time for submitting a paper to EWG to make the <TT>&amp;a[5]</TT> case
well-defined.  See also C23 6.5.3.2p3.</P>
		  
<BR><BR><BR><BR><HR>
<A NAME="Drafting%20Status"></A><H3>Issues with "Drafting" Status</H3>
<HR>
<A NAME="2632"></A><H4>2632.
  
'user-declared' is not defined
</H4>
<B>Section: </B>Clause 3&#160; [<A href="https://wg21.link/intro.defs">intro.defs</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Anoop Rana
 &#160;&#160;&#160;

 <B>Date: </B>2022-09-07<BR>


<P>The term "user-declared" is used 30 times throughout the standard,
but it is not defined.</P>

<P><B>Proposed resolution:</B></P>

<P>Add a new entry after 3.66 [<A href="https://wg21.link/defns.unspecified">defns.unspecified</A>] as follows:</P>

<BLOCKQUOTE class="ins">

<P><B>user-declared [defns.user.declared]</B></P>

<P>not implicitly declared</P>

</BLOCKQUOTE>

<P><B>CWG 2024-06-14</B></P>

<P>The proposed resolution does not work, because utterances such as
"a default constructor is implicitly declared if no constructor is
user-declared" become circular.  The eventual definition should
address the question whether constructors inherited from a base class
are considered user-declared in the inheriting class.</P>

<BR><BR><HR>
<A NAME="1529"></A><H4>1529.
  
Nomenclature for variable vs reference non-static data member
</H4>
<B>Section: </B>6.1&#160; [<A href="https://wg21.link/basic.pre">basic.pre</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-07-24<BR>




<P>According to 6.1 [<A href="https://wg21.link/basic.pre#6">basic.pre</A>] paragraph 6,</P>

<BLOCKQUOTE>

A <I>variable</I> is introduced by the declaration of a reference other than
a non-static data member or of an object.

</BLOCKQUOTE>

<P>In other words, non-static data members of reference type are not
variables.  This complicates the wording in a number of places, where
the text refers to &#8220;variable or data member,&#8221; presumably to
cover the reference case, but that phrasing could lead to the mistaken
impression that all data members are not variables.  It would be better
if either there were a term for the current phrase &#8220;variable or
data member&#8221; or if there were a less-unwieldy term for
&#8220;non-static data member of reference type&#8221; that could be
used in place of &#8220;data member&#8221; in the current phrasing.</P>

<BR><BR><HR>
<A NAME="2480"></A><H4>2480.
  
Lookup for enumerators in modules
</H4>
<B>Section: </B>6.5.1&#160; [<A href="https://wg21.link/basic.lookup.general">basic.lookup.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2021-02-12<BR>




<P>According to 6.5.1 [<A href="https://wg21.link/basic.lookup.general">basic.lookup.general</A>] paragraphs 2-3,</P>

<BLOCKQUOTE>

<P>...A declaration <I>X</I> precedes a program point <I>P</I>
in a translation unit <I>L</I> if <I>P</I>
follows <I>X</I>, <I>X</I> inhabits a class scope and is
reachable from <I>P</I>, or else...</P>

<P>A single search in a scope <I>S</I> for a name <I>N</I>
from a program point <I>P</I> finds all declarations that
precede <I>P</I> to which any name that is the same
as <I>N</I> (6.1 [<A href="https://wg21.link/basic.pre">basic.pre</A>]) is bound
in <I>S</I>.</P>

</BLOCKQUOTE>

<P>These rules cause problems for finding enumerators when
qualified by an exported name of its enumeration type,
unlike a member of a class. For example:</P>

<PRE>
  export module A;
  enum class X { x };
  enum Y { y };

  export module B;
  import A;
  export using XB = X;
  export using YB = Y;

  //<SPAN CLASS="cmnt"> client code</SPAN>
  import B;
  int main() {
    XB x = XB::x; //<SPAN CLASS="cmnt"> should be OK because definition of </SPAN>X<SPAN CLASS="cmnt"> is reachable, even</SPAN>
                  //<SPAN CLASS="cmnt"> though </SPAN>A<SPAN CLASS="cmnt"> is not imported</SPAN>
    YB y = YB::y; //<SPAN CLASS="cmnt"> similarly OK</SPAN>
    YB z = ::y;   //<SPAN CLASS="cmnt"> error, because </SPAN>y<SPAN CLASS="cmnt"> from module </SPAN>A<SPAN CLASS="cmnt"> is not visible</SPAN>
  }
</PRE>

<P>It would seem that this problem could be addressed by changing
&#8220;inhabits a class scope&#8221; to &#8220;does not
inhabit a namespace scope.&#8221;</P>

<BR><BR><HR>
<A NAME="2926"></A><H4>2926.
  
Lookup context for dependent qualified names
</H4>
<B>Section: </B>6.5.5.1&#160; [<A href="https://wg21.link/basic.lookup.qual.general">basic.lookup.qual.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2024-08-16<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/599">#599</A>.)</P>

<P>Consider:</P>

<PRE>
  template &lt;typename U&gt;
  constexpr bool foo = U::b;

  template &lt;class T&gt;
  struct A {
    A() requires(foo&lt;A&gt;) {}
    static constexpr bool b = true;
  };
  A&lt;int&gt; a;
</PRE>
	       
<P>All implementation accept, but there is no normative wording
prescribing the lookup context for <TT>U::b</TT>.</P>

<P><B>Proposed resolution (approved by CWG 2024-09-13):</B></P>

<P>Change in 6.5.5.1 [<A href="https://wg21.link/basic.lookup.qual.general#3">basic.lookup.qual.general</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<I>Qualified name lookup</I> in a class, namespace, or enumeration
performs a search of the scope associated with it
(6.5.2 [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]) except as specified below. Unless
otherwise specified, a qualified name undergoes qualified name lookup
in its lookup context from the point where it appears unless the
lookup context <DEL>either</DEL>
<UL>
<LI>is dependent and is not the current instantiation
(13.8.3.2 [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>])<INS>, in which case the lookup is done from the point of instantiation (13.8.4.1 [<A href="https://wg21.link/temp.point">temp.point</A>]),</INS> or</LI>
<LI>is <DEL>not a class or class template</DEL> <INS>a type that is
not a class, in which case unqualified lookup
is performed from the point where it appears</INS>. <INS>[ Note: Such a
qualified name can be used to name a destructor
(7.5.5.5 [<A href="https://wg21.link/expr.prim.id.dtor">expr.prim.id.dtor</A>]). -- end note ]</INS>
</LI>
</UL>
If nothing is found by qualified lookup for a
member-qualified name that is the terminal name
(7.5.5.2 [<A href="https://wg21.link/expr.prim.id.unqual">expr.prim.id.unqual</A>]) of a <I>nested-name-specifier</I> and
is not dependent, it undergoes unqualified lookup.

</BLOCKQUOTE>

<P><B>Additional notes (September, 2024)</B></P>

<P>The proposed wording appears to make the following example
unintentionally well-formed:</P>

<PRE>
  int n;
  using T = int;
  int m = T::n;
</PRE>

<P><B>CWG 2024-11-08</B></P>

<P>The example above is already ill-formed per
6.5.5.1 [<A href="https://wg21.link/basic.lookup.qual.general#1">basic.lookup.qual.general</A>] paragraph 1.</P>

<BR><BR><HR>
<A NAME="2324"></A><H4>2324.
  
Size of base class subobject
</H4>
<B>Section: </B>6.8.2&#160; [<A href="https://wg21.link/intro.object">intro.object</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2017-02-27<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf#GB9">P0488R0 comment
  GB&#160;9<BR></A>

<P>According to 6.8.2 [<A href="https://wg21.link/intro.object#7">intro.object</A>] paragraph 7,</P>

<BLOCKQUOTE>

Unless it is a bit-field (11.4.10 [<A href="https://wg21.link/class.bit">class.bit</A>]), a most
derived object shall have a nonzero size and shall occupy one or
more bytes of storage. Base class subobjects may have zero size.

</BLOCKQUOTE>

<P>Base class objects of zero size is a misleading term, as
<TT>sizeof</TT> such an object is non-zero. Size should not be a
property of an object, rather of a type.</P>

<BR><BR><HR>
<A NAME="2325"></A><H4>2325.
  
<TT>std::launder</TT> and reuse of character buffers
</H4>
<B>Section: </B>6.8.2&#160; [<A href="https://wg21.link/intro.object">intro.object</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2017-02-27<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf#CA12">P0488R0 comment
  CA&#160;12<BR></A>



<P>The status of the following code should be explicitly
indicated in the Standard to avoid surprise:</P>

<PRE>
  #include &lt;new&gt;
  int bar() {
    alignas(int) unsigned char space[sizeof(int)];
    int *pi = new (static_cast&lt;void *&gt;(space)) int;
    *pi = 42;
    return [=]() mutable {
      return   *std::launder(reinterpret_cast&lt;int *&gt;(space)); }();
   }
</PRE>

<P>In particular, it appears that the call
to <TT>std::launder</TT> has undefined behaviour because the
captured copy of space is not established to provide storage for
an object of type <TT>int</TT> (sub
6.8.2 [<A href="https://wg21.link/intro.object#1">intro.object</A>] paragraph 1).  Furthermore, the code has
undefined behaviour also because it attempts to access the stored
value of the <TT>int</TT> object through a glvalue of an array
type other than one of the ones allowed by sub
7.2.1 [<A href="https://wg21.link/basic.lval#8">basic.lval</A>] paragraph 8.</P>

<BR><BR><HR>
<A NAME="2469"></A><H4>2469.
  
Implicit object creation vs constant expressions
</H4>
<B>Section: </B>6.8.2&#160; [<A href="https://wg21.link/intro.object">intro.object</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2020-12-07<BR>


<P>It is not intended that implicit object creation, as described
in 6.8.2 [<A href="https://wg21.link/intro.object#10">intro.object</A>] paragraph 10, should occur during
constant expression evaluation, but there is currently no wording
prohibiting it.</P>

<P><B>Notes from the February, 2021 teleconference:</B></P>

<P>This issue was occasioned by <A HREF="cwg_defects.html#2464">issue 2464</A>, which is also the subject of
<A HREF="https://cplusplus.github.io/LWG/issue3495">LWG issue 3495</A>.
CWG reviewed the proposed resolution and agrees with it.
The intended approach for this issue is to wait for LWG to
resolve that issue, then add a note in the core section
pointing out the implications of that requirement for
implicit object creation.</P>

<BR><BR><HR>
<A NAME="3029"></A><H4>3029.
  
Confusing note about ordinary character types for aligned memory areas
</H4>
<B>Section: </B>6.8.3&#160; [<A href="https://wg21.link/basic.align">basic.align</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Xavier Bonaventura
 &#160;&#160;&#160;

 <B>Date: </B>2025-03-20<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/687">#687</A>.)</P>

<P>Subclause 6.8.3 [<A href="https://wg21.link/basic.align#6">basic.align</A>] paragraph 6 specifies:</P>

<BLOCKQUOTE>

The alignment requirement of a complete type can be queried using an
alignof expression (7.6.2.6 [<A href="https://wg21.link/expr.alignof">expr.alignof</A>]).  Furthermore, the
narrow character types (6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]) shall have the
weakest alignment requirement.  [<I>Note 2:</I> This enables the
ordinary character types to be used as the underlying type for an
aligned memory area (9.13.2 [<A href="https://wg21.link/dcl.align">dcl.align</A>]). &#8212;<I>end
note</I>]

</BLOCKQUOTE>

<P>The note has multiple problems: First, the note talks about
"ordinary character types" (including <TT>char8_t</TT>; see
6.9.2 [<A href="https://wg21.link/basic.fundamental#7">basic.fundamental</A>] paragraph 7), whereas the immediately
preceding sentence is limited to "narrow character types".  Second,
due to memory model concerns, <TT>signed char</TT> is not suitable for
aligned memory areas providing storage for other objects.</P>

<P><B>Proposed resolution (no objections during CWG reflector review starting 2025-05-11):</B></P>

<P>Change in 6.8.3 [<A href="https://wg21.link/basic.align#6">basic.align</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

The alignment requirement of a complete type can be queried using an
alignof expression (7.6.2.6 [<A href="https://wg21.link/expr.alignof">expr.alignof</A>]).  Furthermore, the
narrow character types (6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]) shall have the
weakest alignment requirement.  [<I>Note 2:</I> <DEL>This enables the
ordinary character types to</DEL> <INS>The type <TT>unsigned char</TT>
can</INS> be used as the underlying type for an aligned memory area
(9.13.2 [<A href="https://wg21.link/dcl.align">dcl.align</A>]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P><B>Additional notes (June, 2025)</B></P>

<P>The "underlying type" is for enumerations and derived integer types
and thus is the wrong phrase to use here.</P>

<BR><BR><HR>
<A NAME="1530"></A><H4>1530.
  
Member access in out-of-lifetime objects
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Howard Hinnant
 &#160;&#160;&#160;

 <B>Date: </B>2012-07-26<BR>




<P>According to 6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>] paragraphs 5 and 6, a program
has undefined behavior if a pointer or glvalue designating an
out-of-lifetime object</P>

<BLOCKQUOTE>

is used to access a non-static data member or call a non-static member
function of the object

</BLOCKQUOTE>

<P>It is not clear what the word &#8220;access&#8221; means in this
context.  A reasonable interpretation might be using the pointer or
glvalue as the left operand of a class member access expression;
alternatively, it might mean to read or write the value of that
member, allowing a class member access expression that is used only
to form an address or bind a reference.</P>

<P>This needs to be clarified.  A relevant consideration is the
recent adoption of the resolution of <A HREF="cwg_defects.html#597">issue 597</A>,
which eased the former restriction on simple address manipulations
involving out-of-lifetime objects: if base-class offset calculations
are now allowed, why not non-static data member offset calculations?</P>

<P>(See also <A HREF="cwg_defects.html#1531">issue 1531</A> for other uses of
the term &#8220;access.&#8221;)</P>

<P><B>Additional note (January, 2013):</B></P>

<P>A related question is the meaning of the phrase
&#8220;before the constructor begins execution&#8221; in
11.9.5 [<A href="https://wg21.link/class.cdtor#1">class.cdtor</A>] paragraph 1 means:</P>

<BLOCKQUOTE>

For an object with a non-trivial constructor, referring to any
non-static member or base class of the object before the constructor
begins execution results in undefined behavior.

</BLOCKQUOTE>

<P>For example:</P>

<PRE>
  struct DerivedMember { ... };

  struct Base {
    Base(DerivedMember const&amp;);
  };

  struct Derived : Base {
    DerivedMember x;
    Derived() : Base(x) {}
  };

  Derived a;
</PRE>

<P>Is the reference to <TT>Derived::x</TT> in the <I>mem-initializer</I>
valid?</P>

<P><B>Additional note (March, 2013):</B></P>

<P>This clause is phrased in terms of the execution of the constructor.
However, it is possible for an aggregate to have a non-trivial default
constructor and be initialized without executing a constructor.  The
wording needs to be updated to allow for non-constructor initialization
to avoid appearing to imply undefined behavior for an example like:</P>

<PRE>
  struct X {
    std::string s;
  } x = {};
  std::string t = x.s;  //<SPAN CLASS="cmnt"> No constructor called for </SPAN>x<SPAN CLASS="cmnt">: undefined behavior?</SPAN>
</PRE>





<BR><BR><HR>
<A NAME="2863"></A><H4>2863.
  
Unclear synchronization requirements for object lifetime rules
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2024-02-24<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/507">#507</A>.)</P>

<P>Subclause 6.8.4 [<A href="https://wg21.link/basic.life#6">basic.life</A>] paragraph 6 specifies:</P>

<BLOCKQUOTE>

Before the lifetime of an object has started but after the storage
which the object will occupy has been allocated [ Footnote: ... ] or,
after the lifetime of an object has ended and before the storage which
the object occupied is reused or released, ...

</BLOCKQUOTE>

<P>"Before" and "after" are intended to refer to the "happens before"
relation (which is not a total order), but the specific use here does
not properly handle evaluations racing with the start of the lifetime
of an object.</P>

<P><U>Possible resolution (option 1) [SUPERSEDED]:</U></P>

<OL>
<LI>

<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#4">basic.life</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

The properties ascribed to objects and references throughout this
document apply for a given object or reference only during its
lifetime.  [<I>Note 2:</I> In particular, <DEL>before the lifetime of
an object starts and after its lifetime ends</DEL> there are
significant restrictions on the use of <DEL>the</DEL> <INS>an</INS>
object <INS>not within its lifetime</INS>, as described below, in
11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>], and in 11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]. Also,
the behavior of an object under construction and destruction can
differ from the behavior of an object whose lifetime has started and
not ended. 11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>] and 11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]
describe the behavior of an object during its periods of construction
and destruction. &#8212;<I>end note</I>]

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#6">basic.life</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

<DEL>Before the lifetime of an object has started but</DEL> <INS>In an
evaluation that occurs</INS> after the storage
which <DEL>the</DEL> <INS>an</INS> object will occupy has been
allocated [ Footnote: ... ] <INS>but not after the lifetime of the
object has started</INS> or, <INS>in an evaluation that occurs not before</INS>
<DEL>after</DEL> the lifetime of an object has ended and before the
storage which the object occupied is reused or released, any pointer
that represents the address of the storage location where the object
will be or was located may be used but only in limited ways. For an
object under construction or destruction, see
11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

Similarly, <DEL>before the lifetime of an object has started but</DEL>
<INS>in an evaluation that occurs</INS> after the storage
which <DEL>the</DEL> <INS>an</INS> object will occupy has been
allocated <INS>but not after the lifetime of the object has
started</INS> or, <INS>in an evaluation that occurs not
before</INS> <DEL>after</DEL> the lifetime of an object has ended and
before the storage which the object occupied is reused or released,
any glvalue that refers to the original object may be used but only in
limited ways.  For an object under construction or destruction, see
11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#8">basic.life</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

If, <INS>in an evaluation that occurs not before</INS>
<DEL>after</DEL> 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 the original object is transparently replaceable
(see below) by the new object. ...

</BLOCKQUOTE>

</LI>
</OL>

<P><B>Proposed resolution (approved by CWG 2024-04-19) [SUPERSEDED]:</B></P>

<OL>
<LI>

<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#4">basic.life</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

The properties ascribed to objects and references throughout this
document apply for a given object or reference only during its
lifetime.  [<I>Note 2:</I> In particular, <DEL>before the lifetime of
an object starts and after its lifetime ends</DEL> there are
significant restrictions on the use of <DEL>the</DEL> <INS>an</INS>
object <INS>not within its lifetime</INS>, as described below, in
11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>], and in 11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]. Also,
the behavior of an object under construction and destruction can
differ from the behavior of an object whose lifetime has started and
not ended. 11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>] and 11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]
describe the behavior of an object during its periods of construction
and destruction. &#8212;<I>end note</I>]

</BLOCKQUOTE>

</LI>

<LI>
<P>Add a new paragraph before 6.8.4 [<A href="https://wg21.link/basic.life#6">basic.life</A>] paragraph 6 as
follows:</P>

<BLOCKQUOTE class="ins">

An evaluation E is said to be in a <I>storage-only phase</I> of an
object O if
<UL>
<LI>E happens after the storage which O will occupy is
allocated and E does not happen after the lifetime of O starts; or</LI>
<LI>E does not happen before the lifetime of O ends and E happens
before the storage which O occupied is reused or released.</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#6">basic.life</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

<DEL>Before the lifetime of an object has started but after the
storage which theobject will occupy has been allocated [ Footnote:
... ] but not after the lifetime of the object has started or, after
the lifetime of an object has ended and before the storage which the
object occupied is reused or released,</DEL>
<INS>In an evaluation that is in a storage-only phase of an
object,</INS> any pointer that represents the address of the storage
location where the object will be or was located may be used but only
in limited ways. For an object under construction or destruction, see
11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

Similarly, <DEL>before the lifetime of an object has started but
after the storage
which the object will occupy has been
allocated  or, after the lifetime of an object has ended and
before the storage which the object occupied is reused or released,</DEL>
<INS>in an evaluation that is in a storage-only phase of an
object,</INS>
any glvalue that refers to the <DEL>original</DEL> object may be
used but only in limited ways.  For an object under construction or
destruction, see 11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#8">basic.life</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

If, <INS>in an evaluation that is in a storage-only phase of an object
and where the evaluation does not happen before</INS>
<DEL>after</DEL> the lifetime of <DEL>an</DEL> <INS>the</INS> object
<INS>ends</INS> <DEL>has ended and before the storage which the object
occupied is reused or released</DEL>, 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 the original
object is transparently replaceable (see below) by the new object. ...

</BLOCKQUOTE>

</LI>
</OL>

<P><B>Additional notes (April, 2024)</B></P>

<P>Concerning the proposed change to 6.8.4 [<A href="https://wg21.link/basic.life#8">basic.life</A>] paragraph 8, it was noted that (for example) a common non-allocating placement new does not happen before the storage is reused.

</P>
<BR><BR><HR>
<A NAME="1676"></A><H4>1676.
  
<TT>auto</TT> return type for allocation and deallocation functions
</H4>
<B>Section: </B>6.8.6.5.2&#160; [<A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-04<BR>




<P>Do we need explicit language to forbid <TT>auto</TT> as the return type
of allocation and deallocation functions?</P>

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

<BR><BR><HR>
<A NAME="2042"></A><H4>2042.
  
Exceptions and deallocation functions
</H4>
<B>Section: </B>6.8.6.5.3&#160; [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-11-13<BR>




<P>According to 6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation#3">basic.stc.dynamic.deallocation</A>] paragraph 3,</P>

<BLOCKQUOTE>

If a deallocation function terminates by throwing an
exception, the behavior is undefined.

</BLOCKQUOTE>

<P>This seems to be in conflict with the provisions of
14.5 [<A href="https://wg21.link/except.spec">except.spec</A>]: if a deallocation function throws an
exception that is not allowed by its <I>exception-specification</I>,
14.5 [<A href="https://wg21.link/except.spec#10">except.spec</A>] paragraph 10 would appear to give the
program defined behavior (calling <TT>std::unexpected()</TT> or
<TT>std::terminate()</TT>).  (Note that 14.5 [<A href="https://wg21.link/except.spec#18">except.spec</A>] paragraph 18
explicitly allows an explicit
<I>exception-specification</I> for a deallocation function.)</P>

<BR><BR><HR>
<A NAME="2826"></A><H4>2826.
  
Missing definition of "temporary expression"
</H4>
<B>Section: </B>6.8.7&#160; [<A href="https://wg21.link/class.temporary">class.temporary</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2022-12-16<BR>


<P>The term "temporary expression" is used in
11.9.3 [<A href="https://wg21.link/class.base.init#8">class.base.init</A>] paragraph 8 and 11.9.3 [<A href="https://wg21.link/class.base.init#11">class.base.init</A>] paragraph 11, but is never defined.</P>

<P><B>Proposed resolution (approved by CWG 2023-11-10):</B></P>

<OL>
<LI>
<P>Change in 6.8.7 [<A href="https://wg21.link/class.temporary#6">class.temporary</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

The third context is when a reference binds to a temporary object. [ Footnote: ... ]
<DEL>The temporary object to which the reference is bound or the
temporary object that is the complete object of a subobject to which
the reference is bound persists for the lifetime of the reference if
the glvalue to which the reference is bound was</DEL>
<INS>A <I>temporary expression</I> is a glvalue</INS> obtained through
one of the following:
<UL>
<LI>a temporary materialization conversion (7.3.5 [<A href="https://wg21.link/conv.rval">conv.rval</A>]),</LI>

<LI>
<TT>( <I>expression</I> )</TT>, where <I>expression</I>
is <DEL>one of these expressions</DEL> <INS>a temporary
expression</INS>,</LI>

<LI>subscripting (7.6.1.2 [<A href="https://wg21.link/expr.sub">expr.sub</A>]) of an array operand,
where that operand is <DEL>one of these expressions</DEL> <INS>a
temporary expression</INS>,</LI>

<LI>a class member access (7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]) using the
. operator where the left operand is <DEL>one of these
expressions</DEL> <INS>a temporary expression</INS> and the right
operand designates a non-static data member of non-reference
type,</LI>

<LI>a pointer-to-member operation (7.6.4 [<A href="https://wg21.link/expr.mptr.oper">expr.mptr.oper</A>]) using
the .* operator where the left operand is <DEL>one of these expressions</DEL>
<INS>a temporary expression</INS> and the right operand is a pointer
to data member of non-reference type,

</LI>
<LI>a
<UL>
<LI>const_cast (7.6.1.11 [<A href="https://wg21.link/expr.const.cast">expr.const.cast</A>]),</LI>
<LI>static_cast (7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>])</LI>
<LI>dynamic_cast (7.6.1.7 [<A href="https://wg21.link/expr.dynamic.cast">expr.dynamic.cast</A>]), or</LI>
<LI>reinterpret_cast (7.6.1.10 [<A href="https://wg21.link/expr.reinterpret.cast">expr.reinterpret.cast</A>])</LI>
</UL>
converting, without a user-defined conversion, a glvalue operand that
is <DEL>one of these expressions</DEL> <INS>a temporary
expression</INS> to a glvalue that refers to the object designated by
the operand, or to its complete object or a subobject thereof,</LI>

<LI>a conditional expression (7.6.16 [<A href="https://wg21.link/expr.cond">expr.cond</A>]) that is a
glvalue where the second or third operand is <DEL>one of these
expressions</DEL> <INS>a temporary expression</INS>, or</LI>

<LI>a comma expression (7.6.20 [<A href="https://wg21.link/expr.comma">expr.comma</A>]) that is a glvalue
where the right operand is <DEL>one of these expressions</DEL> <INS>a
temporary expression</INS>.</LI>
</UL>

<INS>If a reference is bound to an object <I>O</I> that is the result
of a temporary expression, the complete object of <I>O</I> persists
for the lifetime of the reference.</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.9.3 [<A href="https://wg21.link/class.base.init#8">class.base.init</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

<DEL>A temporary expression bound to</DEL> <INS>Binding</INS> a
reference member <INS>to an object that is the result of a temporary
expression</INS> in a <I>mem-initializer</I> is ill-formed.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.9.3 [<A href="https://wg21.link/class.base.init#11">class.base.init</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

<DEL>A temporary expression bound to</DEL> <INS>Binding</INS> a
reference member <INS>to an object that is the result of a temporary
expression</INS> from a default member initializer is ill-formed.

</BLOCKQUOTE>
</LI>

</OL>

<P><B>CWG 2024-03-21</B></P>

<P>The phrasing "If a reference is bound to an object O that is the
result of a temporary expression, ..." can be interpreted to refer to
any temporary expression, even one entirely unrelated to the
initializer of the reference.</P>

<BR><BR><HR>
<A NAME="1986"></A><H4>1986.
  
odr-use and delayed initialization
</H4>
<B>Section: </B>6.10.3.2&#160; [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-08-21<BR>




<P>The current wording of 6.10.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>] allows deferral
of static and thread_local initialization until a variable or function
in the containing translation unit is odr-used.  This requires
implementations to avoid optimizing away the relevant odr-uses.  We
should consider relaxing the rule to allow for such optimizations.</P>

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

<BLOCKQUOTE>

For a variable <TT>V</TT> with thread or static storage duration,
let <TT>X</TT> be the set of all variables with the same storage duration
as <TT>V</TT> that are defined in the same translation unit
as <TT>V</TT>. If the observable behavior of the abstract machine
(6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) depends on the value of <TT>V</TT> through an
evaluation <I>E</I>, and <I>E</I> is not sequenced before the end of the
initialization of any variable in <TT>X</TT>, then the end of the
initialization of all variables in <TT>X</TT> is sequenced before <I>E</I>.

</BLOCKQUOTE>

<P>There is also a problem (submitted by David Majnemer) if the odr-use
occurs in a constexpr context that does not require the variable to be
constructed.  For example,</P>

<PRE>
  struct A { A(); };
  thread_local A a;

  constexpr bool f() { return &amp;a != nullptr; }
</PRE>

<P>It doesn't seem possible to construct <TT>a</TT> before its
odr-use in <TT>f</TT>.</P>

<P>There is implementation divergence in the handling of this example.</P>

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

<P>CWG determined that the second part of the issue (involving
<TT>constexpr</TT>) is not a defect because the address of an
object with thread storage duration is not a constant
expression.</P>

<P><B>Additional note, May, 2015:</B></P>

<P>CWG failed to indicate where and how to apply the wording
in the proposed resolution.  In addition, further review has
raised concern that &#8220;sequenced before&#8221; may be the
wrong relation to use for the static storage duration case
because it implies &#8220;in the same thread.&#8221;</P>

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

<P>The suggested wording is intended to replace some existing
wording in 6.10.3.2 [<A href="https://wg21.link/basic.start.static#2">basic.start.static</A>] paragraph 2.  CWG
affirmed that the correct relationship is &#8220;happens
before&#8221; and not &#8220;sequenced before.&#8221;</P>

<BR><BR><HR>
<A NAME="2148"></A><H4>2148.
  
Thread storage duration and order of initialization
</H4>
<B>Section: </B>6.10.3.2&#160; [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

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




<P>The terms &#8220;ordered&#8221; and &#8220;unordered&#8221;
initialization are only defined in 6.10.3.2 [<A href="https://wg21.link/basic.start.static#2">basic.start.static</A>] paragraph 2
for entities with static storage duration.  They
should presumably apply to entities with thread storage duration
as well.</P>

<BR><BR><HR>
<A NAME="2444"></A><H4>2444.
  
Constant expressions in initialization odr-use
</H4>
<B>Section: </B>6.10.3.3&#160; [<A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Davis Herring
 &#160;&#160;&#160;

 <B>Date: </B>2019-11-06<BR>


<P>According to 6.10.3.3 [<A href="https://wg21.link/basic.start.dynamic#3">basic.start.dynamic</A>] paragraph 3,</P>

<BLOCKQUOTE>

A non-initialization odr-use is an odr-use
(6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]) not caused directly or indirectly
by the initialization of a non-local static or thread
storage duration variable.

</BLOCKQUOTE>

<P>Paragraphs 4-6 uses this term to exclude such odr-uses
from consideration in determining the point by which a
deferred initialization must be performed. A
<TT>static_assert</TT> or a template argument expression can
odr-use a variable, but it cannot be said to define any time
during execution.</P>

<P>Suggestion: Add constant expression evaluation to the
definition. Rename the term to &#8220;initializing odr-use&#8221;
(based on effect rather than cause). Add a note saying that no
such odr-use can occur before <TT>main</TT> begins.</P>

<P><B>Notes from the February, 2021 teleconference:</B></P>

<P>CWG agreed with the direction.</P>



<BR><BR><HR>
<A NAME="2503"></A><H4>2503.
  
Unclear relationship among name, qualified name, and unqualified name
</H4>
<B>Section: </B>7.5.5&#160; [<A href="https://wg21.link/expr.prim.id">expr.prim.id</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2021-08-04<BR>




<P>The phrases &#8220;name&#8221;, &#8220;qualified
name&#8221; and &#8220;unqualified name&#8221; are used in
various places. It is not clear that all names are either
one or the other; there could, in fact, be a third kind of
name that is neither.</P>

<P>See also
<A HREF="https://github.com/cplusplus/draft/pull/4793">editorial
issue 4793</A>.
</P>

<BR><BR><HR>
<A NAME="2086"></A><H4>2086.
  
Reference odr-use vs implicit capture
</H4>
<B>Section: </B>7.5.6.3&#160; [<A href="https://wg21.link/expr.prim.lambda.capture">expr.prim.lambda.capture</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-02-14<BR>




<P>Whether a reference is odr-used or not has less to do with the
context where it is named and more to do with its initializer.  In
particular, 7.5.6 [<A href="https://wg21.link/expr.prim.lambda#12.2">expr.prim.lambda</A>] bullet 12.2 leads to cases
where references that can never be odr-used are implicitly
captured:</P>

<BLOCKQUOTE>

<P>A <I>lambda-expression</I> with an
associated <I>capture-default</I> that does not explicitly
capture <TT>this</TT> or a variable with automatic storage duration
(this excludes any <I>id-expression</I> that has been found
to refer to an <I>init-capture</I>'s associated non-static
data member), is said to implicitly capture the entity
(i.e., this or a variable) if the <I>compound-statement</I>:</P>

<UL>
<LI><P>odr-uses (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]) the entity, or</P></LI>

<LI>

<P>names the entity in a potentially-evaluated expression
(6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]) where the enclosing
full-expression depends on a generic lambda parameter
declared within the reaching scope of
the <I>lambda-expression</I>.</P>
</LI>

</UL>

</BLOCKQUOTE>

<P>For example, <TT>ref</TT> should not be captured in the following:</P>

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

  constexpr bool bar(int &amp;, const A &amp;a) { return &amp;a == &amp;globalA; }

  int main() {
    A &amp;ref = globalA;
    [=](auto q) { static_assert(bar(q, ref), ""); }(0);
  }
</PRE>

<BR><BR><HR>
<A NAME="2243"></A><H4>2243.
  
Incorrect use of implicit conversion sequence
</H4>
<B>Section: </B>7.6.1.9&#160; [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

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




<P>The term &#8220;implicit conversion sequence&#8221; is now used in
some non-call contexts (e.g., 7.6.1.9 [<A href="https://wg21.link/expr.static.cast#4">expr.static.cast</A>] paragraph 4,
7.6.16 [<A href="https://wg21.link/expr.cond#4">expr.cond</A>] paragraph 4, 7.6.10 [<A href="https://wg21.link/expr.eq#4">expr.eq</A>] paragraph 4)
) and it is not clear that the current definition is
suited for these additional uses. In particular, passing an argument
in a function call is always copy-initialization, but some of these
contexts require consideration of direct-initialization.</P>

<P>
<B>Notes from the December, 2016 teleconference:</B>
</P>

<P>The problem is that overload resolution relies on copy initalization
and thus does not describe direct initialization. See also
<A HREF="cwg_defects.html#1781">issue 1781</A>.</P>

<BR><BR><HR>
<A NAME="2281"></A><H4>2281.
  
Consistency of aligned <TT>operator delete</TT> replacement
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2016-06-27<BR>




<P>We should require that a program that replaces the aligned form
of <TT>operator delete</TT> also replaces the sized+aligned form. We
only allow a program to replace the non-sized form without replacing
the sized form for backwards compatibility. This is not needed for the
alignment feature, which is new.</P>

<P><B>Notes from the March, 2018 meeting:</B></P>

<P>CWG concurred with the recommendation.</P>

<BR><BR><HR>
<A NAME="2623"></A><H4>2623.
  
Invoking destroying <TT>operator delete</TT> for constructor failure
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Blacktea Hamburger
 &#160;&#160;&#160;

 <B>Date: </B>2022-08-25<BR>


<P>Subclause 7.6.2.8 [<A href="https://wg21.link/expr.new#28">expr.new</A>] paragraph 28 specifies the
lookup for the deallocation function that is invoked when the
construction of the object in a <I>new-expression</I> exits via an
exception.  However, a destroying <TT>operator delete</TT>
(6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>]) should never be used, because the
object in question has not yet been fully created.</P>

<P><U>Suggested resolution [SUPERSEDED]:</U></P>

<P>Change in 7.6.2.8 [<A href="https://wg21.link/expr.new#28">expr.new</A>] paragraph 28 as follows:</P>

<BLOCKQUOTE>

A declaration of a placement deallocation function matches the
declaration of a placement allocation function if it has the same
number of parameters and, after parameter transformations
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]), all parameter types except the first
are identical. If the lookup finds a single matching deallocation
function, that function will be called; otherwise, no deallocation
function will be called. If the lookup finds a usual deallocation
function and that function, considered as a placement deallocation
function, would have been selected as a match for the allocation
function, the program is ill-formed. For a non-placement allocation
function, the normal deallocation function lookup is used to find the
matching deallocation function (7.6.2.9 [<A href="https://wg21.link/expr.delete">expr.delete</A>])
<INS>, except that any destroying operator delete
(6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>]) is ignored</INS>.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2013"></A><H4>2013.
  
Pointer subtraction in large array
</H4>
<B>Section: </B>7.6.6&#160; [<A href="https://wg21.link/expr.add">expr.add</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-10-02<BR>




<P>The common code sequence used by most implementations for
pointer subtraction involves subtracting the pointer values
to determine the number of bytes and then shifting to scale
for the size of the array element.  This produces incorrect
results when the difference in bytes is larger than can be
represented by a <TT>ptrdiff_t</TT>.  For example, assuming
a 32-bit <TT>ptrdiff_t</TT>:</P>

<PRE>
  int *a, *b;
  a = malloc(0x21000000 * sizeof(int));
  b = a + 0x21000000;
  printf("%lx\n", (long)(b - a));
</PRE>

<P>This will typically print e1000000 instead of 21000000.</P>

<P>Getting the right answer would require using a more expensive
code sequence.  It would be better to make this undefined
behavior.</P>

<BR><BR><HR>
<A NAME="2182"></A><H4>2182.
  
Pointer arithmetic in array-like containers
</H4>
<B>Section: </B>7.6.6&#160; [<A href="https://wg21.link/expr.add">expr.add</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-10-20<BR>


<P>The current direction for <A HREF="cwg_defects.html#1776">issue 1776</A>
(see paper P0137) calls into question the validity of doing pointer
arithmetic to address separately-allocated but contiguous objects
in a container like <TT>std::vector</TT>.  A related question is
whether there should be some allowance made for allowing pointer
arithmetic using a pointer to a base class if the derived class is
a standard-layout class with no non-static data members.  It is
possible that <TT>std::launder</TT> could play a part in the
resolution of this issue.</P>

<P><B>Notes from the February, 2016 meeting:</B></P>

<P>This issue is expected to be resolved by the resolution of
<A HREF="cwg_defects.html#1776">issue 1776</A>. The major problem is when the
elements of the vector contain constant or reference members;
6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7 implies that pointer arithmetic
leading to such an object produces undefined behavior, and CWG
expects this to continue.  Some changes to the interface of
<TT>std::vector</TT> may be required, perhaps using
<TT>std::launder</TT> as part of iterator processing.</P>

<BR><BR><HR>
<A NAME="2023"></A><H4>2023.
  
Composite reference result type of conditional operator
</H4>
<B>Section: </B>7.6.16&#160; [<A href="https://wg21.link/expr.cond">expr.cond</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-10-16<BR>




<P>The conditional operator converts pointer operands to their composite
pointer type (7.6.16 [<A href="https://wg21.link/expr.cond">expr.cond</A>] bullets 6.3 and 6.4).  Similar
treatment should be afforded to operands of reference type.</P>

<P>See also <A HREF="cwg_closed.html#2018">issue 2018</A>.</P>

<BR><BR><HR>
<A NAME="2316"></A><H4>2316.
  
Simplifying class conversions in conditional expressions
</H4>
<B>Section: </B>7.6.16&#160; [<A href="https://wg21.link/expr.cond">expr.cond</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>S. B. Tam
 &#160;&#160;&#160;

 <B>Date: </B>2016-08-16<BR>




<P>According to 7.6.16 [<A href="https://wg21.link/expr.cond#4">expr.cond</A>] paragraph 4,</P>

<BLOCKQUOTE>

<P>Attempts are made to form an implicit conversion sequence
from an operand expression <TT>E1</TT> of type <TT>T1</TT>
to a target type related to the type <TT>T2</TT> of the
operand expression <TT>E2</TT> as follows:</P>

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

<LI><P>If <TT>E2</TT> is a prvalue or if neither of the
conversion sequences above can be formed and at least one of
the operands has (possibly cv-qualified) class
type:</P></LI>

<UL>
<LI><P>if <TT>T1</TT> and <TT>T2</TT> are the same class
type (ignoring cv-qualification) and <TT>T2</TT> is at least
as cv-qualified as <TT>T1</TT>, the target type is
<TT>T2</TT>,</P></LI>

<LI><P>otherwise, if <TT>T2</TT>
is a base class of <TT>T1</TT>, the target type is
<I>cv1</I> <TT>T2</TT>, where <I>cv1</I>
denotes the cv-qualifiers of <TT>T1</TT>,</P></LI>

<LI><P>otherwise, the target type is the type
that <TT>E2</TT> would have after applying the
lvalue-to-rvalue (7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]),
array-to-pointer (7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>]), and
function-to-pointer (7.3.4 [<A href="https://wg21.link/conv.func">conv.func</A>]) standard
conversions.</P></LI>

</UL>

</UL>

</BLOCKQUOTE>

<P>It seems that to satisfy the conditions in the first two
sub-bullets, <TT>T2</TT> must be a class type, in which case
<TT>T2</TT> is the same as the type described in the third
sub-bullet, since the lvalue-to-rvalue conversion does not change
types and the other two conversions do not apply to a class
type. Thus, this bullet and sub-bullets could be simplified
to:</P>

<BLOCKQUOTE>

<UL><LI><P>if <TT>E2</TT> is a prvalue or if neither of the
conversion sequences above can be formed and at least one of
the operands has (possibly cv-qualified) class type, the target
type is the type that E2 would have after applying the
lvalue-to-rvalue (7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]),
array-to-pointer (7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>]), and
function-to-pointer (7.3.4 [<A href="https://wg21.link/conv.func">conv.func</A>]) standard
conversions.</P></LI></UL>

</BLOCKQUOTE>

<P><B>Notes from the August, 2020 teleconference:</B></P>

<P>This issue and suggested resolution predate the
resolution of <A HREF="cwg_defects.html#2321">issue 2321</A>, which
added the second sub-bullet (the citation above reflects the
wording after adoption of <A HREF="cwg_defects.html#2321">issue 2321</A>), giving the result the cv-qualification
of <TT>T1</TT> instead of that of <TT>T2</TT>.  The
suggested resolution would revert that accepted
resolution.</P>

<BR><BR><HR>
<A NAME="1255"></A><H4>1255.
  
Definition problems with <TT>constexpr</TT> functions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

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




<P>The current wording of the Standard is not sufficiently clear regarding
the interaction of class scope (which treats the bodies of member functions
as effectively appearing after the class definition is complete) and the
use of <TT>constexpr</TT> member functions within the class definition in
contexts requiring constant expressions.  For example, an array bound
cannot use a <TT>constexpr</TT> member function that relies on the
completeness of the class or on members that have not yet been declared,
but the current wording does not appear to state that.</P>

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

<P>This question also affects function return type deduction (the
<TT>auto</TT> specifier) in member functions.  For example, the following
should presumably be prohibited, but the current wording is not clear:</P>

<PRE>
  struct S {
    static auto f() {
      return 42;
    }
    auto g() -&gt; decltype(f()) {
      return f();
    }
  };
</PRE>



<P><B>CWG 2023-06-15</B></P>

<P>Definitions of member functions need an "as-needed" treatment.  See
issues <A HREF="cwg_active.html#1890">1890</A> and <A HREF="cwg_active.html#2335">2335</A>.</P>

<BR><BR><HR>
<A NAME="2166"></A><H4>2166.
  
Unclear meaning of &#8220;undefined <TT>constexpr</TT> function&#8221;
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Howard Hinnant
 &#160;&#160;&#160;

 <B>Date: </B>2015-08-05<BR>




<P>According to 7.7 [<A href="https://wg21.link/expr.const#5.4">expr.const</A>] bullet 5.4, an expression
is a constant expression unless (among other reasons) it would
evaluate</P>

<UL><LI><P>an invocation of an undefined <TT>constexpr</TT> function</P></LI></UL>

<P>This does not address the question of the point at which
a <TT>constexpr</TT> function must be defined.  The intent,
in order to allow mutually-recursive <TT>constexpr</TT>
functions, was that the function must be defined prior to
the outermost evaluation that eventually results in the
invocation, but this is not clearly stated.</P>

<BR><BR><HR>
<A NAME="2656"></A><H4>2656.
  
Converting consteval lambda to function pointer in non-immediate context
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2022-11-11<BR>


<P>Converting a consteval lambda to a function pointer in a
non-immediate context should be immediately-escalating.</P>

<P>Currently, this is well-formed:</P>

<PRE>
  auto x = &amp;*[]() consteval { return 42; };
</PRE>

<P><U>Suggested resolution:</U></P>

<P>Make the conversion function of a lambda whose call operator is an
immediate function also an immediate function.</P>

<BR><BR><HR>
<A NAME="1680"></A><H4>1680.
  
Including <TT>&lt;initializer_list&gt;</TT> for range-based <TT>for</TT>
</H4>
<B>Section: </B>8.6.5&#160; [<A href="https://wg21.link/stmt.ranged">stmt.ranged</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-13<BR>




<P>A simple example like</P>

<PRE>
  int main() {
    int k = 0;
    for (auto x : { 1, 2, 3 })
      k += x;
    return k;
  }
</PRE>

<P>requires that the <TT>&lt;initializer_list&gt;</TT> header be
included, because the expansion of the range-based <TT>for</TT> involves
a declaration of the form</P>

<PRE>
  auto &amp;&amp;__range = { 1, 2, 3 };
</PRE>

<P>and a <I>braced-init-list</I> causes <TT>auto</TT> to be deduced
as a specialization of <TT>std::initializer_list</TT>.  This seems
unnecessary and could be eliminated by specifying that <TT>__range</TT>
has an array type for cases like this.</P>

<P>(It should be noted that EWG is considering a proposal to change
<TT>auto</TT> deduction for cases involving <I>braced-init-list</I>s,
so resolution of this issue should be coordinated with that effort.)</P>

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

<P>CWG felt that this issue should be resolved by using the array
variant of the range-based <TT>for</TT> implementation.</P>

<BR><BR><HR>
<A NAME="1348"></A><H4>1348.
  
Use of <TT>auto</TT> in a <I>trailing-return-type</I>
</H4>
<B>Section: </B>9.2.9.7&#160; [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-16<BR>




<P>It is not clear whether the <TT>auto</TT> specifier can appear
in a <I>trailing-return-type</I>.</P>

<BR><BR><HR>
<A NAME="1488"></A><H4>1488.
  
<I>abstract-pack-declarator</I>s in <I>type-id</I>s
</H4>
<B>Section: </B>9.3.2&#160; [<A href="https://wg21.link/dcl.name">dcl.name</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-03-28<BR>




<P>The grammar for <I>type-id</I> in 11.3 [<A href="https://wg21.link/class.name">class.name</A>] paragraph
1 has two problems.  First, the fact that we allow an
<I>abstract-pack-declarator</I> makes some uses of <I>type-id</I>
(template arguments, alignment specifiers, exception-specifications)
ambiguous: <TT>T...</TT> could be parsed either as a <I>type-id</I>,
including the ellipsis, or as the <I>type-id</I> <TT>T</TT> with a
following ellipsis.  There does not appear to be any rule to
disambiguate these parses.</P>

<P>The other problem is that we do not allow parentheses in an
<I>abstract-pack-declarator</I>, which makes</P>

<PRE>
  template&lt;typename...Ts&gt; void f(Ts (&amp;...)[4]);
</PRE>

<P>ill-formed because <TT>(&amp;...)()</TT> is not an
<I>abstract-pack-declarator</I>.  There is implementation variance
on this point.</P>

<BR><BR><HR>
<A NAME="1668"></A><H4>1668.
  
Parameter type determination still not clear enough
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-04-25<BR>




<P>According to 9.3.4.6 [<A href="https://wg21.link/dcl.fct#5">dcl.fct</A>] paragraph 5,</P>

<BLOCKQUOTE>

The type of a function is determined using the following rules. The type of
each parameter (including function parameter packs) is determined from its
own <I>decl-specifier-seq</I> and <I>declarator</I>. After determining the
type of each parameter, any parameter of type &#8220;array
of <TT>T</TT>&#8221; or &#8220;function returning <TT>T</TT>&#8221; is
adjusted to be &#8220;pointer to <TT>T</TT>&#8221; or &#8220;pointer to
function returning <TT>T</TT>,&#8221; respectively. After producing the
list of parameter types, any top-level <I>cv-qualifier</I>s modifying a
parameter type are deleted when forming the function type. The resulting
list of transformed parameter types and the presence or absence of the
ellipsis or a function parameter pack is the function's
<I>parameter-type-list</I>. [<I>Note:</I> This transformation does not
affect the types of the parameters. For example, <TT>int(*)(const int p,
decltype(p)*)</TT> and <TT>int(*)(int, const int*)</TT> are identical
types. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>This is not sufficiently clear to specify the intended handling of an
example like</P>

<PRE>
  void f(int a[10], decltype(a) *p );
</PRE>

<P>Should the type of <TT>p</TT> be <TT>int(*)[10]</TT>
or <TT>int**</TT>?  The latter is the intended result, but the phrase
&#8220;after determining the type of each parameter&#8221; makes it
sound as if the adjustments are performed after all the parameter
types have been determined from the <I>decl-specifier-seq</I> and
<I>declarator</I> instead of for each parameter individually.</P>

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

<BR><BR><HR>
<A NAME="2537"></A><H4>2537.
  
Overbroad grammar for <I>parameter-declaration</I>
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Davis Herring
 &#160;&#160;&#160;

 <B>Date: </B>2021-02-25<BR>




<P>9.3.4.6 [<A href="https://wg21.link/dcl.fct#3">dcl.fct</A>] paragraph 3 specifies the grammar for <I>parameter-declaration</I>:</P>

<PRE>
  <I>parameter-declaration:
      attribute-specifier-seq<sub>opt</sub></I> this<I><sub>opt</sub> decl-specifier-seq declarator
      attribute-specifier-seq<sub>opt</sub></I> this<I><sub>opt</sub> decl-specifier-seq declarator</I> = <I>initializer-clause
      attribute-specifier-seq<sub>opt</sub></I> this<I><sub>opt</sub> decl-specifier-seq abstract-declarator<sub>opt</sub>
      attribute-specifier-seq<sub>opt</sub></I> this<I><sub>opt</sub> decl-specifier-seq abstract-declarator<sub>opt</sub></I> = <I>initializer-clause</I>
</PRE>

<P>This is overly permissive; using
a <I>defining-type-specifier-seq</I> instead of
a <I>decl-specifier-seq</I> is sufficient.</P>

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

<OL>

<LI>
<P>Change in 9.2.2 [<A href="https://wg21.link/dcl.stc#4">dcl.stc</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

There can be no static function declarations within a block<DEL>, nor any
static function parameters</DEL>.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.2.2 [<A href="https://wg21.link/dcl.stc#5">dcl.stc</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

The <TT>extern</TT> specifier shall not be used in the declaration of
a class member<DEL> or function parameter</DEL>.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.2.4 [<A href="https://wg21.link/dcl.typedef#1">dcl.typedef</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The <TT>typedef</TT> specifier shall not be combined in
a <I>decl-specifier-seq</I> with any other kind of specifier except
a <I>defining-type-specifier</I>, and it shall not be used <DEL>in
the <I>decl-specifier-seq</I> of a <I>parameter-declaration</I>
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]) nor</DEL> in
the <I>decl-specifier-seq</I> of a <I>function-definition</I>
(9.6 [<A href="https://wg21.link/dcl.fct.def">dcl.fct.def</A>]).

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.2.8 [<A href="https://wg21.link/dcl.inline#4">dcl.inline</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

The <TT>inline</TT> specifier shall not appear on a block scope
declaration<DEL> or on the declaration of a function parameter</DEL>.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.3.4.6 [<A href="https://wg21.link/dcl.fct#3">dcl.fct</A>] paragraph 3 as follows:</P>

<PRE>
  <I>parameter-declaration:
      attribute-specifier-seq<sub>opt</sub></I> this<I><sub>opt</sub> <DEL>decl-specifier-seq</DEL> <INS>defining-type-specifier-seq</INS> declarator
      attribute-specifier-seq<sub>opt</sub></I> this<I><sub>opt</sub> <DEL>decl-specifier-seq</DEL> <INS>defining-type-specifier-seq</INS> declarator</I> = <I>initializer-clause
      attribute-specifier-seq<sub>opt</sub></I> this<I><sub>opt</sub> <DEL>decl-specifier-seq</DEL> <INS>defining-type-specifier-seq</INS> abstract-declarator<sub>opt</sub>
      attribute-specifier-seq<sub>opt</sub></I> this<I><sub>opt</sub> <DEL>decl-specifier-seq</DEL> <INS>defining-type-specifier-seq</INS> abstract-declarator<sub>opt</sub></I> = <I>initializer-clause</I>
</PRE>
</LI>

</OL>

<P><B>CWG 2023-02-07</B></P>

<P>Additional drafting is needed to address references
to <I>decl-specifier-seq</I> in other parts of the standard.

A list is
<A HREF="https://github.com/cplusplus/CWG/issues/7#issuecomment-1421767008">here</A>.

Furthermore, reducing the grammar to a <I>type-specifier-seq</I>
appears to be sufficient.</P>

<BR><BR><HR>
<A NAME="1580"></A><H4>1580.
  
Default arguments in explicit instantiations
</H4>
<B>Section: </B>9.3.4.7&#160; [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-10-29<BR>


<P>It is not clear, either from 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>] or
13.9.3 [<A href="https://wg21.link/temp.explicit">temp.explicit</A>], whether it is permitted to add a default
argument in an explicit instantiation of a function template:</P>

<PRE>
  template&lt;typename T&gt; void f(T, int) { }
  template void f&lt;int&gt;(int, int=0);  //<SPAN CLASS="cmnt"> Permitted?</SPAN>
</PRE>

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

<P>The intent is to prohibit default arguments in explicit instantiations.</P>

<BR><BR><HR>
<A NAME="2327"></A><H4>2327.
  
Copy elision for direct-initialization with a conversion function
</H4>
<B>Section: </B>9.5&#160; [<A href="https://wg21.link/dcl.init">dcl.init</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2016-09-30<BR>


<P>Consider an example like:</P>

<PRE>
  struct Cat {};
  struct Dog { operator Cat(); };

  Dog d;
  Cat c(d);
</PRE>

<P>This goes to 9.5 [<A href="https://wg21.link/dcl.init#17.6.2">dcl.init</A>] bullet 17.6.2:</P>

<BLOCKQUOTE>

Otherwise, if the initialization is direct-initialization, or if
it is copy-initialization where the cv-unqualified version of the
source type is the same class as, or a derived class of, the
class of the destination, constructors are considered. The
applicable constructors are enumerated
(12.2.2.4 [<A href="https://wg21.link/over.match.ctor">over.match.ctor</A>]), and the best one is chosen
through overload resolution (12.2 [<A href="https://wg21.link/over.match">over.match</A>]). The
constructor so selected is called to initialize the object, with
the initializer expression or <I>expression-list</I> as its
argument(s). If no constructor applies, or the overload
resolution is ambiguous, the initialization is ill-formed.

</BLOCKQUOTE>

<P>Overload resolution selects the move constructor of <TT>Cat</TT>.
Initializing the <TT>Cat&amp;&amp;</TT> parameter of the constructor
results in a temporary, per 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>] bullet
5.2.1.2. This precludes the possitiblity of copy elision for this
case.</P>

<P>This seems to be an oversight in the wording change for
guaranteed copy elision. We should presumably be simultaneously
considering both constructors and conversion functions in this
case, as we would for copy-initialization, but we'll need to make
sure that doesn't introduce any novel problems or ambiguities.</P>

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

<P>This issue is addressed by paper P2828.</P>

<BR><BR><HR>
<A NAME="1304"></A><H4>1304.
  
Omitted array bound with string initialization
</H4>
<B>Section: </B>9.5.3&#160; [<A href="https://wg21.link/dcl.init.string">dcl.init.string</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-04-26<BR>




<P>The example in 9.5.3 [<A href="https://wg21.link/dcl.init.string">dcl.init.string</A>] paragraph
1 says,</P>

<BLOCKQUOTE>

<PRE>
  char msg[] = "Syntax error on line %s\n";
</PRE>

<P>shows a character array whose members are initialized with a
<I>string-literal</I>.  Note that because <TT>'\n'</TT> is a single
character and because a trailing <TT>'\0'</TT> is appended,
<TT>sizeof(msg)</TT> is <TT>25</TT>.
</P>

</BLOCKQUOTE>

<P>However, there appears to be no normative specification of how the
size of the array is to be calculated.</P>

<BR><BR><HR>
<A NAME="1414"></A><H4>1414.
  
Binding an rvalue reference to a reference-unrelated lvalue
</H4>
<B>Section: </B>9.5.4&#160; [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2011-11-09<BR>




<P>Currently an attempt to bind an rvalue reference to a
reference-unrelated lvalue succeeds, binding the reference to a
temporary initialized from the lvalue by copy-initialization.  This
appears to be intentional, as the accompanying example contains the
lines</P>

<PRE>
    int i3 = 2;
    double&amp;&amp; rrd3 = i3;  //<SPAN CLASS="cmnt"> </SPAN>rrd3<SPAN CLASS="cmnt"> refers to temporary with value </SPAN>2.0
</PRE>

<P>This violates the expectations of some who expect that rvalue
references can be initialized only with rvalues.  On the other
hand, it is parallel with the handling of an lvalue
reference-to-const (and is handled by the same wording).  It also
can add efficiency without requiring existing code to be rewritten:
the implicitly-created temporary can be moved from, just as if the
call had been rewritten to create a prvalue temporary from the
lvalue explicitly.</P>

<P>On a related note, assuming the binding is permitted, the intent of
the overload tiebreaker found in 12.2.4.3 [<A href="https://wg21.link/over.ics.rank#3">over.ics.rank</A>] paragraph 3
is not clear:</P>

<UL>
<LI><P>Standard conversion sequence <TT>S1</TT> is a better conversion
sequence than standard conversion sequence <TT>S2</TT> if</P></LI>

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

<LI><P>
<TT>S1</TT> and <TT>S2</TT> are reference bindings
(9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]) and neither refers to an implicit
object parameter of a non-static member function declared without
a <I>ref-qualifier</I>, and <TT>S1</TT> binds an rvalue reference
to an rvalue and <TT>S2</TT> binds an lvalue reference.</P></LI>

</UL>

</UL>

<P>At question is what &#8220;to an rvalue&#8221; means here.  If it
is referring to the value category of the initializer itself,
before conversions, then the supposed performance advantage of
the binding under discussion does not occur because the competing
rvalue and lvalue reference overloads will be ambiguous:</P>

<PRE>
    void f(int&amp;&amp;);    //<SPAN CLASS="cmnt"> #1</SPAN>
    void f(const int&amp;);
    void g(double d) {
        f(d);         //<SPAN CLASS="cmnt"> ambiguous: #1 does not bind to an rvalue</SPAN>
    }
</PRE>

<P>On the other hand, if &#8220;to an rvalue&#8221; refers to the
actual object to which the reference is bound, i.e., to the temporary
in the case under discussion, the phrase would seem to be vacuous because
an rvalue reference can never bind directly to an lvalue.</P>

<P><B>Notes from the February, 2012 meeting:</B></P>

<P>CWG agreed that the binding rules are correct, allowing creation of
a temporary when binding an rvalue reference to a non-reference-related
lvalue.  The phrase &#8220;to an rvalue&#8221; in
12.2.4.3 [<A href="https://wg21.link/over.ics.rank#3">over.ics.rank</A>] paragraph 3 is a leftover from before
binding an rvalue reference to an lvalue was prohibited and should be
removed. A change is also needed to handle the following case:</P>

<PRE>
    void f(const char (&amp;)[1]);         //<SPAN CLASS="cmnt"> #1</SPAN>
    template&lt;typename T&gt; void f(T&amp;&amp;);  //<SPAN CLASS="cmnt"> #2</SPAN>
    void g() {
      f("");                           //<SPAN CLASS="cmnt">calls #2, should call #1</SPAN>
    }
</PRE>

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

<P>Removing &#8220;to an rvalue,&#8221; as suggested, would have the
effect of negating the preference for binding a function lvalue to an
lvalue reference instead of an rvalue reference because the case would
now fall under the preceding bullet of 12.2.4.3 [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>]
bullet 3.1, sub-bullets 4 and 5:</P>

<BLOCKQUOTE>

<P>Two implicit conversion sequences of the same form are
indistinguishable conversion sequences unless one of the following
rules applies:</P>

<UL>
<LI><P>Standard conversion sequence <TT>S1</TT> is a better conversion sequence than
standard conversion sequence <TT>S2</TT> if</P></LI>

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

<LI><P>
<TT>S1</TT> and <TT>S2</TT> are reference bindings
(9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]) and neither refers to an implicit object
parameter of a non-static member function declared without a
<I>ref-qualifier</I>, and <TT>S1</TT> binds an rvalue reference to an
rvalue and <TT>S2</TT> binds an lvalue reference... or, if not that,</P></LI>

<LI><P>
<TT>S1</TT> and <TT>S2</TT> are reference bindings
(9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]) and <TT>S1</TT> binds an lvalue reference
to a function lvalue and <TT>S2</TT> binds an rvalue reference to a
function lvalue.</P></LI>

</UL>

</UL>

</BLOCKQUOTE>

<P>Presumably if the suggested resolution is adopted, the order of these
two bullets should be inverted.</P>

<BR><BR><HR>
<A NAME="1827"></A><H4>1827.
  
Reference binding with ambiguous conversions
</H4>
<B>Section: </B>9.5.4&#160; [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2014-01-07<BR>




<P>In the following case,</P>

<PRE>
  struct A {
    operator int &amp;&amp;() const;
    operator int &amp;&amp;() volatile;
    operator long();
  };

  int main() {
    int &amp;&amp;x = A();
  }
</PRE>

<P>the conversion for direct binding cannot be used because of
the ambiguity, so indirect binding is used, which allows the
use of the conversion to <TT>long</TT> in creating the temporary.</P>

<P>Is this intended?  There is implementation variation.</P>

<P><B>Notes from the February, 2014 meeting:</B></P>

<P>CWG agreed that an ambiguity like this should make the initialization
ill-formed instead of falling through to do indirect binding.</P>

<BR><BR><HR>
<A NAME="1996"></A><H4>1996.
  
Reference list-initialization ignores conversion functions
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-09-04<BR>




<P>The specification for list-initialization of a reference does not
consider the existence of conversion functions.  Consequently, the
following example is ill-formed:</P>

<PRE>
  struct S { operator struct D &amp;(); } s;
  D &amp;d{s};
</PRE>

<BR><BR><HR>
<A NAME="2742"></A><H4>2742.
  
Guaranteed copy elision for brace-initialization from prvalue
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2023-06-06<BR>


<P>Consider:</P>

<PRE>
  struct A {
    A();
    A(A const&amp;) = delete;
  };
  int main(){
    A a = A(A(A())); //<SPAN CLASS="cmnt"> #1 </SPAN>
    A b = A{A{A{}}}; //<SPAN CLASS="cmnt"> #2 </SPAN>
  }
</PRE>

<P>#1 is well-formed per 9.5.1 [<A href="https://wg21.link/dcl.init.general#16.6.1">dcl.init.general</A>] bullet 16.6.1.
However, even though #2 is intended to have a similar effect, the
relevant rule excludes non-aggregates, making the example ill-formed
(because the relevant constructor is deleted); see
9.5.5 [<A href="https://wg21.link/dcl.init.list#3.2">dcl.init.list</A>] bullet 3.2:</P>

<BLOCKQUOTE>

If T is an aggregate class and the initializer list has a single
element of type cv U, where U is T or a class derived from T, the
object is initialized from that element (by copy-initialization for
copy-list-initialization, or by direct-initialization for
direct-list-initialization).

</BLOCKQUOTE>

<P>There is implementation divergence: gcc and clang accept, MSVC rejects.</P>

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

<P><U>Suggested resolution:</U></P>

<P>Change in 9.5.5 [<A href="https://wg21.link/dcl.init.list#3.2">dcl.init.list</A>] bullet 3.2 as follows:</P>

<BLOCKQUOTE>

If T is <DEL>an aggregate class</DEL> <INS>a class type</INS> and the
initializer list has a single element of type cv U, where U is T or a
class derived from T, the object is initialized from that element (by
copy-initialization for copy-list-initialization, or by
direct-initialization for direct-list-initialization).

</BLOCKQUOTE>

<P><B>CWG 2024-03-01</B></P>

<P>Recent MSVC no longer rejects the example.  The suggested
resolution would revert <A HREF="cwg_defects.html#2137">issue 2137</A>, which
is not desirable.  The consensus is to try an initializer-list
constructor first and then fall back to copy-initialization (with
guaranteed copy elision).  A change to 12.2.4.2.6 [<A href="https://wg21.link/over.ics.list">over.ics.list</A>]
may be necessary.</P>

<BR><BR><HR>
<A NAME="1854"></A><H4>1854.
  
Disallowing use of implicitly-deleted functions
</H4>
<B>Section: </B>9.6.2&#160; [<A href="https://wg21.link/dcl.fct.def.default">dcl.fct.def.default</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-02-11<BR>


<P>The resolution of <A HREF="cwg_defects.html#1778">issue 1778</A> means that
whether an explicitly-defaulted function is deleted or not cannot be
known until the end of the class definition.  As a result, new rules
are required to disallow references (in, e.g., <TT>decltype</TT>) to
explicitly-defaulted functions that might later become deleted.</P>

<P><B>Notes from the June, 2014 meeting:</B></P>

<P>The approach favored by CWG was to make any reference to an
explicitly-defaulted function ill-formed if it occurs prior to the
end of the class definition.</P>

<BR><BR><HR>
<A NAME="1485"></A><H4>1485.
  
Out-of-class definition of member unscoped opaque enumeration
</H4>
<B>Section: </B>9.8.1&#160; [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-03-26<BR>




<P>The scope in which the names of enumerators are entered for
a member unscoped opaque enumeration is not clear.  According to
9.8.1 [<A href="https://wg21.link/dcl.enum#10">dcl.enum</A>] paragraph 10,</P>

<BLOCKQUOTE>

Each <I>enum-name</I> and each unscoped enumerator is declared in the
scope that immediately contains the <I>enum-specifier</I>.

</BLOCKQUOTE>

<P>In the case of a member opaque enumeration defined outside its
containing class, however, it is not clear whether the enumerator
names are declared in the class scope or in the lexical scope
containing the definition. Declaring them in the class scope would
be a violation of 11.4 [<A href="https://wg21.link/class.mem#1">class.mem</A>] paragraph 1:</P>

<BLOCKQUOTE>

The <I>member-specification</I> in a class definition declares the
full set of members of the class; no member can be added elsewhere.

</BLOCKQUOTE>

<P>Declaring the names in the lexical scope containing the
definition would be contrary to the example in
13.7.2.6 [<A href="https://wg21.link/temp.mem.enum#1">temp.mem.enum</A>] paragraph 1:</P>

<PRE>
  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;
</PRE>

<P>There also appear to be problems with the rules for dependent
types and members of the current instantiation.</P>

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

<P>CWG agreed that an unscoped opaque enumeration in class scope
should be forbidden.</P>

<P><B>Additional notes (April, 2025)</B></P>

<P>Consider:</P>

<PRE>
  struct S {
    enum E : int;
  };

  enum S::E : int { e1 };

  void f() {
    S::E::e1; //<SPAN CLASS="cmnt"> #1, all implementations accept</SPAN>
    S::e1;    //<SPAN CLASS="cmnt"> #2, all implementations accept</SPAN>
    e1;       //<SPAN CLASS="cmnt"> #3, only Clang accepts</SPAN>
  }
</PRE>

<P>Reflector discussion seems to favor making #2 (because adding a
"member" after the end of the <I>class-specifier</I>; see
11.4.1 [<A href="https://wg21.link/class.mem.general#3">class.mem.general</A>] paragraph 3) and #3 ill-formed.</P>

<BR><BR><HR>
<A NAME="2131"></A><H4>2131.
  
Ambiguity with <I>opaque-enum-declaration</I>
</H4>
<B>Section: </B>9.8.1&#160; [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-05-28<BR>




<P>The declaration</P>

<PRE>
  enum E;
</PRE>

<P>is ambiguous: it could be either a <I>simple-declaration</I>
comprising the <I>elaborated-type-specifier</I> <TT>enum E</TT>
and no <I>init-declarator-list</I>, or it could be an
<I>opaque-enum-declaration</I> with an omitted <I>enum-base</I>
(both of which are ill-formed, for different reasons).</P>

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

<BR><BR><HR>
<A NAME="2505"></A><H4>2505.
  
Nested unnamed namespace of inline unnamed namespace
</H4>
<B>Section: </B>9.9.2.2&#160; [<A href="https://wg21.link/namespace.unnamed">namespace.unnamed</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nathan Sidwell
 &#160;&#160;&#160;

 <B>Date: </B>2021-11-22<BR>


<P>According to 9.9.2.2 [<A href="https://wg21.link/namespace.unnamed#1">namespace.unnamed</A>] paragraph 1,</P>

<BLOCKQUOTE>

<P>An <I>unnamed-namespace-definition</I> behaves as if it
were replaced by</P>

<UL>
<TT>inline</TT><SUB><I>opt</I></SUB> <TT>namespace</TT> <I><B>unique</B></I> <TT>{ /* empty body */ }</TT><BR>
<TT>using namespace</TT> <I><B>unique</B></I> <TT>;</TT><BR>
<TT>namespace</TT> <I><B>unique</B></I> <TT>{</TT> <I>namespace-body</I> <TT>}</TT>
</UL>

<P>where <TT>inline</TT> appears if and only if it appears
in the <I>unnamed-namespace-definition</I> and all
occurrences of <I><B>unique</B></I> in a translation unit are
replaced by the same identifier, and this identifier differs
from all other identifiers in the translation unit.</P>

</BLOCKQUOTE>

<P>The use of a single identifier for all occurrences
of <I><B>unique</B></I> within a translation unit leads to problems
when an inline unnamed namespace contains a nested unnamed
namespace, e.g.,</P>

<PRE>
    inline namespace {
      namespace { }
    }
</PRE>

<P>In this case, the unnamed namespace cannot be reopened
because the lookup for <I><B>unique</B></I> finds both the
outer and inner namespaces and is thus ambiguous.</P>

<P><U>Suggested resolution:</U></P>

<P>Change 9.9.2.2 [<A href="https://wg21.link/namespace.unnamed#1">namespace.unnamed</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

...where <TT>inline</TT> appears if and only if it appears
in the <I>unnamed-namespace-definition</I> and all
occurrences of <I><B>unique</B></I> <INS>in each scope</INS>
in a translation unit are replaced by the
same <INS>scope-specific</INS> identifier, and this
identifier differs from all other identifiers in the
translation unit.

</BLOCKQUOTE>

<P><B>Notes from the December, 2021 teleconference:</B></P>

<P>The suggested resolution deals specifically with unnamed
namespaces, but there are related examples that do not
involve unnamed namespaces. The problem needs to be solved
more generally in the specification of lookup.
</P>

<BR><BR><HR>
<A NAME="2555"></A><H4>2555.
  
Ineffective redeclaration prevention for <I>using-declarator</I>s
</H4>
<B>Section: </B>9.10&#160; [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Christof Meerwald
 &#160;&#160;&#160;

 <B>Date: </B>2022-03-23<BR>




<P>Consider:</P>

<PRE>
  template&lt;int I&gt;
  struct C { };

  struct B
  {
    C&lt;1&gt; foo();
    C&lt;1&gt; bar();
  };

  struct D : B
  {
    using B::foo;
    C&lt;2&gt; foo(this B &amp;);

    using B::bar;
    C&lt;2&gt; bar(this D &amp;);
  };

  struct DD : D
  {
    using D::foo;
    using D::bar;
  };

  void bar(D d, DD dd)
  {
    d.foo();
    dd.foo();

    d.bar();
    dd.bar();
  }
</PRE>

<P>Which functions are called?</P>

<P>Subclause 9.10 [<A href="https://wg21.link/namespace.udecl#11">namespace.udecl</A>] paragraph 11 specifies:</P>

<BLOCKQUOTE>

The set of declarations named by a <I>using-declarator</I> that
inhabits a class <TT>C</TT> does not include member functions and
member function templates of a base class that correspond to (and thus
would conflict with) a declaration of a function or function template
in <TT>C</TT>.

</BLOCKQUOTE>

<P>The definition of "corresponds" considers the type of the implicit
object parameter, which is a deviation from the status quo ante for a
simple example like this one:</P>

<PRE>
  struct B {
    void f();    // #1
  };
  struct D : B {
    void f();
    using B::f;  //<SPAN CLASS="cmnt"> should not name #1</SPAN>
  };
</PRE>

<P><U>Suggested resolution:</U></P>

<P>Change in 9.10 [<A href="https://wg21.link/namespace.udecl#11">namespace.udecl</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

The set of declarations named by a <I>using-declarator</I> that
inhabits a class <TT>C</TT> does not include member functions and
member function templates of a base class that<INS>, when considered
as members of <TT>C</TT>,</INS> correspond to (and thus would conflict
with) a declaration of a function or function template in <TT>C</TT>.

<P>[ <I>Example</I>:</P>
<PRE>
  struct B {
    virtual void f(int);
    virtual void f(char);
    void g(int);
    void h(int);
<INS>    void i();
    void j();</INS>
  };

  struct D : B {
    using B::f;
    void f(int);   //<SPAN CLASS="cmnt"> OK, </SPAN>D::f(int)<SPAN CLASS="cmnt"> overrides </SPAN>B::f(int)
  
    using B::g;
    void g(char);  //<SPAN CLASS="cmnt"> OK</SPAN>
  
    using B::h;
    void h(int);   //<SPAN CLASS="cmnt"> OK, </SPAN>D::h(int)<SPAN CLASS="cmnt"> hides </SPAN>B::h(int)

<INS>    using B::i;
    void i(this B &amp;);  //<SPAN CLASS="cmnt"> OK</SPAN>

    using B::j;
    void j(this D &amp;);  //<SPAN CLASS="cmnt"> OK, </SPAN>D::j()<SPAN CLASS="cmnt"> hides </SPAN>B::j()</INS>
  };

  void k(D* p)
  {
    p-&gt;f(1);        //<SPAN CLASS="cmnt"> calls </SPAN>D::f(int)
    p-&gt;f('a');      //<SPAN CLASS="cmnt"> calls </SPAN>B::f(char)
    p-&gt;g(1);        //<SPAN CLASS="cmnt"> calls </SPAN>B::g(int)
    p-&gt;g('a');      //<SPAN CLASS="cmnt"> calls </SPAN>D::g(char)
<INS>    p-&gt;i();         //<SPAN CLASS="cmnt"> calls </SPAN>B::i<SPAN CLASS="cmnt">, because </SPAN>B::i<SPAN CLASS="cmnt"> as a member of </SPAN>D<SPAN CLASS="cmnt"> is a better match than </SPAN>D::i
    p-&gt;j();         //<SPAN CLASS="cmnt"> calls </SPAN>D::j</INS>
  }
  ...
</PRE>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1706"></A><H4>1706.
  
<TT>alignas</TT> pack expansion syntax
</H4>
<B>Section: </B>9.13.1&#160; [<A href="https://wg21.link/dcl.attr.grammar">dcl.attr.grammar</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-06-26<BR>


<P>The grammar for <I>alignment-specifier</I> in 9.13.1 [<A href="https://wg21.link/dcl.attr.grammar#1">dcl.attr.grammar</A>] paragraph 1
is:</P>

<UL>
<I>alignment-specifier:</I>
<UL>
<TT>alignas (</TT> <I>type-id</I> <TT>...</TT><I><SUB>opt</SUB></I><TT>)</TT><BR>
<TT>alignas (</TT> <I>assignment-expression</I> <TT>...</TT><I><SUB>opt</SUB></I><TT>)</TT>

</UL>

</UL>

<P>where the ellipsis indicates pack expansion.  Naively, one would expect
that the expansion would result in forms like</P>

<PRE>
    alignas()
    alignas(1, 2)
    alignas(int, double)
</PRE>

<P>but none of those forms is given any meaning by the current wording.
Instead, 13.7.4 [<A href="https://wg21.link/temp.variadic#4">temp.variadic</A>] paragraph 4 says,</P>

<BLOCKQUOTE>

In an <I>alignment-specifier</I> (9.13.2 [<A href="https://wg21.link/dcl.align">dcl.align</A>]); the pattern
is the <I>alignment-specifier</I> without the ellipsis.

</BLOCKQUOTE>

<P>Presumably this means that something like <TT>alignas(T...)</TT> would
expand to something like</P>

<PRE>
    alignas(int) alignas(double)
</PRE>

<P>This is counterintuitive and should be reexamined.</P>



<P>See also messages <A href="http://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&amp;msg=24016">24016</A> through <A href="http://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&amp;msg=24021">24021</A>.</P>

<P><B>Notes from the February, 2014 meeting:</B></P>

<P>CWG decided to change the pack expansion of <TT>alignas</TT> so that
the <I>type-id</I> or <I>assignment-expression</I> is repeated inside
the parentheses and to change the definition of <TT>alignas</TT> to
accept multiple arguments with the same meaning as multiple <TT>alignas</TT>
specifiers.</P>

<BR><BR><HR>
<A NAME="2223"></A><H4>2223.
  
Multiple <TT>alignas</TT> specifiers
</H4>
<B>Section: </B>9.13.2&#160; [<A href="https://wg21.link/dcl.align">dcl.align</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Herrick
 &#160;&#160;&#160;

 <B>Date: </B>2016-01-12<BR>


<P>According to 9.13.2 [<A href="https://wg21.link/dcl.align#4">dcl.align</A>] paragraph 4,</P>

<BLOCKQUOTE>

The alignment requirement of an entity is the strictest non-zero alignment
specified by its <I>alignment-specifier</I>s, if any; otherwise,
the <I>alignment-specifier</I>s have no effect.

</BLOCKQUOTE>

<P>It is not clear whether this applies to specifiers within a single
declaration, or if it is intended to apply to the union of all
declarations.</P>

<P>Similarly, paragraph 6 says,</P>

<BLOCKQUOTE>

If the defining declaration of an entity has an <I>alignment-specifier</I>,
any non-defining declaration of that entity shall either specify equivalent
alignment or have no <I>alignment-specifier</I>. Conversely, if any
declaration of an entity has an <I>alignment-specifier</I>, every defining
declaration of that entity shall specify an equivalent alignment. No
diagnostic is required if declarations of an entity have
different <I>alignment-specifier</I>s in different translation units.

</BLOCKQUOTE>

<P>This only talks about agreement between definitions and non-defining
declarations. What about an example where an entity is not defined but
is declared with different <I>alignment-specifier</I>s?</P>

<PRE>
  struct alignas(16) A;
  struct alignas(32) A;
</PRE>

<P>If <TT>A</TT> is not defined, is this, or should it be, ill-formed?</P>

<P><B>Notes from the February, 2017 meeting:</B></P>

<P>CWG agreed that the intent of the wording is that the
&#8220;strictest&#8221; requirement is intended to apply to a single
declaration, and the requirement for compatibility should apply to all
declarations, whether the entity is defined or not.</P>

<BR><BR><HR>
<A NAME="2607"></A><H4>2607.
  
Visibility of enumerator names
</H4>
<B>Section: </B>10.2&#160; [<A href="https://wg21.link/module.interface">module.interface</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2022-06-28<BR>




<P>Consider:</P>

<PRE>
  //<SPAN CLASS="cmnt"> module interface unit</SPAN>
  export module M;
  export enum E : int;
  enum E : int { e };

  //<SPAN CLASS="cmnt"> other translation unit</SPAN>
  import M;
  auto a = E::e;  //<SPAN CLASS="cmnt"> #1: OK?</SPAN>
  auto b = e;     //<SPAN CLASS="cmnt"> #2: OK?</SPAN>
</PRE>

<P>It is unclear whether the enumerator name <TT>e</TT> is or ought to
be visible in the other translation unit.</P>

<P>See also issues <A HREF="cwg_defects.html#2588">2588</A> (friend
declarations) and <A HREF="cwg_active.html#2480">2480</A>.</P>

<P><B>CWG 2022-11-10</B></P>

<P>See 10.2 [<A href="https://wg21.link/module.interface#7">module.interface</A>] paragraph 7.</P>

<BR><BR><HR>
<A NAME="1890"></A><H4>1890.
  
Member type depending on definition of member function
</H4>
<B>Section: </B>11.4&#160; [<A href="https://wg21.link/class.mem">class.mem</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2014-03-07<BR>




<P>Consider an example like:</P>

<PRE>
  struct A {
    struct B {
      auto foo() { return 0; }
    };
    decltype(B().foo()) x;
  };
</PRE>

<P>There does not appear to be a prohibition of cases like this, where
the type of a member depends on the definition of a member function.</P>

<P>(See also issues <A HREF="cwg_defects.html#1360">1360</A>,
<A HREF="cwg_defects.html#1397">1397</A>, and <A HREF="cwg_active.html#2335">2335</A>.)</P>

<P><B>Additional notes (January, 2023):</B></P>

<P>The following example might be related:</P>

<PRE>
  #include &lt;type_traits&gt;

  struct Bar {
    struct Baz {
      int a = 0;
    };
    static_assert(std::is_default_constructible_v&lt;Baz&gt;);
  };
</PRE>

<P><B>Additional notes (November, 2023):</B></P>

<P>The following example is also rejected by implementations, but it
is allowed by the rules:</P>

<PRE>
    struct A {
      static bool f2() { return f(); }

      static consteval bool f() { return true; }
    };
</PRE>

<BR><BR><HR>
<A NAME="1623"></A><H4>1623.
  
Deleted default union constructor and member initializers
</H4>
<B>Section: </B>11.4.5&#160; [<A href="https://wg21.link/class.ctor">class.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Vinny Romano
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-15<BR>




<P>According to 11.4.5 [<A href="https://wg21.link/class.ctor#5">class.ctor</A>] paragraph 5,</P>

<BLOCKQUOTE>

<P>A defaulted default constructor for 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 default constructor,</P></LI>

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

<LI><P>
<TT>X</TT> is a union and all of its variant members are of
const-qualified type (or array thereof),</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),</P></LI>

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

</UL>

</BLOCKQUOTE>

<P>Because the presence of a non-static data member initializer is the
moral equivalent of a <I>mem-initializer</I>, these rules should
probably be modified not to define the generated constructor as
deleted when a union member has a non-static data member initializer.
(Note the non-normative references in 11.5 [<A href="https://wg21.link/class.union">class.union</A>]
paragraphs 2-3 and 9.2.9.2 [<A href="https://wg21.link/dcl.type.cv#2">dcl.type.cv</A>] paragraph 2 that
would also need to be updated if this restriction is changed.)</P>

<P>It would also be helpful to add a requirement to 11.5 [<A href="https://wg21.link/class.union">class.union</A>]
requiring either a non-static data member initializer or a user-provided
constructor if all the members of the union have const-qualified types.</P>

<P>On a more general note, why is the default constructor defined as
deleted just because a member has a non-trivial default constructor?  The
union itself doesn't know which member is the active one, and default
construction won't initialize any members (assuming
no <I>brace-or-equal-initializer</I>).  It is up to the &#8220;owner&#8221;
of the union to control the lifetime of the active member (if any), and
requiring a user-provided constructor is forcing a design pattern that
doesn't make sense.  Along the same lines, why is the default destructor
defined as deleted just because a member has a non-trivial destructor?  I
would agree with this restriction if it only applied when the union also
has a user-provided constructor.</P>

<P>See also issues <A HREF="cwg_defects.html#1460">1460</A>,
<A HREF="cwg_defects.html#1562">1562</A>, <A HREF="cwg_defects.html#1587">1587</A>,
and <A HREF="cwg_defects.html#1621">1621</A>.</P>


<BR><BR><HR>
<A NAME="1808"></A><H4>1808.
  
Constructor templates vs default constructors
</H4>
<B>Section: </B>11.4.5&#160; [<A href="https://wg21.link/class.ctor">class.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-11-12<BR>




<P>It is not clear when, if ever, a constructor template can be
considered to provide a default constructor.  For example:</P>

<PRE>
  struct A {
    template&lt;typename ...T&gt; A(T...); //<SPAN CLASS="cmnt"> #1</SPAN>
    A(std::initializer_list&lt;long&gt;);  //<SPAN CLASS="cmnt"> #2</SPAN>
  };
  A a{};
</PRE>

<P>According to 9.5.5 [<A href="https://wg21.link/dcl.init.list#3">dcl.init.list</A>] paragraph 3, <TT>A</TT>
will be value-initialized if it has a default constructor, and
there is implementation divergence whether this example calls #1
or #2.</P>

<P>Similarly, for an example like</P>

<PRE>
  struct B {
    template&lt;typename T=int&gt; B(T = 0);
  };
</PRE>

<P>it is not completely clear whether a default constructor should
be implicitly declared or not.</P>

<P>More generally, do utterances in the Standard concerning
&#8220;constructors&#8221; also apply to constructor templates?</P>

<P><B>Notes from the February, 2014 meeting:</B></P>

<P>One possibility discussed was that we may need to change places that
explicitly refer to a default constructor to use overload resolution,
similar to the change that was made a few years ago with regard to copy
construction vs &#8220;copy constructor.&#8221;  One additional use of
&#8220;default constructor&#8221; is in determining the triviality of a
class, but it might be a good idea to remove the concept of a trivial
class altogether.  This possibility will be explored.</P>

<P><B>Notes from the February, 2016 meeting:</B></P>

<P>CWG reaffirmed the direction from the preceding note and also
determined that the presence of a constructor template should suppress
implicit declaration of a default constructor.</P>

<P><B>Additional notes (April, 2024)</B></P>

<P>The standard does not seem to contain a use of "trivial class" outside
of examples.  See paper P3247R0 Deprecate the notion of trivial types.</P>

<P>Additional examples to consider for the definition of "trivial class":</P>

<PRE>
  struct A {
    A() = default; //<SPAN CLASS="cmnt">eligible, second constructor unsatisfied</SPAN>
    template&lt;class... Args&gt;
    A(Args&amp;&amp;... args) requires (sizeof...(Args) &gt; 0) {}
  };

  struct B {
    B() = default; //<SPAN CLASS="cmnt">ineligible, second constructor more constrained</SPAN>
    template&lt;class... Args&gt;
    B(Args&amp;&amp;... args) requires (sizeof...(Args) == 0) {}
  };

  struct C {
    C() = default; //<SPAN CLASS="cmnt">eligible, but</SPAN>
    template&lt;class... Args&gt; //<SPAN CLASS="cmnt">also eligible and non-trivial</SPAN>
    C(Args&amp;&amp;... args) {}
  };
</PRE>

<P>See also <A HREF="cwg_defects.html#1363">issue 1363</A>.</P>

<BR><BR><HR>
<A NAME="2799"></A><H4>2799.
  
Inheriting default constructors
</H4>
<B>Section: </B>11.4.5.2&#160; [<A href="https://wg21.link/class.default.ctor">class.default.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2017-09-01<BR>




<P>(See also submission
<A HREF="https://github.com/cplusplus/CWG/issues/545">#545</A>.)</P>

<P>Consider:</P>

<PRE>
  struct A { int n; };
  struct B : A {
    using A::A;
    B(int);
  };
</PRE>

<P>Does <TT>B</TT> have a default constructor?</P>

<P><U>Suggested resolution [SUPERSEDED]:</U></P>

<OL>
<LI>
<P>Change in 9.10 [<A href="https://wg21.link/namespace.udecl#4">namespace.udecl</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

If a constructor or assignment operator brought from a base class into
a derived class has the signature of a <INS>default constructor
or</INS> copy/move constructor or assignment operator for the derived
class (<INS>11.4.5.2 [<A href="https://wg21.link/class.default.ctor">class.default.ctor</A>],</INS>
11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>], 11.4.6 [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]),
the <I>using-declaration</I> does not by itself suppress the implicit
declaration of the derived class member; the member from the base
class is hidden or overridden by the
implicitly-declared <DEL>copy/move constructor or assignment
operator</DEL> <INS>special member function</INS> of the derived
class, as described below.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.5.2 [<A href="https://wg21.link/class.default.ctor#1">class.default.ctor</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A <I>default constructor</I> for a class X is a constructor of class X
for which each parameter that is not a function parameter pack has a
default argument (including the case of a constructor with no
parameters). If there is no user-declared constructor for class
<TT>X</TT>, <INS>or if <TT>X</TT> inherits (9.10 [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>])
one or more default constructors and there is no user-declared default
constructor for <TT>X</TT>,</INS> a non-explicit constructor having no
parameters is implicitly declared as defaulted
(9.6 [<A href="https://wg21.link/dcl.fct.def">dcl.fct.def</A>]). An implicitly-declared default constructor
is an inline public member of its class.

</BLOCKQUOTE>
</LI>
</OL>

<P><B>Proposed resolution [SUPERSEDED]:</B></P>

<P>(This also resolves <A HREF="cwg_active.html#2632">issue 2632</A>.)</P>

<OL>
<LI>
<P>Change in 9.10 [<A href="https://wg21.link/namespace.udecl#4">namespace.udecl</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<DEL>If a constructor or assignment operator brought from a base class
into a derived class has the signature of a copy/move constructor or
assignment operator for the derived class
(11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>], 11.4.6 [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]),
the <I>using-declaration</I> does not by itself suppress the implicit
declaration of the derived class member; the member from the base
class is hidden or overridden by the implicitly-declared copy/move
constructor or assignment operator of the derived class, as described
below.</DEL>

<INS>[ Note: A <I>using-declarator</I> that names a member function of
a base class does not suppress the implicit declaration of a special
member function in the derived class, even if their signatures are the
same (<INS>11.4.5.2 [<A href="https://wg21.link/class.default.ctor">class.default.ctor</A>],</INS>
11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>], 11.4.6 [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]). -- end note ]</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Add a new paragraph before 11.4.1 [<A href="https://wg21.link/class.mem.general#2">class.mem.general</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

... For any other <I>member-declaration</I>, each declared entity that
is not an unnamed bit-field (11.4.10 [<A href="https://wg21.link/class.bit">class.bit</A>]) is a member
of the class, <INS>termed a <I>user-declared</I> member,</INS>
and each such <I>member-declaration</I> shall either declare at least
one member name of the class or declare at least one unnamed
bit-field.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.5.2 [<A href="https://wg21.link/class.default.ctor#1">class.default.ctor</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A <I>default constructor</I> for a class X is a constructor of class X
for which each parameter that is not a function parameter pack has a
default argument (including the case of a constructor with no
parameters). If <DEL>there is no</DEL> <INS>a class <TT>X</TT> does
not have a</INS> user-declared constructor <DEL>for class
<TT>X</TT></DEL>, <INS>or if <TT>X</TT> inherits
(9.10 [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]) one or more default constructors
and <TT>X</TT> does not have a user-declared default
constructor,</INS> a non-explicit constructor having no parameters is
implicitly declared as defaulted (9.6 [<A href="https://wg21.link/dcl.fct.def">dcl.fct.def</A>]). An
implicitly-declared default constructor is an inline public member of
its class.
<INS>[ Example:</INS>
<PRE class="ins">
  struct A {};
  struct B {};
  struct C : A, B {
    using A::A, B::B;
    C(int);
  };
  C c;     // <SPAN CLASS="cmnt">OK</SPAN>

  struct X { X(int = 0, int = 0); };  // <SPAN CLASS="cmnt">#1</SPAN>
  struct Y { Y(int = 0); };           // <SPAN CLASS="cmnt">#2</SPAN>
  struct Z : X, Y {
    using X::X, Y::Y;
  };
  Z z2(1, 1);   // <SPAN CLASS="cmnt">OK, invokes </SPAN>X(1, 1)<SPAN CLASS="cmnt"> and </SPAN>Y()
  Z z1(1);      // <SPAN CLASS="cmnt">error: ambiguous between #1 and #2</SPAN>
  Z z0;         // <SPAN CLASS="cmnt">OK, invokes </SPAN>X()<SPAN CLASS="cmnt"> and </SPAN>Y()

</PRE>
<INS>-- end example ]</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#6">class.copy.ctor</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

If the class <DEL>definition</DEL> does not <DEL>explicitly
declare</DEL> <INS>have</INS> a <INS>user-declared</INS> copy
constructor, a non-explicit one is declared implicitly. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#8">class.copy.ctor</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

If <DEL>the definition of</DEL> a class X does not <DEL>explicitly
declare</DEL> <INS>have</INS> a <INS>user-declared</INS> move
constructor, a non-explicit one will be implicitly declared as
defaulted if and only if ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Add a new paragraph before 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#11">class.copy.ctor</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

<P class="ins">[ Note: A <I>using-declaration</I> in a derived class C
that names a constructor from a base class never suppresses the
implicit declaration of a copy/move constructor of C, even if the base
class constructor would be a copy or move constructor if declared as a
member of C. -- end note]</P>

<P>A copy/move constructor for class X is trivial if it is not
user-provided and if: ...</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.6 [<A href="https://wg21.link/class.copy.assign#2">class.copy.assign</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If the class <DEL>definition</DEL> does not <DEL>explicitly
declare</DEL> <INS>have</INS> a <INS>user-declared</INS> copy
assignment operator, one is declared implicitly. If the class
<DEL>definition declares</DEL> <INS>has</INS>
a <INS>user-declared</INS> move constructor or move assignment
operator, the implicitly declared copy assignment operator is defined
as deleted; otherwise, it is defaulted (9.6 [<A href="https://wg21.link/dcl.fct.def">dcl.fct.def</A>]). The
latter case is deprecated if the class has a user-declared copy
constructor or a user-declared destructor
(D.6 [<A href="https://wg21.link/depr.impldec">depr.impldec</A>]). ...

</BLOCKQUOTE>
</LI>
</OL>

<P><B>Additional notes (November, 2023)</B></P>

<P>How does access checking interact with the proposed resolution above?</P>

<PRE>
  struct B {
  protected:
    B(int = 0);
  };
  struct A : B {
    using B::B;
    A(void *);
  };
  A a;       //<SPAN CLASS="cmnt"> okay?</SPAN>
  A aa(42);  //<SPAN CLASS="cmnt"> not okay</SPAN>
</PRE>

<P><B>CWG 2023-11-06</B></P>

<P>CWG resolved not to declare a default constructor in the derived
class, but instead apply the usual rules for inherited constructors
for this case.  The wording should be changed so that the presence of a
default constructor is never checked, in particular for "trivial class"
(11.2 [<A href="https://wg21.link/class.prop">class.prop</A>], fixed by
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3247r1.html">P3247R1</A>
(Deprecate the notion of trivial types)), vacuous initialization
(6.8.4 [<A href="https://wg21.link/basic.life#1">basic.life</A>] paragraph 1, fixed by <A HREF="cwg_defects.html#2859">issue 2859</A>), and value initialization (9.5.1 [<A href="https://wg21.link/dcl.init.general#9">dcl.init.general</A>] paragraph 9, also fixed by <A HREF="cwg_defects.html#2859">issue 2859</A>).</P>

<BR><BR><HR>
<A NAME="1092"></A><H4>1092.
  
Cycles in overload resolution during instantiation
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#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="1594"></A><H4>1594.
  
Lazy declaration of special members vs overload errors
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-12-06<BR>




<P>The implicit declaration of a special member function sometimes
requires overload resolution, in order to select a special member to
use for base classes and non-static data members. This can be required
to determine whether the member is or would be deleted, and whether
the member is trivial, for instance. The standard appears to require
such overload resolution be performed at the end of the definition of
the class, but in practice, implementations perform it lazily. This
optimization appears to be non-conforming, in the case where overload
resolution would hit an error.  In order to enable this optimization,
such errors should be &#8220;no diagnostic required.&#8221;</P>

<P><B>Additional note (March, 2013):</B></P>

<P>See also <A HREF="cwg_defects.html#1360">issue 1360</A>.</P>

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

<P>The problem with this approach is that hard errors (not in the
immediate context) can occur, affecting portability.  There are some
cases, such as a virtual assignment operator in the base class, where
lazy evaluation cannot be done, so it cannot be mandated.</P>

<BR><BR><HR>
<A NAME="2203"></A><H4>2203.
  
Defaulted copy/move constructors and UDCs
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Vinny Romano
 &#160;&#160;&#160;

 <B>Date: </B>2015-11-20<BR>




<P>Consider:</P>

<PRE>
  struct A
  {
    A();
    A(A&amp;);
    explicit A(int);
    operator int() const;
  };
  struct B
  {
    B(B&amp;&amp; other);
    A a;
  };
  B::B(B&amp;&amp; other) : a(static_cast&lt;B&amp;&amp;&gt;(other).a) {}
  // B::B(B&amp;&amp; other) = default; // <SPAN CLASS="cmnt">ill-formed</SPAN>

  void f(B&amp; b1)
  {
    B b2 = static_cast&lt;B&amp;&amp;&gt;(b1);
  }
</PRE>

<P>The user-defined move constructor is well-formed
because <TT>B::a</TT> can be initialized via <TT>A::operator
int()</TT> and <TT>A::A(int)</TT>; however, Clang and GCC believe a
defaulted one would be ill-formed.</P>

<P>What about the following, which is considered well-formed by
compilers and calls <TT>A::A(C&amp;&amp;)</TT>?</P>

<PRE>
  struct C {};

  struct A : C
  {
    A();
    A(A&amp;);
    A(C&amp;&amp;);
  };
  struct B
  {
    B(B&amp;&amp; other);
    A a;
  };

  B::B(B&amp;&amp; other) = default;
</PRE>

<BR><BR><HR>
<A NAME="2264"></A><H4>2264.
  
Memberwise copying with indeterminate value
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2016-05-06<BR>




<P>It appears that the following example may have unwanted undefined
behavior in C++, although not in C:</P>

<PRE>
  struct A { int x, y; };
  A passthrough(A a) { return a; }
  int main(void) {
   A a;
   a.x = 0;
   return passthrough(a).x;
  }
</PRE>

<P>The default memberwise copying operation is not specified to be done
in a way that is insensitive to indeterminate values.</P>

<BR><BR><HR>
<A NAME="2158"></A><H4>2158.
  
Polymorphic behavior during destruction
</H4>
<B>Section: </B>11.4.7&#160; [<A href="https://wg21.link/class.dtor">class.dtor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-07-13<BR>




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

<PRE>
  #include &lt;stdio.h&gt;
  struct Base {
    Base *p;
    virtual void f() { puts("base"); }
    ~Base() {
      p-&gt;f();
    }
  };
  struct Derived : Base {
    Derived() { p = this; }
    void f() { puts("derived"); }
    void g() {
      p-&gt;f();
      delete this;
    }
  };
  void h() {
    Derived *p = new Derived;
    p-&gt;g();
  }
</PRE>

<P>Should this have defined behavior? On the one hand, the
<TT>Derived</TT> object is in its period of destruction, so
the behavior of the <TT>p-&gt;f()</TT> call in
the <TT>Base</TT> destructor should be to
call <TT>Base::f()</TT>. On the other hand, <TT>p</TT> is a
pointer to a <TT>Derived</TT> object whose lifetime has
ended, and the rules in 6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>] don't
appear to allow the call. (Calling <TT>this-&gt;f()</TT>
from the <TT>Base</TT> destructor would be OK &#8212; the
question is whether you can do that for a pointer that used
to point to the derived object, or if you can only do it for
a pointer that was &#8220;created&#8221; after the dynamic
type of the object changed to be <TT>Base</TT>.)</P>

<P>If the above is valid, it has severe implications for
devirtualization. The purpose of 6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7
appears to be to allow an implementation to
assume that if it will perform two loads of a constant field
(for instance, a const member, the implicit pointer for a
reference member, or a vptr), and the two loads are
performed on the &#8220;same pointer value&#8221;, then
they load the same value.</P>

<P>Should there be a rule for destructors similar to that
of 11.4.5 [<A href="https://wg21.link/class.ctor#12">class.ctor</A>] paragraph 12?</P>

<BLOCKQUOTE>

During the construction of a const object, if the value of
the object or any of its subobjects is accessed through a
glvalue that is not obtained, directly or indirectly, from
the constructor's this pointer, the value of the object or
subobject thus obtained is unspecified.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2335"></A><H4>2335.
  
Deduced return types vs member types
</H4>
<B>Section: </B>11.4.9.3&#160; [<A href="https://wg21.link/class.static.data">class.static.data</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2017-01-29<BR>


<P>It is not clear how an example like the following should be
treated:</P>

<PRE>
  template &lt;class ...&gt; struct partition_indices {
    static auto compute_right () {}
    static constexpr auto right = compute_right;
  };
  auto foo () -&gt; partition_indices&lt;&gt;;
  void f() {
    foo();
  };
</PRE>

<P>The initialization of <TT>right</TT> is in a context that must
be done during the initial parse of the class, but the function
body of <TT>compute_right</TT> is not supposed to be evaluated
until the class is complete. Current implementations appear to
accept the template case but not the equivalent non-template case.
It's not clear why those cases should be treated differently.</P>

<P>If you change the example to include a forward dependency in
the body of <TT>compute_right</TT>, e.g.,</P>

<PRE>
  template &lt;int&gt; struct X {};
  template &lt;class T&gt; struct partition_indices {
    static auto compute_right () { return X&lt;I&gt;(); }
    static constexpr auto right = compute_right;
    static constexpr int I = sizeof(T);
  };

  auto foo () -&gt; partition_indices&lt;int&gt;;

  void f() {
    foo();
  };
</PRE>

<P>current implementations reject the code, but it's not clear
that there is a rationale for the different behavior.</P>

<P><B>Notes from the March, 2018 meeting:</B></P>

<P>It was proposed that one direction might be to disallow instantiating
member functions while the containing class template is being instantiated.
However, overnight implementation experience indicated that this approach
breaks seemingly-innocuous and currently-accepted code like:</P>

<PRE>
  template &lt;class T&gt; struct A {
    static constexpr int num() { return 42; }
    int ar[num()];
  };
  A&lt;int&gt; a;
</PRE>

<P>There was divergence of opinion regarding whether the current
rules describe the current behavior for the two original examples
or whether additional explicit rules are needed to clarify the difference
in behavior between template and non-template examples, as well as
whether there should be a difference at all..</P>

<P><B>Notes from the June, 2018 meeting:</B></P>

<P>The consensus of CWG was to treat templates and classes the same by
"instantiating" delayed-parse regions when they are needed instead of at
the end of the class.</P>

<P>See also issues <A HREF="cwg_closed.html#1626">1626</A> and
<A HREF="cwg_active.html#1890">1890</A>.</P>

<BR><BR><HR>
<A NAME="1702"></A><H4>1702.
  
Rephrasing the definition of &#8220;anonymous union&#8221;
</H4>
<B>Section: </B>11.5&#160; [<A href="https://wg21.link/class.union">class.union</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-17<BR>




<P>11.5 [<A href="https://wg21.link/class.union#5">class.union</A>] paragraph 5 defines an anonymous union as
follows:</P>

<BLOCKQUOTE>

<P>A union of the form</P>

<UL>
<TT>union {</TT> <I>member-specification</I> <TT>} ;</TT>
</UL>

<P>is called an anonymous union; it defines an unnamed object of unnamed type.</P>

</BLOCKQUOTE>

<P>It is obviously intended that a declaration like</P>

<PRE>
    static union { int i; float f; };
</PRE>

<P>is a declaration of that form (cf paragraph 6, which requires the
<TT>static</TT> keyword for anonymous unions declared in namespace
scope).  However, it would be clearer if the definition were recast
in more descriptive terms, e.g.,</P>

<BLOCKQUOTE>

An <I>anonymous union</I> is an unnamed class that is defined with
the <I>class-key</I> <TT>union</TT> in a <I>simple-declaration</I> in
which the <I>init-declarator-list</I> is omitted.  Such a
<I>simple-declaration</I> is treated as if it contained a single
declarator declaring an unnamed variable of the union's type.

</BLOCKQUOTE>

<P>(Note that this definition would require some additional tweaking to
apply to class member anonymous union declarations, since
<I>simple-declaration</I>s are not included
as <I>member-declaration</I>s.)</P>

<P>As a related point, it is not clear how the following examples
are to be treated, and there is implementation variance on some:</P>

<PRE>
   void f() { thread_local union { int a; }; }
   void g() { extern union { int b; }; }
   thread_local union { int c; }; //<SPAN CLASS="cmnt"> </SPAN>static<SPAN CLASS="cmnt"> is implied by </SPAN>thread_local
   static thread_local union { int d; };
   static const union { int e = 0; }; //<SPAN CLASS="cmnt"> is </SPAN>e<SPAN CLASS="cmnt"> const? Clang says yes, gcc says no</SPAN>
   static constexpr union { int f = 0; };
</PRE>

<P><B>Additional notes (July, 2023)</B></P>

<P>This issue is addressed by <A HREF="cwg_active.html#2767">issue 2767</A>.</P>

<BR><BR><HR>
<A NAME="2246"></A><H4>2246.
  
Access of indirect virtual base class constructors
</H4>
<B>Section: </B>11.8.3&#160; [<A href="https://wg21.link/class.access.base">class.access.base</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Vinny Romano
 &#160;&#160;&#160;

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




<P>Consider this example from <A HREF="cwg_closed.html#7">issue 7</A>:</P>

<PRE>
  class Foo { };
  class A : virtual private Foo { };
  class Bar : public A { }; 
</PRE>

<P>This example should cause <TT>Bar</TT>'s defaulted default
constructor to be deleted, because it does not have access to the
injected-class-name <TT>Foo</TT>.</P>

<P>
<B>Notes from the December, 2016 teleconference:</B>
</P>

<P>The injected-class-name is irrelevant to the example, which is
ill-formed. The access should be permitted only if conversion of the
<TT>this</TT> pointer to a pointer to the base class would succeed.
</P>

<BR><BR><HR>
<A NAME="2187"></A><H4>2187.
  
Protected members and access via <I>qualified-id</I>
</H4>
<B>Section: </B>11.8.5&#160; [<A href="https://wg21.link/class.protected">class.protected</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-10-16<BR>




<P>The following line in the example in
11.8.5 [<A href="https://wg21.link/class.protected#1">class.protected</A>] paragraph 1 is no longer allowed
following the change from <A HREF="cwg_defects.html#1873">issue 1873</A>:</P>

<PRE>
  class B {
  protected:
    int i;
    static int j;
  };
  // ...
  class D2 : public B {
    friend void fr(B*, D1*, D2*);
    void mem(B*, D1*);
  };
  void fr(B* pb, D1* p1, D2* p2) {
    // ...
    p2-&gt;B::i = 4;  // <SPAN CLASS="cmnt">OK (access through a </SPAN>D2<SPAN CLASS="cmnt">, even though naming class is </SPAN>B<SPAN CLASS="cmnt">)</SPAN>
    // ...
  }
</PRE>

<P>The example line ought to work, but none of the bullets in
11.8.3 [<A href="https://wg21.link/class.access.base#5">class.access.base</A>] paragraph 5 apply:</P>

<BLOCKQUOTE>

A member m is accessible at the point R when named in class N if
<UL>
<LI>m as a member of N is public, or</LI>
<LI>m as a member of N is private, and R occurs in a direct member or friend of class N, or</LI>
<LI>m as a member of N is protected, and R occurs in a direct
member or friend of class N, or in a member of a class P derived from
N, where m as a member of P is public, private, or protected, or</LI>
<LI>there exists a base class B of N that is accessible at R, and m
is accessible at R when named in class B.</LI>
</UL>

</BLOCKQUOTE>

<P>One aproach might be that 11.8.3 [<A href="https://wg21.link/class.access.base#5.3">class.access.base</A>] bullet 5.3
should also consider friends of a class P derived from N where P is
the type of the object expression (if any) or a base class thereof,
and m as a member of P is public, protected, or private.</P>

<BR><BR><HR>
<A NAME="2403"></A><H4>2403.
  
Temporary materialization and base/member initialization
</H4>
<B>Section: </B>11.9.3&#160; [<A href="https://wg21.link/class.base.init">class.base.init</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2018-12-11<BR>


<P>Given the following example,</P>

<PRE>
  struct Noncopyable {
    Noncopyable();
    Noncopyable(const Noncopyable &amp;) = delete;
  };

  Noncopyable make(int kind = 0);

  struct AsBase : Noncopyable {
    AsBase() : Noncopyable(make()) {} //<SPAN CLASS="cmnt"> #1</SPAN>
  };

  struct AsMember {
    Noncopyable nc;
    AsMember() : nc(make()) { }  //<SPAN CLASS="cmnt"> #2?</SPAN>
  };
</PRE>

<P>All implementations treat #1 as an error, invoking the
deleted copy constructor, while #2 is accepted.  It's not
clear from the current wording why they should be treated
differently.</P>

<P><B>Additional note (August, 2022):</B></P>



<P>If there are concerns about reuse of tail padding in #1, requiring
a copy for some implementation reason, similar concerns should apply
to #2 if the data member is declared
with <TT>[[no_unique_address]]</TT>.</P>

<P>Furthermore, the following example using a delegating constructor
shows implementation divergence:</P>
<PRE>
struct Noncopyable {
  Noncopyable();
  Noncopyable(const Noncopyable &amp;) = delete;
  Noncopyable(int) : Noncopyable(Noncopyable()) {} // #3?
};
</PRE>

<BR><BR><HR>
<A NAME="1278"></A><H4>1278.
  
Incorrect treatment of contrived object
</H4>
<B>Section: </B>12.2.2.2.2&#160; [<A href="https://wg21.link/over.call.func">over.call.func</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-27<BR>




<P>Footnote 127 of 12.2.2.2.2 [<A href="https://wg21.link/over.call.func#3">over.call.func</A>] paragraph 3 reads,</P>

<BLOCKQUOTE>

An implied object argument must be contrived to correspond to the
implicit object parameter attributed to member functions during
overload resolution.  It is not used in the call to the selected
function.  Since the member functions all have the same implicit
object parameter, the contrived object will not be the cause to select
or reject a function.

</BLOCKQUOTE>

<P>It is not true that &#8220;the member functions all have the same
implicit object parameter.&#8221;  This statement does not take into
account member functions brought into the class by <I>using-declaration</I>s
or <I>cv-qualifier</I>s and <I>ref-qualifier</I>s on the non-static
member functions:</P>

<PRE>
    struct B
    {
      char f();         // B &amp;
    };

    struct D : B
    {
      using B::f;
      long f();         // D &amp;

      char g() const;   // D const &amp;
      long g();         // D &amp;

      char h() &amp;;       // D &amp;
      long h() &amp;&amp;;      // D &amp;&amp;
    };

    int main()
    {
      //<SPAN CLASS="cmnt"> </SPAN>D::f()<SPAN CLASS="cmnt"> has better match than </SPAN>B::f()<SPAN CLASS="cmnt"></SPAN>
      decltype(D().f()) *p1 = (long *)0;

      //<SPAN CLASS="cmnt"> </SPAN>D::g()<SPAN CLASS="cmnt"> has better match than </SPAN>D::g() const<SPAN CLASS="cmnt"></SPAN>
      decltype(D().g()) *p2 = (long *)0;

      //<SPAN CLASS="cmnt"> </SPAN>D::h() &amp;<SPAN CLASS="cmnt"> is not viable function</SPAN>
      //<SPAN CLASS="cmnt"> </SPAN>D::h() &amp;&amp;<SPAN CLASS="cmnt"> is viable function</SPAN>
      decltype(D().h()) *p3 = (long *)0;
    }
</PRE>

<P>The value category of a contrived object expression is not
specified by the rules and, probably, cannot be properly specified in
presence of <I>ref-qualifier</I>s, so the statement &#8220;the
contrived object will not be the cause to select or reject a
function&#8221; should be normative rather than informative:</P>

<PRE>
    struct X
    {
      static void f(double) {}
      void f(int) &amp; {}
      void f(int) &amp;&amp; {}
    };

    int main()
    {
      X::f(0); //<SPAN CLASS="cmnt"> ???</SPAN>
    }
</PRE>

<BR><BR><HR>
<A NAME="2564"></A><H4>2564.
  
Conversion to function pointer with an explicit object parameter
</H4>
<B>Section: </B>12.2.2.2.3&#160; [<A href="https://wg21.link/over.call.object">over.call.object</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Christof Meerwald
 &#160;&#160;&#160;

 <B>Date: </B>2022-04-11<BR>




<P>Subclause 12.2.2.2.3 [<A href="https://wg21.link/over.call.object#2">over.call.object</A>] paragraph 2 considers only
those conversion functions matching a particular grammar pattern. This
unintendedly excludes conversion functions with an explicit object
parameter (and, as a pre-existing defect, <CODE>noexcept</CODE>
conversion functions): </P>

<BLOCKQUOTE>

In addition, for each non-explicit conversion function declared in T
of the form
<PRE>
operator <I>conversion-type-id</I> ( ) <I>cv-qualifier-seq<sub>opt</sub></I> <I>ref-qualifier<sub>opt</sub></I> <I>noexcept-specifier<sub>opt</sub></I> <I>attribute-specifier-seq<sub>opt</sub></I> ;
</PRE>
where the optional <I>cv-qualifier-seq</I> is the same
cv-qualification as, or a greater cv-qualification than, cv, and
where <I>conversion-type-id</I> denotes the type &#8220;pointer to
function of (P1 , . . . , Pn ) returning R&#8221;, or the type
&#8220;reference to pointer to function of (P1 , . . . , Pn )
returning R&#8221;, or the type &#8220;reference to function of (P1 ,
. . . , Pn ) returning R&#8221;, a surrogate call function with the
unique name <I>call-function</I> and having the form
<PRE>
R <I>call-function</I> ( <I>conversion-type-id</I> F, P1 a1 , ... , Pn an ) { return F (a1 , . . . , an ); }
</PRE>
is also considered as a
candidate function. Similarly, surrogate call functions are added to
the set of candidate functions for each non-explicit conversion
function declared in a base class of T provided the function is not
hidden within T by another intervening declaration. [ Footnote: ...]

</BLOCKQUOTE>

<P>For example, there is implementation divergence in handling this example:</P>

<PRE>
  using fn_t = void();
  struct C {
    operator fn_t * (this C const &amp;);
  };

  void foo(C c) {
    c();
  }
</PRE>

<BR><BR><HR>
<A NAME="2089"></A><H4>2089.
  
Restricting selection of builtin overloaded operators
</H4>
<B>Section: </B>12.2.2.3&#160; [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-02-26<BR>




<P>The candidates selected by 12.2.2.3 [<A href="https://wg21.link/over.match.oper">over.match.oper</A>] include
built-in candidates that will result in an error if chosen; this
was affirmed by <A HREF="cwg_defects.html#1687">issue 1687</A>.  As a result,
<TT>t+u</TT> is ill-formed because it is resolved to the built-in
<TT>operator+(int*,std::ptrdiff_t)</TT>, although most implementations
do not (yet) agree:</P>

<PRE>
  struct Adaptor { Adaptor(int); };

  struct List { };
  void operator +(List &amp;, Adaptor);

  struct DataType {
    operator int *() const = delete;
    operator List &amp;() const;
  };

  struct Yea;
  struct Nay { int theNaysHaveIt; };

  template &lt;typename T, typename U&gt;
  Yea addCheck(int, T &amp;&amp;t, U &amp;&amp;u, char (*)[sizeof(t + u, 0)] = 0);

  template &lt;typename T, typename U&gt;
  Nay addCheck(void *, T &amp;&amp;t, U &amp;&amp;u);

  void test(DataType &amp;data) { (void)sizeof(addCheck(0, data,
  0.).theNaysHaveIt); }
</PRE>

<P>It might be better to adjust the candidate list in
12.2.2.4 [<A href="https://wg21.link/over.match.ctor#3.3.3">over.match.ctor</A>] bullet 3.3.3 to allow conversion
only on class types and exclude the second standard conversion
sequence.</P>

<BR><BR><HR>
<A NAME="2028"></A><H4>2028.
  
Converting constructors in rvalue reference initialization
</H4>
<B>Section: </B>12.2.2.7&#160; [<A href="https://wg21.link/over.match.ref">over.match.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mitsuru Kariya
 &#160;&#160;&#160;

 <B>Date: </B>2014-10-25<BR>


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

<PRE>
  struct T {
    T() {}
    T(struct S&amp;) {}
  };

  struct S {
    operator T() { return T(); }
  };

  int main()
  {
    S s;
    T&amp;&amp; t(s);  //<SPAN CLASS="cmnt"> #1</SPAN>
  }
</PRE>

<P>Because there are two possible conversions from <TT>S</TT> to
<TT>T</TT>, one by conversion function and the other by converting
constructor, one might expect that the initialization at #1 would
be ambiguous.  However, 12.2.2.7 [<A href="https://wg21.link/over.match.ref">over.match.ref</A>] (used in the
relevant bullet of 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>], paragraph 5.2.1.2)
only deals with conversion functions and ignores converting
constructors.</P>

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

<P>CWG agreed that 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>] should be changed
to consider converting constructors in this case.</P>

<BR><BR><HR>
<A NAME="2108"></A><H4>2108.
  
Conversions to non-class prvalues in reference initialization
</H4>
<B>Section: </B>12.2.2.7&#160; [<A href="https://wg21.link/over.match.ref">over.match.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-03-24<BR>




<P>In 12.2.2.7 [<A href="https://wg21.link/over.match.ref">over.match.ref</A>], candidates that produce
non-class prvalues are considered, although that seems to contradict
what 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>] says.  See also
<A HREF="cwg_active.html#2077">issue 2077</A>.</P>

<BR><BR><HR>
<A NAME="2194"></A><H4>2194.
  
Impossible case in list initialization
</H4>
<B>Section: </B>12.2.2.8&#160; [<A href="https://wg21.link/over.match.list">over.match.list</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Robert Haberlach
 &#160;&#160;&#160;

 <B>Date: </B>2015-11-04<BR>


<P>According to 12.2.2.8 [<A href="https://wg21.link/over.match.list#1">over.match.list</A>] paragraph 1 says,</P>

<BLOCKQUOTE>

If the initializer list has no elements and <TT>T</TT> has a default
constructor, the first phase is omitted.

</BLOCKQUOTE>

<P>However, this case cannot occur. If <TT>T</TT> is a non-aggregate
class type with a default constructor and the initializer is an
empty initializer list, the object will be value-constructed, per
9.5.5 [<A href="https://wg21.link/dcl.init.list#3.4">dcl.init.list</A>] bullet 3.4. Overload resolution is only
necessary if default-initialization (or a check of its semantic
constraints) is implied, with the relevant section concerning
candidates for overload resolution being 12.2.2.4 [<A href="https://wg21.link/over.match.ctor">over.match.ctor</A>].</P>

<P>See also <A HREF="cwg_defects.html#1518">issue 1518</A>.</P>

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

<P>Change 12.2.2.8 [<A href="https://wg21.link/over.match.list#1">over.match.list</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<P>When objects of non-aggregate class type <TT>T</TT> are list-initialized
such that 9.5.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>] specifies that overload resolution is
performed according to the rules in this section, overload resolution
selects the constructor in two phases:</P>

<UL>
<LI><P>Initially, the candidate functions are the initializer-list
constructors (9.5.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]) of the class <TT>T</TT> and the
argument list consists of the initializer list as a single
argument.</P></LI>

<LI><P>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 the argument list consists of the
elements of the initializer list.</P></LI>

</UL>

<P>
<DEL>If the initializer list has no elements and <TT>T</TT> has a
default constructor, the first phase is omitted.</DEL> In
copy-list-initialization, if an explicit constructor is chosen...</P>

</BLOCKQUOTE>

<P><B>Additional notes, February, 2017:</B></P>

<P>The statement of the issue is incorrect. In an example like</P>

<PRE>
  struct A { A(); A(initializer_list&lt;int&gt;); };
  void f(A a);
  int main() { f({}); }
</PRE>

<P>the rule in question is not used for the initialization of the
parameter. However, it is used to determine whether a valid implicit
conversion sequence exists for <TT>a</TT>. It is unclear whether an
additional change to resolve this discrepancy is needed or not.</P>

<BR><BR><HR>
<A NAME="2467"></A><H4>2467.
  
CTAD for alias templates and the deducible check
</H4>
<B>Section: </B>12.2.2.9&#160; [<A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2019-08-12<BR>




<P>Given the declarations</P>

<PRE>
  template&lt;typename T = int&gt; using X = vector&lt;int&gt;;
  X x = {1, 2, 3};

  template&lt;typename...&gt; using Y = vector&lt;int&gt;;
  Y y = {1, 2, 3};
</PRE>

<P>CTAD deduces <TT>vector&lt;int&gt;</TT>. Then we are asked
to perform a check that the arguments of <TT>X</TT> and
<TT>Y</TT> are deducible from <TT>vector&lt;int&gt;</TT>.</P>



<P>I think this check should succeed, deducing <TT>T =
int</TT> in the first case
and <TT>&lt;</TT><I>pack</I><TT>&gt; =
&lt;</TT><I>empty</I><TT>&gt;</TT> in the second case, so
both declarations should be valid.  That seems consistent
with what would happen for a non-alias with template
parameters that CTAD can't deduce, where there is either a
default template argument or the parameter is a pack.  But
what actually happens is that we're asked to form</P>

<PRE>
  template&lt;typename T&gt; struct AA;
  template&lt;typename T = int&gt; struct AA&lt;X&lt;T&gt;&gt;;
</PRE>

<P>and</P>

<PRE>
  template&lt;typename T&gt; struct AA;
  template&lt;typename ...Ts&gt; struct AA&lt;Y&lt;Ts...&gt;&gt;;
</PRE>

<P>However, both of those partial specializations are
ill-formed: a partial specialization can't have default
template arguments, and neither of these is more specialized
than the primary template, because <TT>T</TT> / <TT>Ts</TT>
are not used in deducible contexts.</P>

<P>I think we have the wrong model here, and should instead be
considering (effectively) whether function template argument
deduction would succeed for</P>

<PRE>
  template&lt;typename T&gt; struct AA {};
  template&lt;typename T = int&gt; void f(AA&lt;X&lt;T&gt;&gt;);
</PRE>

<P>and</P>

<PRE>
  template&lt;typename T&gt; struct AA {};
  template&lt;typename ...Ts&gt; void f(AA&lt;Y&lt;Ts...&gt;&gt;);
</PRE>

<P>respectively, when given an argument of
type <TT>AA&lt;</TT><I>deduced return type</I><TT>&gt;</TT>.
That is, get rid of the weird class template partial
specialization restrictions, and instead add in the rules
from function templates to use default template arguments
and to default non-deduced packs to empty packs.</P>

<BR><BR><HR>
<A NAME="2471"></A><H4>2471.
  
Nested class template argument deduction
</H4>
<B>Section: </B>12.2.2.9&#160; [<A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2021-01-26<BR>


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

<PRE>
  template&lt;class T&gt; struct S {
    template&lt;class U&gt; struct N {
      N(T) {}
      N(T, U) {}
      template&lt;class V&gt; N(V, U) {}
    };
  };
  S&lt;int&gt;::N x{2.0, 1};
</PRE>

<P>The description of CTAD in 12.2.2.9 [<A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>]
doesn't really specify how nested classes work. If you are
supposed to deduce all the enclosing class template
arguments, the example is ill-formed because there is no
way to deduce <TT>T</TT>. If you are supposed to consider
<TT>S&lt;int&gt;::N</TT> as having a new constructor
template, then it should probably be well-formed.</P>

<P><B>Notes from the March, 2021 teleconference:</B></P>

<P>CWG agreed that the intent is to use the partially-instantiated
inner template with the explicitly-specified template argument
<TT>int</TT>.</P>

<BR><BR><HR>
<A NAME="2319"></A><H4>2319.
  
Nested brace initialization from same type
</H4>
<B>Section: </B>12.2.4.2&#160; [<A href="https://wg21.link/over.best.ics">over.best.ics</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2016-09-06<BR>




<P>Consider:</P>

<PRE>
  struct A { A(); } a;
  A a1 = {a}, a2 = {{a}}, a3 = {{{a}}};
</PRE>

<P>
<TT>a1</TT> and <TT>a2</TT> are valid, <TT>a3</TT> is ill-formed,
because 12.2.4.2 [<A href="https://wg21.link/over.best.ics#4.5">over.best.ics</A>] bullet 4.5 allows one pair of
braces and 12.2.4.2.6 [<A href="https://wg21.link/over.ics.list#2">over.ics.list</A>] paragraph 2 allows a second
pair of braces.  The implicit conversion sequence from <TT>{{a}}</TT>
to <TT>A</TT> is a user-defined conversion.</P>

<P>Prior to the list-initialization-from-same-type changes via issues
<A HREF="cwg_defects.html#1467">1467</A> and
<A HREF="cwg_defects.html#2076">2076</A>, <TT>a2</TT> was ill-formed like
<TT>a3</TT>.</P>

<P>Is this intended, or did DR2076 not go far enough in reintroducing
the restriction? Perhaps a more extreme rule, such as saying that a
copy/move constructor is simply not a candidate for
list-initialization from a list that contains one element that is
itself a list, would work better?</P>

<P><B>Notes from the July, 2017 meeting:</B></P>

<P>CWG agreed that the <TT>a2</TT> example should be ill-formed but that
the <TT>a1</TT> example must remain for C compatibility.</P>

<BR><BR><HR>
<A NAME="2077"></A><H4>2077.
  
Overload resolution and invalid rvalue-reference initialization
</H4>
<B>Section: </B>12.2.4.2.5&#160; [<A href="https://wg21.link/over.ics.ref">over.ics.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-01-29<BR>




<P>The resolution of <A HREF="cwg_defects.html#1604">issue 1604</A> broke
the following example:</P>

<PRE>
  struct A {};
  struct B { operator const A() const; };
  void f(A const&amp;);
  void f(A&amp;&amp;);

  int main() {
    B a;
    f(a);
  }
</PRE>

<P>Overload resolution selects the <TT>A&amp;&amp;</TT> overload,
but then initialization fails. This seems like a major regression;
we're now required to reject</P>

<PRE>
   std::vector&lt;A&gt; va;
   B b;
   va.push_back(b);
</PRE>

<P>Should we update 12.2.4.2.5 [<A href="https://wg21.link/over.ics.ref">over.ics.ref</A>] to match
the changes made to 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]?</P>

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

<BR><BR><HR>
<A NAME="1536"></A><H4>1536.
  
Overload resolution with temporary from initializer list
</H4>
<B>Section: </B>12.2.4.2.6&#160; [<A href="https://wg21.link/over.ics.list">over.ics.list</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2012-08-14<BR>


<P>In determining the implicit conversion sequence for an initializer list
argument passed to a reference parameter, the intent is that a temporary
of the appropriate type will be created and bound to the reference, as
reflected in 12.2.4.2.6 [<A href="https://wg21.link/over.ics.list#5">over.ics.list</A>] paragraph 5:</P>

<BLOCKQUOTE>

Otherwise, if the parameter is a reference, see 12.2.4.2.5 [<A href="https://wg21.link/over.ics.ref">over.ics.ref</A>].  [<I>Note:</I> The rules in this section will
apply for initializing the underlying temporary for the reference.
&#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>However, 12.2.4.2.5 [<A href="https://wg21.link/over.ics.ref">over.ics.ref</A>] deals only with expression
arguments, not initializer lists:</P>

<BLOCKQUOTE>

<P>When a parameter of reference type binds directly (9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]) to an argument expression, the implicit conversion
sequence is the identity conversion, unless the argument expression
has a type that is a derived class of the parameter type, in which
case the implicit conversion sequence is a derived-to-base Conversion
(12.2.4.2 [<A href="https://wg21.link/over.best.ics">over.best.ics</A>])... If the parameter binds directly to
the result of applying a conversion function to the argument
expression, the implicit conversion sequence is a user-defined
conversion sequence (12.2.4.2.3 [<A href="https://wg21.link/over.ics.user">over.ics.user</A>]), with the second
standard conversion sequence either an identity conversion or, if the
conversion function returns an entity of a type that is a derived
class of the parameter type, a derived-to-base Conversion.
</P>

<P>When a parameter of reference type is not bound directly to an
argument expression, the conversion sequence is the one required to
convert the argument expression to the underlying type of the
reference according to 12.2.4.2 [<A href="https://wg21.link/over.best.ics">over.best.ics</A>].  Conceptually,
this conversion sequence corresponds to copy-initializing a temporary
of the underlying type with the argument expression.  Any difference
in top-level cv-qualification is subsumed by the initialization itself
and does not constitute a conversion.
</P>

</BLOCKQUOTE>

<P>(Note in particular that the reference binding refers to
9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>], which also does not handle initializer
lists, and not to 9.5.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>].)</P>

<P>Either 12.2.4.2.5 [<A href="https://wg21.link/over.ics.ref">over.ics.ref</A>] needs to be revised to
handle binding references to initializer list arguments or
12.2.4.2.6 [<A href="https://wg21.link/over.ics.list#5">over.ics.list</A>] paragraph 5 needs to be clearer on how
the expression specification is intended to be applied to
initializer lists.</P>



<BR><BR><HR>
<A NAME="2110"></A><H4>2110.
  
Overload resolution for base class conversion and reference/non-reference
</H4>
<B>Section: </B>12.2.4.3&#160; [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Alexander Kulpin
 &#160;&#160;&#160;

 <B>Date: </B>2015-03-27<BR>




<P>There are overload tiebreakers that order reference/nonreference
and base/derived conversions, but how they relate is not specified.
For example:</P>

<PRE>
  struct A { A(); };
  struct B : A {};
  struct C : B {};

  void f1(B&amp;);
  void f1(A);

  void f2(B);
  void f2(A&amp;);

  int main()
  {
     C v;
     f1(v); //<SPAN CLASS="cmnt"> all compilers choose </SPAN>f1(B&amp;)
     f2(v); //<SPAN CLASS="cmnt"> all compilers choose </SPAN>f2(B)
  }
</PRE>

<P>The Standard does not appear to specify what happens in this
case.</P>

<BR><BR><HR>
<A NAME="1989"></A><H4>1989.
  
Insufficient restrictions on parameters of postfix operators
</H4>
<B>Section: </B>12.4&#160; [<A href="https://wg21.link/over.oper">over.oper</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-08-30<BR>


<P>According to 12.4.7 [<A href="https://wg21.link/over.inc#1">over.inc</A>] paragraph 1,</P>

<BLOCKQUOTE>

The user-defined function called <TT>operator++</TT> implements the
prefix and postfix <TT>++</TT> operator. If this function is a
non-static member function with no parameters, or a
non-member function with one parameter, it defines the
prefix increment operator <TT>++</TT> for objects of that type. If
the function is a non-static member function with one
parameter (which shall be of type <TT>int</TT>) or a non-member
function with two parameters (the second of which shall be
of type <TT>int</TT>), it defines the postfix increment operator <TT>++</TT>
for objects of that type.

</BLOCKQUOTE>

<P>According to 12.4 [<A href="https://wg21.link/over.oper#8">over.oper</A>] paragraph 8,</P>

<BLOCKQUOTE>

Operator functions cannot have more or fewer parameters than
the number required for the corresponding operator, as
described in the rest of this subclause.

</BLOCKQUOTE>

<P>This does not rule out an <TT>operator++</TT> with more than two
parameters, however, since there is no corresponding operator.</P>

<P>One possibility might be to add a sentence like,</P>

<BLOCKQUOTE>

A function named <TT>operator++</TT> shall declare either a prefix
or postfix increment operator.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="205"></A><H4>205.
  
Templates and static data members
</H4>
<B>Section: </B>Clause 13&#160; [<A href="https://wg21.link/temp">temp</A>]
 &#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,
Clause 13 [<A href="https://wg21.link/temp#1">temp</A>] 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,
Clause 13 [<A href="https://wg21.link/temp#6">temp</A>] 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 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#4">dcl.fct.default</A>] 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="1463"></A><H4>1463.
  
<TT>extern "C"</TT> alias templates
</H4>
<B>Section: </B>13.1&#160; [<A href="https://wg21.link/temp.pre">temp.pre</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-08-19
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>Currently 13.1 [<A href="https://wg21.link/temp.pre#6">temp.pre</A>] paragraph 6 forbids any template
from having C linkage. Should alias templates be exempt from this
prohibition, since they do not have any linkage?</P>

<P><B>Additional note, April, 2013:</B></P>

<P>It was suggested 
that relaxing this restriction for alias templates could provide a
way of addressing the long-standing lack of a way of specifying a
language linkage for a dependent function type (see
<A HREF="cwg_closed.html#13">issue 13</A>).  </P>

<P><B>Rationale (April, 2013):</B></P>

<P>CWG felt that this suggested use of alias templates should be considered in
a broader context and thus was more appropriate for EWG.</P>

<P><B>EWG 2022-11-11</B></P>

<P>
<TT>extern "C"</TT> on a template should be allowed, and should
affect only calling convention, but not mangling.
This is tracked in github issue
<A HREF="https://github.com/cplusplus/papers/issues/1373">cplusplus/papers#1373</A>.
</P>

<BR><BR><HR>
<A NAME="1444"></A><H4>1444.
  
Type adjustments of non-type template parameters
</H4>
<B>Section: </B>13.2&#160; [<A href="https://wg21.link/temp.param">temp.param</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2012-01-15<BR>




<P>The type adjustment of template non-type parameters described in
13.2 [<A href="https://wg21.link/temp.param#8">temp.param</A>] paragraph 8 appears to be underspecified.  For
example, implementations vary in their treatment of</P>

<PRE>
  template&lt;typename T, T[T::size]&gt; struct A {};
  int dummy;
  A&lt;int, &amp;dummy&gt; a;
</PRE>

<P>and</P>

<PRE>
  template&lt;typename T, T[1]&gt; struct A;
  template&lt;typename T, T*&gt; struct A {};
  int dummy;
  A&lt;int, &amp;dummy&gt; a;
</PRE>

<P>See also issues <A HREF="cwg_active.html#1322">1322</A> and
<A HREF="cwg_active.html#1668">1668</A>.</P>

<P><B>Additional note, February, 2021:</B></P>

<P>See the discussion regarding top-level cv-qualifiers
on template parameters when determining the type in
<A HREF="https://bugs.llvm.org/show_bug.cgi?id=47792">this
compiler bug report</A>.
</P>

<BR><BR><HR>
<A NAME="1635"></A><H4>1635.
  
How similar are template default arguments to function default arguments?
</H4>
<B>Section: </B>13.2&#160; [<A href="https://wg21.link/temp.param">temp.param</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-06<BR>




<P>Default function arguments are instantiated only when needed.  Is
the same true of default template arguments?  For example, is the
following well-formed?</P>

<PRE>
  #include &lt;type_traits&gt;

  template&lt;class T&gt;
  struct X {
    template&lt;class U = typename T::type&gt;
    static void foo(int){}
    static void foo(...){}
  };

  int main(){
    X&lt;std::enable_if&lt;false&gt;&gt;::foo(0);
  }
</PRE>

<P>Also, is the effect on lookup the same?  E.g.,</P>

<PRE>
  struct S {
    template&lt;typename T = U&gt; void f();
    struct U {};
  };
</PRE>

<P><B>Additional note (November, 2020):</B></P>

<P>Paper P1787R6, adopted at the November, 2020 meeting, partially
addresses this issue.</P>

<BR><BR><HR>
<A NAME="2395"></A><H4>2395.
  
Parameters following a pack expansion
</H4>
<B>Section: </B>13.2&#160; [<A href="https://wg21.link/temp.param">temp.param</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2018-12-03<BR>


<P>The Standard is not clear, and there is implementation divergence,
for an example like the following:</P>

<PRE>
  template&lt;class ...Types&gt; struct Tuple_ { //<SPAN CLASS="cmnt"> _VARIADIC_TEMPLATE </SPAN>
    template&lt;Types ...T, int I&gt; int f() {
      return sizeof...(Types);
    }
  };
  int main() {
    Tuple_&lt;char,int&gt; a;
    int b = a.f&lt;1, 2, 3&gt;();
  }
</PRE>

<P>The question is whether the <TT>3</TT> is accepted as the
argument for <TT>I</TT> or an error, exceeding the number of
arguments for <TT>T</TT>, which is set as 2 by the template
arguments for <TT>Tuple_</TT>. See also
<A HREF="cwg_closed.html#2383">issue 2383</A> for a related
example.</P>

<BR><BR><HR>
<A NAME="2903"></A><H4>2903.
  
Can we omit the <TT>template</TT> disambiguator in <I>nested-name-specifier</I>s in type-only contexts?
</H4>
<B>Section: </B>13.3&#160; [<A href="https://wg21.link/temp.names">temp.names</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2024-06-13<BR>




<P>Are the following examples well-formed?  Note the absence of
a <TT>template</TT> disambiguator:</P>

<PRE>
  template&lt;typename T&gt; class C {
   T::X&lt;int&gt; g1();      // <SPAN CLASS="cmnt">#1</SPAN>
   T::X&lt;int&gt;::Y g2();   // <SPAN CLASS="cmnt">#2</SPAN>
  };

  template&lt;typename T&gt;
  T::X&lt;int&gt; h1();       // <SPAN CLASS="cmnt">#3</SPAN>
  template&lt;typename T&gt;
  T::X&lt;int&gt;::Y h2();    // <SPAN CLASS="cmnt">#4</SPAN>
</PRE>

<P>The return type is a type-only context per
13.8.1 [<A href="https://wg21.link/temp.res.general#4">temp.res.general</A>] paragraph 4.  However,
13.3 [<A href="https://wg21.link/temp.names#3">temp.names</A>] paragraph 3
excludes <I>nested-name-specifier</I>s from the set of situations
where <TT>template</TT> can be omitted. That means that #1 and #3
are valid; <TT>X</TT> is not part of a <I>nested-name-specifier</I>.
However, #2 and #4 are invalid; the <TT>template</TT> disambiguator is
missing.  Those examples ought to be valid, too.</P>

<P><B>Proposed resolution (approved by CWG 2024-06-14):</B></P>

<P>Change in 13.3 [<A href="https://wg21.link/temp.names#3">temp.names</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<INS>A name is in a <I>transitive type-only context</I>
if</INS>
<UL class="ins">
<LI>
it is in a type-only context (13.8.1 [<A href="https://wg21.link/temp.res.general">temp.res.general</A>]) and is not
the terminal name of a <I>nested-name-specifier</I>, or</LI>
<LI>it is the terminal name of a <I>nested-name-specifier</I> that
precedes a name in a transitive type-only context (possibly with an
intervening <TT>template</TT> keyword).
</LI>
</UL>

A &lt; is interpreted as the delimiter of
a <I>template-argument-list</I> if it follows a name that is not
a <I>conversion-function-id</I> and
<UL>
<LI>that follows the keyword template or a ~ after
a <I>nested-name-specifier</I> or in a class member access expression,
or</LI>
<LI>for which name lookup finds the injected-class-name of a class
template or finds any declaration of a template, or
</LI>
<LI>that is an unqualified name for which name lookup either finds one
or more functions or finds nothing, or</LI>
<LI>that is a terminal name in a <I>using-declarator</I>
(9.10 [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]), in a <I>declarator-id</I>
(9.3.4 [<A href="https://wg21.link/dcl.meaning">dcl.meaning</A>]), or in a <INS>transitive</INS> type-only context <DEL>other than
a <I>nested-name-specifier</I> (13.8 [<A href="https://wg21.link/temp.res">temp.res</A>])</DEL>.</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2043"></A><H4>2043.
  
Generalized template arguments and array-to-pointer decay
</H4>
<B>Section: </B>13.4.3&#160; [<A href="https://wg21.link/temp.arg.nontype">temp.arg.nontype</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-11-13<BR>


<P>According to 13.4.3 [<A href="https://wg21.link/temp.arg.nontype#1">temp.arg.nontype</A>] paragraph 1 (newly revised
by the adoption of paper N4268),</P>

<BLOCKQUOTE>

<P>For a non-type <I>template-parameter</I> of reference or pointer type, the
value of the constant expression shall not refer to (or for a pointer type,
shall not be the address of):</P>

<UL>
<LI><P>a subobject (6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]),</P></LI>

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

</UL>

</BLOCKQUOTE>

<P>This change breaks an example like</P>

<PRE>
   template&lt;int *p&gt; struct X {};
   int arr[32];
   X&lt;arr&gt; x;
</PRE>

<P>because the array-to-pointer decay produces a pointer to the first
element, which is a subobject.</P>

<P><U>Suggested resolution:</U></P>

<P>Change the referenced bullet to read:</P>

<UL>
<LI><P>a subobject (6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>])
<INS>that is not the first element of a complete object of array
type</INS>,</P></LI>

</UL>

<P>Note that this resolution also allows an example like</P>

<PRE>
    template&lt;char &amp;p&gt; struct S { };
    char arr[2];
    S&lt;arr[0]&gt; s_arr;
</PRE>

<P>which may not be exactly what we want.</P>

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

<BR><BR><HR>
<A NAME="2401"></A><H4>2401.
  
Array decay vs prohibition of subobject non-type arguments
</H4>
<B>Section: </B>13.4.3&#160; [<A href="https://wg21.link/temp.arg.nontype">temp.arg.nontype</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

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


<P>Consider an example like:</P>

<PRE>
  template &lt;const char *N&gt; struct A { static const int val; };

  template &lt;const char *N&gt; const int A&lt;N&gt;::val = 0;

  static const char c[2] = "";

  int main() {
    A&lt;c&gt; a;
    return A&lt;c&gt;::val;
  }
</PRE>

<P>Formally, this appears to violate the prohibition of using the
address of a subobject as a non-type template argument, since
the array reference <TT>c</TT> in the argument decays to a pointer
to the first element of the array. However, at least some
implementations accept this example, and at least conceptually the
template argument designates the complete object. Should an
exception be made for the result of array decay?</P>

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

<P><B>Notes from the July, 2019 meeting</B></P>

<P>CWG felt that the example should be allowed if the parameter type
is a pointer to object type (thus prohibiting <TT>void*</TT>).</P>

<BR><BR><HR>
<A NAME="2057"></A><H4>2057.
  
Template template arguments with default arguments
</H4>
<B>Section: </B>13.4.4&#160; [<A href="https://wg21.link/temp.arg.template">temp.arg.template</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-12-12<BR>




<P>It is not clear how to handle an example like:</P>

<PRE>
  template&lt;typename T1, typename T2 = char&gt; class A { };

  template&lt;template&lt;typename... T&gt; class X&gt; class S {
    X&lt;int&gt; x;
  };

  S&lt;A&gt; a;
</PRE>

<P>
<A HREF="cwg_defects.html#184">Issue 184</A> dealt with a similar question
but did so in the era before variadic templates.  This usage should
be permitted in modern C++.</P>

<P><B>Notes from the February, 2016 meeting:</B></P>

<P>CWG felt that this usage should be permitted, but only
for template template parameters with a parameter pack..
Furthermore, if the template template parameter has a
default argument followed by a parameter pack, the
parameter's default argument would be used, followed by any
remaining default arguments from the template template
argument.</P>

<BR><BR><HR>
<A NAME="2398"></A><H4>2398.
  
Template template parameter matching and deduction
</H4>
<B>Section: </B>13.4.4&#160; [<A href="https://wg21.link/temp.arg.template">temp.arg.template</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-12-03<BR>




<P>Do the changes from
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0522r0.html">P0522R0</A>
regarding template template parameter matching apply to
deduction? For example:</P>

<PRE>
  template&lt;class T, class U = T&gt; class B { /* ... */ };
  template&lt;template&lt;class&gt; class P, class T&gt; void f(P&lt;T&gt;);

  int main()  {
    f(B&lt;int&gt;());       //<SPAN CLASS="cmnt"> OK?</SPAN>
    f(B&lt;int,float&gt;()); //<SPAN CLASS="cmnt"> ill-formed, T deduced to int and float</SPAN>
  }
</PRE>

<P>In deduction we can determine that <TT>P</TT> is more
specialized than <TT>B</TT>, then substitute <TT>B</TT>
into <TT>P&lt;T&gt;</TT>, and then
compare <TT>B&lt;T,T&gt;</TT> to <TT>B&lt;int,int&gt;</TT>.
This will allow deduction to succeed, whereas
comparing <TT>&lt;T&gt;</TT> to <TT>&lt;int,int&gt;</TT> without
this substitution would fail.  I suppose this is similar to
deducing a type parameter, substituting it into the type of
a non-type parameter, then deducing the value of the
non-type parameter</P>

<P>Does this make sense? Do we need more wording?</P>

<P>Consider also this example;</P>

<PRE>
  template&lt;typename&gt; struct match;

  template&lt;template&lt;typename&gt; class t,typename T&gt;
  struct match&lt;t&lt;T&gt; &gt; { typedef int type; };      //<SPAN CLASS="cmnt"> #1</SPAN>

  template&lt;template&lt;typename,typename&gt; class t,typename T0,typename T1&gt;
  struct match&lt;t&lt;T0,T1&gt; &gt; { typedef int type; };  //<SPAN CLASS="cmnt"> #2</SPAN>

  template&lt;typename,typename = void&gt; struct other { };
  typedef match&lt;other&lt;void,void&gt; &gt;::type type;
</PRE>

<P>Before this change, partial specialization #1 was not a
candidate; now it is, and neither partial specialization is
at least as specialized as the other, so we get an
ambiguity.  It seems that the consistent way to address this
would be to use <TT>other</TT> during partial ordering, so
we'd be comparing</P>

<PRE>
  template&lt;typename T&gt;
  void fn (match&lt;other&lt;T&gt;&gt;); //<SPAN CLASS="cmnt"> i.e. </SPAN>other&lt;T,void&gt;
  template&lt;typename T0, typename T1&gt;
  void fn (match&lt;other&lt;T0,T1&gt;&gt;);
</PRE>

<P>So #1 is more specialized, whereas before this change we
chose #2.</P>

<P><B>Additional notes (May, 2024)</B></P>

<P>Paper
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3310r0.html">P3310R0</A>
(Solving partial ordering issues introduced by P0522R0)
by Matheus Izvekov
strives to solve this issue, currently with focus on partial ordering (only).
</P>

<BR><BR><HR>
<A NAME="2037"></A><H4>2037.
  
Alias templates and template declaration matching
</H4>
<B>Section: </B>13.6&#160; [<A href="https://wg21.link/temp.type">temp.type</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-11-06<BR>




<P>For the following example,</P>

<PRE>
  template&lt;int N&gt; struct A {};
  template&lt;short N&gt; using B = A&lt;N&gt;;
  template&lt;int N&gt; void f(B&lt;N&gt;) {} //<SPAN CLASS="cmnt"> #1</SPAN>
  template&lt;int N&gt; void f(A&lt;N&gt;) {} //<SPAN CLASS="cmnt"> #2</SPAN>
</PRE>

<P>There is implementation variance as to whether there is one
<TT>f</TT> or two.  As with previously-discussed cases, these
have different SFINAE effects, perhaps equivalent but not
functionally equivalent.  Should the argument to #1 be treated
as something like <TT>A&lt;(int)(short)N&gt;</TT> and not just
<TT>A&lt;N&gt;</TT>.</P>

<P>See also issues <A HREF="cwg_active.html#1668">1668</A> and
<A HREF="cwg_active.html#1979">1979</A>.</P>

<BR><BR><HR>
<A NAME="1730"></A><H4>1730.
  
Can a variable template have an unnamed type?
</H4>
<B>Section: </B>13.7&#160; [<A href="https://wg21.link/temp.decls">temp.decls</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Larisse Voufo
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-05<BR>




<P>Is it permitted for a variable template to have an unnamed
type?</P>

<BR><BR><HR>
<A NAME="1647"></A><H4>1647.
  
Type agreement of non-type template arguments in partial specializations
</H4>
<B>Section: </B>13.7.6&#160; [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-04<BR>


<P>The Standard appears to be silent on whether the types of
non-type template arguments in a partial specialization must be
the same as those of the primary template or whether conversions
are permitted.  For example,</P>

<PRE>
  template&lt;char...&gt; struct char_values {};
  template&lt;int C1, char C3&gt;
  struct char_values&lt;C1, 12, C3&gt; {
    static const unsigned value = 1;
  };
  int check0[char_values&lt;1, 12, 3&gt;::value == 1? 1 : -1];
</PRE>

<P>The closest the current wording comes to dealing with this
question is 13.7.6.1 [<A href="https://wg21.link/temp.spec.partial.general#9.1">temp.spec.partial.general</A>] bullet 9.1:</P>

<UL>
<LI><P>A partially specialized non-type argument expression shall
not involve a template parameter of the partial
specialization except when the argument expression is a
simple <I>identifier</I>.</P></LI>

</UL>

<P>In this example, one might think of the first template argument
in the partial specialization as <TT>(char)C1</TT>, which would
violate the requirement, but that reasoning is tenuous.</P>

<P>It would be reasonable to require the types to match in
cases like this.  If this kind of usage is allowed it could
get messy if the primary template were <TT>int...</TT> and
the partial specialization had a parameter that
was <TT>char</TT> because not all of the possible values
from the primary template could be represented in the
parameter of the partial specialization.  A similar issue
exists if the primary template takes <TT>signed char</TT>
and the partial specialization takes <TT>unsigned
int</TT>.</P>

<P>There is implementation variance in the treatment of this
example.</P>

<P>(See also issues <A HREF="cwg_defects.html#1315">1315</A>,
<A HREF="cwg_defects.html#2033">2033</A>, and
<A HREF="cwg_active.html#2127">2127</A>.)</P>

<BR><BR><HR>
<A NAME="2127"></A><H4>2127.
  
Partial specialization and nullptr
</H4>
<B>Section: </B>13.7.6&#160; [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Faisal Vali
 &#160;&#160;&#160;

 <B>Date: </B>2015-05-18<BR>




<P>An example like the following would seem to be plausible:</P>

<PRE>
  template&lt;class T, T*&gt; struct X { };
  //<SPAN CLASS="cmnt"> We want to partially specialize for all nullptrs...</SPAN>
  template&lt;class T&gt; struct X&lt;T, nullptr&gt; { ... }; //<SPAN CLASS="cmnt"> NOT OK</SPAN>
</PRE>

<P>This is disallowed by the rule in bullet 9.2 of
13.7.6.1 [<A href="https://wg21.link/temp.spec.partial.general">temp.spec.partial.general</A>]:</P>

<UL><LI><P>The type of a template parameter corresponding to a
specialized non-type argument shall not be dependent on a
parameter of the specialization.</P></LI></UL>

<P>(See also issues <A HREF="cwg_defects.html#1315">1315</A>,
<A HREF="cwg_active.html#1647">1647</A>, and
<A HREF="cwg_defects.html#2033">2033</A>.)</P>



<BR><BR><HR>
<A NAME="2179"></A><H4>2179.
  
Required diagnostic for partial specialization after first use
</H4>
<B>Section: </B>13.7.6.1&#160; [<A href="https://wg21.link/temp.spec.partial.general">temp.spec.partial.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2015-10-12<BR>


<P>According to 13.7.6.1 [<A href="https://wg21.link/temp.spec.partial.general#1">temp.spec.partial.general</A>] paragraph 1,</P>

<BLOCKQUOTE>

A partial specialization shall be declared before the first
use of a class template specialization that would make use
of the partial specialization as the result of an implicit
or explicit instantiation in every translation unit in which
such a use occurs; no diagnostic is required.

</BLOCKQUOTE>

<P>There are two problems with this wording.  First, the
&#8220;no diagnostic required&#8221; provision is presumably
to avoid mandating cross-translation-unit analysis, but there
is no reason not to require the diagnostic if the rule is
violated within a single translation unit.  Also, &#8220;would
make use&#8221; is imprecise; it could be interpreted as
applying only when the partial specialization would have been
selected by a previous specialization, but it should also apply to
cases where the partial specialization would have made a
previous specialization ambiguous.</P>

<P>Making these two changes would guarantee that a diagnostic is
issued for the following example:</P>

<PRE>
   template &lt;class T1, class T2&gt; class A;
   template &lt;class T&gt; struct A&lt;T, void&gt; { void f(); };
   template &lt;class T&gt; void g(T) { A&lt;char, void&gt;().f(); }   //<SPAN CLASS="cmnt"> #1</SPAN>
   template&lt;typename T&gt; struct A&lt;char, T&gt; {};
   A&lt;char, void&gt; f;   //<SPAN CLASS="cmnt"> #2</SPAN>
</PRE>

<P>It is unspecified whether the reference to
<TT>A&lt;char, void&gt;</TT> at #1 is the &#8220;first
use&#8221; or not.  If so, <TT>A&lt;char, void&gt;</TT>
is bound to the first partial specialization and, under the
current wording, an implementation is not required to
diagnose the ambiguity resulting from the second partial
specialization.  If #2 is the &#8220;first use,&#8221; it is
clearly ambiguous and must result in a diagnostic.  There is
implementation divergence on the handling of this example
that would be addressed by the suggested changes.</P>

<BR><BR><HR>
<A NAME="549"></A><H4>549.
  
Non-deducible parameters in partial specializations
</H4>
<B>Section: </B>13.7.6.2&#160; [<A href="https://wg21.link/temp.spec.partial.match">temp.spec.partial.match</A>]
 &#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>(See also <A HREF="cwg_defects.html#1246">issue 1246</A>.)</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>



<P><B>Additional note, December, 2021:</B></P>

<P>The original issue, but not the *#8220;similar
issues *#8221; pointed out in the 2006-04 note, was resolved
by the changes for <A HREF="cwg_defects.html#1315">issue 1315</A>
and paper P0127R2.</P>

<BR><BR><HR>
<A NAME="1755"></A><H4>1755.
  
Out-of-class partial specializations of member templates
</H4>
<B>Section: </B>13.7.6.4&#160; [<A href="https://wg21.link/temp.spec.partial.member">temp.spec.partial.member</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-19<BR>




<P>According to 13.7.6.4 [<A href="https://wg21.link/temp.spec.partial.member#2">temp.spec.partial.member</A>] paragraph 2,</P>

<BLOCKQUOTE>

If a member template of a class template is partially specialized, the
member template partial specializations are member templates of the
enclosing class template; if the enclosing class template is instantiated
(13.9.2 [<A href="https://wg21.link/temp.inst">temp.inst</A>], 13.9.3 [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]), a declaration
for every member template partial specialization is also instantiated as
part of creating the members of the class template specialization.

</BLOCKQUOTE>

<P>Does this imply that only partial specializations of member templates
that are declared before the enclosing class is instantiated are
considered?  For example, in</P>

<PRE>
  template&lt;typename A&gt; struct X { template&lt;typename B&gt; struct Y; };
  template struct X&lt;int&gt;;
  template&lt;typename A&gt; template&lt;typename B&gt; struct X&lt;A&gt;::Y&lt;B*&gt; { int n; };
  int k = X&lt;int&gt;::Y&lt;int*&gt;().n;
</PRE>

<P>is the last line valid?  There is implementation variance on this
point.  Similarly, for an example like</P>

<PRE>
  template&lt;typename A&gt; struct Outer {
   template&lt;typename B, typename C&gt; struct Inner;
  };
  Outer&lt;int&gt; outer;
  template&lt;typename A&gt; template&lt;typename B&gt;
    struct Outer&lt;A&gt;::Inner&lt;typename A::error, B&gt; {};
</PRE>

<P>at what point, if at all, is the declaration of the partial
specialization instantiated?  Again, there is implementation variance in
the treatment of this example.</P>

<P><B>Notes from the February, 2014 meeting:</B></P>

<P>CWG decided that partial specialization declarations should be
instantiated only when needed to determine whether the partial
specialization matches or not.</P>

<P><B>Additional note, November, 2014:</B></P>

<P>See also paper N4090.</P>

<BR><BR><HR>
<A NAME="1554"></A><H4>1554.
  
Access and alias templates
</H4>
<B>Section: </B>13.7.8&#160; [<A href="https://wg21.link/temp.alias">temp.alias</A>]
 &#160;&#160;&#160;

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

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

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




<P>The interaction of alias templates and access control is not clear
from the current wording of 13.7.8 [<A href="https://wg21.link/temp.alias">temp.alias</A>].  For
example:</P>

<PRE>
  template &lt;class T&gt; using foo = typename T::foo;

  class B {
    typedef int foo;
    friend struct C;
  };

  struct C {
    foo&lt;B&gt; f;    //<SPAN CLASS="cmnt"> Well-formed?</SPAN>
  };
</PRE>

<P>Is the substitution of <TT>B::foo</TT> for <TT>foo&lt;B&gt;</TT>
done in the context of the befriended class <TT>C</TT>, making the
reference well-formed, or is the access determined independently of
the context in which the alias template specialization appears?</P>

<P>If the answer to this question is that the access is determined
independently from the context, care must be taken to ensure that an
access failure is still considered to be &#8220;in the immediate
context of the function type&#8221; (13.10.3 [<A href="https://wg21.link/temp.deduct#8">temp.deduct</A>] paragraph 8)
 so that it results in a deduction failure rather than
a hard error.</P>

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

<P>The consensus of CWG was that instantiation (lookup and access)
for alias templates should be as for other templates, in the definition
context rather than in the context where they are used.  They should
still be expanded immediately, however.</P>

<P><B>Additional note (February, 2014):</B></P>

<P>A related problem is raised by the definition of
<TT>std::enable_if_t</TT> (21.3.3 [<A href="https://wg21.link/meta.type.synop">meta.type.synop</A>]):</P>

<PRE>
  template &lt;bool b, class T = void&gt;
  using enable_if_t = typename enable_if&lt;b,T&gt;::type;
</PRE>

<P>If <TT>b</TT> is <TT>false</TT>, there will be no <TT>type</TT>
member.  The intent is that such a substitution failure is to be
considered as being &#8220;in the immediate context&#8221; where the
alias template specialization is used, but the existing wording does
not seem to accomplish that goal.</P>

<P><B>Additional note, November, 2014:</B></P>

<P>Concern has been expressed  that the intent to analyze
access in the context of the alias template definition is at odds
with the fact that friendship cannot be granted to alias
templates; if it could, the access violation in the original example
could be avoided by making <TT>foo</TT> a friend of class <TT>B</TT>,
but that is not possible.</P>

<P><B>Additional node, February, 2016:</B></P>

<P>The issue has been returned to "open" status to facilitate further
discussion by CWG as to whether the direction in the October, 2012 note is
still desirable.</P>

<P><B>Notes from the February, 2016 meeting:</B></P>

<P>CWG reaffirmed the direction described in the October,
2012 note above.  With regard to the November, 2014 note
regarding granting of friendship, it was observed that the
same problem occurs with enumerators, which might refer to
inaccessible names in the enumerator volue.  The solution in
both cases is to embed the declaration in a class and grant
the class friendship.  See <A HREF="cwg_active.html#1844">issue 1844</A>, dealing with the definition of
&#8220;immediate context.&#8221;</P>

<P><B>CWG 2024-06-28</B></P>

<P>See <A HREF="cwg_active.html#2296">issue 2296</A> for the definition of
"immediate context".</P>

<BR><BR><HR>
<A NAME="1979"></A><H4>1979.
  
Alias template specialization in template member definition
</H4>
<B>Section: </B>13.7.8&#160; [<A href="https://wg21.link/temp.alias">temp.alias</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-07-31<BR>




<P>In an example like</P>

<PRE>
  template&lt;typename T&gt; struct A {
    struct B {
      void f();
    };
  };

  template&lt;typename T&gt; using X = typename A&lt;T&gt;::B;

  template&lt;typename T&gt; void X&lt;T&gt;::f() { }       //<SPAN CLASS="cmnt"> #1</SPAN>
</PRE>

<P>should #1 be considered a definition of <TT>A&lt;T&gt;::B::f()</TT>?</P>

<P>Analogy with <I>alias-declaration</I>s would suggest that
it should, but alias template specializations involve issues
like SFINAE on unused template parameters (see
<A HREF="cwg_defects.html#1558">issue 1558</A>) and possibly other
complications.</P>

<P>(See also issues <A HREF="cwg_active.html#1980">1980</A>,
<A HREF="cwg_closed.html#2021">2021</A>, <A HREF="cwg_closed.html#2025">2025</A>,
<A HREF="cwg_active.html#2037">2037</A>, and <A HREF="cwg_active.html#2794">2794</A>.)</P>

<P><B>Notes from the May, 2015 meeting:</B></P>

<P>CWG felt that this kind of usage should be permitted only via
a &#8220;simple&#8221; alias, in which the SFINAE is the same
as the template to which it refers and all the template parameters
are used.  See also <A HREF="cwg_active.html#1286">issue 1286</A>.</P>

<BR><BR><HR>
<A NAME="1980"></A><H4>1980.
  
Equivalent but not functionally-equivalent redeclarations
</H4>
<B>Section: </B>13.7.8&#160; [<A href="https://wg21.link/temp.alias">temp.alias</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-08-04<BR>




<P>In an example like</P>

<PRE>
  template&lt;typename T, typename U&gt; using X = T;
  template&lt;typename T&gt; X&lt;void, typename T::type&gt; f();
  template&lt;typename T&gt; X&lt;void, typename T::other&gt; f();
</PRE>

<P>it appears that the second declaration of <TT>f</TT> is a
redeclaration of the first but distinguishable by SFINAE, i.e.,
equivalent but not functionally equivalent.</P>

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

<P>CWG felt that these two declarations should not be equivalent.</P>

<BR><BR><HR>
<A NAME="2236"></A><H4>2236.
  
When is an alias template specialization dependent?
</H4>
<B>Section: </B>13.7.8&#160; [<A href="https://wg21.link/temp.alias">temp.alias</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Maxim Kartashev
 &#160;&#160;&#160;

 <B>Date: </B>2016-03-01<BR>




<P>There is implementation divergence for this example:</P>

<PRE>
  struct A { typedef int type; };
  template &lt;typename T&gt; using ALIAS = A;

  template &lt;typename T&gt; void foo()
  {
     ALIAS&lt;T&gt;::type t; //<SPAN CLASS="cmnt"> Is </SPAN>typename<SPAN CLASS="cmnt"> required here?</SPAN>
  }

  int main()
  {
    foo&lt;A&gt;();
  } 
</PRE>

<P>See also issues <A HREF="cwg_defects.html#1558">1558</A>,
<A HREF="cwg_active.html#1979">1979</A>, and
<A HREF="cwg_active.html#2037">2037</A>.</P>

<BR><BR><HR>
<A NAME="1390"></A><H4>1390.
  
Dependency of alias template specializations
</H4>
<B>Section: </B>13.8.3.2&#160; [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-09-04<BR>




<P>According to 13.8.3.2 [<A href="https://wg21.link/temp.dep.type#8">temp.dep.type</A>] paragraph 8, a type
is dependent (among other things) if it is</P>

<UL><LI><P>a <I>simple-template-id</I> in which either the
template name is a template parameter or any of the template
arguments is a dependent type or an expression that is
type-dependent or value-dependent</P></LI></UL>

<P>This applies to alias template specializations, even if the
resulting type does not depend on the template argument:</P>

<PRE>
    struct B { typedef int type; };
    template&lt;typename&gt; using foo = B;
    template&lt;typename T&gt; void f() {
      foo&lt;T&gt;::type * x;  //<SPAN CLASS="cmnt">error: </SPAN><TT>typename</TT><SPAN CLASS="cmnt"> required</SPAN>
    }
</PRE>

<P>Is a change to the rules for cases like this warranted?</P>

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

<P>CWG agreed that no <TT>typename</TT> should be required in this
case.  In some ways, an alias template specialization is like the current
instantiation and can be known at template definition time.</P>

<BR><BR><HR>
<A NAME="1524"></A><H4>1524.
  
Incompletely-defined class template base
</H4>
<B>Section: </B>13.8.3.2&#160; [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]
 &#160;&#160;&#160;

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

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

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




<P>The correct handling of an example like the following is unclear:</P>

<PRE>
  template&lt;typename T&gt; struct A {
    struct B: A { };
  };
</PRE>

<P>A type used as a base must be complete (11.7 [<A href="https://wg21.link/class.derived#2">class.derived</A>] paragraph 2)
.  The fact that the base class in this example is the
current instantiation could be interpreted as indicating that it
should be available for lookup, and thus the normal rule should apply,
as members declared after the nested class would not be visible.</P>

<P>On the other hand, 13.8.3 [<A href="https://wg21.link/temp.dep#3">temp.dep</A>] paragraph 3
says,</P>

<BLOCKQUOTE>

In the definition of a class or class template, if a base class
depends on a <I>template-parameter</I>, the base class scope is not
examined during unqualified name lookup either at the point of
definition of the class template or member or during an instantiation
of the class template or member.

</BLOCKQUOTE>

<P>This wording refers not to a dependent type, which would permit
lookup in the current instantiation, but simply to a type that
&#8220;depends on a <I>template-parameter</I>,&#8221; and the current
instantiation is such a type.</P>

<P>Implementations vary on the handling of this example.</P>

<P>(See also <A HREF="cwg_closed.html#1526">issue 1526</A> for another case
related to the distinction between a &#8220;dependent type&#8221; and
a &#8220;type that depends on a <I>template-parameter</I>.&#8221;)</P>

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

<P>CWG determined that the example should be ill-formed.</P>

<BR><BR><HR>
<A NAME="2074"></A><H4>2074.
  
Type-dependence of local class of function template
</H4>
<B>Section: </B>13.8.3.2&#160; [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-01-20<BR>




<P>According to 13.8.3.2 [<A href="https://wg21.link/temp.dep.type#9">temp.dep.type</A>] paragraph 9, a
local class in a function template is dependent if and only if
it contains a subobject of a dependent type.  However, given
an example like</P>

<PRE>
  template&lt;typename T&gt; void f() {
    struct X {
      typedef int type;
  #ifdef DEPENDENT
      T x;
  #endif
    };
  X::type y;    //<SPAN CLASS="cmnt"> #1</SPAN>
  }
  void g() { f&lt;int&gt;(); }
</PRE>

<P>there is implementation variance in the treatment of #1, but
whether or not <TT>DEPENDENT</TT> is defined appears to make no
difference.</P>

<P>In a related question, should a value-dependent
<TT>alignas</TT> specifier cause a type to be dependent? Given</P>

<PRE>
  template&lt;int N&gt; struct Y { typedef int type; };
  template&lt;int N&gt; void h() {
    struct alignas(N) X {};
    Y&lt;alignof(X)&gt;::type z;   //<SPAN CLASS="cmnt"> #2</SPAN>
  }
  void i() { h&lt;4&gt;(); }
</PRE>

<P>Most/all implementations issue an error for a missing
<TT>typename</TT> in #2.</P>

<P>Perhaps the right answer is that the types should be dependent
but a member of the current instantiation, permitting name
lookup without <TT>typename</TT>.</P>

<P><B>Additional notes (September, 2022):</B></P>

<P>At present, the term "current instantiation" is defined for class
templates only, and thus does not apply to function templates.</P>

<P>Moreover, the resolution for this issue should also handle local
enums, with particular attention to 9.8.2 [<A href="https://wg21.link/enum.udecl#1">enum.udecl</A>] paragraph 1:</P>

<BLOCKQUOTE>

The <I>elaborated-enum-specifier</I> shall not name a dependent type
and...

</BLOCKQUOTE>

<P>This rule, without amendment, would disallow the following
reasonable example if local enums were made dependent types:</P>

<PRE>
template &lt;class T&gt;
void f() {
  enum class E { e1, e2 };
  using enum E;
}
</PRE>

<BR><BR><HR>
<A NAME="2275"></A><H4>2275.
  
Type-dependence of function template
</H4>
<B>Section: </B>13.8.3.3&#160; [<A href="https://wg21.link/temp.dep.expr">temp.dep.expr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-06-21<BR>




<P>Consider:</P>

<PRE>
  struct B { template &lt;class T&gt; void h(); };
  template &lt;class T&gt; struct A {
    template &lt;class U&gt; static U f(U);
    void g() {
     f(B()).h&lt;int&gt;(); //<SPAN CLASS="cmnt"> OK, </SPAN>f(B())<SPAN CLASS="cmnt"> is non-type-dependent with type </SPAN>B<SPAN CLASS="cmnt">.</SPAN>
    }
  }; 
</PRE>

<P>A member template ought to be dependent only if it depends on
template parameters of the current scope, but
13.8.3.3 [<A href="https://wg21.link/temp.dep.expr#3">temp.dep.expr</A>] paragraph 3 is silent on the matter.</P>

<BR><BR><HR>
<A NAME="2487"></A><H4>2487.
  
Type dependence of function-style cast to incomplete array type
</H4>
<B>Section: </B>13.8.3.3&#160; [<A href="https://wg21.link/temp.dep.expr">temp.dep.expr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2021-03-12<BR>




<P>Consider:</P>

<PRE>
  using T = int[];
  using U = int[2];
  template&lt;auto M, int ...N&gt; void f() {
    auto &amp;&amp;arr1 = T(N...);
    auto &amp;&amp;arr2 = T{N...};
    auto &amp;&amp;arr3 = U(M, M);
    auto &amp;&amp;arr4 = U{M, M};
  };
</PRE>

<P>I think here <TT>T(N...)</TT> is not type-dependent, per
13.8.3.3 [<A href="https://wg21.link/temp.dep.expr#3">temp.dep.expr</A>] paragraph 3, but should be. (I
think <TT>T{N...}</TT> is type-dependent.)  Conversely, I
think <TT>U{M, M}</TT> is type-dependent, per
13.8.3.3 [<A href="https://wg21.link/temp.dep.expr#6">temp.dep.expr</A>] paragraph 6, but should not
be. (<TT>U(M, M)</TT> is not type-dependent.)</P>

<P>I think we should say that</P>

<UL>
<I>simple-type-specifier</I> <TT>(</TT> <I>expression-list<SUB>opt</SUB></I> <TT>)</TT><BR>
<I>typename-specifier</I> <TT>(</TT> <I>expression-list<SUB>opt</SUB></I> <TT>)</TT><BR>
<I>simple-type-specifier braced-init-list</I><BR>
<I>typename-specifier braced-init-list</I>
</UL>

<P>are type-dependent if the type specifier names a
dependent type, or if it names an array of unknown bound and
the <I>braced-init-list</I> or <I>expression-list</I> is
type-dependent.</P>

<P>(I think we could be a little more precise than that in
the case where there is no top-level pack
expansion: <TT>T{M, M}</TT> needs to be type-dependent for a
general array of unknown bound <TT>T</TT> due to brace
elision, but not in the case where the array element type is
a scalar type. And <TT>T(M, M)</TT> does not need to be
type-dependent because direct aggregate initialization can't
perform brace elision. But I think the simpler rule is
probably good enough.)</P>

<P><B>Notes from the August, 2021 teleconference:</B></P>

<P>CWG agreed with the suggested change. There was some
support for the &#8220;more precise&#8221; approach
mentioned in the description.</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>13.8.4&#160; [<A href="https://wg21.link/temp.dep.res">temp.dep.res</A>]
 &#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>13.8.4.1&#160; [<A href="https://wg21.link/temp.point">temp.point</A>]
 &#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 6.5.5.2 [<A href="https://wg21.link/class.qual">class.qual</A>] and
_N4567_.5.1.1 [<A href="https://wg21.link/expr.prim.general#7">expr.prim.general</A>] 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 (6.4.7 [<A href="https://wg21.link/basic.scope.class">basic.scope.class</A>])."  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 13.8.4.1 [<A href="https://wg21.link/temp.point#3">temp.point</A>] 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 13.8.4.1 [<A href="https://wg21.link/temp.point#3">temp.point</A>] 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 <INS>the same as</INS> the point of
instantiation of the enclosing template. Otherwise, the point of
instantiation for such a specialization immediately precedes the
<INS>nearest enclosing declaration</INS>.
<INS>[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.]</INS>
</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>

<P>See also issues <A HREF="cwg_closed.html#595">595</A> and
<A HREF="cwg_defects.html#1330">1330</A>.</P>

<BR><BR><HR>
<A NAME="1845"></A><H4>1845.
  
Point of instantiation of a variable template specialization
</H4>
<B>Section: </B>13.8.4.1&#160; [<A href="https://wg21.link/temp.point">temp.point</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-01-28<BR>


<P>The current wording of 13.8.4.1 [<A href="https://wg21.link/temp.point">temp.point</A>] does not
define the point of instantiation of a variable template
specialization.  Presumably replacing the references to &#8220;static
data member of a class template&#8221; with &#8220;variable
template&#8221; in paragraphs 1 and 8 would be sufficient.</P>

<P><B>Additional note, July, 2017:</B></P>

<P>It has also been observed that there is no definition of the
point of instantiation for an alias template. It is not clear that
there is a need for normative wording for the point of instantiation
of an alias template, but if not, a note explaining its absence
would be helpful.</P>

<BR><BR><HR>
<A NAME="2245"></A><H4>2245.
  
Point of instantiation of incomplete class template
</H4>
<B>Section: </B>13.8.4.1&#160; [<A href="https://wg21.link/temp.point">temp.point</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

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




<P>Consider:</P>

<PRE>
  template&lt;typename T&gt; struct X;

  extern X&lt;int&gt; *p;
  void *q = +p; //<SPAN CLASS="cmnt"> #1, complete type affects semantics via ADL</SPAN>

  template&lt;typename T&gt; struct X {};
  X&lt;int&gt; x; //<SPAN CLASS="cmnt"> #2, ill-formed, </SPAN>X&lt;int&gt;<SPAN CLASS="cmnt"> is incomplete</SPAN>
</PRE>

<P>According to the wording of <A HREF="cwg_defects.html#212">issue 212</A>,
this program is ill-formed, because the single point of instantiation
for <TT>X&lt;int&gt;</TT> is at #1, thus <TT>X&lt;int&gt;</TT> is an
incomplete type even at #2 after the primary template has been completed.</P>

<P><B>Notes from the December, 2016 teleconference:</B></P>

<P>The consensus was that references to specializations before the
template definition is seen are not points of instantiation.</P>

<BR><BR><HR>
<A NAME="2497"></A><H4>2497.
  
Points of instantiation for constexpr function templates
</H4>
<B>Section: </B>13.8.4.1&#160; [<A href="https://wg21.link/temp.point">temp.point</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2019-07-20<BR>




<P>Consider:</P>

<PRE>
  template&lt;typename T&gt; constexpr T f();
  constexpr int g() { return f&lt;int&gt;(); } //<SPAN CLASS="cmnt"> #1</SPAN>
  template&lt;typename T&gt; constexpr T f() { return 123; }
  int k[g()];
  //<SPAN CLASS="cmnt"> #2</SPAN>
</PRE>

<P>There are two points of instantiation for <TT>f&lt;int&gt;</TT>.
At #1, the template isn't defined, so it cannot be instantiated
there. At #2, it's too late, as the definition was needed when
parsing the type of <TT>k</TT>.</P>

<P>Should we also treat the point of definition of (at
least) a constexpr function template as a point of
instantiation for all specializations that have a point of
instantiation before that point? Note the possible
interaction of such a resolution with
13.8.4.1 [<A href="https://wg21.link/temp.point#7">temp.point</A>] paragraph 7:</P>

<BLOCKQUOTE>

If two different points of instantiation give a template
specialization different meanings according to the
one-definition rule (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]), the program
is ill-formed, no diagnostic required.

</BLOCKQUOTE>

<P><B>Notes from the November, 2021 teleconference:</B></P>

<P>Another possibility for a point of instantiation, other
than the definition of the template, would be the point at
which the function is called. Similar questions have been
raised regarding the points at which variables are
initialized (<A HREF="cwg_defects.html#2186">issue 2186</A>) and
constexpr functions are defined (<A HREF="cwg_active.html#2166">issue 2166</A>).</P>

<BR><BR><HR>
<A NAME="2202"></A><H4>2202.
  
When does default argument instantiation occur?
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-11-19<BR>




<P>According to 13.9.2 [<A href="https://wg21.link/temp.inst#11">temp.inst</A>] paragraph 11,</P>

<BLOCKQUOTE>

If a function template <TT>f</TT> is called in a way that requires a
default argument to be used, the dependent names are looked up, the
semantics constraints are checked, and the instantiation of any template
used in the default argument is done as if the default argument had been an
initializer used in a function template specialization with the same scope,
the same template parameters and the same access as that of the function
template <TT>f</TT> used at that point, except that the scope in which a
closure type is declared (7.5.6.2 [<A href="https://wg21.link/expr.prim.lambda.closure">expr.prim.lambda.closure</A>]) &#8212; and
therefore its associated namespaces &#8212; remain as determined from the
context of the definition for the default argument.  This analysis is
called default argument instantiation. The instantiated default argument is
then used as the argument of <TT>f</TT>.

</BLOCKQUOTE>

<P>Some details are not clear from this description. For example, given</P>

<PRE>
  #include &lt;type_traits&gt;
  template&lt;class T&gt; struct Foo { Foo(T = nullptr) {} };
  bool b = std::is_constructible&lt;Foo&lt;int&gt;&gt;::value;
  int main() {}
</PRE>

<P>does &#8220;used&#8221; mean odr-used or used in any way? Is a failure
of default argument instantiation in the immediate context of the call
or is a failure a hard error? And does it apply only to function templates,
as it says, or should it apply to member functions of class templates? There
is implementation divergence on these questions.</P>

<P><B>Notes from the March, 2018 meeting:</B></P>

<P>CWG felt that such errors should be substitution failures, not hard
errors.</P>

<P><B>Additional notes (March, 2024)</B></P>

<P>This issue is related to <A HREF="cwg_active.html#2296">issue 2296</A>.</P>

<BR><BR><HR>
<A NAME="2222"></A><H4>2222.
  
Additional contexts where instantiation is not required
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-01-11<BR>


<P>According to 13.9.2 [<A href="https://wg21.link/temp.inst#6">temp.inst</A>] paragraph 6,</P>

<BLOCKQUOTE>

If the function selected by overload resolution (12.2 [<A href="https://wg21.link/over.match">over.match</A>])
can be determined without instantiating a class template definition, it is
unspecified whether that instantiation actually takes place.

</BLOCKQUOTE>

<P>There are other contexts in which a smart implementation could
presumably avoid instantiations, such as when doing argument-dependent
lookup involving a class template specialization when the template
definition contains no <TT>friend</TT> declarations or checking
base/derived relationships involving incomplete class template
definitions. It would be helpful to enumerate such contexts.
</P>

<BR><BR><HR>
<A NAME="2263"></A><H4>2263.
  
Default argument instantiation for <TT>friend</TT>s
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2016-05-04<BR>




<P>The instantiation of default arguments for friends defined in a
templated entity is not covered by
13.7.1 [<A href="https://wg21.link/temp.decls.general#3">temp.decls.general</A>] paragraph 3 or
13.9.2 [<A href="https://wg21.link/temp.inst#2">temp.inst</A>] paragraph 2.
Consider:</P>

<PRE>
  template &lt;typename T&gt;
  struct A {
    friend void foo(A &amp;&amp;, int = T::happy) { }
  };

  int main(void) { foo(A&lt;int&gt;(), 0); }
</PRE>

<P>There is implementation divergence in the treatment of this example.</P>

<P>
<B>Notes from the December, 2016 teleconference:</B>
</P>

<P>This issue should be resolved by the resolution of
<A HREF="cwg_defects.html#2174">issue 2174</A>.</P>

<BR><BR><HR>
<A NAME="2265"></A><H4>2265.
  
Delayed pack expansion and member redeclarations
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2016-05-11<BR>




<P>It is not clear how to handle parameter packs that are expanded during
instantiation in parallel with those that are not yet concrete. In
particular, does the following example require a diagnostic?</P>

<PRE>
  template&lt;typename ...T&gt; struct Tuple;
  template&lt;class T, class U&gt; struct Outer;
  template&lt;class ...T, class ...U&gt;
  struct Outer&lt;Tuple&lt;T ...&gt;, Tuple&lt;U ...&gt; &gt; {
    template&lt;class X, class Y&gt; struct Inner;
    template&lt;class ...Y&gt; struct Inner&lt;Tuple&lt;T, Y&gt; ...&gt; { };
    template&lt;class ...Y&gt; struct Inner&lt;Tuple&lt;U, Y&gt; ...&gt; { };
  };
  Outer&lt;Tuple&lt;int, void&gt;, Tuple&lt;int, void&gt; &gt; outer;
</PRE>

<P><B>Notes from the March, 2018 meeting:</B></P>

<P>CWG felt that ill-formed, no diagnostic required was the correct
approach.</P>

<BR><BR><HR>
<A NAME="2596"></A><H4>2596.
  
Instantiation of constrained non-template friends
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>David Friberg
 &#160;&#160;&#160;

 <B>Date: </B>2022-06-03<BR>


<P>Consider:</P>

<PRE>
  struct Base {};

  template&lt;int N&gt;
  struct S : public Base {
    friend int foo(Base&amp;) requires (N == 1) { return 1; }
    friend int foo(Base&amp;) requires (N == 2) { return 3; }
  };

  int main() {
    S&lt;1&gt; s1{};
    S&lt;2&gt; s2{};  // #1
  }
</PRE>

<P>The current wording does not seem to cover what happens for this
case.  In particular, 13.9.2 [<A href="https://wg21.link/temp.inst#17">temp.inst</A>] paragraph 17 does not
cover constrained non-template friends.</P>

<P>See also the Itanium ABI
<A HREF="https://github.com/itanium-cxx-abi/cxx-abi/issues/24#issuecomment-934713719">issue 24</A>.</P>

<P><U>Suggested resolution:</U></P>

<OL>

<LI>
<P>Change in 13.7.5 [<A href="https://wg21.link/temp.friend#9">temp.friend</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

A non-template friend declaration with a <I>requires-clause</I> shall
be a definition. A friend function template with a constraint that
depends on a template parameter from an enclosing template shall be a
definition.  Such a constrained friend function or function template
declaration does not declare the same function or function template as
a declaration <DEL>in</DEL> <INS>inhabiting</INS> any other scope.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.9.2 [<A href="https://wg21.link/temp.inst#17">temp.inst</A>] paragraph 17 as follows:</P>

<BLOCKQUOTE>

The <I>type-constraint</I>s and <I>requires-clause</I> of a template
specialization or <DEL>member</DEL> <INS>templated</INS> function are
not instantiated along with the specialization or function itself,
even for a member function of a local class; substitution into the
atomic constraints formed from them is instead performed as specified
in 13.5.3 [<A href="https://wg21.link/temp.constr.decl">temp.constr.decl</A>] and 13.5.2.3 [<A href="https://wg21.link/temp.constr.atomic">temp.constr.atomic</A>] when
determining whether the constraints are satisfied or as specified in
13.5.3 [<A href="https://wg21.link/temp.constr.decl">temp.constr.decl</A>] when comparing declarations.

<P>[ Note 7: ... ]</P>

<P>[ Example 10: ... ]</P>

<P><INS>[ Example:</INS></P>

<PRE>
<INS>  struct Base {};

  template&lt;int N&gt;
  struct S : Base {
    friend int foo(Base&amp;) requires (N == 1) { return 1; }  // <SPAN CLASS="cmnt">#1</SPAN>
    friend int foo(Base&amp;) requires (N == 2) { return 3; }  // <SPAN CLASS="cmnt">#2</SPAN>
  };
  S&lt;1&gt; s1;
  S&lt;2&gt; s2;          // <SPAN CLASS="cmnt">OK, no conflict between #1 and #2</SPAN>
  int x = foo(s1);  // <SPAN CLASS="cmnt">OK, selects #1</SPAN>
  int y = foo(s2);  // <SPAN CLASS="cmnt">OK, selects #2</SPAN></INS>
</PRE>

<P><INS>-- end example ]</INS></P>

<P>[ Example 11: ... ]</P>

</BLOCKQUOTE>
</LI>

</OL>

<P><B>CWG 2022-11-10</B></P>

<P>The friend definitions should conflict with friend definitions from
other instantiations of the same class template, consistent with how
non-constrained friends would work. Note that the enclosing dependent
class type does not appear in the friend function's signature, which
is unusual.</P>

<BR><BR><HR>
<A NAME="1665"></A><H4>1665.
  
Declaration matching in explicit instantiations
</H4>
<B>Section: </B>13.9.3&#160; [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-19<BR>




<P>Consider a case like</P>

<PRE>
  struct X {
    template&lt;typename T&gt; void f(T);
    void f(int);
  };
  template void X::f(int);
</PRE>

<P>or</P>

<PRE>
  template&lt;typename T&gt; void f(T) {}
  void f(int);
  template void f(int);
</PRE>

<P>Presumably in both these cases the explicit instantiation should
refer to the template and not to the non-template; however,
13.7.3 [<A href="https://wg21.link/temp.mem#2">temp.mem</A>] paragraph 2 says,</P>

<BLOCKQUOTE>

A normal (non-template) member function with a given name and type and a
member function template of the same name, which could be used to generate
a specialization of the same type, can both be declared in a class. When
both exist, a use of that name and type refers to the non-template member
unless an explicit template argument list is supplied.

</BLOCKQUOTE>

<P>This would appear to give the wrong answer for the first example.
It's not clearly stated, but consistency would suggest a similar wrong
answer for the second.  Presumably a statement is needed somewhere that
an explicit instantiation directive applies to a template and not a
non-template function if both are visible.</P>

<P><B>Additional note, January, 2014:</B></P>

<P>A related example has been raised:</P>

<PRE>
  template&lt;typename T&gt; class Matrix {
  public:
    Matrix(){}
    Matrix(const Matrix&amp;){}
    template&lt;typename U&gt;
      Matrix(const Matrix&lt;U&gt;&amp;);
  };

  template Matrix&lt;int&gt;::Matrix(const Matrix&amp;);

  Matrix&lt;int&gt; m;
  Matrix&lt;int&gt; mm(m);
</PRE>

<P>If the explicit instantiation directive applies to the
constructor template, there is no way to explicitly instantiate
the copy constructor.</P>

<BR><BR><HR>
<A NAME="2421"></A><H4>2421.
  
Explicit instantiation of constrained member functions
</H4>
<B>Section: </B>13.9.3&#160; [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Casey Carter
 &#160;&#160;&#160;

 <B>Date: </B>2019-07-16<BR>




<P>An explicit instantiation of a class template
specialization also explicitly instantiates member functions
of that class template specialization whose constraints are
satisfied, even those that are not callable because a
more-constrained overload exists which would always be
selected by overload resolution. Ideally, we would not
explicitly instantiate definitions of such uncallable
functions.</P>

<P><B>Notes from the August, 2020 teleconference:</B></P>

<P>CWG felt that the concept of &#8220;eligible&#8221; might
form a basis for the resolution of this issue.</P>

<BR><BR><HR>
<A NAME="2501"></A><H4>2501.
  
Explicit instantiation and trailing <I>requires-clause</I>s
</H4>
<B>Section: </B>13.9.3&#160; [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Davis Herring
 &#160;&#160;&#160;

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


<P>CWG determined that <A HREF="cwg_active.html#2488">issue 2488</A>
was not a defect. However, the discussion uncovered an issue
regarding the handling of an explicit instantiation of a
class template containing such members. According to
13.9.3 [<A href="https://wg21.link/temp.explicit#10">temp.explicit</A>] paragraph 10,</P>

<BLOCKQUOTE>

An explicit instantiation that names a class template
specialization is also an explicit instantiation of the same
kind (declaration or definition) of each of its direct
non-template members that has not been previously explicitly
specialized in the translation unit containing the explicit
instantiation, provided that the associated constraints, if
any, of that member are satisfied by the template arguments
of the explicit instantiation (13.5.3 [<A href="https://wg21.link/temp.constr.decl">temp.constr.decl</A>],
13.5.2 [<A href="https://wg21.link/temp.constr.constr">temp.constr.constr</A>]), except as described below.

</BLOCKQUOTE>

<P>Paragraph 12 says,</P>

<BLOCKQUOTE>

An explicit instantiation of a prospective destructor
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]) shall correspond to the
selected destructor of the class.

</BLOCKQUOTE>

<P>Perhaps the virtual and constrained members could be
handled in an analogous fashion.</P>

<P><B>Notes from the November, 2021 teleconference:</B></P>

<P>
<A HREF="cwg_active.html#2488">Issue 2488</A> is being reopened
due to subsequent comments. </P>

<P><B>CWG 2022-11-10</B></P>

<P>For each explicit instantiation, there shall be exactly one member
whose constraints are more specialized than any other member with the
same signature.  Use the "address of function" model to determine this
member.</P>

<BR><BR><HR>
<A NAME="1840"></A><H4>1840.
  
Non-deleted explicit specialization of deleted function template
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-01-19<BR>




<P>The resolution of <A HREF="cwg_defects.html#941">issue 941</A> permits a
non-deleted explicit specialization of a deleted function template.
For example:</P>

<PRE>
  template&lt;typename T&gt; void f() = delete;
  decltype(f&lt;int&gt;()) *p;
  template&lt;&gt; void f&lt;int&gt;();
</PRE>

<P>However, the existing normative wording is not adequate to handle
this usage.  For one thing, <TT>=delete</TT> is formally, at least,
a function definition, and an implementation is not permitted to
instantiate a function definition unless it is used; presumably, then,
an implementation could not reject the <TT>decltype</TT> above as
a reference to a deleted specialization.  Furthermore, there should
be a requirement that a non-deleted explicit specialization of a
deleted function template must precede any reference to that
specialization.  (I.e., the example should be ill-formed as written
but well-formed if the last two lines were interchanged.)</P>

<BR><BR><HR>
<A NAME="2409"></A><H4>2409.
  
Explicit specializations of constexpr static data members
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2019-04-29<BR>


<P>The status of an example like the following is not clear:</P>

<PRE>
  struct S {
    template &lt;int N&gt; static constexpr inline int m = N;
  };
  template &lt;&gt; constexpr inline int S::m&lt;5&gt;;
</PRE>

<P>Some implementations accept this, apparently on the basis
of allowing and ignoring a redeclaration of a constexpr
static data member outside its class, although there is
implementation divergence. Most or all implementations,
however, diagnose an attempt to use such a specialization in
a constant context.</P>

<P>Should it be required to have a definition of the explicit
specialization in order to declare it outside the class in such
cases?</P>

<P>In addition, most or all implementations accept a version
of the example in which the explicit specialization contains an
initializer, including allowing its use in constant contexts:</P>

<PRE>
  template &lt;&gt; constexpr inline int S::m&lt;5&gt; = 2;
</PRE>

<P>This would seem to be disallowed both by
11.4.9.3 [<A href="https://wg21.link/class.static.data#3">class.static.data</A>] paragraph 3,</P>

<BLOCKQUOTE>

An inline static data member may be defined in the class
definition and may specify
a <I>brace-or-equal-initializer</I>.  If the member is
declared with the <TT>constexpr</TT> specifier, it may be
redeclared in namespace scope with no initializer (this
usage is deprecated; see _N4778_.D.4 [<A href="https://wg21.link/depr.static_constexpr">depr.static_constexpr</A>]).

</BLOCKQUOTE>

<P>which prohibits an initializer, and
13.9.4 [<A href="https://wg21.link/temp.expl.spec#2">temp.expl.spec</A>] paragraph 2,</P>

<BLOCKQUOTE>

An explicit specialization may be declared in any scope in
which the corresponding primary template may be defined
(_N4868_.9.8.2.3 [<A href="https://wg21.link/namespace.memdef">namespace.memdef</A>], 11.4 [<A href="https://wg21.link/class.mem">class.mem</A>],
13.7.3 [<A href="https://wg21.link/temp.mem">temp.mem</A>]).

</BLOCKQUOTE>

<P>since the definition of a constexpr static data member is
inside the class.</P>

<P><B>Notes from the May, 2019 teleconference:</B></P>

<P>These examples should behave in the same way as if the class were
templated: instantiate the declaration and the definition of the
static data member separately. The first example should be ill-formed,
because the explicit specializaation does not have an initializer.</P>

<BR><BR><HR>
<A NAME="2055"></A><H4>2055.
  
Explicitly-specified non-deduced parameter packs
</H4>
<B>Section: </B>13.10.2&#160; [<A href="https://wg21.link/temp.arg.explicit">temp.arg.explicit</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-12-09<BR>




<P>According to 13.10.2 [<A href="https://wg21.link/temp.arg.explicit#3">temp.arg.explicit</A>] paragraph 3,</P>

<BLOCKQUOTE>

Trailing template arguments that can be deduced
(13.10.3 [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]) or obtained from
default <I>template-argument</I>s may be omitted from the
list of explicit <I>template-argument</I>s. A trailing
template parameter pack (13.7.4 [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]) not
otherwise deduced will be deduced to an empty sequence of
template arguments. If all of the template arguments can be
deduced, they may all be omitted; in this case, the empty
template argument list <TT>&lt;&gt;</TT> itself may also be
omitted. In contexts where deduction is done and fails, or
in contexts where deduction is not done, if a template
argument list is specified and it, along with any default
template arguments, identifies a single function template
specialization, then the <I>template-id</I> is an lvalue for
the function template specialization.

</BLOCKQUOTE>

<P>It is not clear that this permits an example like:</P>

<PRE>
  template&lt;typename... T&gt; void f(typename T::type...)   {
  }

  int main() {
    f&lt;&gt;();
  }
</PRE>

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

<BR><BR><HR>
<A NAME="1172"></A><H4>1172.
  
&#8220;instantiation-dependent&#8221; constructs
</H4>
<B>Section: </B>13.10.3&#160; [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 &#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>

<P><B>Notes from the March, 2011 meeting:</B></P>

<P>The CWG reconsidered the direction from the November, 2010 meeting,
as it would make more constructs dependent, thus requiring more
<TT>template</TT> and <TT>typename</TT> keywords, resulting in worse
error messages, etc.</P>

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

<P>The following example (from <A HREF="cwg_closed.html#1273">issue 1273</A>)
was deemed relevant for this issue:</P>

<PRE>
    template &lt;class T&gt; struct C;

    class A {
       int i;
       friend struct C&lt;int&gt;;
    } a;

    class B {
       int i;
       friend struct C&lt;float&gt;;
    } b;

    template &lt;class T&gt;
    struct C {
       template &lt;class U&gt; decltype (a.i) f() { } // #1
       template &lt;class U&gt; decltype (b.i) f() { } // #2
    };

    int main() {
       C&lt;int&gt;().f&lt;int&gt;();     // calls #1
       C&lt;float&gt;().f&lt;float&gt;(); // calls #2
    }
</PRE>



<BR><BR><HR>
<A NAME="1322"></A><H4>1322.
  
Function parameter type decay in templates
</H4>
<B>Section: </B>13.10.3&#160; [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-05-19<BR>




<P>The discussion of <A HREF="cwg_active.html#1001">issue 1001</A> seemed to have
settled on the approach of doing the 9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
transformations immediately to the function template declaration, so
that the original form need not be remembered.  However, the example
in 13.10.3 [<A href="https://wg21.link/temp.deduct#8">temp.deduct</A>] paragraph 8 suggests otherwise:</P>

<PRE>
  template &lt;class T&gt; int f(T[5]);
  int I = f&lt;int&gt;(0);
  int j = f&lt;void&gt;(0); //<SPAN CLASS="cmnt"> invalid array</SPAN>
</PRE>

<P>One way that might be addressed would be to separate the concepts
of the type of the template that participates in overload resolution and
function matching from the type of the template that is the source for
template argument substitution.  (See also the example in paragraph 3 of
the same section.)</P>

<P><B>Notes, January, 2012:</B></P>

<P></P>

<BR><BR><HR>
<A NAME="1582"></A><H4>1582.
  
Template default arguments and deduction failure
</H4>
<B>Section: </B>13.10.3&#160; [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2012-10-31<BR>


<P>According to 13.10.3 [<A href="https://wg21.link/temp.deduct#5">temp.deduct</A>] paragraph 5,</P>

<BLOCKQUOTE>

The resulting substituted and adjusted function type is used as the
type of the function template for template argument deduction. If a
template argument has not been deduced and its corresponding template
parameter has a default argument, the template argument is determined
by substituting the template arguments determined for preceding
template parameters into the default argument.  If the substitution
results in an invalid type, as described above, type deduction fails.

</BLOCKQUOTE>

<P>This leaves the impression that default arguments are used after
deduction failure leaves an argument undeduced.  For example,</P>

<PRE>
  template&lt;typename T&gt; struct Wrapper;
  template&lt;typename T = int&gt; void f(Wrapper&lt;T&gt;*);
  void g() {
    f(0);
  }
</PRE>

<P>Deduction fails for <TT>T</TT>, so presumably <TT>int</TT> is used.
However, some implementations reject this code.  It appears that the
intent would be better expressed as something like</P>

<BLOCKQUOTE>

...If a template argument is used only in a non-deduced context and
its corresponding template parameter has a default argument...

</BLOCKQUOTE>

<P><B>Rationale (November, 2013):</B></P>

<P>CWG felt that this issue should be considered by EWG in a broader
context before being resolved.</P>

<P><B>Additional note, April, 2015:</B></P>

<P>EWG has requested that CWG resolve this issue along the lines
discussed above. </P>

<P><B>Notes from the May, 2015 meeting:</B></P>

<P>CWG agreed that a default template argument should only be used
if the parameter is not used in a deducible context.  See also
<A HREF="cwg_defects.html#2092">issue 2092</A>.</P>

<BR><BR><HR>
<A NAME="1513"></A><H4>1513.
  
<TT>initializer_list</TT> deduction failure
</H4>
<B>Section: </B>13.10.3.2&#160; [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-06-28<BR>


<P>According to 13.10.3.2 [<A href="https://wg21.link/temp.deduct.call#1">temp.deduct.call</A>] paragraph 1,</P>

<BLOCKQUOTE>

If removing references and cv-qualifiers from <TT>P</TT> gives
<TT>std::initializer_list&lt;<I>P'</I>&gt;</TT> for some
<TT><I>P'</I></TT> and the argument is an initializer list
(9.5.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]), then deduction is performed instead for
each element of the initializer list, taking <TT><I>P'</I></TT> as a
function template parameter type and the initializer element as its
argument. Otherwise, an initializer list argument causes the parameter
to be considered a non-deduced context (13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]).

</BLOCKQUOTE>

<P>It is not entirely clear whether the deduction for an initializer
list meeting a <TT>std::initializer_list&lt;T&gt;</TT> is a recursive
subcase, or part of the primary deduction.  A relevant question is:
if the deduction on that part fails, does the entire deduction fail,
or is the parameter to be considered non-deduced?</P>

<P>See also <A HREF="cwg_closed.html#2326">issue 2326</A>.</P>

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

<P>CWG determined that the entire deduction fails in this case.</P>

<BR><BR><HR>
<A NAME="1584"></A><H4>1584.
  
Deducing function types from cv-qualified types
</H4>
<B>Section: </B>13.10.3.2&#160; [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-11-04<BR>




<P>It is not clear whether the following is well-formed or not:</P>

<PRE>
  void foo(){}

  template&lt;class T&gt;
  void deduce(const T*) { }

  int main() {
    deduce(foo);
  }
</PRE>

<P>Implementations vary in their treatment of this example.</P>

<P><B>Proposed resolution (April, 2013):</B></P>

<P>Change 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#18">temp.deduct.type</A>] paragraph 18 as follows:</P>

<BLOCKQUOTE>

<P>A <I>template-argument</I> can be deduced from a function, pointer to
function, or pointer to member function type. <INS>[<I>Note:</I>
cv-qualification of a deduced function type is ignored; see
9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]. &#8212;<I>end note</I>]</INS>
[<I>Example:</I>
</P>

<PRE>
  template&lt;class T&gt; void f(void(*)(T,int));
<INS>  template&lt;class T&gt; void f2(const T*);</INS>
  template&lt;class T&gt; void foo(T,int);
  void g(int,int);
  void g(char,int);
<INS>  void g2();</INS>

  void h(int,int,int);
  void h(char,int);
  int m() {
    f(&amp;g);     //<SPAN CLASS="cmnt"> error: ambiguous</SPAN>
    f(&amp;h);     //<SPAN CLASS="cmnt"> OK: </SPAN>void h(char,int)<SPAN CLASS="cmnt"> is a unique match</SPAN>
    f(&amp;foo);   //<SPAN CLASS="cmnt"> error: type deduction fails because </SPAN>foo<SPAN CLASS="cmnt"> is a template</SPAN>
<INS>    f2(g2);    //<SPAN CLASS="cmnt"> OK: cv-qualification of deduced function type ignored</SPAN></INS>
  }
</PRE>

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

</BLOCKQUOTE>

<P><B>Additional note, November, 2014:</B></P>

<P>Concern was expressed regarding the proposed resolution over its
treatment of an example like the following:</P>

<PRE>
  template&lt;typename T&gt; struct tuple_size {};
  template&lt;typename T&gt; struct tuple_size&lt;T const&gt;: tuple_size&lt;T&gt; {};

  tuple_size&lt;void()&gt; t;
</PRE>

<P>In this case <TT>T const</TT> is always considered to be more
specialized for <TT>void()</TT>, leading to infinite self-derivation.
</P>

<P>The issue has been returned to "open" status for further
consideration.</P>

<P><B>Notes from the May, 2015 meeting:</B></P>

<P>The consensus of CWG was that the cv-qualification of the
argument and parameter must match, so the original example
should be rejected.</P>

<BR><BR><HR>
<A NAME="1486"></A><H4>1486.
  
Base-derived conversion in member pointer deduction
</H4>
<B>Section: </B>13.10.3.3&#160; [<A href="https://wg21.link/temp.deduct.funcaddr">temp.deduct.funcaddr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2012-03-26<BR>


<P>The rules for deducing template arguments when taking the address of a
function template in 13.10.3.3 [<A href="https://wg21.link/temp.deduct.funcaddr">temp.deduct.funcaddr</A>] do not appear to allow
for a base-to-derived conversion in a case like:</P>

<PRE>
  struct Base {
    template&lt;class U&gt; void f(U);
  };

  struct Derived : Base { };

  int main() {
    void (Derived::*pmf)(int) = &amp;Derived::f;
  }
</PRE>

<P>Most implementations appear to allow this adjustment, however.</P>

<BR><BR><HR>
<A NAME="1610"></A><H4>1610.
  
Cv-qualification in deduction of reference to array
</H4>
<B>Section: </B>13.10.3.5&#160; [<A href="https://wg21.link/temp.deduct.partial">temp.deduct.partial</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-28<BR>


<P>Given</P>

<PRE>
   template&lt;class C&gt; void foo(const C* val) {}
   template&lt;int N&gt; void foo(const char (&amp;t)[N]) {}
</PRE>

<P>it is intuitive that the second template is more specialized than
the first.  However, the current rules make them unordered.
In 13.10.3.5 [<A href="https://wg21.link/temp.deduct.partial#4">temp.deduct.partial</A>] paragraph 4, we have P as
<TT>const C*</TT> and A as <TT>const char (&amp;)[N]</TT>.  Paragraph 5
transforms A to <TT>const char[N]</TT>.  Finally, paragraph 7 removes
top-level cv-qualification; since a cv-qualified array element type is
considered to be cv-qualification of the array (6.9.5 [<A href="https://wg21.link/basic.type.qualifier#5">basic.type.qualifier</A>] paragraph 5,
 cf <A HREF="cwg_defects.html#1059">issue 1059</A>), A
becomes <TT>char[N]</TT>.  P remains <TT>const C*</TT>, so deduction fails
because of the missing <TT>const</TT> in A.</P>

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

<P>CWG agreed that the <TT>const</TT> should be preserved in the
array type.</P>

<BR><BR><HR>
<A NAME="2328"></A><H4>2328.
  
Unclear presentation style of template argument deduction rules
</H4>
<B>Section: </B>13.10.3.6&#160; [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2016-10-11<BR>


<P>The presentation style of 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#8">temp.deduct.type</A>] paragraph 8
results in a specification that is unclear,
needlessly verbose, and incomplete. Specific problems include:</P>

<UL>
<LI><P>What does it mean for <TT>P</TT> and <TT>A</TT> to
have one of a set of forms? Do they both have to have that form?
(That doesn't happen; typically, only <TT>P</TT> contains template
parameters)</P></LI>

<LI><P>In the introductory sentence,
aren't <TT>T</TT>, <TT>TT</TT>, and <TT>i</TT> supposed to be the
names of template parameters rather than template
arguments?</P></LI>

<LI><P>In <TT>T[i]</TT>, it appears we can deduce <TT>i</TT>, but
not <TT>T</TT> (<TT>T</TT> can only be deduced in the
form <TT>T[<I>integer-constant</I>]</TT>
</P></LI>

<LI><P>What is an <I>integer-constant</I> supposed to be?</P></LI>

<LI><P>What is a <I>cv-list</I>?</P></LI>

<LI><P>Why can we not deduce <TT>const T</TT> from <TT>T</TT>?
(Apparently you only get to deduce if both or neither type have
a <I>cv-list</I>, whatever a <I>cv-list</I> is.)</P></LI>

<LI><P>We have extreme redundancy because, for instance, there is
no way to say &#8220;in <TT>T (T::*)(T)</TT>, you can deduce any
of those <TT>T</TT>s, and it's OK if some of the positions don't
have a <TT>T</TT>&#8221;. So we have seven (!)  forms of that
construct, for all cases except the one where none of the three
positions contain a <TT>T</TT>.</P></LI>

<LI><P>We have special case rules for pointers to member
functions, even though they're not a special case and should be
covered by the rule for pointers to members and the rule for
functions.</P></LI>

<LI>

<P>We do not allow deducing a template template parameter's value
from a template template argument &#8212; there is
a <TT>TT&lt;T&gt;</TT> form, a <TT>TT&lt;i&gt;</TT> form,
a <I>template-name</I>&lt;T&gt; form, and
a <I>template-name</I><TT>&lt;i&gt;</TT> form, but
no <TT>TT&lt;TT&gt;</TT> form
nor <I>template-name</I><TT>&lt;TT&gt;</TT> form.</P>
</LI>

</UL>

<BR><BR><HR>
<A NAME="2172"></A><H4>2172.
  
Multiple exceptions with one exception object
</H4>
<B>Section: </B>14.4&#160; [<A href="https://wg21.link/except.handle">except.handle</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-09-14<BR>


<P>During the discussion of <A HREF="cwg_defects.html#2098">issue 2098</A> it
was observed that multiple exceptions may share a single exception
object via <TT>std::exception_ptr</TT>.  It is not clear that the
current wording handles that case correctly.</P>

<BR><BR><HR>
<A NAME="2219"></A><H4>2219.
  
Dynamically-unreachable handlers
</H4>
<B>Section: </B>14.4&#160; [<A href="https://wg21.link/except.handle">except.handle</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>2016-01-04
 &#160;&#160;&#160;

 <B>Date: </B>Richard Smith<BR>




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

<PRE>
  #include &lt;cstdio&gt;
  #include &lt;cstdlib&gt;

  void f() {
    struct X {
     ~X() {
       std::puts("unwound");
       std::exit(0);
     }
    } x;
    throw 0;
  }

  int main(int argc, char**) {
    try {
      f();
    } catch (int) {
      std::puts("caught");
    }
  }
</PRE>

<P>According to the Standard, this should print <TT>unwound</TT> and
exit. Current optimizing implementations call <TT>terminate()</TT>,
because:</P>

<UL>
<LI><P>
<TT>f()</TT> obviously never unwinds (all paths out of it
call <TT>exit</TT>)</P></LI>

<LI><P>Therefore the <TT>catch(int)</TT> clause is unreachable</P></LI>

<LI><P>Therefore the <TT>catch(int)</TT> clause is removed</P></LI>

<LI><P>When countering the <TT>throw 0;</TT> statement, the search for a
handler finds nothing, so <TT>terminate</TT> is called without unwinding
the stack.</P></LI>

</UL>

<P>More abstractly, before calling <TT>terminate</TT>, we're required to
check whether there is an active handler for an exception of type <TT>int</TT>,
and in some sense there is not (because the handler in <TT>main</TT> is
dynamically unreachable).</P>

<P>There seem to be three possible solutions:</P>

<OL>
<LI><P>Change the standard to say that <TT>terminate()</TT> is a valid
response to this situation [this seems problematic, as any non-returning
destructor now risks program termination, but is in fact the status quo on
multiple implementations and does not seem to have resulted in any bug
reports]</P></LI>

<LI><P>Always fully unwind before calling terminate() [this significantly
harms debugability of exceptions]</P></LI>

<LI><P>Teach the compilers to not optimize out unreachable exception handlers
[for some implementations, this is &#8220;remove, redesign and reimplement
middle-end support for EH&#8221;-level difficult, and harms the ability to
optimize code involving catch handlers]</P></LI>

</OL>

<BR><BR><HR>
<A NAME="2003"></A><H4>2003.
  
Zero-argument macros incorrectly specified
</H4>
<B>Section: </B>15.7&#160; [<A href="https://wg21.link/cpp.replace">cpp.replace</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-09-12<BR>




<P>According to 15.7 [<A href="https://wg21.link/cpp.replace#4">cpp.replace</A>] paragraph 4,</P>

<BLOCKQUOTE>

If the <I>identifier-list</I> in the macro definition does not end
with an ellipsis, the number of arguments (including those
arguments consisting of no preprocessing tokens) in an
invocation of a function-like macro shall equal the number
of parameters in the macro definition.

</BLOCKQUOTE>

<P>That is, a sequence of no preprocessing tokens counts as an
argument.  That phrasing has problems with zero-argument
function-like macros, e.g.,</P>

<PRE>
  #define M()
  M();
</PRE>

<P>
<TT>M</TT> is defined as having no parameters but the invocation
has one (empty) argument, which does not match the number of
parameters in the definition.</P>

<BR><BR><BR><BR><HR>
<A NAME="Open%20Status"></A><H3>Issues with "Open" Status</H3>
<HR>
<A NAME="783"></A><H4>783.
  
Definition of &#8220;argument&#8221;
</H4>
<B>Section: </B>Clause 3&#160; [<A href="https://wg21.link/intro.defs">intro.defs</A>]
 &#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>4.1&#160; [<A href="https://wg21.link/intro.compliance">intro.compliance</A>]
 &#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 4.1 [<A href="https://wg21.link/intro.compliance#7">intro.compliance</A>] 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 (16.4.2.5 [<A href="https://wg21.link/compliance">compliance</A>]).

</BLOCKQUOTE>

<P>This definition links two relatively separate topics: the lack
of an operating system and the minimal set of libraries.
Furthermore, 6.10.3.1 [<A href="https://wg21.link/basic.start.main#1">basic.start.main</A>] 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="2776"></A><H4>2776.
  
Substitution failure and implementation limits
</H4>
<B>Section: </B>4.1.1&#160; [<A href="https://wg21.link/intro.compliance.general">intro.compliance.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-27
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Are there behavioral bounds in case an implementation limit is
encountered?  For example, a constant expression may fail to be
recognized as such due to an implementation limit (e.g. a recursion or
step limit), causing overload resolution to pick a different overload.
Is that acceptable?</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 4.1.1 [<A href="https://wg21.link/intro.compliance.general#2">intro.compliance.general</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

Although this document states only requirements on C++
implementations, those requirements are often easier to understand if
they are phrased as requirements on programs, parts of programs, or
execution of programs <INS>as specified in the rules in
Clause 5 [<A href="https://wg21.link/lex">lex</A>] through Clause 32 [<A href="https://wg21.link/thread">thread</A>] and Annex
D</INS>. Such requirements have the following meaning:
<UL>
<LI class="ins">
<P>If a program contains a violation of a rule for which no diagnostic
is required, this document places no requirement on implementations
with respect to that program.</P>
</LI>

<LI class="ins">
<P>Otherwise, if an implementation limit (Annex B) is reached during
translation, an implementation shall reject the program.</P>
<P>
<I>Recommended practice:</I> An implementation should document
limits where they are known, and should issue a diagnostic in cases
where it can reasonably detect that the implementation limit is
reached.</P>
</LI>

<LI>
<DEL>If a program contains no
violations of the rules in Clause 5 [<A href="https://wg21.link/lex">lex</A>] through
Clause 32 [<A href="https://wg21.link/thread">thread</A>] and Annex D, a conforming implementation
shall, within its resource limits as described in Annex B,
accept and correctly execute [ Footnote: ... ] that program.</DEL>
</LI>

<LI>
<DEL>If a program contains a violation
of a rule for which no diagnostic is required, this document places no
requirement on implementations with respect to that program.</DEL>
</LI>

<LI>
Otherwise, if <DEL>a</DEL> <INS>that</INS> program contains a violation
of any diagnosable rule or an occurrence of a construct described in
this document as &#8220;conditionally-supported&#8221; when the
implementation does not support that construct, a conforming
implementation shall issue at least one diagnostic message.
</LI>

<LI class="ins">
Otherwise, a conforming implementation shall accept and correctly
execute that program.  [ Note: "Correct execution" can include
undefined behavior, depending on the data being processed; see
Clause 3 [<A href="https://wg21.link/intro.defs">intro.defs</A>] and 4.1.2 [<A href="https://wg21.link/intro.abstract">intro.abstract</A>]. -- end note ] 
</LI>
</UL>
</BLOCKQUOTE>
</LI>

<LI>
<P>Add a new paragraph after 4.1.2 [<A href="https://wg21.link/intro.abstract#6">intro.abstract</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

<P>
[Note 2 : More stringent correspondences between abstract and actual
semantics can be defined by each implementation.  -- end note]
</P>

<P class="ins">
If an implementation limit (Annex B) is reached, the behavior is
undefined.
</P>

<P class="ins">
<I>Recommended practice:</I> An implementation should document limits
where they are known and abort the execution of the program in cases
where it can reasonably detect that the implementation limit is
reached.
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.7 [<A href="https://wg21.link/expr.const#5">expr.const</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>
<DEL>an expression that would exceed the implementation-defined limits (see
Annex B);</DEL>
</LI>
<LI>
an operation that would have undefined behavior as specified in
Clause 4 [<A href="https://wg21.link/intro">intro</A>] through Clause 15 [<A href="https://wg21.link/cpp">cpp</A>], excluding
9.13.3 [<A href="https://wg21.link/dcl.attr.assume">dcl.attr.assume</A>] <INS>and exceeding an implementation limit
(4.1.2 [<A href="https://wg21.link/intro.abstract">intro.abstract</A>])</INS>; [ Footnote: ... ]
<DIV class="ins">[ Example:
<PRE>
  constexpr bool f(int x) { return (x == 0) || f(x-1); }
  const bool g = f(60000);    // <SPAN CLASS="cmnt">well-formed static initialization (6.10.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]);</SPAN>
                              // <SPAN CLASS="cmnt">program can be rejected because implementation limit is reached</SPAN>
</PRE>
-- end example ]
</DIV>
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.9.2 [<A href="https://wg21.link/temp.inst#16">temp.inst</A>] paragraph 16 as follows:</P>

<BLOCKQUOTE>

There is an implementation-defined quantity that specifies the limit
on the total depth of recursive instantiations (Annex B), which could
involve more than one template. <DEL>The result of an infinite recursion in
instantiation is undefined.</DEL>

</BLOCKQUOTE>
</LI>
</OL>

<P><B>CWG 2023-08-25</B></P>

<P>For the example in change 3, implementations currently switch to
dynamic initialization when their implementation limits related to
constant evaluation are exceeded.  This might be surprising to users,
because dynamic initialization can exhibit order-of-initialization
issues.  It might be less harmful to reject such situations as
ill-formed.  Furthermore, it is unclear whether implementations can
reliably determine that an implementation limit is reached, before
crashing.</P>

<P>CWG is requesting EWG guidance via
<A HREF="https://github.com/cplusplus/papers/issues/1631">paper issue #1631</A>.</P>

<P><B>EWG 2023-11-07</B></P>

<P>EWG is soliciting a paper to make this either ill-formed, no
diagnostic required, or well-formed.</P>

<BR><BR><HR>
<A NAME="2779"></A><H4>2779.
  
Restrictions on the ordinary literal encoding
</H4>
<B>Section: </B>5.3.1&#160; [<A href="https://wg21.link/lex.charset">lex.charset</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2023-03-28<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/285">#285</A>.)</P>

<P>There are no restrictions on the implementation's choice of
ordinary literal encoding.  However, there is an implicit assumption
that a code unit value must fit into a <TT>char</TT>.</P>

<P>Tangentially related to that, "cannot be encoded as a single code
unit" could be interpreted as referring to the values of the code
units as opposed to the fact that multiple code units might be
needed.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 5.3.1 [<A href="https://wg21.link/lex.charset#8">lex.charset</A>] paragraph 8 as follows and add to
the index of implementation-defined behavior:</P>


<BLOCKQUOTE>

A <I>code unit</I> is an integer value of character type
(6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]). Characters in a <I>character-literal</I>
other than a multicharacter <DEL>or non-encodable character</DEL>
literal or in a <I>string-literal</I> are encoded as a sequence of one
or more code units, as determined by the <I>encoding-prefix</I>
(5.13.3 [<A href="https://wg21.link/lex.ccon">lex.ccon</A>], 5.13.5 [<A href="https://wg21.link/lex.string">lex.string</A>]); this is
termed the respective <I>literal encoding</I>.  The <I>ordinary literal
encoding</I> is the
<INS>implementation-defined</INS> encoding applied to an ordinary
character or string literal<INS>; its code units are of
type <TT>unsigned char</TT></INS>.  The <I>wide literal encoding</I>
is the <INS>implementation-defined</INS> encoding applied to a wide
character or string literal<INS>; its code units are of
type <TT>wchar_t</TT></INS>.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 5.13.3 [<A href="https://wg21.link/lex.ccon#3.1">lex.ccon</A>] bullet 3.1 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>
A <I>character-literal</I> with a <I>c-char-sequence</I> consisting of
a single <I>basic-c-char</I> , <I>simple-escape-sequence</I>,
or <I>universal-character-name</I> is the code unit value of the
specified character as encoded in the literal's associated character
encoding. If the specified character lacks representation in the
literal's associated character encoding or if it <DEL>cannot be
encoded as a single code unit</DEL> <INS>is encoded with multiple code
units</INS>, then the program is ill-formed.
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><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>5.5&#160; [<A href="https://wg21.link/lex.pptoken">lex.pptoken</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Martin v. Loewis
 &#160;&#160;&#160;

 <B>Date: </B>30 July 2002<BR>


<P>5.5 [<A href="https://wg21.link/lex.pptoken#2">lex.pptoken</A>] paragraph 2 specifies that there are 5
categories of tokens in phases 3 to 6. With 5.8 [<A href="https://wg21.link/lex.operators#1">lex.operators</A>] 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="1655"></A><H4>1655.
  
Line endings in raw string literals
</H4>
<B>Section: </B>5.5&#160; [<A href="https://wg21.link/lex.pptoken">lex.pptoken</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-26<BR>


<P>According to 5.5 [<A href="https://wg21.link/lex.pptoken#3">lex.pptoken</A>] paragraph 3,</P>

<BLOCKQUOTE>

<P>If the input stream has been parsed into preprocessing
tokens up to a given character:</P>

<UL>
<LI>

<P>If the next character begins a sequence of characters that
could be the prefix and initial double quote of a raw string
literal, such as <TT>R"</TT>, the next preprocessing token shall be a
raw string literal. Between the initial and final double
quote characters of the raw string, any transformations
performed in phases 1 and 2 (trigraphs,
universal-character-names, and line splicing) are reverted;
this reversion shall apply before
any <I>d-char</I>, <I>r-char</I>, or delimiting parenthesis
is identified.</P>
</LI>

</UL>

</BLOCKQUOTE>

<P>However, phase 1 is defined as:</P>

<BLOCKQUOTE>

Physical source file characters are mapped, in an
implementation-defined manner, to the basic source character
set (introducing new-line characters for end-of-line
indicators) if necessary. The set of physical source file
characters accepted is implementation-defined. Trigraph
sequences (_N4140_.2.4 [<A href="https://wg21.link/lex.trigraph">lex.trigraph</A>]) are replaced by
corresponding single-character internal representations. Any
source file character not in the basic source character set
(5.3.1 [<A href="https://wg21.link/lex.charset">lex.charset</A>]) is replaced by the
universal-character-name that designates that character.

</BLOCKQUOTE>

<P>The reversion described in 5.5 [<A href="https://wg21.link/lex.pptoken">lex.pptoken</A>] paragraph
3 specifically does not mention the replacement of physical
end-of-line indicators with new-line characters.  Is it intended
that, for example, a CRLF in the source of a raw string literal
is to be represented as a newline character or as the original
characters?</P>

<BR><BR><HR>
<A NAME="3019"></A><H4>3019.
  
Restrictions on character sequences in <I>header-name</I>s
</H4>
<B>Section: </B>5.6&#160; [<A href="https://wg21.link/lex.header">lex.header</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2025-03-26<BR>




<P>Subclause 5.6 [<A href="https://wg21.link/lex.header">lex.header</A>] specifies implementation-defined
behavior for certain character sequences appearing
in <I>header-name</I>s.  This is redundant with the
implementation-defined searches specified in 15.3 [<A href="https://wg21.link/cpp.include">cpp.include</A>]
and 15.4.1 [<A href="https://wg21.link/cpp.embed.gen">cpp.embed.gen</A>], which already cover recognition
of <TT>\</TT> escape sequences and similar implementation
deviations.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 5.6 [<A href="https://wg21.link/lex.header">lex.header</A>] as follows:</P>

<BLOCKQUOTE>

<DEL>The appearance of either of the characters ' or \ or of either of
the character sequences /* or // in a <I>q-char-sequence</I> or
an <I>h-char-sequence</I> is conditionally-supported with
implementation-defined semantics, as is the appearance of the
character " in an <I>h-char-sequence</I>.</DEL> [<I>Note
2:</I> <INS>As specified in 15.3 [<A href="https://wg21.link/cpp.include">cpp.include</A>] and
15.4 [<A href="https://wg21.link/cpp.embed">cpp.embed</A>], which header, source file, or resource is
identified by a <I>header-name</I>, if any, is
implementation-defined.</INS> Thus, a sequence of characters that
resembles an escape sequence can result in an error, be interpreted as
the character corresponding to the escape sequence, or have a
completely different meaning, depending on the
implementation. <INS>However, a <TT>"</TT> character cannot appear in
an <I>q-char-sequence</I>, and a <TT>&gt;</TT> character cannot appear
in a <I>h-char-sequence</I>, even if preceded by a <TT>\</TT>
character.</INS> &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P><B>Additional notes (March, 2025)</B></P>

<P>The new wording removes the permission for implementations to yield
an error when a <I>header-name</I> contains ", \, or ' in
a <TT>__has_include</TT>.</P>

<BR><BR><HR>
<A NAME="189"></A><H4>189.
  
Definition of <I>operator</I> and <I>punctuator</I>
</H4>
<B>Section: </B>5.8&#160; [<A href="https://wg21.link/lex.operators">lex.operators</A>]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#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
5.10 [<A href="https://wg21.link/lex.token">lex.token</A>]
 are not defined.  There is
a definition of the nonterminal <I>operator</I> in
12.4 [<A href="https://wg21.link/over.oper#1">over.oper</A>] 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
5.8 [<A href="https://wg21.link/lex.operators">lex.operators</A>]
, 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 12.4 [<A href="https://wg21.link/over.oper">over.oper</A>]
 to use the term
<I>overloadable-operator</I>.</LI>

<LI>Change 5.10 [<A href="https://wg21.link/lex.token">lex.token</A>]
 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 5.8 [<A href="https://wg21.link/lex.operators">lex.operators</A>]
 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
12.4 [<A href="https://wg21.link/over.oper#3">over.oper</A>] 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="1901"></A><H4>1901.
  
<I>punctuator</I> referenced but not defined
</H4>
<B>Section: </B>5.10&#160; [<A href="https://wg21.link/lex.token">lex.token</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-03-25<BR>




<P>The syntactic nonterminal <I>punctuator</I> appears in the grammar
for <I>token</I> in 5.10 [<A href="https://wg21.link/lex.token">lex.token</A>], but it is nowhere
defined.  It should be merged with <I>operator</I> and given an
appropriate list of tokens as a definition for the merged term.</P>



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

<OL>
<LI><P>Change 5.9 [<A href="https://wg21.link/lex.digraph#2">lex.digraph</A>] paragraph 2 as follows</P></LI>

<BLOCKQUOTE>

In all respects of the language <INS>except in an
<I>attribute-token</I> (9.13.1 [<A href="https://wg21.link/dcl.attr.grammar">dcl.attr.grammar</A>])</INS>, each
alternative token behaves the same, respectively, as its primary token,
except for its spelling.<SUP>18</SUP> The set of alternative tokens...

</BLOCKQUOTE>

<LI><P>Change the grammar in 5.10 [<A href="https://wg21.link/lex.token">lex.token</A>] as follows:</P></LI>

<UL>
<I>token:</I>
<UL>
<I>identifier</I><BR>
<I>keyword</I><BR>
<I>literal<INS>-token</INS></I><BR>
<I>operator</I><BR>
<I>punctuator</I>
</UL>
</UL>
<BR>
<UL>
<I><INS>literal-token:</INS></I>
<UL>
<I><INS>integer-literal</INS></I><BR>
<I><INS>floating-literal</INS></I><BR>
<I><INS>character-literal</INS></I><BR>
<I><INS>string-literal</INS></I><BR>
<I><INS>user-defined-literal</INS></I>
</UL>
</UL>
<BR>
<UL>
<INS><I>symbol:</I> one of</INS>
<UL>
<PRE>
<INS>{    }    [    ]    (    )    ;    :    ...  ?    ::   .    .*</INS>
<INS>+    -    *    /    %    ^    &amp;    |    ~    !    =    &lt;    &gt;</INS>
<INS>+=   -=   *=   /=   %=   ^=   &amp;=   |=   &lt;&lt;   &gt;&gt;   &lt;&lt;=  &gt;&gt;=</INS>
<INS>==   !=   &lt;=   &gt;=   &amp;&amp;   ||   ++   --   ,    -&gt;*  -&gt;</INS>
</PRE>
</UL>
</UL>

<LI><P>Change 5.10 [<A href="https://wg21.link/lex.token#1">lex.token</A>] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>There are <DEL>five</DEL> <INS>four</INS> kinds of tokens: identifiers,
keywords, literals,<SUP>19</SUP> <DEL>operators, and other separators</DEL>
<INS>and symbols</INS>. <DEL>Blanks, horizontal and vertical tabs, newlines,
formfeeds, and comments (collectively, &#8220;white space&#8221;), as
described below, are ignored except as they serve to separate
tokens. [<I>Note:</I> Some white space is required to separate otherwise
adjacent identifiers, keywords, numeric literals, and alternative tokens
containing alphabetic characters. &#8212;<I>end note</I>]</DEL>
<INS>Each <I>preprocessing-token</I> resulting from translation phase 6
is converted into the corresponding <I>token</I> as follows:</INS>
</P>

<UL>
<LI><P><INS>If the <I>preprocessing-token</I> is an <I>identifier</I>
or is one of the <I>preprocessing-op-or-punc</I> tokens <TT>new</TT> or
<TT>delete</TT>, the resulting <I>token</I> is a <I>keyword</I> if it is
listed in Table 5, and otherwise is an <I>identifier</I>.</INS></P></LI>

<LI><P><INS>Otherwise, if the <I>preprocessing-token</I> is a
<I>pp-number</I> with the lexical form of an <I>integer-literal</I> or
<I>floating-literal</I>, or is a <I>character-literal</I> or
<I>string-literal</I>, the resulting <I>token</I> is of the corresponding
form.</INS></P></LI>

<LI><P><INS>Otherwise, if the <I>preprocessing-token</I> is a
<I>pp-number</I> with the lexical form of
a <I>user-defined-integer-literal</I>
or <I>user-defined-floating-literal</I> or is
a <I>user-defined-character-literal</I> or
<I>user-defined-string-literal</I>, the resulting token is a
<I>user-defined-literal</I>.</INS></P></LI>

<LI><P><INS>Otherwise, if the <I>preprocessing-token</I> is a
<I>preprocessing-op-or-punc</I>, and there is a corresponding <I>symbol</I>
(after converting alternative token representations to their primary
tokens), the resulting <I>token</I> is that <I>symbol</I>.</INS></P></LI>

<LI><P><INS>Otherwise, the program is ill-formed.</INS></P></LI>

</UL>

<P><INS>[<I>Note:</I> Within an <I>attribute-token</I>
(9.13.1 [<A href="https://wg21.link/dcl.attr.grammar">dcl.attr.grammar</A>]), a <I>token</I> formed from a
<I>preprocessing-token</I> that satisfies the syntactic requirements of
an <I>identifier</I> is considered to be an <I>identifier</I> with the
spelling of the <I>preprocessing-token</I>. &#8212;<I>end
note</I>]</INS></P>

</BLOCKQUOTE>

<LI><P>Delete the final sentence of 5.8 [<A href="https://wg21.link/lex.operators#1">lex.operators</A>] paragraph 1.
</P></LI>

<BLOCKQUOTE>

<DEL>Each <I>preprocessing-op-or-punc</I> is converted to a single token in
translation phase 7 (5.2 [<A href="https://wg21.link/lex.phases">lex.phases</A>]).</DEL>

</BLOCKQUOTE>

</OL>



<BR><BR><HR>
<A NAME="2752"></A><H4>2752.
  
Excess-precision floating-point literals
</H4>
<B>Section: </B>5.13.4&#160; [<A href="https://wg21.link/lex.fcon">lex.fcon</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Peter Dimov
 &#160;&#160;&#160;

 <B>Date: </B>2023-06-29
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Consider:</P>

<PRE>
  int main()
  {
    constexpr auto x = 3.14f;
    assert( x == 3.14f );         //<SPAN CLASS="cmnt"> can fail?</SPAN>
    static_assert( x == 3.14f );  //<SPAN CLASS="cmnt"> can fail?</SPAN>
  }
</PRE>

<P>Can a conforming implementation represent a floating-point literal
with excess precision, causing the comparisons to fail?</P>

<P>Subclause 5.13.4 [<A href="https://wg21.link/lex.fcon#3">lex.fcon</A>] paragraph 3 specifies:</P>

<BLOCKQUOTE>

If the scaled value is not in the range of representable values for
its type, the program is ill-formed. Otherwise, the value of
a <I>floating-point-literal</I> is the scaled value if representable,
else the larger or smaller representable value nearest the scaled
value, chosen in an implementation-defined manner.

</BLOCKQUOTE>

<P>This phrasing leaves little leeway for excess precision.  In
contrast, C23 specifies in section 6.4.4.3 paragraph 6:

<BLOCKQUOTE>

The values of floating constants may be represented in greater range
and precision than that required by the type (determined by the
suffix); the types are not changed thereby. ...

</BLOCKQUOTE>
</P>

<P>Subclause 7.1 [<A href="https://wg21.link/expr.pre#6">expr.pre</A>] paragraph 6 allows excess precision
for floating-point computations (including their operands):</P>

<BLOCKQUOTE>

The values of the floating-point operands and the results of
floating-point expressions may be represented in greater precision and
range than that required by the type; the types are not changed
thereby. [ Footnote: The cast and assignment operators must still
perform their specific conversions as described in
7.6.1.4 [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>], 7.6.3 [<A href="https://wg21.link/expr.cast">expr.cast</A>],
7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>] and 7.6.19 [<A href="https://wg21.link/expr.assign">expr.assign</A>]. -- end
footnote ]

</BLOCKQUOTE>

<P>Taken together, that means that <TT>314.f / 100.f</TT> can be
computed and represented more precisely than <TT>3.14f</TT>, which is
hard to justify.  The footnote appears to imply
that <TT>(float)3.14f</TT> is required to yield a value
with <TT>float</TT> precision, but that conversion (eventually) ends up at 9.5.1 [<A href="https://wg21.link/dcl.init.general#16.9">dcl.init.general</A>] bullet 16.9:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>Otherwise, the initial value of the object being initialized is the
(possibly converted) value of the initializer expression. ... </LI>
</UL>

</BLOCKQUOTE>

<P>If values produced from literals were permitted to carry excess
precision, this phrasing does not seem to convery permission to
discard excess precision when converting from a <TT>float</TT> value
to type <TT>float</TT> ("... is the value..."), apparently requiring
that the target object's value also carry the excess precision.</P>

<P>However, if initialization is intended to drop excess precision,
then an overloaded operator returning <TT>float</TT> can never behave
like a built-in operation with excess precision, because returning a value
means initializing the return value.</P>

<P>The C++ standard library inherits the <TT>FLT_EVAL_METHOD</TT>
macro from the C standard library. C23 specifies it as
follows in section 5.2.5.3.3:</P>

<BLOCKQUOTE>

<TABLE>
<TR>
<TD>0</TD>
<TD>evaluate all operations and constants just to the range and precision
of the type;</TD>
</TR>
<TR>
<TD VALIGN="TOP">1</TD>
<TD>evaluate operations and constants of type float and
double to the range and precision of the double type, evaluate long
double operations and constants to the range and precision of the long
double type;</TD>
</TR>
<TR>
<TD>2</TD>
<TD>evaluate all operations and constants to the range and
precision of the long double type.</TD>
</TR>
</TABLE>

</BLOCKQUOTE>

<P>Taken together, a conforming C++ implementation cannot
define <TT>FLT_EVAL_METHOD</TT> to 1 or 2, because literals (=
"constants") cannot be represented with excess precision in C++.</P>

<P><B>Additional notes (June, 2023)</B></P>

<P>Forwarded to EWG via
<A HREF="https://github.com/cplusplus/papers/issues/1584">cplusplus/papers#1584</A>, by decision of the CWG chair.</P>

<BR><BR><HR>
<A NAME="2766"></A><H4>2766.
  
Repeated evaluation of a <I>string-literal</I> may yield different
objects
</H4>
<B>Section: </B>5.13.5&#160; [<A href="https://wg21.link/lex.string">lex.string</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Balog Pal
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-15<BR>




<P>Prior to the resolution of <A HREF="cwg_defects.html#1823">issue 1823</A>
(incorporated into C++17), the specification required in
9.2.3 [<A href="https://wg21.link/dcl.fct.spec#4">dcl.fct.spec</A>] paragraph 4:</P>

<BLOCKQUOTE>

A string literal in the body of an <TT>extern</TT> <TT>inline</TT>
function is the same object in different translation units.

</BLOCKQUOTE>

<P>That was changed to the following specification in
5.13.5 [<A href="https://wg21.link/lex.string#9">lex.string</A>] paragraph 9:</P>

<BLOCKQUOTE>

Evaluating a <I>string-literal</I> results in a string literal object
with static storage duration (6.8.6 [<A href="https://wg21.link/basic.stc">basic.stc</A>]).
... whether successive evaluations of a <I>string-literal</I> yield
the same or a different object is unspecified.

</BLOCKQUOTE>

<P>The treatment of string literal objects was harmonized with backing
arrays in P2752R3 (approved in June, 2023) and
<A HREF="cwg_defects.html#2753">issue 2753</A>.</P>

<P>The rationale for the change made by <A HREF="cwg_defects.html#1823">issue 1823</A> was deviating implementation practice: Implementations do
not unify string literal objects in inline functions or template
instantiations across different translation units.</P>

<P>However, that was a silent behavior change for examples such as:</P>

<PRE>
  const char *f() { return "abc"; }
  bool b = f() == f();    //<SPAN CLASS="cmnt"> guaranteed </SPAN>true<SPAN CLASS="cmnt"> prior to CWG1823, now unspecified</SPAN>
</PRE>

<P>The matter should be revisited in light of this new information.</P>

<BR><BR><HR>
<A NAME="1266"></A><H4>1266.
  
<I>user-defined-integer-literal</I> overflow
</H4>
<B>Section: </B>5.13.9&#160; [<A href="https://wg21.link/lex.ext">lex.ext</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-20<BR>


<P>The <I>decimal-literal</I> in a <I>user-defined-integer-literal</I>
might be too large for an <TT>unsigned long long</TT> to represent (in
implementations with extended integer types).  In such cases, the
original intent appears to have been to call a raw literal operator or
a literal operator template; however, the existing wording of
5.13.9 [<A href="https://wg21.link/lex.ext#3">lex.ext</A>] paragraph 3 always calls the
<TT>unsigned long long</TT> literal operator if it exists, regardless
of the value of the <I>decimal-literal</I>.</P>

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

<BR><BR><HR>
<A NAME="1723"></A><H4>1723.
  
Multicharacter user-defined character literals
</H4>
<B>Section: </B>5.13.9&#160; [<A href="https://wg21.link/lex.ext">lex.ext</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-31<BR>




<P>According to 5.13.3 [<A href="https://wg21.link/lex.ccon#1">lex.ccon</A>] paragraph 1, a multicharacter
literal like <TT>'ab'</TT> is conditionally-supported and has
type <TT>int</TT>.</P>

<P>According to 5.13.9 [<A href="https://wg21.link/lex.ext#6">lex.ext</A>] paragraph 6,</P>

<BLOCKQUOTE>

<P>If <I>L</I> is a <I>user-defined-character-literal</I>, let <I>ch</I> be
the literal without its <I>ud-suffix</I>. <I>S</I> shall contain a literal
operator (12.6 [<A href="https://wg21.link/over.literal">over.literal</A>]) whose only parameter has the type
of <I>ch</I> and the literal <I>L</I> is treated as a call of the form</P>

<UL>
<TT>operator ""</TT> <I>X</I><TT>(</TT><I>ch</I><TT>)</TT>
</UL>

</BLOCKQUOTE>

<P>A <I>user-defined-character-literal</I> like <TT>'ab'_foo</TT> would
thus require a literal operator</P>

<UL><TT>operator "" _foo(int)</TT></UL>

<P>However, that is not one of the signatures permitted by
12.6 [<A href="https://wg21.link/over.literal#3">over.literal</A>] paragraph 3.</P>

<P>Should multicharacter <I>user-defined-character-literal</I>s be
conditionally-supported?  If so, 12.6 [<A href="https://wg21.link/over.literal#3">over.literal</A>] paragraph 3
should be adjusted accordingly.  If not, a note in
5.13.9 [<A href="https://wg21.link/lex.ext#6">lex.ext</A>] paragraph 6 saying explicitly that they are not
supported would be helpful.</P>

<BR><BR><HR>
<A NAME="1735"></A><H4>1735.
  
Out-of-range literals in <I>user-defined-literal</I>s
</H4>
<B>Section: </B>5.13.9&#160; [<A href="https://wg21.link/lex.ext">lex.ext</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-12<BR>


<P>The description of the numeric literals occurring as part of
<I>user-defined-integer-literal</I>s and
<I>user-defined-floating-literal</I>s in 5.13.9 [<A href="https://wg21.link/lex.ext">lex.ext</A>] says
nothing about whether they are required to satisfy the same constraints as
literals that are not part of a <I>user-defined-literal</I>.  In
particular, because it is the spelling, not the value, of the literal
that is used for raw literal operators and literal operator templates,
there is no particular reason that they should be restricted to the
maximum values and precisions that apply to ordinary literals (and one
could imagine that this would be a good notation for allowing literals
of extended-precision types).</P>

<P>Is this relaxation of limits intended to be required, or is it a
quality-of-implementation issue?  Should something be said, either
normatively or non-normatively, about this question?</P>

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

<BR><BR><HR>
<A NAME="2983"></A><H4>2983.
  
Non-type template parameters are not variables
</H4>
<B>Section: </B>6.1&#160; [<A href="https://wg21.link/basic.pre">basic.pre</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2025-01-09<BR>




<P>Subclause 6.1 [<A href="https://wg21.link/basic.pre#6">basic.pre</A>] paragraph 6 specifies:</P>

<BLOCKQUOTE>

A <I>variable</I> is introduced by the declaration of a reference other than
a non-static data member or of an object. The variable's name, if any,
denotes the reference or object.

</BLOCKQUOTE>

<P>Does this mean that non-type template parameters of class type are
variables?  Better not.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.1 [<A href="https://wg21.link/basic.pre#6">basic.pre</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

<INS>A <I>non-template-parameter declaration</I> is a declaration that
is not a <I>type-parameter</I> or <I>parameter-declaration</I> of
a <I>template-parameter</I>.</INS> A <I>variable</I> is introduced by
the <INS>non-template-parameter</INS> declaration of a reference other
than a non-static data member or of an object. The variable's name, if
any, denotes the reference or object.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2992"></A><H4>2992.
  
Labels do not have names
</H4>
<B>Section: </B>6.1&#160; [<A href="https://wg21.link/basic.pre">basic.pre</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Vlad Serebrennikov
 &#160;&#160;&#160;

 <B>Date: </B>2025-02-20<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/673">#673</A>.)

<P>Subclause 6.1 [<A href="https://wg21.link/basic.pre#3">basic.pre</A>] paragraph 3 specifies:</P>

<BLOCKQUOTE>

A name is an <I>identifier</I> (5.11 [<A href="https://wg21.link/lex.name">lex.name</A>]),
<I>conversion-function-id</I> (11.4.8.3 [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>]),
<I>operator-function-id</I> (12.4 [<A href="https://wg21.link/over.oper">over.oper</A>]), or
<I>literal-operator-id</I> (12.6 [<A href="https://wg21.link/over.literal">over.literal</A>]).

</BLOCKQUOTE>

<P>That seems to incorrectly include identifier labels per the grammar
in 8.2 [<A href="https://wg21.link/stmt.label#1">stmt.label</A>] paragraph 1 as well as attributes per the
grammar in 9.13.1 [<A href="https://wg21.link/dcl.attr.grammar#1">dcl.attr.grammar</A>] paragraph 1.</P>
</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.1 [<A href="https://wg21.link/basic.pre#3">basic.pre</A>] paragraph 3 as follows and add bullets:</P>

<BLOCKQUOTE>

A <I>name</I> is
<UL>
<LI>an <I>identifier</I> (5.11 [<A href="https://wg21.link/lex.name">lex.name</A>]) <INS>other than
the <I>identifier</I> of a <I>label</I>
or <I>attribute-token</I></INS>,</LI>
<LI>
<I>conversion-function-id</I> (11.4.8.3 [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>]),</LI>
<LI>
<I>operator-function-id</I> (12.4 [<A href="https://wg21.link/over.oper">over.oper</A>]), or</LI>
<LI>
<I>literal-operator-id</I> (12.6 [<A href="https://wg21.link/over.literal">over.literal</A>]).</LI>
</UL>

</BLOCKQUOTE>

<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>6.3&#160; [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]
 &#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 6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>] does not make any special
provision for expressions that appear only in uninstantiated template
definitions.</P>

(See also <A HREF="cwg_closed.html#1254">issue 1254</A>.)

<BR><BR><HR>
<A NAME="2781"></A><H4>2781.
  
Unclear recursion in the one-definition rule
</H4>
<B>Section: </B>6.3&#160; [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2023-08-19<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/402">#402</A>.)</P>

<P>Consider the following tokens appearing in multiple translation units:</P>

<PRE>
 inline void f() {
   int a;
   int b = a;
 }
</PRE>

<P>Does <TT>f</TT> violate the one-definition rule?</P>

<P>We have this check in 6.3 [<A href="https://wg21.link/basic.def.odr#14.5">basic.def.odr</A>] paragraph 14.5:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>In each such definition, corresponding names, looked up according to
6.5 [<A href="https://wg21.link/basic.lookup">basic.lookup</A>], shall refer to the same entity, ...</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>Does <TT>a</TT> refer to the same entity in the several definitions
of <TT>f</TT>? Subclause 6.3 [<A href="https://wg21.link/basic.def.odr#16">basic.def.odr</A>] paragraph 16
specifies:</P>

<BLOCKQUOTE>

These requirements also apply to corresponding entities defined within
each definition of D (including the closure types
of <I>lambda-expression</I>s, but excluding entities defined within
default arguments or default template arguments of either D or an
entity not defined within D). For each such entity and for D itself,
the behavior is as if there is a single entity with a single
definition, including in the application of these requirements to
other entities.

</BLOCKQUOTE>

<P>Thus, the requirements apply recursively to the definitions
of <TT>a</TT>, but it is unclear whether the conclusion "as if there
is a single entity with a single definition" is reached at each level
of the recursion separately.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.3 [<A href="https://wg21.link/basic.def.odr#16">basic.def.odr</A>] paragraph 16 as follows:</P>

<BLOCKQUOTE>

<INS>If these requirements are satisfied, the behavior for <TT>D</TT>
is as if there is a single entity with a single definition, including
in the application of these requirements to other entities.</INS>
<DEL>These requirements</DEL> <INS>This behavior</INS>
also <DEL>apply</DEL> <INS>applies</INS> to corresponding entities
defined within each definition of D (including the closure types
of <I>lambda-expression</I>s, but excluding entities defined within
default arguments or default template arguments of either D or an
entity not defined within D). <DEL>For each such entity and for D
itself, the behavior is as if there is a single entity with a single
definition, including in the application of these requirements to
other entities.</DEL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2782"></A><H4>2782.
  
Treatment of closure types in the one-definition rule
</H4>
<B>Section: </B>6.3&#160; [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-20<BR>




<P>Consider:</P>

<PRE>
  inline auto lambda = []{}; //<SPAN CLASS="cmnt"> same in different translation units or not?</SPAN>
</PRE>

<P>This can be observed, for example, through the following variable
template:</P>

<PRE>
  template&lt;class T&gt; int v;
</PRE>

<P>Is <TT>&amp;v&lt;decltype(lambda)&gt;</TT> the same address in every
translation unit?</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 6.3 [<A href="https://wg21.link/basic.def.odr#14">basic.def.odr</A>] paragraph 14 as follows:</P>

<BLOCKQUOTE>

For any definable item D with definitions in multiple translation
units,
<UL>
<LI>if D is a non-inline non-templated function or variable, or</LI>
<LI>if the definitions in different translation units do not satisfy
the following requirements,</LI>
</UL>
the program is ill-formed; a diagnostic is required only if the
definable item is attached to a named module and a prior definition is
reachable at the point where a later definition occurs. Given such an
item, for all definitions of D, or, if D is an unnamed enumeration,
for all definitions of D that are reachable at any given program
point, the following requirements shall be satisfied<INS>, where the
definition of a closure type is considered to consist of the sequence
of tokens of the corresponding <I>lambda-expression</I></INS>.

<UL>
<LI>...</LI>
<LI>Each such definition shall consist of the same sequence of
tokens<DEL>, where the definition of a closure type is considered to
consist of the sequence of tokens of the
corresponding <I>lambda-expression</I></DEL>.</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Add another example after example 6, immediately before
6.3 [<A href="https://wg21.link/basic.def.odr#18">basic.def.odr</A>] paragraph 18:</P>

<BLOCKQUOTE class="ins">

[ Example:
<PRE>
  inline decltype([]{}) v1;
  inline auto v2 = []{};
</PRE>
If the definition of <TT>v1</TT> appears in multiple translation
units, the program is ill-formed, no diagnostic required, because each
definition declares <TT>v1</TT> to have a different type. If the
definition of <TT>v2</TT> appears in multiple translation units, the
behavior of the program is as if there is only one definition, and
only a definition can supply an initializer; therefore the behavior is
as if there is only one initializer. Therefore, <TT>v2</TT> has the
same type in every translation unit.  -- end example]

</BLOCKQUOTE>
<BLOCKQUOTE>

<P>If, at any point in the program, there is more than one reachable
unnamed enumeration definition in the same scope...</P>

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="2969"></A><H4>2969.
  
Scopes in the <I>function-try-block</I> of a constructor
</H4>
<B>Section: </B>6.4&#160; [<A href="https://wg21.link/basic.scope">basic.scope</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2024-12-09<BR>




<P>Per the specification, the block scope for a
<I>function-try-block</I> does not include the
<I>ctor-initializer</I>.  Consider the following implementation
divergence:</P>

<PRE>
  struct A {
    A() try : p((struct B*)nullptr) {
      B *q;
      struct B {};
      B *r = q;       //<SPAN CLASS="cmnt"> EDG, GCC, MSVC: error: cannot convert, two different Bs</SPAN>
    } catch (...) {
      B *q;           //<SPAN CLASS="cmnt"> GCC: B not in scope here.</SPAN>
    }
   void *p;
  };

  struct C {
    C(int B) try : p((struct B*)0) {      //<SPAN CLASS="cmnt"> GCC: error: shadows parameter; MSVC: error: redefinition of B</SPAN>
    } catch (...) { }
    void *p;
  };
</PRE>

<P>There is also implementation divergence regarding the scope of
the <I>ctor-initializer</I> if no <I>function-try-block</I>s are
involved.</P>

<BR><BR><HR>
<A NAME="2488"></A><H4>2488.
  
Overloading virtual functions and functions with trailing <I>requires-clause</I>s
</H4>
<B>Section: </B>6.4.1&#160; [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2020-08-19<BR>


<P>According to 6.4.1 [<A href="https://wg21.link/basic.scope.scope#3">basic.scope.scope</A>] paragraph 3,</P>

<BLOCKQUOTE>

<P>Two declarations <I>correspond</I> if they (re)introduce
the same name, both declare constructors, or both declare
destructors, unless</P>

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

<LI><P>each declares a function or function template, except when</P></LI>

<UL>
<LI><P>both declare functions with the same
parameter-type-list,<SUP>21</SUP> equivalent
(13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>])
trailing <I>requires-clause</I>s (if any, except as
specified in 13.7.5 [<A href="https://wg21.link/temp.friend">temp.friend</A>]), and, if both are
non-static members, the same <I>cv-qualifiers</I> (if any)
and <I>ref-qualifier</I> (if both have one), or</P></LI>

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

</UL>

</UL>

</BLOCKQUOTE>

<P>This would indicate that a virtual function (which
cannot have a trailing <I>requires-clause</I>, per
11.7.3 [<A href="https://wg21.link/class.virtual#6">class.virtual</A>] paragraph 6) can be overloaded
with a non-virtual member function with the same
parameter type list but with a trailing <I>requires-clause</I>.
However, this is not implementable on some ABIs, since the
mangling of the two functions would be the same. For example:</P>

<PRE>

  #include &lt;type_traits&gt;
  template&lt;class T&gt;
  struct Foo {
     virtual void fun() const {}
     void fun() const requires std::is_object_v&lt;T&gt; {}
  };
  int main() {
    Foo&lt;int&gt;{}.fun();
  }
</PRE>

<P>Should such overloading be ill-formed or
conditionally-supported, or should the current rules
be kept?</P>

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

<P>CWG felt that the current rules are correct; it
simply means that only the virtual function can be
called, and all other references are simply ambiguous.
(See also <A HREF="cwg_active.html#2501">issue 2501</A> for a
related question dealing with explicit instantiation.</P>

<P><B>Notes from the November, 2021 teleconference:</B></P>

<P>The issue has been reopened in response to additional
discussion. </P>

<P><B>CWG 2022-11-11</B></P>

<P>This is related to <A HREF="cwg_active.html#2501">issue 2501</A>.
CWG solicits a paper to address this issue.</P>

<BR><BR><HR>
<A NAME="2788"></A><H4>2788.
  
Correspondence and redeclarations
</H4>
<B>Section: </B>6.4.1&#160; [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

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


<P>Consider:</P>

<PRE>
  struct S {
    void f() &amp;;
  };
  void S::f(this S&amp;) {}
</PRE>

<P>Both declarations of <TT>S::f</TT> correspond
(6.4.1 [<A href="https://wg21.link/basic.scope.scope#4">basic.scope.scope</A>] paragraph 4), but are ill-formed according to
6.7 [<A href="https://wg21.link/basic.link#1">basic.link</A>] paragraph 1, because the functions are not of
the same type:</P>

<BLOCKQUOTE>

For any two declarations of an entity E:
<UL>
<LI>If one declares E to
be a variable or function, the other shall declare E as one of the
same type.</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>A similar situation arises for the following example:</P>

<PRE>
  struct S {
    void g() &amp;;
  };
  void S::g() { }
</PRE>

<P><U>Possible resolution:</U></P>

<P>Add a note in 6.4.1 [<A href="https://wg21.link/basic.scope.scope#4">basic.scope.scope</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>
<INS>[ Note: Two function declarations with
different <I>ref-qualifier</I>s or parameter-type-lists do not have
the same type even if they correspond (6.7 [<A href="https://wg21.link/basic.link">basic.link</A>]). --
end note ]</INS><BR>

[ Example 2:
<PRE>
  typedef int Int;
  ...
   
<INS>    void m();
    void n();</INS>
  };

<INS> X::m() &amp; {}       // <SPAN CLASS="cmnt">error: redeclaration of </SPAN>X::m<SPAN CLASS="cmnt"> with a different type</SPAN>
 X::n(this X&amp;) {}  // <SPAN CLASS="cmnt">error: redeclaration of </SPAN>X::n<SPAN CLASS="cmnt"> with a different type</SPAN></INS>
</PRE>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2835"></A><H4>2835.
  
Name-independent declarations
</H4>
<B>Section: </B>6.4.1&#160; [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jakub Jel&#237;nek
 &#160;&#160;&#160;

 <B>Date: </B>2023-11-30<BR>


<P>The wording for name-independent declarations applied by P2169R4 (A
nice placeholder with no name) apparently fails to implement the
intent.</P>

<P>Consider:</P>

<PRE>
  void foo () { auto c = [_ = 2, _ = 3] () {}; }   // <SPAN CLASS="cmnt">duplicate identifier in lambda-capture</SPAN>

  struct S { int _; int _; };  // <SPAN CLASS="cmnt">repeated member declaration</SPAN>

  void f() {
    if (int _ = 5) {    // <SPAN CLASS="cmnt">#1</SPAN>
      int _ = 6;        // <SPAN CLASS="cmnt">#2</SPAN>
      int k = _;        // <SPAN CLASS="cmnt">ambiguous lookup despite #1 and #2 in different scopes?</SPAN>
    } else {
       int _ = 7;
    }
  }
</PRE>

<P><U>Possible resolution (first two issues):</U></P>

<OL>
<LI>
<P>Change in 7.5.6.3 [<A href="https://wg21.link/expr.prim.lambda.capture#2">expr.prim.lambda.capture</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

... <INS>A <I>capture name</I> is an <I>identifier</I>
or <TT>this</TT>.</INS> Ignoring appearances in initializers
of <I>init-capture</I>s, <DEL>an identifier or <TT>this</TT> shall not
appear more than once</DEL> <INS>the program is ill formed if the
appearance of a capture name precedes another appearance of the
same capture name </INS>in a <I>lambda-capture</I><INS>, and the
latter is not a name-independent declaration
(6.4.1 [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>])</INS>.

[ Example 1:

<PRE>
  struct S2 { void f(int i); };
  void S2::f(int i) {
    [&amp;, i]{ };  //<SPAN CLASS="cmnt"> OK</SPAN>
    [&amp;, this, i]{ }; //<SPAN CLASS="cmnt"> OK, equivalent to [&amp;, i]</SPAN>
    [&amp;, &amp;i]{ };      //<SPAN CLASS="cmnt"> error: i preceded by &amp; when &amp; is the default</SPAN>
    [=, *this]{ };   //<SPAN CLASS="cmnt"> OK</SPAN>
    [=, this]{ };    //<SPAN CLASS="cmnt"> OK, equivalent to [=]</SPAN>
    [i, i]{ };       //<SPAN CLASS="cmnt"> error: i repeated</SPAN>
<INS>    int _ = 17;
    [_, _ = 42]{ };      //<SPAN CLASS="cmnt"> OK</SPAN></INS>
    [this, *this]{ }; //<SPAN CLASS="cmnt"> error: this appears twice</SPAN>
  }
</PRE>
--end example ]

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.1 [<A href="https://wg21.link/class.mem.general#5">class.mem.general</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

A member shall not be declared twice in the <I>member-specification</I>,
except that
<UL>
<LI>a nested class or member class template can be declared and then
later defined, and
</LI>
<LI>
an enumeration can be introduced with
an <I>opaque-enum-declaration</I> and later redeclared with
an <I>enum-specifier</I>.
</LI>
</UL>

[<I>Note 3:</I> A single name can denote several member functions
provided their types are sufficiently different
(6.4.1 [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]). <INS>Repeated name-independent
declarations declare different members.</INS> &#8212;<I>end note</I>]

</BLOCKQUOTE>

</LI>
</OL>

<P><B>CWG 2023-12-15</B></P>

<P>Having a lookup ambiguity for the third case (<TT>int k = _;</TT>)
seems consistent with the idea that #1 and #2 are considered to be in
the same scope as far as name conflict detection is concerned.
However, that would need new rules, given that name lookup does not
proceed to outer scopes when a name is found in an inner scope.
Similar lookup ambiguities across nested scopes can arise among lambda
captures, template parameters of a lambda, lambda function parameters,
and declartions in the outermost block scope of a lambda.</P>

<BR><BR><HR>
<A NAME="3005"></A><H4>3005.
  
Function parameters should never be name-independent
</H4>
<B>Section: </B>6.4.1&#160; [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jan Schultke
 &#160;&#160;&#160;

 <B>Date: </B>2025-03-10<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/681">#681</A>.)</P>

<P>According to
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2169r4.pdf">P2169R4</A>
(A nice placeholder with no name):</P>

<BLOCKQUOTE>

In Varna, EWG decided not to support function parameter names and
requires clauses param-eter as these can remained unamed without
semantics differences.

</BLOCKQUOTE>

<P>However, the normative wording does permit function parameters to
be name-independent, contrary to the express design intent.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.4.1 [<A href="https://wg21.link/basic.scope.scope#5.1">basic.scope.scope</A>] bullet 5.1 as follows:</P>

<BLOCKQUOTE>

A declaration is name-independent if its name is _ (u+005f low line)
and it declares
<UL>
<LI>a variable with automatic storage duration <INS>other than a
function parameter</INS>,</LI>
<LI>a structured binding with no <I>storage-class-specifier</I> and
not inhabiting a namespace scope,</LI>
<LI>the variable introduced by an <I>init-capture</I>, or</LI>
<LI>a non-static data member of other than an anonymous union.</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2838"></A><H4>2838.
  
Declaration conflicts in <I>lambda-expression</I>s
</H4>
<B>Section: </B>6.4.3&#160; [<A href="https://wg21.link/basic.scope.block">basic.scope.block</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jakub Jel&#237;nek
 &#160;&#160;&#160;

 <B>Date: </B>2023-11-30<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/475">#475</A>.)</P>

<P>Consider:</P>

<PRE>
  void foo () {
    auto f = [i = 5] () { int i; return 0; };
  }
</PRE>

<P>Before P2579R0 and P2036R3, this was ill-formed, because the
capture inhabited the same scope as <TT>int i</TT>. Subclause
6.4.3 [<A href="https://wg21.link/basic.scope.block#2">basic.scope.block</A>] paragraph 2 relies on the "parent" scope:</P>

<BLOCKQUOTE>

If a declaration that is not a name-independent declaration and whose
target scope is the block scope S of a
<UL>
<LI>
<I>compound-statement</I> of a <I>lambda-expression</I>,
<I>function-body</I>, or <I>function-try-block</I>,</LI>
<LI>substatement of a selection or iteration statement that is not
itself a selection or iteration statement, or</LI>
<LI>handler of a <I>function-try-block</I>
</LI>
</UL>
potentially conflicts with a declaration whose target scope is the
parent scope of S, the program is ill-formed.

</BLOCKQUOTE>

<P>However, after P2579R0, the <I>init-capture</I> inhabits the lambda
scope (6.4.5 [<A href="https://wg21.link/basic.scope.lambda">basic.scope.lambda</A>]), which is the parent of the
parameter scope (6.4.4 [<A href="https://wg21.link/basic.scope.param">basic.scope.param</A>]), which is the parent of
the <I>compound-statement</I> scope, thus the provision does not
apply.</P>

<P>As observed in <A HREF="cwg_active.html#2965">issue 2965</A>, there is no a
template parameter scope (6.4.9 [<A href="https://wg21.link/basic.scope.temp">basic.scope.temp</A>]) for a generic
lambda:</P>

<PRE>
  auto f = [i = 5] &lt;int N&gt; () { int i; return 0; };
</PRE>

<P><U>Possible resolution:</U></P>

<P>Change in 6.4.3 [<A href="https://wg21.link/basic.scope.block#2">basic.scope.block</A>] paragraph 2 as follows, adding bullets:</P>

<BLOCKQUOTE>

If a declaration that is not a name-independent declaration and whose
target scope is the block scope S of a
<UL>
<LI>
<I>compound-statement</I> of a <I>lambda-expression</I>,
<I>function-body</I>, or <I>function-try-block</I>,</LI>
<LI>substatement of a selection or iteration statement that is not
itself a selection or iteration statement, or</LI>
<LI>handler of a <I>function-try-block</I>
</LI>
</UL>
potentially conflicts with a declaration whose target scope is
<UL>
<LI>the parent scope of S <INS>or</INS>,</LI>
<LI><INS>if S is the block scope of a <I>compound-statement</I> of
a <I>lambda-expression</I>, the nearest enclosing lambda scope of
S,</INS></LI>
</UL>
the program is ill-formed.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3045"></A><H4>3045.
  
Regularizing environment interactions of expansion statement
</H4>
<B>Section: </B>6.4.3&#160; [<A href="https://wg21.link/basic.scope.block">basic.scope.block</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jakub Jelinek
 &#160;&#160;&#160;

 <B>Date: </B>2025-07-18<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/729">#729</A>.)</P>

<P>Consider:</P>

<PRE>
  template for (auto x : whatever) {
    int x = 42;
  }
</PRE>

<P>This is valid, but the parallel <I>for-range-statement</I> is not:</P>

<PRE>
  for (auto g : whatever) {
    int g = 42;
  }
</PRE>

<P>Furthermore, due to the possibly surprising rewriting nature of
expansion statements, 9.13.5 [<A href="https://wg21.link/dcl.attr.fallthrough">dcl.attr.fallthrough</A>] should
prohibit <TT>[[fallthrough]]</TT>.</P>

<P><U>Possible suggested resolution:</U></P>

<OL>
<LI>
<P>Change in 6.4.3 [<A href="https://wg21.link/basic.scope.block#2">basic.scope.block</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If a declaration that is not a name-independent declaration and that
binds a name in the block scope S of a
<UL>
<LI>
<I>compound-statement</I> of a <I>lambda-expression</I>,
<I>function-body</I>, or <I>function-try-block</I>,
</LI>
<LI>substatement of a selection <DEL>or</DEL> <INS>,</INS>
iteration<INS>, or expansion</INS> statement that is not itself a
selection <DEL>or</DEL> <INS>,</INS> iteration<INS>, or
expansion</INS> statement, or</LI>
<LI>handler of a <I>function-try-block</I>
</LI>
</UL>
potentially conflicts with a declaration whose target scope is the
parent scope of S, the program is ill-formed.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.13.5 [<A href="https://wg21.link/dcl.attr.fallthrough#1">dcl.attr.fallthrough</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The <I>attribute-token</I> fallthrough may be applied to a null
statement (8.3 [<A href="https://wg21.link/stmt.expr">stmt.expr</A>]); such a statement is a
fallthrough statement. No <I>attribute-argument-clause</I> shall be
present. A fallthrough statement may only appear within an enclosing
switch statement (8.5.3 [<A href="https://wg21.link/stmt.switch">stmt.switch</A>]). The next statement that
would be executed after a fallthrough statement shall be a labeled
statement whose label is a case label or default label for the same
switch statement and, if the fallthrough statement is contained in an
iteration statement, the next statement shall be part of the same
execution of the substatement of the innermost enclosing iteration
statement. The program is ill-formed if there is no such
statement. <INS>The innermost enclosing switch statement of a
fallthrough statement S shall be contained in the innermost enclosing
expansion statement (8.7 [<A href="https://wg21.link/stmt.expand">stmt.expand</A>]) of S, if any.</INS>

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="3033"></A><H4>3033.
  
Scope after <I>declarator-id</I> before determining correspondence
</H4>
<B>Section: </B>6.4.6&#160; [<A href="https://wg21.link/basic.scope.namespace">basic.scope.namespace</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2025-04-12<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/698">#698</A>.)</P>

<P>Consider:</P>

<PRE>
  namespace N {
    inline namespace A {
      constexpr int f(int *);
    }
    inline namespace B {
      constexpr int f(long *);
    }
  } //<SPAN CLASS="cmnt"> namespace N</SPAN>

  template &lt;typename T&gt; struct Q { using type = long; };

  constexpr int N::f(Q&lt;struct X *&gt;::type *) { return 42; } //<SPAN CLASS="cmnt"> #1</SPAN>

  namespace N {
    inline namespace B {
      struct X {};
    }
  } //<SPAN CLASS="cmnt"> namespace N</SPAN>
  template &lt;&gt; struct Q&lt;N::B::X *&gt;; //<SPAN CLASS="cmnt"> explicit specialization after implicit instantiation</SPAN>
  static_assert(N::B::f(0) == 42);
</PRE>

<P>According to 6.4.6 [<A href="https://wg21.link/basic.scope.namespace#1">basic.scope.namespace</A>] paragraph 1, the target scope
of the declaration #1 is <TT>N::B</TT>.  This is known only
after establishing correspondence with the two earlier candidate
declarations of <TT>f</TT>.  However, a target scope for
the <I>elaborated-type-specifier</I> <TT>struct X</TT> at #1 must be
determined prior to establishing correspondence.</P>

<P>It would be reasonable to use <TT>N</TT> as the target scope
for <TT>struct X</TT>, i.e. the scope named by
the <I>nested-name-specififer</I>.</P>

<BR><BR><HR>
<A NAME="2965"></A><H4>2965.
  
Generic lambdas do not have a template parameter scope
</H4>
<B>Section: </B>6.4.9&#160; [<A href="https://wg21.link/basic.scope.temp">basic.scope.temp</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2024-12-03<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/648">#648</A>.)
</P>

<P>A generic lambda does not have its own template parameter scope.
Add a note to highlight this surprising fact.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.4.9 [<A href="https://wg21.link/basic.scope.temp#2">basic.scope.temp</A>] paragraph 2 as follows:</P>



<BLOCKQUOTE>

<P>Each <I>template-declaration</I> D introduces a template parameter
scope that extends from the beginning of
its <I>template-parameter-list</I> to the end of
the <I>template-declaration</I>. Any declaration outside
the <I>template-parameter-list</I> that would inhabit that scope
instead inhabits the same scope as D. The parent scope of any scope S
that is not a template parameter scope is the smallest scope that
contains S and is not a template parameter scope.
</P>
<P>[<I>Note 1:</I>
Therefore, only template parameters belong to a template parameter
scope, and only template parameter scopes have a template parameter
scope as a parent scope. &#8212;<I>end note</I>]</P>
<P class="ins">[ Note: The optional <I>template-parameter-list</I> of
a <I>lambda-expression</I> (7.5.6 [<A href="https://wg21.link/expr.prim.lambda">expr.prim.lambda</A>]) does not
introduce a template parameter scope. -- end note ]</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2968"></A><H4>2968.
  
Name lookup result for <I>typedef-name</I> vs. <I>class-name</I>
</H4>
<B>Section: </B>6.5.1&#160; [<A href="https://wg21.link/basic.lookup.general">basic.lookup.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2024-11-21<BR>


<P><A HREF="https://godbolt.org/z/rveEe88xq">Consider:</A></P>

<PRE>
  class C {
  public:
    struct S { };
  private:
    typedef struct S S;
  };
  C::S s;
</PRE>

<P>According to 6.5.1 [<A href="https://wg21.link/basic.lookup.general#4">basic.lookup.general</A>] paragraph 4:</P>

<BLOCKQUOTE>
In certain contexts, only certain kinds of declarations are
included. After any such restriction, any declarations of classes or
enumerations are discarded if any other declarations are found.
[Note 4: A type (but not a <I>typedef-name</I> or template) is therefore
hidden by any other entity in its scope. -- end note]
However, if
a lookup is type-only, only declarations of types and templates whose
specializations are types are considered; furthermore, if declarations
of a <I>typedef-name</I> and of the type to which it refers are found,
the declaration of the <I>typedef-name</I> is discarded instead of the
type declaration.

</BLOCKQUOTE>

<P>Thus, the declaration of <TT>s</TT> is ill-formed, because the
public <I>class-name</I> <TT>S</TT> is discarded.  Clang and EDG
concur; GCC and MSVC prefer the public <I>class-name</I>.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.5.1 [<A href="https://wg21.link/basic.lookup.general#4">basic.lookup.general</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

...
<P>However, if a lookup is type-only, only declarations of types and
templates whose specializations are types are considered; furthermore,
if declarations of a <I>typedef-name</I> and of the type to which it
refers are found, the declaration of the <I>typedef-name</I> is
discarded instead of the type declaration.</P>

<P class="ins">[ Example:</P>

<PRE class="ins">
  class C {
  public:
    struct S { };          //<SPAN CLASS="cmnt"> #1</SPAN>
  private:
    typedef struct S S;    //<SPAN CLASS="cmnt"> #2</SPAN>
  };
  struct C::S s;           //<SPAN CLASS="cmnt"> OK, type-only lookup, </SPAN>C::S<SPAN CLASS="cmnt"> denotes #1, because #2 is discarded</SPAN>
  C::S s;                  //<SPAN CLASS="cmnt"> error: </SPAN>C::S<SPAN CLASS="cmnt"> denotes #2, because #1 is discarded</SPAN>
</PRE>
<P class="ins">-- end example ]</P>
</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3058"></A><H4>3058.
  
"Program point" is not defined
</H4>
<B>Section: </B>6.5.1&#160; [<A href="https://wg21.link/basic.lookup.general">basic.lookup.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2025-08-13<BR>




<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/749">#749</A>.)</P>

<P>There is no definition for the term "program point".</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.5.1 [<A href="https://wg21.link/basic.lookup.general#2">basic.lookup.general</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<INS>There is a <I>program point</I> before the first token of the
translation unit, between every pair of adjacent tokens, and after the
last token of the translation unit.</INS> A program point <I>P</I> is
said to follow any declaration in the same translation unit whose
locus (6.4.2 [<A href="https://wg21.link/basic.scope.pdecl">basic.scope.pdecl</A>]) is before P.  [<I>Note 1:</I> The
declaration might appear in a scope that does not contain P
. &#8212;<I>end note</I>] ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="380"></A><H4>380.
  
Definition of "ambiguous base class" missing
</H4>
<B>Section: </B>6.5.2&#160; [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]
 &#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.  6.5.2 [<A href="https://wg21.link/class.member.lookup#7">class.member.lookup</A>] paragraph 7 seems like the place
to do it.</P>

<BR><BR><HR>
<A NAME="1089"></A><H4>1089.
  
Template parameters in member selections
</H4>
<B>Section: </B>6.5.5.1&#160; [<A href="https://wg21.link/basic.lookup.qual.general">basic.lookup.qual.general</A>]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#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>

<P><B>Additional note (November, 2020):</B></P>

<P>Paper P1787R6, adopted at the November, 2020 meeting, partially
addresses this issue.</P>

<P><B>CWG 2023-12-01</B></P>

<P>Per the status quo rules, <TT>T::x</TT> is a dependent name and
thus no lookup occurs at template definition time.  At template
instantiation time, <TT>T</TT> is first looked up in the class
of <TT>p</TT> and, if not found, the template parameter <TT>T</TT> is
found.  This, in turn, implies that the two templates discussed above
are not equivalent, because the first potentially references
a <TT>T</TT> member, the other a <TT>U</TT> member of <TT>p</TT>.
</P>

<P>
Subclause 13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>] paragraph 5 is not in conflict
with this interpretation, because no lookup occurs for the <TT>T</TT>
token inside the <TT>decltype</TT> at template definition time at all,
thus (reliably) "name a template parameter" is not satisfied at that
point.
</P>

<BLOCKQUOTE>

Two expressions involving template parameters are considered
equivalent if two function definitions containing the expressions
would satisfy the one-definition rule (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]),
except that the tokens used to name the template parameters may differ
as long as a token used to name a template parameter in one expression
is replaced by another token that names the same template parameter in
the other expression. ...

</BLOCKQUOTE>

<P>In order to clarify this, suggestions for a note including the
example from this issue are welcome.</P>

<BR><BR><HR>
<A NAME="2956"></A><H4>2956.
  
Missing allowance for pseudo-destructors in qualified lookup
</H4>
<B>Section: </B>6.5.5.1&#160; [<A href="https://wg21.link/basic.lookup.qual.general">basic.lookup.qual.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2024-11-08<BR>


<P>Subclause 6.5.5.1 [<A href="https://wg21.link/basic.lookup.qual.general#1">basic.lookup.qual.general</A>] paragraph 1 does not, but
should, allow for pseudo-destructors.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.5.5.1 [<A href="https://wg21.link/basic.lookup.qual.general#1">basic.lookup.qual.general</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Lookup of an identifier followed by a :: scope resolution operator
considers only namespaces, types, and templates whose specializations
are types.  If a name, <I>template-id</I>, or
<I>computed-type-specifier</I> is followed by a ::, it shall designate
a namespace, class, enumeration, or dependent type, <INS>or
if the <TT>::</TT> is followed by <TT>~</TT>, a scalar type,</INS> and the :: is
never interpreted as a complete <I>nested-name-specifier</I>.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2670"></A><H4>2670.
  
Programs and translation units
</H4>
<B>Section: </B>6.7&#160; [<A href="https://wg21.link/basic.link">basic.link</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2022-12-21<BR>




<P>Subclause 6.7 [<A href="https://wg21.link/basic.link#1">basic.link</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

A <I>program</I> consists of one or more translation units
(5.1 [<A href="https://wg21.link/lex.separate">lex.separate</A>]) linked together. A translation unit
consists of a sequence of declarations.

</BLOCKQUOTE>

<P>Subclause 5.1 [<A href="https://wg21.link/lex.separate#1">lex.separate</A>] paragraph 1 defines "translation unit":</P>

<BLOCKQUOTE>

A source file together with all the headers
(16.4.2.3 [<A href="https://wg21.link/headers">headers</A>]) and source files included
(15.3 [<A href="https://wg21.link/cpp.include">cpp.include</A>]) via the preprocessing directive #include,
less any source lines skipped by any of the conditional inclusion
(15.2 [<A href="https://wg21.link/cpp.cond">cpp.cond</A>]) preprocessing directives, is called a
<I>translation unit</I>.

</BLOCKQUOTE>

<P>Subclause 5.2 [<A href="https://wg21.link/lex.phases#7">lex.phases</A>] paragraph 7 first mentions the "translation" of translation units:</P>

<BLOCKQUOTE>

Whitespace characters separating tokens are no longer
significant. Each preprocessing token is converted into a token
(5.10 [<A href="https://wg21.link/lex.token">lex.token</A>]). The resulting tokens are syntactically and
semantically analyzed and translated as a translation unit.

</BLOCKQUOTE>

<P>However, 5.2 [<A href="https://wg21.link/lex.phases#8">lex.phases</A>] paragraph 8 introduces
"instantiation units" and 5.2 [<A href="https://wg21.link/lex.phases#9">lex.phases</A>] paragraph 9
specifies:</P>

<BLOCKQUOTE>

Translated translation units and instantiation units are combined as
follows:

</BLOCKQUOTE>

<P>and 5.2 [<A href="https://wg21.link/lex.phases#9">lex.phases</A>] paragraph 9 specifies:</P>

<BLOCKQUOTE>

All external entity references are resolved. Library components are
linked to satisfy external references to entities not defined in the
current translation. All such translator output is collected into a
program image which contains information needed for execution in its
execution environment.

</BLOCKQUOTE>

<P>The term "linking" in 5.2 [<A href="https://wg21.link/lex.phases">lex.phases</A>] comes after
translated translation units and instantiation units are combined, yet
6.7 [<A href="https://wg21.link/basic.link#1">basic.link</A>] paragraph 1 states that (untranslated)
translation units are linked to form a program.  That seems
inconsistent.</P>

<P><B>Additional notes (February, 2023)</B></P>

<P>See also <A HREF="cwg_defects.html#2518">issue 2518</A>, which introduced
the term "preprocessing translation unit" to remove the conflict
between 6.7 [<A href="https://wg21.link/basic.link#1">basic.link</A>] paragraph 1 and 5.1 [<A href="https://wg21.link/lex.separate#1">lex.separate</A>] paragraph 1.</P>

<BR><BR><HR>
<A NAME="2706"></A><H4>2706.
  
Repeated structured binding declarations
</H4>
<B>Section: </B>6.7&#160; [<A href="https://wg21.link/basic.link">basic.link</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2023-02-13<BR>


<P>Consider:</P>

<PRE>
  struct A {
    int a;
  };
  struct B {
    int b;
  };
  auto&amp;&amp; [x] = A{}; //<SPAN CLASS="cmnt">#1</SPAN>
  auto&amp;&amp; [x] = B{}; //<SPAN CLASS="cmnt">#2</SPAN>
</PRE>

<P>A rule is missing to make such repeated structured binding
declarations ill-formed.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.7 [<A href="https://wg21.link/basic.link#11">basic.link</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

For any two declarations of an entity E:
<UL>
<LI>If one declares E to be a variable or function, the other shall
declare E as one of the same type.</LI>
<LI>If one declares E to be an enumerator, the other shall do so.</LI>
<LI><INS>If one declares E to be a structured binding, the program is ill-formed.</INS></LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2938"></A><H4>2938.
  
Inheriting linkage from a previous declaration
</H4>
<B>Section: </B>6.7&#160; [<A href="https://wg21.link/basic.link">basic.link</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Vlad Serebrennikov
 &#160;&#160;&#160;

 <B>Date: </B>2024-09-12<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/609">#609</A>.)
</P>

<P>Consider the following example from 6.7 [<A href="https://wg21.link/basic.link#6">basic.link</A>] paragraph 6:</P>

<PRE>
  static void f();   //<SPAN CLASS="cmnt"> #1</SPAN>
  void q() {
    extern void f(); //<SPAN CLASS="cmnt"> #2, internal linkage</SPAN>
  }
</PRE>

<P>#1 has internal linkage per 6.7 [<A href="https://wg21.link/basic.link#3.1">basic.link</A>] bullet 3.1.
However, it is unclear why #2 would also get internal linkage.  At
issue is the phrasing in 6.7 [<A href="https://wg21.link/basic.link#4">basic.link</A>] paragraph 4:</P>

<BLOCKQUOTE>

... The name of an entity that belongs to a namespace scope that has not
been given internal linkage above and that is the name of ...

</BLOCKQUOTE>

<P>How does the name matching for "has been given" work here,
considering that functions may be overloaded, i.e. different entities
may have the same name?  The notion of names (as opposed to entities)
having linkage is questionable to start with.</P>

<P><B>CWG 2024-11-08</B></P>

<P>While the wording is in dire need of improvement here, the intent
is that "has been given" uses the "same entity" rules specified in
6.7 [<A href="https://wg21.link/basic.link#8">basic.link</A>] paragraph 8.  Since both declarations
of <TT>f</TT> correspond, have the same target scope, and are in the
same translation unit, they refer to the same entity.  A rewrite of
6.7 [<A href="https://wg21.link/basic.link">basic.link</A>] should improve the wording and amend the
comment in the example.</P>

<BR><BR><HR>
<A NAME="2945"></A><H4>2945.
  
Redundant constraints on matching function template declarations
</H4>
<B>Section: </B>6.7&#160; [<A href="https://wg21.link/basic.link">basic.link</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Vlad Serebrennikov
 &#160;&#160;&#160;

 <B>Date: </B>2024-10-27<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/630">#630</A>.)
</P>

<P>Subclause 6.7 [<A href="https://wg21.link/basic.link#11">basic.link</A>] paragraph 11 specifies:</P>

<BLOCKQUOTE>

For any two declarations of an entity E:
<UL>
<LI>...</LI>
<LI>If one declares E to be a function template or a (partial
specialization of a) variable template, the other shall declare E to
be one with an equivalent <I>template-head</I> and type.</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>However, two function template declarations can only ever declare
the same entity if they correspond (6.7 [<A href="https://wg21.link/basic.link#8">basic.link</A>] paragraph 8), which requires they have the same <I>template-head</I>s
(6.4.1 [<A href="https://wg21.link/basic.scope.scope#4">basic.scope.scope</A>] paragraph 4).  The "equivalent type"
requirement covers differences in <TT>noexcept</TT>, which is
(intentionally) not covered by "corresponding signatures".</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.7 [<A href="https://wg21.link/basic.link#11">basic.link</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

For any two declarations of an entity E:
<UL>
<LI>...</LI>
<LI class="ins">If one declares E to be a function template,
the other shall declare E to be one with an equivalent type.</LI>
<LI>If one declares E to be <DEL>a function template or</DEL> a (partial
specialization of a) variable template, the other shall declare E to
be one with an equivalent <I>template-head</I> and type.</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2988"></A><H4>2988.
  
Is a closure type from a <I>lambda-expression</I> appearing in a <I>concept-definition</I> a TU-local entity?
</H4>
<B>Section: </B>6.7&#160; [<A href="https://wg21.link/basic.link">basic.link</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2025-01-24<BR>




<P>Consider:</P>

<PRE>
   template&lt;typename _Tp&gt;
    concept __is_derived_from_optional = requires (const _Tp&amp; __t) {
     []&lt;typename _Up&gt;(const optional&lt;_Up&gt;&amp;){ }(__t);
    };
</PRE>

<P>According to 6.7 [<A href="https://wg21.link/basic.link#15">basic.link</A>] paragraph 15, the closure type
of the <I>lambda-expression</I> is a TU-local entity, thus the concept
is an exposure, thus it cannot appear in a module interface unit.
There is no fundamental reason why this needs to be the case.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.7 [<A href="https://wg21.link/basic.link#15.2">basic.link</A>] paragraph 15.2 as follows:</P>



<BLOCKQUOTE>

An entity is TU-local if it is
<UL>
<LI>a type, function, variable, or template that
<UL>
<LI>has a name with internal linkage, or</LI>
<LI>does not have a name with linkage and is declared, or introduced
by a <I>lambda-expression</I>, within the definition of a TU-local
entity,</LI>
</UL>
</LI>
<LI>a type with no name that is defined outside
a <I>class-specifier</I>, function body,
<INS><I>concept-definition</I>,</INS> or initializer or is introduced
by a <I>defining-type-specifier</I> that is used to declare only
TU-local entities,</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2334"></A><H4>2334.
  
Creation of objects by <TT>typeid</TT>
</H4>
<B>Section: </B>6.8.2&#160; [<A href="https://wg21.link/intro.object">intro.object</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Chris Hallock
 &#160;&#160;&#160;

 <B>Date: </B>2017-01-30<BR>


<P>The list of ways that an object may be created in
6.8.2 [<A href="https://wg21.link/intro.object#1">intro.object</A>] paragraph 1 does not include creation
of <TT>type_info</TT> objects by <TT>typeid</TT> expressions, but
7.6.1.8 [<A href="https://wg21.link/expr.typeid">expr.typeid</A>] does not appear to require that such
objects exist before they are referenced. Should the list in
6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>] be extended to include this case?</P>

<BR><BR><HR>
<A NAME="2744"></A><H4>2744.
  
Multiple objects of the same type at the same address
</H4>
<B>Section: </B>6.8.2&#160; [<A href="https://wg21.link/intro.object">intro.object</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Chris Hallock
 &#160;&#160;&#160;

 <B>Date: </B>2023-06-08<BR>


<P>(From thread beginning
<A HREF="https://groups.google.com/a/isocpp.org/g/std-discussion/c/GHwA_pOc4CA/m/RF4qoKgZAAAJ">here</A>.)</P>

<P>Consider:</P>

<PRE>
  #include &lt;new&gt;

  struct A { unsigned char buf[1]; };
  static_assert(sizeof(A) == 1); // A<SPAN CLASS="cmnt"> can fit within </SPAN>A::buf

  int main()
  {
    A x{};
    new (x.buf) A{};
  }
</PRE>

<P>
<TT>A::buf</TT> provides storage for another <TT>A</TT> object.
Thus, there are now two objects of type <TT>A</TT> within lifetime,
which is inconsistent with the goal expressed by
6.8.2 [<A href="https://wg21.link/intro.object#9">intro.object</A>] paragraph 9.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.8.2 [<A href="https://wg21.link/intro.object#3">intro.object</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

If a complete object <INS>of type T</INS> is created
(7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]) in storage associated with another
object e of type &#8220;array of N unsigned char&#8221; or of type
&#8220;array of N std::byte&#8221; (17.2.1 [<A href="https://wg21.link/cstddef.syn">cstddef.syn</A>]), that
array provides storage for the created object if:
<UL>
<LI>the lifetime of e has begun and not ended, and</LI>
<LI>the storage for the new object fits entirely within e, and</LI>
<LI class="ins">
<I>e</I> is not and is not nested within an object of
type similar (7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>]) to <TT>T</TT> that is within
its lifetime, and</LI>
<LI>there is no array object that satisfies these constraints
nested within e.</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2765"></A><H4>2765.
  
Address comparisons between potentially non-unique objects during constant evaluation
</H4>
<B>Section: </B>6.8.2&#160; [<A href="https://wg21.link/intro.object">intro.object</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-07-14<BR>


<P>
The (arguably) expanded treatment of backing arrays and string
literals as potentially non-unique objects in
<A HREF="cwg_defects.html#2753">issue 2753</A> lead to the question how
the resulting address comparisons are treated during constant evaluation.
</P>

<P>Subclause 7.7 [<A href="https://wg21.link/expr.const#5.24">expr.const</A>] bullet 5.24 specifies:</P>

<BLOCKQUOTE>

An expression E is a <I>core constant expression</I> unless the
evaluation of E, following the rules of the abstract machine
(6.10.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]), would evaluate one of the following:
<UL>
<LI>...</LI>
<LI>a three-way comparison (7.6.8 [<A href="https://wg21.link/expr.spaceship">expr.spaceship</A>]), relational
(7.6.9 [<A href="https://wg21.link/expr.rel">expr.rel</A>]), or equality
(7.6.10 [<A href="https://wg21.link/expr.eq">expr.eq</A>]) operator where the result is
unspecified;</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>This phrasing is understood to refer to explicitly unspecified
outcomes only.  The treatment of an example such as</P>

<PRE>
  constexpr bool b = "abc" == "abc";
</PRE>

<P>is unclear, given that identical string literals may or may not
yield distinct string literal objects.</P>

<P>The assumption that equality comparison of
<TT>std::string_view</TT> would compare addresses as a short-cut
before comparing the character sequence could not be confirmed
(27.2.2 [<A href="https://wg21.link/char.traits.require">char.traits.require</A>], 27.3.3.8 [<A href="https://wg21.link/string.view.ops#12">string.view.ops</A>] paragraph 12).</P>

<P><B>CWG in Tokyo 2024-03-22</B></P>

<P>Different approaches are feasible:</P>
<UL>
<LI>Require merging of string literals (and backing arrays of
character types?) at compile-time: Comparing addresses of string
literals is equivalent to comparing their contents.</LI>
<LI>Being able to guarantee that addresses of string literals with
different contents are unequal also at compile time seems useful. In
particular, this idea would allow comparisons during constant
evaluation if (and only if) the runtime result is reliable.</LI>
<LI>At compile time, tag each evaluation of a string literal with a
globally-unique counter value.  Comparing two such pointers with
different tags makes the evaluation not a constant expressions.
</LI>
<LI>At compile time, each string literal (as written in the source
code) yields a different address.  Repeated evaluations of the same
string literal yield pointers that compare equal.  This can be
achieved by tagging the pointer to the string literal obtained upon
evaluation with the source location of the string literal.</LI>
</UL>

<P>In the latter cases, tag values can be preserved when performing
pointer arithmetic.</P>

<P><U>Possible resolution (January, 2025)</U></P>

<OL>

<LI>
<P>Add a new paragraph before 6.9.4 [<A href="https://wg21.link/basic.compound#4">basic.compound</A>] paragraph 4:</P>

<BLOCKQUOTE>

<P class="ins">
A pointer value pointing to a potentially non-unique object <I>O</I>
(6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) is <I>associated with</I> the evaluation
of the <I>string-literal</I> (5.13.5 [<A href="https://wg21.link/lex.string">lex.string</A>]) or
initializer list (9.5.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]) that resulted in the
string literal object or backing array, respectively, that is <I>O</I>
or of which <I>O</I> is a subobject.  [ Note: A pointer value obtained
by pointer arithmetic (7.6.6 [<A href="https://wg21.link/expr.add">expr.add</A>]) from a pointer
value associated with an evaluation <I>E</I> is also associated
with <I>E</I>. -- end note ]</P>

<P>A pointer value P is valid in the context of an evaluation E if ...</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Add a bullet after 7.7 [<A href="https://wg21.link/expr.const#10.25">expr.const</A>] bullet 10.25 as follows:</P>

<BLOCKQUOTE>

An expression E is a core constant expression unless the evaluation of
E, following the rules of the abstract machine
(6.10.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]), would evaluate one of the following:

<UL>
<LI>...</LI>
<LI>a three-way comparison (7.6.8 [<A href="https://wg21.link/expr.spaceship">expr.spaceship</A>]), relational
(7.6.9 [<A href="https://wg21.link/expr.rel">expr.rel</A>]), or equality
(7.6.10 [<A href="https://wg21.link/expr.eq">expr.eq</A>]) operator where the result is
unspecified;</LI>

<LI class="ins">an equality operator comparing pointers to potentially
non-unique objects, if the pointer values of both operands are
associated with different evaluations (6.9.4 [<A href="https://wg21.link/basic.compound">basic.compound</A>]) and
they can both point to the same offset within the same potentially
non-unique object;

[ Example:
<PRE>
  constexpr const char *f() { return "foo"; }

  constexpr bool b1 = "foo" == "foo";   //<SPAN CLASS="cmnt"> error: non-constant</SPAN>
  constexpr bool b2 = f() == f();       //<SPAN CLASS="cmnt"> error: non-constant</SPAN>
  constexpr const char *p = f();
  constexpr bool b3 = p == p;           //<SPAN CLASS="cmnt"> OK, value of </SPAN>b3<SPAN CLASS="cmnt"> is </SPAN>true
  constexpr bool b4 = "xfoo" + 1 == "foo\0y"; //<SPAN CLASS="cmnt"> error: non-constant; string literal object could contain </SPAN>"xfoo\0y"
  constexpr bool b5 = "foo" == "bar";   //<SPAN CLASS="cmnt"> OK, value of </SPAN>b5<SPAN CLASS="cmnt"> is </SPAN>false
  constexpr bool b6 = "foo" == "oo";    //<SPAN CLASS="cmnt"> OK, value of </SPAN>b6<SPAN CLASS="cmnt"> is </SPAN>false<SPAN CLASS="cmnt">; offsets would be different in a merged string literal object</SPAN>
</PRE>
-- end example ]
</LI>

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

</BLOCKQUOTE>
</LI>
</OL>
<BR><BR><HR>
<A NAME="3039"></A><H4>3039.
  
Undefined behavior from implicit object creation ignores observable checkpoints
</H4>
<B>Section: </B>6.8.2&#160; [<A href="https://wg21.link/intro.object">intro.object</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jan Schultke
 &#160;&#160;&#160;

 <B>Date: </B>2025-06-23<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/719">#719</A>.)</P>

<P>Consider:</P>

<PRE>
  int main() {
    unsigned char buffer[1];   //<SPAN CLASS="cmnt"> #1, undefined behavior</SPAN>
    std::println("...");       //<SPAN CLASS="cmnt"> #2, intended to be observable checkpoint, but also UB</SPAN>
    std::unreachable();        //<SPAN CLASS="cmnt"> #3, also undefined behavior</SPAN>
  }
</PRE>

<P>According to 6.8.2 [<A href="https://wg21.link/intro.object#11">intro.object</A>] paragraph 11, the implicit
object creation at #1 only takes place "if doing so would result in
the program having defined behavior", and otherwise the entire program
has undefined behavior.  However, since #3 arranges for no possible
execution to have defined behavior, implicit object creation does not
take place, and #1 has undefined behavior, ignoring the observable
checkpoint at #2.</P>

<P><U>Suggested resolution:</U></P>

<OL>
<LI>
<P>Add after 4.1.2 [<A href="https://wg21.link/intro.abstract#7">intro.abstract</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

<P>
<I>Recommended practice:</I> An implementation should issue a diagnostic
when such an operation is executed.  [<I>Note 3:</I> ... &#8212;<I>end
note</I>]</P>

<P class="ins">Certain operations are specified as making a choice to
maximize the defined prefix of the execution. The behavior of all such
operations in that execution is such that the defined prefix P of the
execution is not a proper subset of the defined prefix that would
result from any other choices, but the choices are otherwise
unspecified.</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.2 [<A href="https://wg21.link/intro.object#11">intro.object</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

Some operations are described as implicitly creating objects within a
specified region of storage. For each operation <INS><I>O</I></INS>
that is specified as implicitly creating objects, that
operation <INS><I>O</I></INS> implicitly creates and starts the
lifetime of zero or more objects of implicit-lifetime types
(6.10.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]) in its specified region of storage
<DEL>if doing so would result in the program having defined
behavior</DEL> <INS>chosen to maximize the defined prefix of the
execution (4.1.2 [<A href="https://wg21.link/intro.abstract">intro.abstract</A>])</INS>.  <DEL>If no such set of
objects would give the program defined behavior, the behavior of the
program is undefined.</DEL>
<INS>[Note:</INS> If multiple such sets of objects would
<DEL>give the program defined behavior</DEL> <INS>result in a maximal
defined prefix for the execution</INS>, it is unspecified which such
set of objects is created. <INS>-- end note]</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.2 [<A href="https://wg21.link/intro.object#12">intro.object</A>] paragraph 12 as follows:</P>

<BLOCKQUOTE>

Further, after implicitly creating objects within a specified region
of storage, some operations are described as producing a pointer to a
suitable created object. These operations select one of the
implicitly-created objects whose address is the address of the start
of the region of storage, and produce a pointer value that points to
that object <DEL>, if that value would result in the program having
defined behavior. If no such pointer value would give the program
defined behavior, the behavior of the program is
undefined</DEL> <INS>such as to maximize the defined prefix of the
execution</INS>. <INS>[ Note:</INS> If multiple such pointer
values <DEL>would give the program defined behavior</DEL> <INS>result in a
maximal prefix</INS>, it is unspecified which such pointer value is
produced. <INS>-- end note]</INS>

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="1211"></A><H4>1211.
  
Misaligned lvalues
</H4>
<B>Section: </B>6.8.3&#160; [<A href="https://wg21.link/basic.align">basic.align</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>David Svoboda
 &#160;&#160;&#160;

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




<P>6.8.3 [<A href="https://wg21.link/basic.align">basic.align</A>] speaks of &#8220;alignment
requirements,&#8221; and 6.8.6.5.2 [<A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>] 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="2840"></A><H4>2840.
  
Missing requirements for fundamental alignments
</H4>
<B>Section: </B>6.8.3&#160; [<A href="https://wg21.link/basic.align">basic.align</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

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


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/412">#412</A>.)</P>

<P>Consider:</P>

<PRE>
struct S {
  long double d;
};
</PRE>

<P>There appears to be no rule that prevents <TT>S</TT> from having an
extended alignment.
(See also WG14
<A HREF="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2396.htm#dr_445">DR445</A>.)
</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 6.8.3 [<A href="https://wg21.link/basic.align#2">basic.align</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A fundamental alignment is represented by an alignment less than or
equal to <DEL>the greatest alignment supported by the implementation
in all contexts, which is equal to</DEL>
<TT>alignof(std::max_align_t)</TT>
(17.2 [<A href="https://wg21.link/support.types">support.types</A>]).  <INS>Fundamental alignments shall be
supported by the implementation for objects of all storage durations
(6.8.6 [<A href="https://wg21.link/basic.stc">basic.stc</A>]).</INS> The alignment required for a type
may be different when it is used as the type of a complete object and
when it is used as the type of a subobject. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.3 [<A href="https://wg21.link/basic.align#3">basic.align</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

An extended alignment is represented by an alignment greater than
alignof(std::max_align_t). It is implementation-defined whether any
extended alignments are supported and the <DEL>contexts
in</DEL> <INS>storage durations for</INS> which they are supported
(9.13.2 [<A href="https://wg21.link/dcl.align">dcl.align</A>]). A type having an extended alignment
requirement is an <I>over-aligned type</I>.

[<I>Note 1:</I> Every over-aligned type is or contains a class type to
which extended alignment applies (possibly through a non-static data
member). &#8212;<I>end note</I>]

<INS>[<I>Note 2:</I> The strictest supported alignment can be
different for objects with different storage durations. &#8212;<I>end
note</I>]</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Insert a new paragraph before 6.8.3 [<A href="https://wg21.link/basic.align#4">basic.align</A>] paragraph 4
and change as follows:</P>

<BLOCKQUOTE>

<P class="ins">
Each of the following types has a fundamental alignment requirement:
<UL class="ins">
<LI>a scalar type (6.9.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]),</LI>
<LI>an array type (9.3.4.5 [<A href="https://wg21.link/dcl.array">dcl.array</A>]) whose element type
has a fundamental alignment requirement, and</LI>
<LI>a class type (Clause 11 [<A href="https://wg21.link/class">class</A>]) where all base classes and
non-static data members have a type with a fundamental alignment
requirement and no non-static data member is declared with
an <I>alignment-specifier</I> (9.13.2 [<A href="https://wg21.link/dcl.align">dcl.align</A>]) specifying
an extended alignment.</LI>
</UL>
</P>

<P>Alignments are represented as values of the type
<TT>std::size_t</TT>.  Valid alignments include only <DEL>those values
returned by an alignof expression for the</DEL>
fundamental <DEL>types</DEL> <INS>alignments</INS> plus an additional
implementation-defined set of values, which may be empty. Every
alignment value shall be a non-negative integral power of two.</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.13.2 [<A href="https://wg21.link/dcl.align#2">dcl.align</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

When the alignment-specifier is of the form
alignas( <I>constant-expression</I> ):
<UL>
<LI>the <I>constant-expression</I> shall be an integral constant
expression <INS>and</INS>
</LI>
<LI>if the constant expression does not evaluate to an alignment value
(6.8.3 [<A href="https://wg21.link/basic.align">basic.align</A>]), or evaluates to an extended alignment
and the implementation does not support that alignment <DEL>in the
context of the declaration</DEL> <INS>for the storage duration (if
any) of the entity being declared</INS>, the program is
ill-formed.</LI>
</UL>

</BLOCKQUOTE>
</LI>
</OL>

<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>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#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>11.9.5 [<A href="https://wg21.link/class.cdtor#2">class.cdtor</A>] paragraph 2 makes this valid, but
6.8.4 [<A href="https://wg21.link/basic.life#5">basic.life</A>] 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 11.9.5 [<A href="https://wg21.link/class.cdtor#2">class.cdtor</A>] paragraph 2 because the base
class B constructor hasn't started yet.
7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>] 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
6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>].  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="2258"></A><H4>2258.
  
Storage deallocation during period of destruction
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2016-04-12<BR>




<P>What happens if the storage for an object is deallocated in its
period of destruction?  Consider:</P>

<PRE>
  struct Base {
    virtual ~Base() {
      ::operator delete(this);
    }
    void operator delete(void*) {}
  };

  struct Derived : Base {};

  int main() {
    delete new Derived;
  } 
</PRE>

<P>This ought to be undefined behavior, but the standard is silent on
the matter.</P>

<P>
<B>Notes from the December, 2016 teleconference:</B>
</P>

<P>The consensus view was that this should be undefined behavior.</P>

<P><B>Additional notes (July, 2023)</B></P>

<P>This issue is a subset of <A HREF="cwg_active.html#2757">issue 2757</A>.</P>

<BR><BR><HR>
<A NAME="2514"></A><H4>2514.
  
Modifying const subobjects
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2021-11-07
  &#160;&#160;&#160;
  <B>Liaison: </B>SG12<BR>


<P>The change in C++20 for
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1971r0.html#RU007">RU007</A>
allows transparently replacing a const subobject whose complete
object is not const, and the new object can be non-const.
However, if the reuse of the object has not happened, modifying
such subobjects is still undefined behavior.</P>

<P>This restriction causes problems in the implementation of
<TT>std::map</TT> and <TT>std::unordered_map</TT>; see
<A HREF="https://reviews.llvm.org/D47607">this bug report</A>.
Here, the <TT>key_type</TT> objects in map containers are
const, and implementations generally can't replace these objects
after construction.</P>

<P>Perhaps these restrictions can be relaxed to assist in this
case: if</P>

<UL>
<LI><P>the complete object of a <TT>key_type</TT> subobject
in a container is not const (as the <TT>mapped_type</TT>
subobject is not const), or</P></LI>

<LI><P>the complete object has dynamic storage duration</P></LI>

</UL>

<P>a const subobject could be modified.</P>

<P>(Is it meaningful to allow a <I>new-expression</I> like
<TT>new const int(42)</TT> to create cv-qualified objects?
Perhaps such objects should be unqualified, while maintaining
the cv-qualification in the type of the expression?)</P>

<P><B>Notes from the November, 2022 meeting</B></P>

<P>The advice of SG12 is solicited; see
<A HREF="https://github.com/cplusplus/papers/issues/1365">cplusplus/papers#1395</A>.</P>

<BR><BR><HR>
<A NAME="2676"></A><H4>2676.
  
Replacing a complete object having base subobjects
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2022-12-06<BR>


<P>Base subobjects cannot be transparently replaced with complete
objects, as specified in 6.8.4 [<A href="https://wg21.link/basic.life#8.4">basic.life</A>] bullet 8.4:</P>

<BLOCKQUOTE>

An object o1 is transparently replaceable by an object o2 if:

<UL>
<LI>...</LI>
<LI>neither o1 nor o2 is a potentially-overlapping
subobject (6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]), and</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>However, that bullet is over-reaching, because it disallows:</P>

<PRE>
  struct A { int n; };
  struct B : A {};
  B b;
  new (&amp;b) B { {5} };  //<SPAN CLASS="cmnt"> New </SPAN>A<SPAN CLASS="cmnt"> base class does not transparently replace existing </SPAN>A<SPAN CLASS="cmnt"> base class due to /8.4.</SPAN>
  int k = b.n;  //<SPAN CLASS="cmnt"> UB: member </SPAN>n<SPAN CLASS="cmnt"> of </SPAN>A<SPAN CLASS="cmnt"> base class is outside its lifetime</SPAN>
</PRE>

<P>See <A HREF="cwg_active.html#2677">issue 2677</A> for a suggested resolution.</P>

<P><B>Additional notes (February, 2023)</B></P>

<P>Consider this example:</P>

<PRE>
  struct A {
   int n;
   char c;
   //<SPAN CLASS="cmnt"> tail padding</SPAN>
  };
  struct B {
   [[no_unique_address]] A a;
   char in_tail_padding[3];
  };

  B b;
  void f() {
   //<SPAN CLASS="cmnt"> Transparently replaces old member, potentially overwriting the data in the tail padding!</SPAN>
   new (&amp;b.a) A{};
  }
</PRE>

<P>The suggestions do not address this example.</P>



<BR><BR><HR>
<A NAME="2952"></A><H4>2952.
  
Vacuous initialization for subobjects
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2024-10-31<BR>




<P>Consider:</P>

<PRE>
  struct A {
    int x, y;
    constexpr A() : x((y = 1, y)) {}
  };
  constexpr int k = A().y;
</PRE>

<P>"Vacuous initialization" is defined in 6.8.4 [<A href="https://wg21.link/basic.life#1">basic.life</A>] paragraph 1 only for variables, not for subobjects, so it is unclear
whether the example is well-formed or not.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#1">basic.life</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The <I>lifetime</I> of an object or reference is a runtime property of
the object or reference. <DEL>A variable is said to have <I>vacuous
initialization</I> if it is default-initialized, no other
initialization is performed, and, if it is of class type or a
(possibly multidimensional) array thereof, a trivial constructor of
that class type is selected for the default-initialization.</DEL> 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>its initialization <DEL>(if any)</DEL> is complete <DEL>(including vacuous
initialization) (9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>])</DEL>,</LI>
</UL>
except that if the object is a union member or subobject thereof, its
lifetime only begins if that union member is the initialized member in
the union (9.5.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>], 11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]),
or as described in 11.5 [<A href="https://wg21.link/class.union">class.union</A>],
11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>], and 11.4.6 [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>], and
except as described in 20.2.10.2 [<A href="https://wg21.link/allocator.members">allocator.members</A>]. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.8.5 [<A href="https://wg21.link/basic.indet#1">basic.indet</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

... If <DEL>no initialization is performed for</DEL> an object (including
<DEL>subobjects</DEL> <INS>a subobject</INS>) <INS>is not accessed
during its initialization</INS>, such a byte retains its initial value
until that value is replaced (9.5.1 [<A href="https://wg21.link/dcl.init.general">dcl.init.general</A>],
7.6.19 [<A href="https://wg21.link/expr.assign">expr.assign</A>]). If any bit in the value representation
has an indeterminate value, the object has an indeterminate value;
otherwise, if any bit in the value representation has an erroneous
value, the object has an erroneous value (7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]).

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 8.10 [<A href="https://wg21.link/stmt.dcl#2">stmt.dcl</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>
<INS>A variable is said to have <I>vacuous initialization</I> if it is
default-initialized (9.5.1 [<A href="https://wg21.link/dcl.init.general">dcl.init.general</A>]), no other
initialization is performed, and, if it is of class type or a
(possibly multidimensional) array thereof, a trivial constructor of
that class type (11.4.5.2 [<A href="https://wg21.link/class.default.ctor">class.default.ctor</A>]) is selected for the
default-initialization.</INS> A block variable with automatic storage
duration (6.8.6.4 [<A href="https://wg21.link/basic.stc.auto">basic.stc.auto</A>]) is <I>active</I> everywhere in
the scope to which it belongs after its <I>init-declarator</I> . Upon
each transfer of control (including sequential execution of
statements) within a function from point P to point Q, all block
variables with automatic storage duration that are active at P and not
at Q are destroyed in the reverse order of their construction. Then,
all block variables with automatic storage duration that are active at
Q but not at P are initialized in declaration order; unless all such
variables have vacuous initialization
<DEL>(6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>])</DEL>, the transfer of control shall
not be a jump. [ Footnote: ... ] When a <I>declaration-statement</I>
is executed, P and Q are the points immediately before and after it;
when a function returns, Q is after its body.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.5.1 [<A href="https://wg21.link/dcl.init.general#7.3">dcl.init.general</A>] bullet 7.3 as follows:</P>

<BLOCKQUOTE>

To <I>default-initialize</I> an object of type T means:
<UL>
<LI>If T is a (possibly cv-qualified) class type (Clause
Clause 11 [<A href="https://wg21.link/class">class</A>]), constructors are considered. The applicable
constructors are enumerated (12.2.2.4 [<A href="https://wg21.link/over.match.ctor">over.match.ctor</A>]), and the
best one for the initializer () is chosen through overload resolution
(12.2 [<A href="https://wg21.link/over.match">over.match</A>]). The constructor thus selected is called,
with an empty argument list, to initialize the object.</LI>
<LI>If T is
an array type, the semantic constraints of default-initializing a
hypothetical element shall be met and each element is
default-initialized.</LI>
<LI>Otherwise, <DEL>no</DEL> <INS>default</INS> initialization <DEL>is
performed</DEL>
<INS>completes without accessing the object</INS>.</LI>
</UL>

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2960"></A><H4>2960.
  
Introduce discontiguous object lifetime
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2024-11-18<BR>


<P>Permitting discontiguous object lifetimes instead of carving out
special exceptions for pointers to transparently replaced objects
would simplify the wording; when transparemtly replacing an object,
the lifetime of the prior objecct would simply start again.</P>

<BR><BR><HR>
<A NAME="2986"></A><H4>2986.
  
Creating objects within a mutable member of a const object
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

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


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/367">#367</A>.)
</P>

<P>Consider:</P>

<PRE>
  struct S {
    alignas(int) mutable unsigned char buf[sizeof(int)];
  };
  int f() {
    const S s{};
    ::new ((void*)s.buf) int{42};
  }
</PRE>

<P>Creating a new object in the mutable portion of a const complete
object is undefined behavior per 6.8.4 [<A href="https://wg21.link/basic.life#12">basic.life</A>] paragraph 12.
However, this ought to be allowed.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#12">basic.life</A>] paragraph 12 as follows:</P>

<BLOCKQUOTE>

Creating a new object <INS>O</INS> within the storage that a const,
complete object <INS>X</INS> with static, thread, or automatic storage
duration occupies, or within the storage that such a const object used
to occupy before its lifetime ended, results in undefined behavior
unless <INS>O is nested within a mutable subobject of X</INS>. [
Example: ... ]

</BLOCKQUOTE>
<BR><BR><HR>
<A NAME="3001"></A><H4>3001.
  
Inconsistent restrictions for <TT>static_cast</TT> on pointers to out-of-lifetime objects
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Cody Miller
 &#160;&#160;&#160;

 <B>Date: </B>2025-02-26<BR>




<P>According to 6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7, converting a pointer-to-derived to pointer-to-base for an out-of-lifetime object is allowed implicitly, but disallowed using <TT>static_cast</TT>.  That seems inconsistent.</P>

<P>Also, the out-of-lifetime rules mishandle this example:</P>

<PRE>
  int a;
  int *p = &amp;a;
  *p = 1;
  new (p) int;
</PRE>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change 7.3.12 [<A href="https://wg21.link/conv.ptr#3">conv.ptr</A>] paragraph 3 as follows:</P>


<BLOCKQUOTE>

... Otherwise, if B is a virtual base class of D <INS>or a base class
of a virtual base class of <TT>D</TT></INS> and v does not point to an
object whose type is similar (7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>]) to D and
that is within its lifetime or within its period of construction or
destruction (11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]), the behavior is
undefined. ...

</BLOCKQUOTE>
</LI>
<LI>
<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

Before the lifetime of an object has started but after the storage
which the object will occupy has been allocated [ Footnote: ...] or,
after the lifetime of an object has ended and before the storage which
the object occupied is reused or released, any pointer
that <DEL>represents the address of the storage location where the
object will be or was located</DEL> <INS>points to the object</INS>
may be used but only in limited ways. For an object under construction
or destruction, see 11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>].  Otherwise, such a
pointer refers to allocated storage (6.8.6.5.2 [<A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>]),
and using the pointer as if the pointer were of type void* is
well-defined. Indirection through such a pointer is permitted but the
resulting lvalue may only be used in limited ways, as described
below. The program has undefined behavior if
<UL>
<LI>the pointer is used as the operand of a <I>delete-expression</I>,</LI>
<LI>the pointer is used to access a non-static data member or call a
non-static member function of the object, <DEL>or</DEL>
</LI>
<LI>the pointer is <DEL>implicitly</DEL> converted
(7.3.12 [<A href="https://wg21.link/conv.ptr">conv.ptr</A>]<INS>, 7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]</INS>)
to a pointer to a virtual base class <INS>or to a base class
thereof</INS>, or</LI>
<LI class="del">the pointer is used as the operand of a static_cast
(7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]), except when the conversion is to
pointer to cv void, or to pointer to cv void and subsequently to
pointer to cv char, cv unsigned char, or cv std::byte
(17.2.1 [<A href="https://wg21.link/cstddef.syn">cstddef.syn</A>]), or</LI>
<LI>the pointer is used as the operand of a dynamic_cast
(7.6.1.7 [<A href="https://wg21.link/expr.dynamic.cast">expr.dynamic.cast</A>]).</LI>
</UL>

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="3047"></A><H4>3047.
  
Calling destructors on out-of-lifetime objects
</H4>
<B>Section: </B>6.8.4&#160; [<A href="https://wg21.link/basic.life">basic.life</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2025-06-18<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/717">#717</A>.)</P>

<P>Calling a non-static member function for an ou8t-of-lifetime object
is undefined behavior according to 6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7
and paragraph 8.  There is no reason to normatively duplicate that
general rule for a subset of destructors in 6.8.4 [<A href="https://wg21.link/basic.life#11">basic.life</A>] paragraph 11.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.8.4 [<A href="https://wg21.link/basic.life#11">basic.life</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

<INS>[Note:</INS> If a program ends the lifetime of an object of type
T <DEL>with static (6.8.6.2 [<A href="https://wg21.link/basic.stc.static">basic.stc.static</A>]), thread
(6.8.6.3 [<A href="https://wg21.link/basic.stc.thread">basic.stc.thread</A>]), or automatic
(6.8.6.4 [<A href="https://wg21.link/basic.stc.auto">basic.stc.auto</A>]) storage duration and if T has a
non-trivial destructor</DEL> <INS>for which the destructor will be
called implicitly (8.10 [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>],
6.10.3.4 [<A href="https://wg21.link/basic.start.term">basic.start.term</A>])</INS>, and another object of the
original type does not occupy that same storage location when the
implicit destructor call takes place, the behavior of the program is
undefined. <DEL>This is true even if the block is exited with an
exception.</DEL> [<I>Example 4:</I> ... &#8212;<I>end
example</I>] <INS>-- end note]</INS>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="365"></A><H4>365.
  
Storage duration and temporaries
</H4>
<B>Section: </B>6.8.6&#160; [<A href="https://wg21.link/basic.stc">basic.stc</A>]
 &#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 6.8.6 [<A href="https://wg21.link/basic.stc">basic.stc</A>]:</P>
<UL>
<LI>
<P>6.8.6 [<A href="https://wg21.link/basic.stc#2">basic.stc</A>] paragraph 2 says that "Static and automatic
storage durations are associated with objects introduced by
declarations (6.2 [<A href="https://wg21.link/basic.def">basic.def</A>]) and implicitly created
by the implementation (6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>])."</P>

<P>In fact, objects "implicitly created by the implementation" are the
temporaries described in (6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>]), and have neither
static nor automatic storage duration, but a totally different duration,
described in 6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>].</P>
</LI>
<LI>
<P>6.8.6 [<A href="https://wg21.link/basic.stc">basic.stc</A>] 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 6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>]. If temporaries are covered by
this section, and the statement in 6.8.6 [<A href="https://wg21.link/basic.stc">basic.stc</A>]
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
6.8.6 [<A href="https://wg21.link/basic.stc#1">basic.stc</A>] 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 6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>].
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 6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>] 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>

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

<P>The CWG decided that further consideration of this issue would be
deferred until someone produces a paper explaining the need for action
and proposing specific changes.</P>

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

<BR><BR><HR>
<A NAME="1634"></A><H4>1634.
  
Temporary storage duration
</H4>
<B>Section: </B>6.8.6&#160; [<A href="https://wg21.link/basic.stc">basic.stc</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-04<BR>




<P>According to 6.8.6 [<A href="https://wg21.link/basic.stc#2">basic.stc</A>] paragraph 2,</P>

<BLOCKQUOTE>

Static, thread, and automatic storage durations are associated with objects
introduced by declarations (6.2 [<A href="https://wg21.link/basic.def">basic.def</A>]) and implicitly
created by the implementation (6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>]).

</BLOCKQUOTE>

<P>The apparent intent of the reference to 6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>] is
that a temporary whose lifetime is extended to be that of a reference with
one of those storage durations is considered also to have that storage
duration.  This interpretation is buttressed by use of the phrase &#8220;an
object with the same storage duration as the temporary&#8221; (twice) in
6.8.7 [<A href="https://wg21.link/class.temporary#5">class.temporary</A>] paragraph 5.</P>

<P>There are two problems, however: first, the specification of lifetime
extension of temporaries (also in 6.8.7 [<A href="https://wg21.link/class.temporary#5">class.temporary</A>] paragraph 5)
does not say anything about storage duration.  Also, nothing is said in
either of these locations about the storage duration of a temporary whose
lifetime is not extended.</P>

<P>The latter point is important because 6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>] makes
a distinction between the lifetime of an object and the acquisition and
release of the storage the object occupies, at least for objects with
non-trivial initialization and/or a non-trivial destructor.  The
assumption is made in 6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>] and elsewhere that the
storage in which a temporary is created is no longer available for
reuse, as specified in 6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>], after the lifetime of
the temporary has ended, but this assumption is not explicitly stated.
One way to make that assumption explicit would be to define a storage
duration for temporaries whose lifetime is not extended.</P>

<P>See also issues <A HREF="cwg_active.html#365">365</A> and
<A HREF="cwg_defects.html#2256">2256</A>.</P>

<BR><BR><HR>
<A NAME="1682"></A><H4>1682.
  
Overly-restrictive rules on function templates as allocation functions
</H4>
<B>Section: </B>6.8.6.5.2&#160; [<A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2009-03-03<BR>




<P>Requirements for allocation functions are given in
6.8.6.5.2 [<A href="https://wg21.link/basic.stc.dynamic.allocation#1">basic.stc.dynamic.allocation</A>] paragraph 1:</P>

<BLOCKQUOTE>

An allocation function can be a function template. Such a template shall
declare its return type and first parameter as specified above (that is,
template parameter types shall not be used in the return type and first
parameter type). Template allocation functions shall have two or more
parameters.

</BLOCKQUOTE>

<P>There are a couple of problems with this description.  First, it is
instances of function templates that can be allocation functions, not
the templates themselves (cf 6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation#2">basic.stc.dynamic.deallocation</A>] paragraph 2,
which uses the correct terminology regarding deallocation functions).</P>

<P>More importantly, this specification was written before template
metaprogramming was understood and hence prevents use of SFINAE on the
return type or parameter type to select among function template
specializations.  (The parallel passage for deallocation functions in
6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation#2">basic.stc.dynamic.deallocation</A>] paragraph 2 shares this deficit.)</P>



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

<BR><BR><HR>
<A NAME="2073"></A><H4>2073.
  
Allocating memory for exception objects
</H4>
<B>Section: </B>6.8.6.5.2&#160; [<A href="https://wg21.link/basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-01-20<BR>




<P>According to 6.8.6.5.2 [<A href="https://wg21.link/basic.stc.dynamic.allocation#4">basic.stc.dynamic.allocation</A>] paragraph 4,</P>

<BLOCKQUOTE>

[<I>Note:</I> In particular, a global allocation function is
not called to allocate storage for objects with static
storage duration (6.8.6.2 [<A href="https://wg21.link/basic.stc.static">basic.stc.static</A>]), for objects
or references with thread storage duration
(6.8.6.3 [<A href="https://wg21.link/basic.stc.thread">basic.stc.thread</A>]), for objects of type
<TT>std::type_info</TT> (7.6.1.8 [<A href="https://wg21.link/expr.typeid">expr.typeid</A>]), or for an
exception object (14.2 [<A href="https://wg21.link/except.throw">except.throw</A>]). &#8212;<I>end
note</I>]

</BLOCKQUOTE>

<P>The restriction against allocating exception objects on the
heap was intended to ensure that heap exhaustion could be reported
by throwing an exception, i.e., that obtaining storage for
<TT>std::bad_alloc</TT> could not fail because the heap was full.
However, this implicitly relied on the assumption of a single
thread and does not scale to large numbers of threads, so the
restriction should be lifted and another mechanism found for
guaranteeing the ability to throw <TT>std::bad_alloc</TT>.</P>

<P><B>Notes from the February, 2016 meeting:</B></P>

<P>The prohibition of using an allocation function appears only in a
note, although there is a normative reference to the rule in
14.2 [<A href="https://wg21.link/except.throw#4">except.throw</A>] paragraph 4. CWG was in favor of
retaining the prohibition of using a C++ allocation function for
the memory of an exception object, with the implicit understanding
that use of <TT>malloc</TT> would be permitted.  The resolution
for this issue should delete the note and move the prohibition to
normative text in the relevant sections.</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>6.8.6.5.3&#160; [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>]
 &#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, 6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>] says
that the deallocation &#8220;[renders] invalid all pointers referring
to any part of the deallocated storage.&#8221; According to
6.9.4 [<A href="https://wg21.link/basic.compound#3">basic.compound</A>] 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
7.6.2.9 [<A href="https://wg21.link/expr.delete#4">expr.delete</A>] paragraph 4, which also mentions that
the system deallocation function renders a pointer invalid.)</P>

<BR><BR><HR>
<A NAME="3025"></A><H4>3025.
  
Deallocation functions returning void
</H4>
<B>Section: </B>6.8.6.5.3&#160; [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Timur Doumler
 &#160;&#160;&#160;

 <B>Date: </B>2025-05-08<BR>




<P>Subclause 6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation#3">basic.stc.dynamic.deallocation</A>] paragraph 3 specifies:</P>

<BLOCKQUOTE>

Each deallocation function shall return <TT>void</TT>. ...

</BLOCKQUOTE>

<P>It has caused confusion in the marketplace whether that is a
syntactic constraint on the return type of a deallocation function, or
a semantic constraint on the behavior (e.g. a deallocation cannot
perform a <TT>longjmp</TT>).</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation#3">basic.stc.dynamic.deallocation</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<DEL>Each</DEL> <INS>A</INS> deallocation function shall <INS>have a declared</INS> return <INS>type of type</INS> <TT>void</TT>. ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2666"></A><H4>2666.
  
Lifetime extension through <TT>static_cast</TT>
</H4>
<B>Section: </B>6.8.7&#160; [<A href="https://wg21.link/class.temporary">class.temporary</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2022-10-17<BR>


<P>Consider:</P>

<PRE>
  struct S { S(int) {} };

  const S&amp; r1 = 0; //<SPAN CLASS="cmnt"> #1</SPAN>
  const S&amp; r2 = static_cast&lt;const S&amp;&gt;(S(0)); //<SPAN CLASS="cmnt"> #2</SPAN>
  const S&amp; r3 = static_cast&lt;const S&amp;&gt;(0); //<SPAN CLASS="cmnt"> #3</SPAN>
  //<SPAN CLASS="cmnt"> Are r1, r2, and r3 dangling past this point?</SPAN>
</PRE>

<P>For #1, a temporary object is materialized and the reference binds
to the result of the materialization conversion. This results in
lifetime extension per 6.8.7 [<A href="https://wg21.link/class.temporary#6.1">class.temporary</A>] bullet 6.1.</P>

<P>For #2, 6.8.7 [<A href="https://wg21.link/class.temporary#6.6">class.temporary</A>] bullet 6.6 requires the cast
to convert "without a user-defined conversion", but <TT>S(0)</TT> is
such.</P>

<P>For #3, a user-defined conversion is clearly required.</P>

<P>However, implementations treat all three cases the same and do
extend the lifetime of the temporary.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.8.7 [<A href="https://wg21.link/class.temporary#6.6">class.temporary</A>] bullet 6.6 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>a
<UL>
<LI>const_cast (7.6.1.11 [<A href="https://wg21.link/expr.const.cast">expr.const.cast</A>]),</LI>
<LI>static_cast (7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]),</LI>
<LI>dynamic_cast (7.6.1.7 [<A href="https://wg21.link/expr.dynamic.cast">expr.dynamic.cast</A>]), or</LI>
<LI>reinterpret_cast (7.6.1.10 [<A href="https://wg21.link/expr.reinterpret.cast">expr.reinterpret.cast</A>])</LI>
</UL>
<DEL>converting, without a user-defined conversion, a glvalue operand that
is one of these expressions to a glvalue that refers to the object
designated by the operand, or to its complete object or a subobject
thereof</DEL>,

<INS>where</INS>
<UL class="ins">
<LI>the cast does not invoke a user-defined conversion, or</LI>
<LI>the cast invokes a user-defined conversion that yields a prvalue,
and the glvalue result of the cast is bound directly
(9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]) to that prvalue,</LI>
</UL>

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

</BLOCKQUOTE>

<P><B>Additional notes (October, 2024)</B></P>

<P>The suggested resolution does not use the "is one of these
expressions" structure that limits the tracking of temporary objects
through the expression tree required from implementation. For
example:</P>

<PRE>
  int glob;
  struct A {
   constexpr ~A() { arr[0] = &amp;glob; }
   int *arr[1];
  };
  constexpr int f() {
   int *&amp;&amp;ref = static_cast&lt;int *&amp;&amp;&gt;(0[+A().arr]); //<SPAN CLASS="cmnt"> note unary +; lifetime is not extended</SPAN>
   delete ref; //<SPAN CLASS="cmnt"> error: attempt to delete `&amp;glob`</SPAN>
   return 0;
  }
  extern constexpr int x = f();
</PRE>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.8.7 [<A href="https://wg21.link/class.temporary#6.6">class.temporary</A>] bullet 6.6 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>a
<UL>
<LI>const_cast (7.6.1.11 [<A href="https://wg21.link/expr.const.cast">expr.const.cast</A>]),</LI>
<LI>static_cast (7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]),</LI>
<LI>dynamic_cast (7.6.1.7 [<A href="https://wg21.link/expr.dynamic.cast">expr.dynamic.cast</A>]), or</LI>
<LI>reinterpret_cast (7.6.1.10 [<A href="https://wg21.link/expr.reinterpret.cast">expr.reinterpret.cast</A>])</LI>
</UL>
<DEL>converting, without a user-defined conversion, a glvalue operand that
is one of these expressions to a glvalue that refers to the object
designated by the operand, or to its complete object or a subobject
thereof,</DEL>

<INS>expression where</INS>
<UL class="ins">
<LI>the operand is one of these expressions and the cast does not invoke a user-defined conversion, or</LI>
<LI>the result of the cast refers to an object created by a temporary materialization conversion that is required or performed by the cast, or to a subobject of such an object, where
<UL>
<LI>the cast does not invoke a user-defined conversion, or</LI>
<LI>the temporary materialization conversion is applied to the prvalue result of a user-defined conversion that is applied to the operand.</LI>
</UL>
</LI>
</UL>

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

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2832"></A><H4>2832.
  
Invented temporary variables and temporary objects
</H4>
<B>Section: </B>6.8.7&#160; [<A href="https://wg21.link/class.temporary">class.temporary</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Thomas K&#246;ppe
 &#160;&#160;&#160;

 <B>Date: </B>2023-11-09<BR>


<P>(From editorial issue
<A HREF="https://github.com/cplusplus/draft/issues/6646">6646</A>.)</P>

<P>Both 7.3.1 [<A href="https://wg21.link/conv.general">conv.general</A>] and 7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]
introduce "invented temporary variables", but it is unclear whether
the corresponding objects are temporary objects with lifetimes as
specified in 6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>].</P>

<P><U>Possible resolution:</U></P>

<OL>

<LI>
<P>Change in 6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>] as follows:</P>
</LI>

<LI>
<P>Change in 7.3.1 [<A href="https://wg21.link/conv.general#3">conv.general</A>] paragraph 3 and paragraph 4 as
follows, moving the declarations into a code block:</P>

<BLOCKQUOTE>
<P>
An expression <I>E</I> can be <I>implicitly converted</I> to a type T if and
only if the declaration
<PRE>
  T t = <I>E</I>;
</PRE> is well-formed, for some invented temporary variable <TT>t</TT>
(<INS>6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>],</INS> 9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]).
</P>

<P>Certain language constructs require that an expression be converted
to a Boolean value. An expression <I>E</I> appearing in such a context
is said to be <I>contextually converted to bool</I> and is well-formed
if and only if the declaration
<PRE>
  bool t(<I>E</I>);
</PRE>
is well-formed, for some invented temporary variable <TT>t</TT>
(<INS>6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>],</INS> 9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]).</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>] as follows:</P>

<BLOCKQUOTE>

... If T is a reference type, the effect is the same as performing the
declaration and initialization
<PRE>
  T t(<I>E</I>);
</PRE>
for some invented temporary variable <TT>t</TT>
(<INS>6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>],</INS> 9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) and
then using the temporary variable as the result of the conversion. ...

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2868"></A><H4>2868.
  
Self-references in trivially copyable objects as function return values
</H4>
<B>Section: </B>6.8.7&#160; [<A href="https://wg21.link/class.temporary">class.temporary</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2018-02-16<BR>




<P>Consider:</P>

<PRE>
  struct A {
    A *children;
    long long arr[100];

    A() : children() {}
    A(int) : children(this) {}
  };

  __attribute__((noinline))
  A Foo() {
    return A(0);   // <SPAN CLASS="cmnt">#1</SPAN>
  }

  A x[3] = {};

  void Bar(int n) {
    A a = Foo();
    for (int i = 0; i &lt; n; i++) {
      a.children[i].children = x;     // <SPAN CLASS="cmnt">#2</SPAN>
    }
  }

  int main() {
    Bar(3);
    return x[0].children || !x[1].children || !x[2].children;
  }
</PRE>

<P>It ought to be valid to hoist the load of <TT>a.children</TT> out
of the loop. However, guaranteed copy elision is required to apply to
#1, making the <TT>A</TT> objects in <TT>Foo</TT> and <TT>Bar</TT> be
the same object.  An additional temporary copy can be made per
6.8.7 [<A href="https://wg21.link/class.temporary#3">class.temporary</A>] paragraph 3, but that does not cause
the <TT>children</TT> member of the <TT>a</TT> variable to become
invalid.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.8.7 [<A href="https://wg21.link/class.temporary#3">class.temporary</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

When an object of class type X is passed to or returned from a
function, if X has at least one eligible copy or move constructor
(11.4.4 [<A href="https://wg21.link/special">special</A>]), each such constructor is trivial, and
the destructor of X is either trivial or deleted, implementations are
permitted to create a temporary object to hold the function parameter
or result object. The temporary object is constructed from the
function argument or return value, respectively, and the function's
parameter or return object is initialized as if by using the eligible
trivial constructor to copy the temporary (even if that constructor is
inaccessible or would not be selected by overload resolution to
perform a copy or move of the object).
<INS>The temporary object may occupy the storage that the parameter or
return object is going to occupy, but pointers that pointed to the
temporary object become invalid pointer values
(6.9.4 [<A href="https://wg21.link/basic.compound">basic.compound</A>]) when the parameter or return object is
constructed and do not point to the parameter or return object.</INS>

</BLOCKQUOTE>

<P><B>CWG 2024-05-03</B></P>

<P>For return values, CWG favors replacing the exception in
6.8.7 [<A href="https://wg21.link/class.temporary#3">class.temporary</A>] paragraph 3 with an amendment to the
specification of guaranteed copy elision in 9.5.1 [<A href="https://wg21.link/dcl.init.general#16.6.1">dcl.init.general</A>] bullet 16.6.1.  It is unclear whether parameter values should be
treated the same.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 6.8.7 [<A href="https://wg21.link/class.temporary#3">class.temporary</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

When an object of <DEL>class</DEL> <INS>trivially returnable
(8.8.4 [<A href="https://wg21.link/stmt.return">stmt.return</A>])</INS> type X is passed to <DEL>or
returned from</DEL> a function, <DEL>if X has at least one eligible
copy or move constructor (11.4.4 [<A href="https://wg21.link/special">special</A>]), each such
constructor is trivial, and the destructor of X is either trivial or
deleted,</DEL> implementations are permitted to create a temporary
object to hold the function parameter <DEL>or result object</DEL>. The
temporary object is constructed from the function argument <DEL>or
return value, respectively,</DEL> and the function's parameter <DEL>or
return object</DEL> is initialized as if by using the eligible trivial
constructor to copy the temporary (even if that constructor is
inaccessible or would not be selected by overload resolution to
perform a copy or move of the object).

</BLOCKQUOTE>
</LI>

<LI>
<P>Split and change 8.8.4 [<A href="https://wg21.link/stmt.return#2">stmt.return</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<P>The <I>expr-or-braced-init-list</I> of a return statement is called
its operand. A return statement with no operand shall be used only in
a function whose return type is cv void, a constructor
(11.4.5 [<A href="https://wg21.link/class.ctor">class.ctor</A>]), or a destructor
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]).  A return statement with an operand of
type void shall be used only in a function that has a cv void return
type. A return statement with any other operand shall be used only in
a function that has a return type other than cv void<DEL>; the return
statement initializes the returned reference or prvalue result object
of the (explicit or implicit) function call
by copy-initialization (9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) from the
operand</DEL>.  [<I>Note 1:</I> A constructor or destructor does not have a
return type. &#8212;<I>end note</I>]
</P>

<P>
<INS>A type <TT>T</TT> is <I>trivially returnable</I> if <TT>T</TT>
is a class type that has at least one eligible copy or move
constructor (11.4.4 [<A href="https://wg21.link/special">special</A>]), each such constructor is
trivial, and the destructor of <TT>T</TT> is either trivial or
deleted.  If a function has a return type <TT>R</TT> other than
<I>cv</I> <TT>void</TT>:</INS>
<UL class="ins">
<LI>If <TT>R</TT> is trivially returnable, the return statement
initializes a first temporary object from the operand
(7.3.5 [<A href="https://wg21.link/conv.rval">conv.rval</A>]).  Then, a second temporary object is
constructed from the first temporary object, using an eligible trivial
constructor for the copy.  Then, the first temporary object is
destroyed and the duration of its storage ends.  [ Note: A pointer
value pointing to the first temporary object becomes an invalid
pointer value (6.9.4 [<A href="https://wg21.link/basic.compound">basic.compound</A>]). -- end note ] Finally, the
prvalue result object of the function call is initialized from the
second temporary object, using an eligible trivial constructor for the
copy, and the second temporary object is destroyed.  In both cases, an
eligible trivial constructor is used even if that constructor is
inaccessible or would not be selected by overload resolution to
perform a copy or move of the object.</LI>
<LI>Otherwise, the return statement initializes the
returned reference or prvalue result object of the (explicit or
implicit) function call by copy-initialization
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) from the operand.
</LI>
</UL>
[ <I>Note 2:</I> A return statement can involve an invocation of a
constructor to perform a copy or move of the operand <DEL>if it is not
a prvalue or if its type differs from the return type of the
function</DEL>. A copy operation associated with a return statement
can be elided or converted to a move operation if an automatic storage
duration variable is returned (11.9.6 [<A href="https://wg21.link/class.copy.elision">class.copy.elision</A>]).
&#8212;<I>end note</I>]
</P>

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2941"></A><H4>2941.
  
Lifetime extension for function-style cast to reference type
</H4>
<B>Section: </B>6.8.7&#160; [<A href="https://wg21.link/class.temporary">class.temporary</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2024-10-18<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/625">#625</A>.)
</P>

<P>
<A HREF="cwg_defects.html#2894">Issue 2894</A> will clarify that a
function-style cast to reference type produces a glvalue, not a
prvalue.  However, 6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>] does not specify
lifetime-extension for this case, even though implementations
uniformly do extend the lifetime.</P>

<P>For example:</P>

<PRE>
  int glob;
  struct A {
   constexpr ~A() { p = &amp;glob; }
   int *p;
  };
  constexpr int f() {
   typedef const A &amp;AR;
   const A &amp;ref = AR{0};
   delete ref.p;
   return 0;
  }
  extern constexpr int x = f(); //<SPAN CLASS="cmnt"> okay</SPAN>
</PRE>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.8.7 [<A href="https://wg21.link/class.temporary#6">class.temporary</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>
<UL>
<LI>a
<UL>
<LI>const_cast (7.6.1.11 [<A href="https://wg21.link/expr.const.cast">expr.const.cast</A>]),</LI>
<LI>...</LI>
</UL>
</LI>

<LI class="ins">an explicit type conversion (functional notation)
(7.6.1.4 [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>]) to a reference type whose initializer
is a <I>braced-init-list</I> where the reference is
<UL>
<LI>bound directly to the glvalue result of one of these expressions
that is the sole element of the <I>braced-init-list</I> or</LI>
<LI>bound to the result of a temporary materialization conversion,</LI>
</UL>
</LI>

<LI>a conditional expression (7.6.16 [<A href="https://wg21.link/expr.cond">expr.cond</A>]) that is a
glvalue where the second or third operand is one of these expressions,
or</LI>
</UL>
</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3043"></A><H4>3043.
  
Lifetime extension for temporaries in expansion statements
</H4>
<B>Section: </B>6.8.7&#160; [<A href="https://wg21.link/class.temporary">class.temporary</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jakub Jelinek
 &#160;&#160;&#160;

 <B>Date: </B>2025-07-07<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/724">#724</A>.)</P>

<P>Subclause 6.8.7 [<A href="https://wg21.link/class.temporary#7">class.temporary</A>] paragraph 7 and paragraph 8 specify:</P>

<BLOCKQUOTE>

<P>The fourth context is when a temporary object is created in
the <I>for-range-initializer</I> of either a range-based for statement
or an enumerating expansion statement (8.7 [<A href="https://wg21.link/stmt.expand">stmt.expand</A>]). If
such a temporary object would otherwise be destroyed at the end of
the <I>for-range-initializer</I> full-expression, the object persists
for the lifetime of the reference initialized by
the <I>for-range-initializer</I>.</P>

<P>The fifth context is when a temporary object is created in
the <I>expansion-initializer</I> of an iterating or destructuring
expansion statement. If such a temporary object would otherwise be
destroyed at the end of that <I>expansion-initializer</I> , the object
persists for the lifetime of the reference initialized by
the <I>expansion-initializer</I>, if any.
</P>

</BLOCKQUOTE>

<P>There are a number of problems with this phrasing:</P>
<UL>
<LI>The original idea of lifetime extension in a
<I>for-range-initializer</I> was to ensure that temporaries defining a
range would survive across all iterations.  For an enumerating
expansion statement, there is no overarching range expression; each
element of the <I>expression-list</I> is considered separately.
Furthermore, there is no <I>for-range-initializer</I> in the
corresponding grammar to start with.
</LI>
<LI>
For an iterating expansion statement, the involved variables
are <TT>constexpr</TT>, so no dangling pointers or similar could
escape from the constant evaluation to start with.  The necessity for
temporary lifetime extension is thus unclear.
</LI>
</UL>

<P><U>Possible resolution:</U></P>

<P>Change in 6.8.7 [<A href="https://wg21.link/class.temporary#7">class.temporary</A>] paragraph 7 and paragraph 8 as
follows:</P>

<BLOCKQUOTE>

<P>The fourth context is when a temporary object is created in
the <I>for-range-initializer</I> of <DEL>either</DEL> a range-based for statement
<DEL>or an enumerating expansion statement
(8.7 [<A href="https://wg21.link/stmt.expand">stmt.expand</A>])</DEL>. If such a temporary object would
otherwise be destroyed at the end of the <I>for-range-initializer</I>
full-expression, the object persists for the lifetime of the reference
initialized by the <I>for-range-initializer</I>.</P>

<P>The fifth context is when a temporary object is created in
the <I>expansion-initializer</I> of <DEL>an iterating
or</DEL> <INS>a</INS> destructuring expansion statement. If such a
temporary object would otherwise be destroyed at the end of
that <I>expansion-initializer</I>, the object persists for the
lifetime of the reference initialized by
the <I>expansion-initializer</I>, if any.
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3063"></A><H4>3063.
  
Lifetime extension of temporaries past function return
</H4>
<B>Section: </B>6.8.7&#160; [<A href="https://wg21.link/class.temporary">class.temporary</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2025-09-12<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/760">#760</A>.)</P>

<P>Consider:</P>

<PRE>
  struct B { ~B(); };
  struct A { const B &amp;b; };
  A foo() { return {{}}; }   //<SPAN CLASS="cmnt"> #1</SPAN>
  void bar();
  int main() {
    A a = foo();
    bar();
  }
</PRE>

<P>At #1, a temporary of type <TT>B</TT> is created and, due to
guaranteed copy elision, is bound to <TT>a.b</TT> in <TT>main</TT>.
The current rules, as amended by
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2748r5.html">P2748R5</A>
(Disallow Binding a Returned Glvalue to a Temporary), prescribe
lifetime extension of that temporary, which is a novel requirement
accidentally imposed by P2748R5 that is hard to implement.</P>

<P><U>Suggested resolution:</U></P>

<P>Add in 6.8.7 [<A href="https://wg21.link/class.temporary#6.11">class.temporary</A>] bullet 6.11 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>A temporary object bound to a reference element of an aggregate of
class type initialized from a parenthesized <I>expression-list</I>
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) persists until the completion of the
full-expression containing the <I>expression-list</I>.</LI>

<LI class="ins">
The lifetime of a temporary bound to <INS>a reference member of</INS>
the returned value in a function <TT>return</TT> statement
(8.8.4 [<A href="https://wg21.link/stmt.return">stmt.return</A>]) is not extended; the temporary is
destroyed at the end of the full-expression in the <TT>return</TT>
statement.
</LI>

<LI>A temporary bound to a reference in a <I>new-initializer</I>
(7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]) persists until ...</LI>
</UL>

</BLOCKQUOTE>
<BR><BR><HR>
<A NAME="350"></A><H4>350.
  
<TT>signed char</TT> underlying representation for objects
</H4>
<B>Section: </B>6.9&#160; [<A href="https://wg21.link/basic.types">basic.types</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Noah Stein
 &#160;&#160;&#160;

 <B>Date: </B>16 April 2002
  &#160;&#160;&#160;
  <B>Liaison: </B>WG14<BR>


<P>Sent in by David Abrahams:</P>

<P>Yes, and to add to this tangent, 6.9.2 [<A href="https://wg21.link/basic.fundamental#1">basic.fundamental</A>] paragraph 1
states "Plain char, signed char, and unsigned char are
three distinct types."  Strangely, 6.9 [<A href="https://wg21.link/basic.types#2">basic.types</A>] 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 6.8.4 [<A href="https://wg21.link/basic.life#5.3">basic.life</A>] bullet 5.3 from</P>

<UL>
<LI>
the pointer is used as the operand of a
<TT>static_cast</TT>
(7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>])
(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>
(7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>])
(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 6.8.4 [<A href="https://wg21.link/basic.life#6.3">basic.life</A>] bullet 6.3 from </P>
<UL>
<LI>
the lvalue is used as the operand of a
<TT>static_cast</TT>
(7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>])
(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>
(7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>])
(except when the conversion is ultimately to a reference to
byte-character type),
or
</LI>
</UL>

<P>Change the beginning of 6.9 [<A href="https://wg21.link/basic.types#2">basic.types</A>] 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 (6.8.1 [<A href="https://wg21.link/intro.memory">intro.memory</A>])
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 (6.8.1 [<A href="https://wg21.link/intro.memory">intro.memory</A>])
making up the object can be copied
into an array of byte-character type.
</BLOCKQUOTE>

<P>Add the indicated text to 6.9.2 [<A href="https://wg21.link/basic.fundamental#1">basic.fundamental</A>] 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<INS>, called the <I>byte-character types</I></INS>.
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
(6.9 [<A href="https://wg21.link/basic.types">basic.types</A>]); that is, they have the
same object representation.
For <INS>byte-</INS>character types, all bits of the object representation participate in
the value representation.
For unsigned <INS>byte-</INS>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 7.2.1 [<A href="https://wg21.link/basic.lval#15">basic.lval</A>] 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 6.8.4 [<A href="https://wg21.link/basic.life#5.4">basic.life</A>] bullet 5.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> (7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]) (except when
the conversion is to <INS><I>cv</I></INS> <TT>void*</TT>, or to
<INS><I>cv</I></INS> <TT>void*</TT> and subsequently to
<DEL><TT>char*</TT>, or <TT>unsigned char*</TT></DEL> <INS>a
pointer to a cv-qualified or cv-unqualified byte-character type
(6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>])</INS>), or</P></LI>

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

</UL>

</BLOCKQUOTE>

<LI><P>Change 6.8.4 [<A href="https://wg21.link/basic.life#6.4">basic.life</A>] bullet 6.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> (7.6.1.9 [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]) except when the
conversion is ultimately to <DEL><I>cv</I> <TT>char&amp;</TT> or
<I>cv</I> <TT>unsigned char&amp;</TT></DEL> <INS>a reference to a
cv-qualified or cv-unqualified byte-character type (6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]) or an array thereof</INS>, or</P></LI>

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

</UL>

</BLOCKQUOTE>

<LI><P>Change 6.9 [<A href="https://wg21.link/basic.types#2">basic.types</A>] 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 (6.8.1 [<A href="https://wg21.link/intro.memory">intro.memory</A>]) making up the object can be copied into an array of
<DEL><TT>char</TT> or <TT>unsigned char</TT></DEL> <INS>a
byte-character type (6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>])</INS>.<SUP>39</SUP> If the content of
<DEL>the</DEL> <INS>that</INS> array <DEL>of <TT>char</TT> or
<TT>unsigned char</TT></DEL> is copied back into the object, the
object shall subsequently hold its original
value. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Change 6.9.2 [<A href="https://wg21.link/basic.fundamental#1">basic.fundamental</A>] 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<INS>, called the
<I>byte-character types</I></INS>.  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 (6.8.3 [<A href="https://wg21.link/basic.align">basic.align</A>]); that is, they have the same object
representation. For <INS>byte-</INS>character types, all bits of
the object representation participate in the value
representation.  For <DEL>unsigned character types</DEL>
<INS><TT>unsigned char</TT></INS>, all possible bit patterns of
the value representation represent numbers...

</BLOCKQUOTE>

<LI><P>Change 7.2.1 [<A href="https://wg21.link/basic.lval#15">basic.lval</A>] 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 <DEL><TT>char</TT> or <TT>unsigned char</TT></DEL>
<INS>byte-character</INS> type <INS>(6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>])</INS>.</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 6.8.3 [<A href="https://wg21.link/basic.align#6">basic.align</A>] paragraph 6 as follows:</P></LI>

<BLOCKQUOTE>

The alignment requirement of a complete type can be queried using
an <TT>alignof</TT> expression (7.6.2.6 [<A href="https://wg21.link/expr.alignof">expr.alignof</A>]).
Furthermore, the <INS>byte-character</INS> types
<INS>(6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>])</INS> <DEL><TT>char</TT>,
<TT>signed char</TT>, and <TT>unsigned char</TT></DEL> shall have
the weakest alignment requirement.  [<I>Note:</I> this enables
the <INS>byte-</INS>character types to be used as the underlying
type for an aligned memory area (9.13.2 [<A href="https://wg21.link/dcl.align">dcl.align</A>]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 7.6.2.8 [<A href="https://wg21.link/expr.new#10">expr.new</A>] paragraph 10 as follows:</P></LI>

<BLOCKQUOTE>

...For arrays of <DEL><TT>char</TT> and <TT>unsigned
char</TT></DEL> <INS>a byte-character type (6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>])</INS>, 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 (6.8.3 [<A href="https://wg21.link/basic.align">basic.align</A>]) 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 <INS>byte-</INS>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>

<P><B>Additional note, November, 2014:</B></P>

<P>There is now the term &#8220;narrow character type&#8221; that
should be used instead of &#8220;byte-character type&#8221;.</P>

<BR><BR><HR>
<A NAME="1701"></A><H4>1701.
  
Array vs sequence in object representation
</H4>
<B>Section: </B>6.9&#160; [<A href="https://wg21.link/basic.types">basic.types</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Lawrence Crowl
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-14<BR>


<P>According to 6.9 [<A href="https://wg21.link/basic.types#4">basic.types</A>] paragraph 4,</P>

<BLOCKQUOTE>

The object representation of an object of type <TT>T</TT> is the sequence
of <I>N</I> <TT>unsigned char</TT> objects taken up by the object of
type <TT>T</TT>, where <I>N</I> equals <TT>sizeof(T)</TT>.

</BLOCKQUOTE>

<P>However, it is not clear that a &#8220;sequence&#8221; can be indexed,
as an array can and as is required for the implementation of
<TT>memcpy</TT> and similar code.</P>

<P><B>Additional note, November, 2014:</B></P>

<P>An additional point of concern has been raised
 as to whether it is appropriate
to refer to the constituent bytes of an object as being
&#8220;objects&#8221; themselves, along with the interaction of
this specification with copying or not copying parts of the object
representation that do not participate in the value representation
of the object (&#8220;padding&#8221; bytes).</P>

<BR><BR><HR>
<A NAME="2953"></A><H4>2953.
  
Value representation for non-trivially-copyable types
</H4>
<B>Section: </B>6.9.1&#160; [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2024-11-08<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/635">#635</A>.)
</P>

<P>Subclause 6.9.1 [<A href="https://wg21.link/basic.types.general#4">basic.types.general</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

... The <I>value representation</I> of a type T is the set of bits in
the object representation of T that participate in representing a
value of type T. ... For trivially copyable types, the value
representation is a set of bits in the object representation that
determines a <I>value</I>, ... [ Footnote: ... ]

</BLOCKQUOTE>

<P>It is unclear what difference is intended between "participate in
representing a value" and "determines a value".  If there is no
difference, it is unclear why one of the statements applies only to
trivially copyable types. The standard does not seem to refer to the
value representation of types that are not trivially copyable.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.9.1 [<A href="https://wg21.link/basic.types.general#4">basic.types.general</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

The <I>object representation</I> of a complete object type T is the
sequence of N unsigned char objects taken up by a non-bit-field
complete object of type T, where N equals sizeof(T). The <I>value
representation</I> of a <INS>trivially copyable</INS> type T is the
set of bits in the object representation of T that participate in
representing a <DEL>value</DEL> <INS><I>value</I></INS> of type
T<INS>, which is one discrete element of an implementation-defined set
of values</INS>. The object and value representation of a
non-bit-field complete object of type T are the bytes and bits,
respectively, of the object corresponding to the object and value
representation of its type. The object representation of a bit-field
object is the sequence of N bits taken up by the object, where N is
the width of the bit-field (11.4.10 [<A href="https://wg21.link/class.bit">class.bit</A>]).  The value
representation of a bit-field object is the set of bits in the object
representation that participate in representing its value. Bits in the
object representation of a type or object that are not part of the
value representation are <I>padding bits</I>. <DEL>For trivially copyable
types, the value representation is a set of bits in the object
representation that determines a <I>value</I>, which is one discrete
element of an implementation-defined set of values.</DEL> [ Footnote: ... ]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="146"></A><H4>146.
  
Floating-point zero
</H4>
<B>Section: </B>6.9.2&#160; [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]
 &#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>6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]
 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
7.3.14 [<A href="https://wg21.link/conv.fctptr#1">conv.fctptr</A>] 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>6.9.2&#160; [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]
 &#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>6.9.2 [<A href="https://wg21.link/basic.fundamental#2">basic.fundamental</A>] 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>

<P><B>Notes from the June, 2016 meeting:</B></P>

<P>See <A HREF="cwg_defects.html#2185">issue 2185</A>.</P>

<BR><BR><HR>
<A NAME="2966"></A><H4>2966.
  
Alignment and value representation of <TT>std::nullptr_t</TT>
</H4>
<B>Section: </B>6.9.2&#160; [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2024-11-22<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/644">#644</A>.)
</P>

<P>While 6.9.2 [<A href="https://wg21.link/basic.fundamental#16">basic.fundamental</A>] paragraph 16 specifies the size
of <TT>std::nullptr_t</TT>, it is silent on any alignment
requirements.  Furthermore, unlike in C23, there is no statement about
the value representation of <TT>std::nullptr_t</TT>.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.9.2 [<A href="https://wg21.link/basic.fundamental#16">basic.fundamental</A>] paragraph 16 as follows:</P>



<BLOCKQUOTE>

The types denoted by cv std::nullptr_t are distinct types. A value of
type <TT>std::nullptr_t</TT> is a null pointer constant
(7.3.12 [<A href="https://wg21.link/conv.ptr">conv.ptr</A>]). Such values participate in the pointer
and the pointer-to-member conversions (7.3.12 [<A href="https://wg21.link/conv.ptr">conv.ptr</A>],
7.3.13 [<A href="https://wg21.link/conv.mem">conv.mem</A>]). <DEL><TT>sizeof(std::nullptr_t)</TT>
shall be equal to <TT>sizeof(void*)</TT>.</DEL> <INS>The size
(7.6.2.5 [<A href="https://wg21.link/expr.sizeof">expr.sizeof</A>]) and alignment requirement
(6.8.3 [<A href="https://wg21.link/basic.align">basic.align</A>]) of the type <TT>std::nullptr_t</TT> are
those of the type "pointer to <TT>void</TT>". [ Note: The value
representation can comprise no bits (7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]). --
end note ]</INS>

</BLOCKQUOTE>
<BR><BR><HR>
<A NAME="3036"></A><H4>3036.
  
Extended floating-point types should not be cv-qualified
</H4>
<B>Section: </B>6.9.3&#160; [<A href="https://wg21.link/basic.extended.fp">basic.extended.fp</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jan Schultke
 &#160;&#160;&#160;

 <B>Date: </B>2025-06-03<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/710">#710</A>.)</P>

<P>It is underspecified whether <TT>std::float16_t</TT> and related
extended floating-point types are cv-qualified or not.  The intent is
that those are cv-unqualified.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 17.4.2 [<A href="https://wg21.link/stdfloat.syn">stdfloat.syn</A>] as follows:</P>

<PRE>
  namespace std {
    #if defined(__STDCPP_FLOAT16_T__)
      using float16_t = <DEL>implementation-defined</DEL> <INS>decltype(0.0f16)</INS> ; //<SPAN CLASS="cmnt"> see 6.9.3 [<A href="https://wg21.link/basic.extended.fp">basic.extended.fp</A>]</SPAN>
    #endif
    #if defined(__STDCPP_FLOAT32_T__)
      using float32_t = <DEL>implementation-defined</DEL> <INS>decltype(0.0f32)</INS> ; //<SPAN CLASS="cmnt"> see 6.9.3 [<A href="https://wg21.link/basic.extended.fp">basic.extended.fp</A>]</SPAN>
    #endif
    #if defined(__STDCPP_FLOAT64_T__)
      using float64_t = <DEL>implementation-defined</DEL> <INS>decltype(0.0f64)</INS> ; //<SPAN CLASS="cmnt"> see 6.9.3 [<A href="https://wg21.link/basic.extended.fp">basic.extended.fp</A>]</SPAN>
    #endif
    #if defined(__STDCPP_FLOAT128_T__)
      using float128_t = <DEL>implementation-defined</DEL> <INS>decltype(0.0f128)</INS> ; //<SPAN CLASS="cmnt"> see 6.9.3 [<A href="https://wg21.link/basic.extended.fp">basic.extended.fp</A>]</SPAN>
    #endif
    #if defined(__STDCPP_BFLOAT16_T__)
      using bfloat16_t = <DEL>implementation-defined</DEL> <INS>decltype(0.0bf16)</INS> ; //<SPAN CLASS="cmnt"> see 6.9.3 [<A href="https://wg21.link/basic.extended.fp">basic.extended.fp</A>]</SPAN>
    #endif
  }
</PRE>
<BR><BR><HR>
<A NAME="2544"></A><H4>2544.
  
Address of past-the-end of a potentially-overlapping subobject
</H4>
<B>Section: </B>6.9.4&#160; [<A href="https://wg21.link/basic.compound">basic.compound</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2022-02-20<BR>


<P>6.9.4 [<A href="https://wg21.link/basic.compound#3">basic.compound</A>] paragraph 3 states:</P>

<BLOCKQUOTE>

A value of a pointer type that is a pointer to or past the end of an
object represents the address of the first byte in memory
(6.8.1 [<A href="https://wg21.link/intro.memory">intro.memory</A>]) occupied by the object [ <I>Footnote</I>:
... ] or the first byte in memory after the end of the storage
occupied by the object, respectively.

</BLOCKQUOTE>

<P>A potentially-overlapping subobject of type <TT>T</TT> may occupy
fewer bytes than indicated by <TT>sizeof(T)</TT>, yet pointer
arithmetic will only consider <TT>sizeof(T)</TT>, not the number of
actually occupied bytes.  For example,</P>

<PRE>
struct X {
  X() = default;
  int x;
  short y;
};

struct S {
  [[no_unique_address]] X x;
  short z;
};

static_assert(sizeof(X) == sizeof(S));
</PRE>

<P>On a popular implementation, <TT>z</TT> is actually put into the
tail padding of <TT>x</TT>, and thus <TT>&amp;S().x + 1</TT> does not
actually point to "the first byte in memory after the end of the
storage occupied by" <TT>x</TT>.</P>

<P><U>Suggested resolution (amended 2022-03-10):</U></P>

<P>Change in 6.9.4 [<A href="https://wg21.link/basic.compound#3">basic.compound</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<P>
A value <INS><I>V</I></INS> of <INS>a</INS> pointer type <DEL>that is
a pointer to or past the end of an object</DEL> <I>represents the address</I>
<DEL>of the first byte in memory (6.8.1 [<A href="https://wg21.link/intro.memory">intro.memory</A>]) occupied by
the object</DEL> <INS><I>A</I> as follows</INS>:

<UL>
<LI>
<INS>If <I>V</I> is a pointer to an object, <I>A</I> is the address of the
object as specified in 6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]</INS> [ <I>Footnote</I>:
... ]
<DEL>or the first byte in memory after the end of the storage
occupied by the object, respectively</DEL>.
</LI>

<LI>
<INS>If <I>V</I> is a pointer past the end of an object that is not a
potentially-overlapping subobject, <I>A</I> is the address of the
first byte in memory after the end of the storage occupied by the
object.</INS>
</LI>

<LI>
<INS>If <I>V</I> is a pointer past the end of a
potentially-overlapping subobject, <I>A</I> is an
implementation-defined choice of an address within the complete object
or the address of the first byte in memory after the end of the
storage occupied by the complete object.</INS>
</LI>

<LI>
<INS>If <I>V</I> is a null pointer value or an invalid pointer value,
<I>V</I> does not represent an address.</INS>
</LI>

</UL>
</P>
</BLOCKQUOTE>

<P><B>CWG 2022-11-11</B></P>

<P>Unify the treatment of all subobjects by saying the pointer
past-the-end has address <TT>address(begin) + sizeof(T)</TT>.</P>

<BR><BR><HR>
<A NAME="698"></A><H4>698.
  
The definition of &#8220;sequenced before&#8221; is too narrow
</H4>
<B>Section: </B>6.10.1&#160; [<A href="https://wg21.link/intro.execution">intro.execution</A>]
 &#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 6.10.1 [<A href="https://wg21.link/intro.execution#14">intro.execution</A>] paragraph 14, &#8220;sequenced
before&#8221; is a relation between &#8220;evaluations.&#8221;  However,
6.10.3.3 [<A href="https://wg21.link/basic.start.dynamic#3">basic.start.dynamic</A>] 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>, 17.5 [<A href="https://wg21.link/support.start.term">support.start.term</A>]), 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="2955"></A><H4>2955.
  
Unify rules about conflicting unordered accesses
</H4>
<B>Section: </B>6.10.1&#160; [<A href="https://wg21.link/intro.execution">intro.execution</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2024-11-08<BR>


<P>The rules in 6.10.1 [<A href="https://wg21.link/intro.execution#10">intro.execution</A>] paragraph 10 (within a single
thread) and 6.10.2.2 [<A href="https://wg21.link/intro.races#2">intro.races</A>] paragraph 2 (for concurrent
evaluations) are strikingly similar and should be merged.</P>

<BR><BR><HR>
<A NAME="1842"></A><H4>1842.
  
Unevaluated operands and &#8220;carries a dependency&#8221;
</H4>
<B>Section: </B>6.10.2&#160; [<A href="https://wg21.link/intro.multithread">intro.multithread</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-01-23
  &#160;&#160;&#160;
  <B>Liaison: </B>SG1<BR>


<P>According to 6.10.2 [<A href="https://wg21.link/intro.multithread#9">intro.multithread</A>] paragraph 9,</P>

<BLOCKQUOTE>

<P>An evaluation <I>A carries a dependency</I> to an evaluation <I>B</I>
if</P>

<UL>
<LI><P>the value of <I>A</I> is used as an operand of <I>B</I>,
unless:</P></LI>

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

<LI><P>
<I>A</I> is the left operand of a built-in logical AND
(<TT>&amp;&amp;,</TT> see 7.6.14 [<A href="https://wg21.link/expr.log.and">expr.log.and</A>]) or logical OR
(<TT>||</TT>, see 7.6.15 [<A href="https://wg21.link/expr.log.or">expr.log.or</A>]) operator, or</P></LI>

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

</UL>

</UL>

</BLOCKQUOTE>

<P>The intent is that this does not apply to the second operands
of such operators if the first operand is such that they are not
evaluated, but the wording is not clear to that effect.  (A similar
question applies to the non-selected operand of the conditional
operator <TT>?:</TT>.)</P>

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

<P>It appears likely that the text involved will be removed by a
revision to the <TT>memory_order_consume</TT> specification.</P>

<P><B>Notes from the February, 2016 meeting:</B></P>

<P>Action on this issue will be deferred until the specification
for <TT>memory_order_consume</TT> is complete; it should not currently
be used.</P>

<BR><BR><HR>
<A NAME="2297"></A><H4>2297.
  
Unclear specification of atomic operations
</H4>
<B>Section: </B>6.10.2.2&#160; [<A href="https://wg21.link/intro.races">intro.races</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Kazutoshi Satoda
 &#160;&#160;&#160;

 <B>Date: </B>2016-01-21<BR>


<P>It is not sufficiently clear that the only atomic operations are the
ones defined in 32.5 [<A href="https://wg21.link/atomics">atomics</A>] by the library. The intent
is that no accesses are atomic unless the Standard describes them as
such.</P>

<P>An additional problem is that, e.g., <TT>new</TT> and <TT>delete</TT>
are defined to be synchronization operations, but they are not defined
in Clauses 32.5 [<A href="https://wg21.link/atomics">atomics</A>] and Clause 32 [<A href="https://wg21.link/thread">thread</A>].
</P>

<P><U>Suggested resolution:</U></P>

<P>Change 6.10.2.2 [<A href="https://wg21.link/intro.races#3">intro.races</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

The library defines <DEL>a number</DEL> <INS>the set</INS> of atomic
operations (32.5 [<A href="https://wg21.link/atomics">atomics</A>])<DEL> and operations on mutexes
(Clause 32 [<A href="https://wg21.link/thread">thread</A>]) that</DEL><INS>. Some of these, and some
other library operations, such as those on mutexes (
Clause 32 [<A href="https://wg21.link/thread">thread</A>])</INS> are specially identified as synchronization
operations. These operations...

</BLOCKQUOTE>

<P><B>Notes from the April, 2017 teleconference:</B></P>

<P>CWG determined that this issue should be handled
editorially; it will be in "review" status until the change
has been made and verified.  See
<A HREF="https://github.com/cplusplus/draft/issues/1611">editorial
issue 1611</A>.</P>

<P><B>Additional notes, October, 2018:</B></P>

<P>This is also
<A HREF="http://open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#2506">
library issue 2506</A>. SG1 has requested a paper to deal with this
issue, so it is no longer considered editorial.
</P>

<BR><BR><HR>
<A NAME="2298"></A><H4>2298.
  
Actions and expression evaluation
</H4>
<B>Section: </B>6.10.2.2&#160; [<A href="https://wg21.link/intro.races">intro.races</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Kazutoshi Satoda
 &#160;&#160;&#160;

 <B>Date: </B>2016-01-21
  &#160;&#160;&#160;
  <B>Liaison: </B>SG1<BR>


<P>Section 6.10.2.2 [<A href="https://wg21.link/intro.races">intro.races</A>] uses the terms &#8220;action&#8221;
and &#8220;expression evaluation&#8221; interchangeably. &#8220;Sequenced
before&#8221; is defined on expression evaluations. Probably none of
those is correct.</P>

<P>We should really be talking about individual accesses to
&#8220;memory locations&#8221;. Talking about larger &#8220;expression
evaluations&#8221; is incorrect, since they may include internal
synchronization. Thus concurrent evaluation of large conflicting
expression evaluations may not actually correspond to a data race.
I'm not sure what term we should be using instead of &#8220;expression
evaluation&#8221; to denote such individual accesses. Call it
<I>X</I> for now.</P>

<P>There is also an issue with the fact that &#8220;sequenced
before&#8221; is defined on expression evaluation. &#8220;Sequenced
before&#8221; should also be defined on <I>X</I>s. It doesn't make
any sense to talk about &#8220;sequenced before&#8221; ordering on
two evaluations when one includes the other. Whenever we say
&#8220;<TT>A</TT> is sequenced before <TT>B</TT>&#8221;, we probably
really mean that all <I>X</I>s in <TT>A</TT> are sequenced before all
<I>X</I>s in <TT>B</TT>. We could probably just include a blanket
statement to that effect.</P>

<P><B>Additional notes (April, 2022)</B></P>

<P>Forwarded to SG1 with
<A HREF="https://github.com/cplusplus/papers/issues/1234">paper issue 1234</A>,
reflecting the former "concurrency" status of this issue.</P>

<BR><BR><HR>
<A NAME="3060"></A><H4>3060.
  
Change in behavior for <TT>noexcept</TT> <TT>main</TT>
</H4>
<B>Section: </B>6.10.3.1&#160; [<A href="https://wg21.link/basic.start.main">basic.start.main</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2025-08-15<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/752">#752</A>.)</P>

<P>Consider:</P>

<PRE>
  int main() noexcept {}
</PRE>

<P>Prior to P0012R1 (C++17), this was allowed,
because <TT>noexcept</TT> was not part of a function type.  This is
now ill-formed, because such a <TT>main</TT> function is not of one of
the types allowed in 6.10.3.1 [<A href="https://wg21.link/basic.start.main#2">basic.start.main</A>] paragraph 2.</P>

<P>This needs an Annex C entry or a relaxation of the rules.  Note
that the presence or absence of <TT>noexcept</TT> does not change
behavior, because an exception leaving <TT>main</TT> calls
<TT>std::terminate</TT> either way, and <TT>main</TT> cannot be
named in expressions.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.10.3.1 [<A href="https://wg21.link/basic.start.main#2">basic.start.main</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

... An implementation shall allow both
<UL>
<LI>a <INS>"optionally <TT>noexcept</TT></INS> function of () returning int<INS>"</INS> and</LI>
<LI>a <INS>"optionally <TT>noexcept</TT></INS> function of (int, pointer to pointer to char) returning int<INS>"</INS>
</LI>
</UL>
as the type of main (9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]). ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="371"></A><H4>371.
  
Interleaving of constructor calls
</H4>
<B>Section: </B>6.10.3.2&#160; [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]
 &#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
6.10.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>].</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 6.10.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>].
Actually, when I read 6.10.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]
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 6.10.3.2 [<A href="https://wg21.link/basic.start.static#3">basic.start.static</A>] 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="1294"></A><H4>1294.
  
Side effects in dynamic/static initialization
</H4>
<B>Section: </B>6.10.3.2&#160; [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-04-08<BR>




<P>According to 6.10.3.2 [<A href="https://wg21.link/basic.start.static#3">basic.start.static</A>] paragraph 3,</P>

<BLOCKQUOTE>

<P>An implementation is permitted to perform the initialization of a
non-local variable with static storage duration as a static
initialization even if such initialization is not required to be done
statically, provided that</P>

<UL>

<LI><P> the dynamic version of the initialization does not change the value
 of any other object of namespace scope prior to its initialization,
 and
</P></LI>

<LI><P>the static version of the initialization produces the same value in
the initialized variable as would be produced by the dynamic
initialization if all variables not required to be initialized
statically were initialized dynamically.
</P></LI>

</UL>

</BLOCKQUOTE>

<P>This does not consider side effects of the initialization in this
determination, only the values of namespace-scope variables.</P>



<P><B>CWG 2022-11-11</B></P>

<P>The precise normative identification of side effects relevant for
the rule remains open.  An approach similar to the constexpr model of
considering the transitive hull of evaluations might be
applicable.</P>

<BR><BR><HR>
<A NAME="1659"></A><H4>1659.
  
Initialization order of thread_local template static data members
</H4>
<B>Section: </B>6.10.3.2&#160; [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-14<BR>


<P>According to 6.10.3.2 [<A href="https://wg21.link/basic.start.static#5">basic.start.static</A>] paragraph 5,</P>

<BLOCKQUOTE>

It is implementation-defined whether the dynamic initialization of a
non-local variable with static or thread storage duration is done before
the first statement of the initial function of the thread. If the
initialization is deferred to some point in time after the first statement
of the initial function of the thread, it shall occur before the first
odr-use (6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]) of any variable with thread storage
duration defined in the same translation unit as the variable to be
initialized.

</BLOCKQUOTE>

<P>This doesn't consider that initialization of instantiations of static
data members of class templates (which can be <TT>thread_local</TT>) are
unordered.  Presumably odr-use of such a static data member should not
trigger the initialization of any <TT>thread_local</TT> variable other than
that one?</P>

<BR><BR><HR>
<A NAME="2684"></A><H4>2684.
  
thread_local dynamic initialization
</H4>
<B>Section: </B>6.10.3.3&#160; [<A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-01-06<BR>


<P>Subclause 6.10.3.3 [<A href="https://wg21.link/basic.start.dynamic#7">basic.start.dynamic</A>] paragraph 7 specifies:</P>

<BLOCKQUOTE>

It is implementation-defined whether the dynamic initialization of a
non-block non-inline variable with thread storage duration is
sequenced before the first statement of the initial function of a
thread or is deferred. If it is deferred, the initialization
associated with the entity for thread t is sequenced before the first
non-initialization odr-use by t of any non-inline variable with thread
storage duration defined in the same translation unit as the variable
to be initialized. ...

</BLOCKQUOTE>

<P>How does the rule quoted above affect variables
declared <TT>constinit</TT>?  For example:</P>

<PRE>
  extern thread_local constinit int x;
</PRE>

<P>Clang and gcc do not emit suitable wrapper code to allow for
deferred initialization of <TT>x</TT>, which is non-conforming.
Should this be allowed?</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 6.10.3.3 [<A href="https://wg21.link/basic.start.dynamic#7">basic.start.dynamic</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

It is implementation-defined whether the dynamic initialization of a
non-block non-inline variable with thread storage duration is
sequenced before the first statement of the initial function of a
thread or is deferred. If it is deferred, the initialization
associated with the entity for thread t is sequenced before the first
non-initialization odr-use by t of any non-inline variable with thread
storage duration <INS>and dynamic initialization</INS> defined in the
same translation unit as the variable to be initialized. ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2928"></A><H4>2928.
  
No ordering for initializing thread-local variables
</H4>
<B>Section: </B>6.10.3.3&#160; [<A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2024-08-16<BR>


<P>The heading of subclause 6.10.3.3 [<A href="https://wg21.link/basic.start.dynamic">basic.start.dynamic</A>] purports to
specify "dynamic initialization of non-block variables", but the
subclause actually specifies dynamic initialization of variables with
static storage duration only, omitting variables with thread storage
duration.</P>

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

<BR><BR><HR>
<A NAME="3042"></A><H4>3042.
  
Implicit object creation is insufficient to model effective type rule of C
</H4>
<B>Section: </B>7.2.1&#160; [<A href="https://wg21.link/basic.lval">basic.lval</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2025-07-04<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/723">#723</A>.)</P>

<P>Consider:</P>

<PRE>
  #include &lt;stdlib.h&gt;

  int main() {
   void* p = malloc(sizeof(int) + sizeof(float));

   *(int*)p = 0;        //<SPAN CLASS="cmnt"> #1</SPAN>
   *(float*)p = 0.0f;   //<SPAN CLASS="cmnt"> #2</SPAN>
  }
</PRE>

<P>This example has well-defined behavior in C, because C23 6.5.1p6
says</P>

<BLOCKQUOTE>

... If a value is stored into an object having no declared type through an
lvalue having a type that is not a non-atomic character type, then the
type of the lvalue becomes the effective type of the object for that
access and for subsequent accesses that do not modify the stored
value. ...

</BLOCKQUOTE>

<P>In contrast, implicit object creation for <TT>malloc</TT> happens
once, and there is no single type that would make the program have
defined behavior at both #1 and #2, since copy-assignment cannot
create objects in C++.
</P>

<P><U>Possible resolution:</U></P>

<P>Add to C.7.4 [<A href="https://wg21.link/diff.expr">diff.expr</A>] as follows:</P>

<BLOCKQUOTE class="ins">

<B>Affected subclause:</B> 7.6.19 [<A href="https://wg21.link/expr.assign">expr.assign</A>]<BR>
<B>Change:</B> Effective type rules are approximated with implicit object creation.<BR>
<B>Rationale:</B> C++ has a stronger type system than C.<BR>
<B>Effect on original feature:</B> Change to semantics of well-defined feature. Some well-defined C expressions will have undefined behavior in C++.<BR>
[Example:
<PRE>
  void f() {
    void* p = malloc(sizeof(int) + sizeof(float));

    *(int*)p = 0;
    *(float*)p = 0.0f;   //<SPAN CLASS="cmnt"> well-formed in both C and C++; undefined behavior in C++</SPAN>
  }
</PRE>
--end example]<BR>
<B>Difficulty of converting:</B> Programs must avoid implicit type changes of objects.<BR>
<B>How widely used:</B> Seldom.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2964"></A><H4>2964.
  
Reading "invalid pointer values"
</H4>
<B>Section: </B>7.3.2&#160; [<A href="https://wg21.link/conv.lval">conv.lval</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Davis Herring
 &#160;&#160;&#160;

 <B>Date: </B>2024-11-22<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/645">#645</A>.)
</P>

<P>
<A HREF="cwg_defects.html#2822">Issue 2822</A> clarified that pointer values
are not replaced by invalid pointer values when the duration of the
storage of their pointee ends, but merely become invalid in the
context of evaluations outside of the duration of the storage.
However, 7.3.2 [<A href="https://wg21.link/conv.lval#3.3">conv.lval</A>] bullet 3.3 still reads:</P>

<BLOCKQUOTE>

The result of the conversion is determined according to the following
rules:

<UL>
<LI>...</LI>
<LI>Otherwise, if the object to which the glvalue refers contains an
invalid pointer value (6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>]), the behavior
is implementation-defined.</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P><U>Possible resolution:</U></P>

<P>Change in 7.3.2 [<A href="https://wg21.link/conv.lval#3.3">conv.lval</A>] bullet 3.3 as follows:</P>

<BLOCKQUOTE>

The result of the conversion is determined according to the following
rules:

<UL>
<LI>...</LI>
<LI>Otherwise, if the object to which the glvalue refers
contains <DEL>an invalid pointer value
(6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>])</DEL>
<INS>a pointer value that is not valid in the context of the
conversion (6.9.4 [<A href="https://wg21.link/basic.compound">basic.compound</A>])</INS>, the behavior is
implementation-defined.</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2438"></A><H4>2438.
  
Problems in the specification of qualification conversions
</H4>
<B>Section: </B>7.3.6&#160; [<A href="https://wg21.link/conv.qual">conv.qual</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2019-08-14<BR>


<OL>
<LI><P>A type has multiple cv-decompositions, and
7.3.6 [<A href="https://wg21.link/conv.qual#3">conv.qual</A>] paragraph 3 does not say which one
to use when determining the cv-combined type. Should this be
the longest decomposition that works, i.e., the greatest
<I>n</I> for which you can decompose both types? (We used to
refer to the cv-qualification signature, which implicitly
meant to take the longest decomposition.)</P></LI>

<LI><P>When computing the cv-combined types of two types
<TT>T1</TT> and <TT>T2</TT>, if <TT>U1</TT> and <TT>U2</TT>
are different, shouldn't we add <TT>const</TT> to all layers
above that in the type?</P></LI>

<LI><P>
<I>cv<SUB>0</SUB><SUP>3</SUP></I> is left unspecified
by the wording in paragraph 3.</P></LI>

<LI><P>We are too eager to replace a <I>P<SUB>i</SUB><SUP>3</SUP></I>
with &#8220;array of unknown bound of&#8221;. That should only
happen if both <I>P<SUB>i</SUB><SUP>1</SUP></I> and
<I>P<SUB>i</SUB><SUP>2</SUP></I> are array types, or we end up
not forming a type <I>T3</I> that is similar to <I>T1</I>. For
example, the cv-combined type of <TT>int**</TT> and
<TT>const int (*)[]</TT>, when decomposed with <I>n</I> == 2,
is required to be <TT>const int (*)[]</TT> by the bulleted
rules, and that type is not similar to the original <TT>T1</TT>.</P></LI>

<LI><P>In various places, we have operators that say,
&#8220;if one operand is of pointer type, apply array-to-pointer
conversions, pointer conversions, and qualification conversions
to bring the two operands to their composite pointer type,&#8221;
but that doesn't work, because the definition of composite
pointer type can't cope with one operand being a pointer and the
other being an array. We either need to define the composite
pointer type of a pointer and an array (and, if that's done in
terms of computing the cv-combined type, be careful to ensure
that computing the cv-combined type actually works in that case)
or to perform the array-to-pointer conversion before considering
the composite pointer type.</P></LI>

</OL>

<BR><BR><HR>
<A NAME="2981"></A><H4>2981.
  
Usual arithmetic conversions and result types
</H4>
<B>Section: </B>7.4&#160; [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jan Schultke
 &#160;&#160;&#160;

 <B>Date: </B>2025-01-02<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/663">#663</A>.)
</P>

<P>Subclause 7.4 [<A href="https://wg21.link/expr.arith.conv#1">expr.arith.conv</A>] paragraph 1 specifies:</P>


<BLOCKQUOTE>

Many binary operators that expect operands of arithmetic or
enumeration type cause conversions and yield result types in a similar
way. The purpose is to yield a common type, which is also the type of
the result. ...

</BLOCKQUOTE>

<P>However, while the relational and equality operators do apply the
usual arithmetic conversions, their result type is <TT>bool</TT> and
not the common type from the usual arithmetic conversions.</P>

<P><U>Suggested resolution:</U></P>

<OL>
<LI>
<P>Change in 7.4 [<A href="https://wg21.link/expr.arith.conv#1">expr.arith.conv</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Many binary operators that expect operands of arithmetic or
enumeration type cause conversions <DEL>and yield result types</DEL>
in a similar way. The purpose is to yield a common type<DEL>, which is
also the type of the result</DEL>. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.5 [<A href="https://wg21.link/expr.mul#2">expr.mul</A>] paragraph 2 as follows:</P>



<BLOCKQUOTE>

The operands of * and / shall have arithmetic or unscoped enumeration
type; the operands of % shall have integral or unscoped enumeration
type. The usual arithmetic conversions (7.4 [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>]) are
performed on the operands <INS>to bring them to a common type,</INS>
and <DEL>determine the type of</DEL> the result <INS>is a prvalue of
that type</INS>.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.6 [<A href="https://wg21.link/expr.add#1">expr.add</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The additive operators + and - group left-to-right. Each operand shall
be a prvalue. <INS>The result is a prvalue.</INS> If both operands
have arithmetic or unscoped enumeration type, the usual arithmetic
conversions (7.4 [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>]) are performed <INS>on the
operands to bring them to a common type, and the result is of that
type</INS>. Otherwise, if one operand has arithmetic or unscoped
enumeration type, integral promotion is applied
(7.3.7 [<A href="https://wg21.link/conv.prom">conv.prom</A>]) to that operand. A converted or promoted
operand is used in place of the corresponding original operand for the
remainder of this section.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.9 [<A href="https://wg21.link/expr.rel#2">expr.rel</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

The converted operands shall have arithmetic, enumeration, or pointer
type. The operators &lt; (less than), &gt; (greater than), &lt;= (less
than or equal to), and &gt;= (greater than or equal to) all yield
<INS>prvalues of</INS> <DEL>false or true. The</DEL> type <DEL>of the
result is</DEL> bool.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 7.6.10 [<A href="https://wg21.link/expr.eq#2">expr.eq</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

The converted operands shall have scalar type. The operators == and !=
both yield <DEL>true or false, i.e.,</DEL>
a <DEL>result</DEL> <INS>prvalue</INS> of type bool. In each case
below, the operands shall have the same type after the specified
conversions have been applied.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.11 [<A href="https://wg21.link/expr.bit.and#1">expr.bit.and</A>] paragraph 1 as follows:</P>



<BLOCKQUOTE>

The &amp; operator groups left-to-right. The operands shall be of
integral or unscoped enumeration type. The usual arithmetic
conversions (7.4 [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>]) are performed <INS>on the
operands to bring them to a common type, and the result is a prvalue of
that type</INS>. Given the coefficients xi and yi of the base-2
representation (6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]) of the converted operands
x and y, the coefficient ri of the base-2 representation of the result
r is 1 if both xi and yi are 1, and 0 otherwise.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.12 [<A href="https://wg21.link/expr.xor#1">expr.xor</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The ^ operator groups left-to-right. The operands shall be of integral
or unscoped enumeration type. The usual arithmetic conversions
(7.4 [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>]) are performed <INS>on the operands to bring
them to a common type, and the result is a prvalue of that
type</INS>. Given the coefficients xi and yi of the base-2
representation (6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]) of the converted operands
x and y, the coefficient ri of the base-2 representation of the result
r is 1 if either (but not both) of xi and yi is 1, and 0 otherwise.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.6.13 [<A href="https://wg21.link/expr.or#1">expr.or</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The | operator groups left-to-right. The operands shall be of integral
or unscoped enumeration type. The usual arithmetic conversions
(7.4 [<A href="https://wg21.link/expr.arith.conv">expr.arith.conv</A>]) are performed <INS>on the operands to bring
them to a common type, and the result is a prvalue of that
type</INS>. Given the coefficients xi and yi of the base-2
representation (6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]) of the converted operands
x and y, the coefficient ri of the base-2 representation of the result
r is 1 if at least one of xi and yi is 1, and 0 otherwise.

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="2989"></A><H4>2989.
  
Remove misleading general allowance for parentheses
</H4>
<B>Section: </B>7.5.4&#160; [<A href="https://wg21.link/expr.prim.paren">expr.prim.paren</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2025-01-17<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/661">#661</A>.)
</P>

<P>The second sentence in 7.5.4 [<A href="https://wg21.link/expr.prim.paren#1">expr.prim.paren</A>] paragraph 1 occasionally
causes confusion whether parenthesized constructs are allowed where
the grammar or other rules do not specifically allow them.</P>

<P>Specific areas of concern are:</P>
<UL>
<LI>Parenthesized integer literal with value 0 as a null pointer
constant, e.g. <TT>(((0ULL)))</TT> (supported by all
implementations)</LI>
<LI>Parenthesized operand for <TT>&amp;</TT> when forming a
pointer-to-member (7.6.2.2 [<A href="https://wg21.link/expr.unary.op#3">expr.unary.op</A>] paragraph 3)</LI>
<LI>Parenthesized non-type template arguments when matching template
specializations (13.7.6.1 [<A href="https://wg21.link/temp.spec.partial.general#8">temp.spec.partial.general</A>] paragraph 8,
13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#8">temp.deduct.type</A>] paragraph 8)</LI>
</UL>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 6.8.5 [<A href="https://wg21.link/basic.indet#2.1">basic.indet</A>] bullet 2.1 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>If an indeterminate or erroneous value of unsigned ordinary character
type (6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]) or std::byte type
(17.2.1 [<A href="https://wg21.link/cstddef.syn">cstddef.syn</A>]) is produced by the evaluation of:
<UL>
<LI class="ins">the operand of a parenthesized expression
(7.5.4 [<A href="https://wg21.link/expr.prim.paren">expr.prim.paren</A>]),</LI>
<LI>the second or third operand of a conditional expression
(7.6.16 [<A href="https://wg21.link/expr.cond">expr.cond</A>]),</LI>
<LI>the right operand of a comma
expression (7.6.20 [<A href="https://wg21.link/expr.comma">expr.comma</A>]),</LI>
<LI>...</LI>
</UL>
then the result of the operation is an indeterminate value or that
erroneous value, respectively.
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.9.2 [<A href="https://wg21.link/basic.fundamental#15">basic.fundamental</A>] paragraph 15 as follows:</P>
<BLOCKQUOTE>

A type cv void is an incomplete type that cannot be completed; such a
type has an empty set of values. It is used as the return type for
functions that do not return a value. An expression of type cv void
shall be used only as
<UL>
<LI>an expression statement (8.3 [<A href="https://wg21.link/stmt.expr">stmt.expr</A>]),</LI>
<LI>the expression in a return statement (8.8.4 [<A href="https://wg21.link/stmt.return">stmt.return</A>])
for a function with the return type cv void,</LI>
<LI class="ins">the operand of a parenthesized expression
(7.5.4 [<A href="https://wg21.link/expr.prim.paren">expr.prim.paren</A>]),</LI>
<LI>an operand of a comma expression
(7.6.20 [<A href="https://wg21.link/expr.comma">expr.comma</A>]),</LI>
<LI>the second or third operand of <DEL>?:</DEL> <INS>a conditional
expression</INS> (7.6.16 [<A href="https://wg21.link/expr.cond">expr.cond</A>]),</LI>
<LI>the operand of a typeid expression
(7.6.1.8 [<A href="https://wg21.link/expr.typeid">expr.typeid</A>]),</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.3.12 [<A href="https://wg21.link/conv.ptr#1">conv.ptr</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A <I>null pointer constant</I> is <DEL>an</DEL> <INS>a (possibly
parenthesized)</INS> integer literal (5.13.2 [<A href="https://wg21.link/lex.icon">lex.icon</A>])
with value zero or a prvalue of type std::nullptr_t. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change 7.5.4 [<A href="https://wg21.link/expr.prim.paren#1">expr.prim.paren</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A parenthesized expression (E) is a primary expression whose type,
result, and value category are identical to those of E. <INS>The
parenthesized expression is a bit-field if E is a bit-field. If (E) is
a discarded-value expression (7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>]), so is
E.</INS>
<DEL>The parenthesized expression can be used in
exactly the same contexts as those where E can be used, and with the
same meaning, except as otherwise indicated.</DEL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.5.5.5 [<A href="https://wg21.link/expr.prim.id.dtor#2">expr.prim.id.dtor</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If the <I>id-expression</I> names a pseudo-destructor, T shall be a
scalar type and the <I>id-expression</I> shall appear as the right
operand of a class member access (7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]) that
forms the <INS>(possibly parenthesized)</INS>
<I>postfix-expression</I> of a function call
(7.6.1.3 [<A href="https://wg21.link/expr.call">expr.call</A>]).

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.5.1 [<A href="https://wg21.link/class.union.general#5">class.union.general</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

When the left operand of an assignment operator involves a member
access expression (7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]) that nominates a
union member, it may begin the lifetime of that union member, as
described below. For an expression E, define the set S(E) of
subexpressions of E as follows:
<UL>
<LI class="ins">If E is of the form (A), S(E) is S(A).</LI>
<LI>If E is of the form A.B, S(E) contains the elements of S(A), and
also contains A.B if B names a union member of a non-class, non-array
type, or of a class type with a trivial default constructor that is
not deleted, or an array of such types.</LI>
<LI>If E is of the form A[B] and is interpreted as a built-in array
subscripting operator, S(E) is S(A) if A is of array type, S(B) if B
is of array type, and empty otherwise.</LI>
<LI>Otherwise, S(E) is empty.</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.9.6 [<A href="https://wg21.link/class.copy.elision#1">class.copy.elision</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

This elision of object creation, called copy elision, is permitted in
the following circumstances (which may be combined to eliminate
multiple copies):
<UL>
<LI>in a return statement (8.8.4 [<A href="https://wg21.link/stmt.return">stmt.return</A>]) in a function
with a class return type, when the expression is the <INS>(possibly
parenthesized)</INS> name of a non-volatile object o with automatic
storage duration (other than a function parameter or a variable
introduced by the <I>exception-declaration</I> of a handler
(14.4 [<A href="https://wg21.link/except.handle">except.handle</A>])), the copy-initialization of the result
object can be omitted by constructing o directly into the function
call's result object;
</LI>
<LI>in a <I>throw-expression</I> (7.6.18 [<A href="https://wg21.link/expr.throw">expr.throw</A>]), when
the operand is the <INS>(possibly parenthesized)</INS> name of a
non-volatile object o with automatic storage duration (other than a
function parameter or a variable introduced by
the <I>exception-declaration</I> of a handler ) that belongs to a
scope that does not contain the innermost
enclosing <I>compound-statement</I> associated with a <I>try-block</I>
(if there is one), the copy-initialization of the exception object can
be omitted by constructing o directly into the exception object;
</LI>
<LI>in a coroutine (9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]), ...;
</LI>
<LI>when the <I>exception-declaration</I> of a handler
(14.4 [<A href="https://wg21.link/except.handle">except.handle</A>]) declares an object o, ...
</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.2.2.2.1 [<A href="https://wg21.link/over.match.call.general#1">over.match.call.general</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

In a function call (7.6.1.3 [<A href="https://wg21.link/expr.call">expr.call</A>])
<PRE>
   postfix-expression ( expression-list<SUB>opt</SUB> )
</PRE>
if the <I>postfix-expression</I> <DEL>names at least one function or
function template</DEL> <INS>is an overload set</INS>, overload
resolution is applied as specified in
12.2.2.2.2 [<A href="https://wg21.link/over.call.func">over.call.func</A>]. If the <I>postfix-expression</I>
denotes an object of class type, overload resolution is applied as
specified in 12.2.2.2.3 [<A href="https://wg21.link/over.call.object">over.call.object</A>].

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.2.2.2.2 [<A href="https://wg21.link/over.call.func#1">over.call.func</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Of interest in 12.2.2.2.2 [<A href="https://wg21.link/over.call.func">over.call.func</A>] are only those function
calls in which the <I>postfix-expression</I> <DEL>ultimately contains
an <I>id-expression</I> that denotes one or more
functions</DEL> <INS>is an overload set</INS>. Such
a <I>postfix-expression</I>, perhaps nested arbitrarily deep in
parentheses, has one of the following forms: ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.3 [<A href="https://wg21.link/over.over#1">over.over</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

An <DEL><I>id-expression</I> whose</DEL> <INS>expression E designates
the <I>address of an overload set</I> S if E is</INS>
<UL class="ins">
<LI>an <I>id-expression</I>, or</LI>
<LI>of the form <TT>&amp; <I>X</I></TT>, where <I>X</I> is a (possibly
parenthesized) <I>id-expression</I>, or</LI>
<LI>of the form <TT>( <I>X</I> )</TT>, where <I>X</I> is one of these
expressions,</LI>
</UL>
<INS>where the</INS> terminal name <INS>of the
<I>id-expression</I> </INS>refers to an overload set S
and <DEL>that</DEL> <INS>E</INS> appears without arguments<INS>.  Such
an expression</INS> is resolved to a function, a pointer to function,
or a pointer to member function for a specific function that is chosen
from a set of functions selected from S determined based on the target
type required in the context (if any), as described below. The target
can be ....  If the target type contains a placeholder type,
placeholder type deduction is performed
(9.2.9.7.2 [<A href="https://wg21.link/dcl.type.auto.deduct">dcl.type.auto.deduct</A>]), and the remainder of this subclause
uses the target type so deduced. <DEL>The <I>id-expression</I> can be
preceded by the &amp; operator.</DEL>
<DEL>[<I>Note 1:</I> Any redundant set of parentheses surrounding the
function name is ignored (7.5.4 [<A href="https://wg21.link/expr.prim.paren">expr.prim.paren</A>]). &#8212;<I>end
note</I>]</DEL>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 12.3 [<A href="https://wg21.link/over.over#6">over.over</A>] paragraph 6 as follows:</P>

<PRE>
  int f(double);
  int f(int);
  int (*pfd)(double) = &amp;f;         //<SPAN CLASS="cmnt"> selects f(double)</SPAN>
  int (*pfi)(int) = <INS>(((</INS>&amp;f<INS>)))</INS>;      //<SPAN CLASS="cmnt"> selects f(int)</SPAN>
  ...
</PRE>
</LI>

<LI>
<P>Change in 13.7.6.1 [<A href="https://wg21.link/temp.spec.partial.general#8">temp.spec.partial.general</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

A non-type argument is non-specialized if it is
the <INS>unparenthesized</INS> name of a non-type parameter. All other
non-type arguments are specialized.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#8">temp.deduct.type</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

... [<I>Note 3:</I> If a type matches such a form but contains no Ts, is,
or TTs, deduction is not possible. &#8212;<I>end note</I>] Similarly,
&lt;T&gt; represents template argument lists where at least one
argument contains a T, &lt;i&gt; represents template argument lists
where at least one argument contains an i and &lt;&gt; represents
template argument lists where no argument contains a T or an i.
<INS>[ Note: If a non-type template parameter is parenthesized,
deduction is not possible.  [ Example:</INS>
<PRE class="ins">
  template&lt;int N&gt; struct X {};
  template&lt;int N&gt; void f(X&lt;(N)&gt;);   //<SPAN CLASS="cmnt"> #1</SPAN>
  void g() { f(X&lt;0&gt;()); }           //<SPAN CLASS="cmnt"> error: cannot deduce </SPAN>N<SPAN CLASS="cmnt"> in #1</SPAN>
</PRE>
<INS>-- end example ] -- end note ]</INS>
</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2972"></A><H4>2972.
  
Declarative <I>nested-name-specifier</I> naming a partial specialization
</H4>
<B>Section: </B>7.5.5.3&#160; [<A href="https://wg21.link/expr.prim.id.qual">expr.prim.id.qual</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2024-12-20<BR>




<P>Consider:</P>

<PRE>
  template &lt;auto AX&gt; struct A;
  template &lt;int AX&gt; struct A&lt;AX&gt; {
   static constexpr int X = AX;
  };
  template &lt;int AX&gt; const int A&lt;AX&gt;::X;   //<SPAN CLASS="cmnt"> #1</SPAN>
</PRE>

<P>According to 7.5.5.3 [<A href="https://wg21.link/expr.prim.id.qual#3">expr.prim.id.qual</A>] paragraph 3, the
declarative <I>nested-name-specifier</I> at #1 names the primary
template and is thus ill-formed:</P>

<BLOCKQUOTE>

... If a <I>nested-name-specifier</I> N is declarative and has
a <I>simple-template-id</I> with a template argument list A that
involves a template parameter, let T be the template nominated by N
without A. T shall be a class template.
<UL>
<LI>If A is the template
argument list (13.4 [<A href="https://wg21.link/temp.arg">temp.arg</A>]) of the
corresponding <I>template-head</I> H (13.7.3 [<A href="https://wg21.link/temp.mem">temp.mem</A>]), N
nominates the primary template of T ; H shall be equivalent to
the <I>template-head</I> of T (13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]).</LI>
<LI>Otherwise, N nominates the partial specialization
(13.7.6 [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]) of T whose template argument list is
equivalent to A (13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]); the program is
ill-formed if no such partial specialization exists.</LI>
</UL>

</BLOCKQUOTE>

<P>However, the <I>qualified-id</I> is obviously intended to refer a
member of the partial specialization.</P>

<P>Furthermore, the specification does not handle references to
constrained partial specializations:</P>

<PRE>
  template &lt;typename T&gt; struct A;
  template &lt;typename T&gt; concept C = true;

  template &lt;typename T&gt;
  requires C&lt;T&gt;
  struct A&lt;T *&gt; {
    struct B;
  };

  template &lt;typename T&gt;
  requires true &amp;&amp; C&lt;T&gt;
  struct A&lt;T *&gt; {
    struct B;                   //<SPAN CLASS="cmnt"> #1</SPAN>
  };

  template &lt;typename T&gt;
  requires true &amp;&amp; C&lt;T&gt;
  struct A&lt;T *&gt;::B {};         //<SPAN CLASS="cmnt"> ought to refer to #1</SPAN>
</PRE>

<BR><BR><HR>
<A NAME="2473"></A><H4>2473.
  
Parentheses in pseudo-destructor calls
</H4>
<B>Section: </B>7.5.5.5&#160; [<A href="https://wg21.link/expr.prim.id.dtor">expr.prim.id.dtor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2020-12-15<BR>


<P>According to 7.5.5.5 [<A href="https://wg21.link/expr.prim.id.dtor#2">expr.prim.id.dtor</A>] paragraph 2,</P>

<BLOCKQUOTE>

If the <I>id-expression</I> names a
pseudo-destructor, <TT>T</TT> shall be a scalar type and
the <I>id-expression</I> shall appear as the right operand
of a class member access (7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]) that
forms the <I>postfix-expression</I> of a function call
(7.6.1.3 [<A href="https://wg21.link/expr.call">expr.call</A>]).

</BLOCKQUOTE>

<P>This would appear to make the following example
ill-formed, because it is the parenthesized expression and
not the class member access that is
the <I>postfix-expression</I> in the function call:</P>

<PRE>
  typedef int T;
  void f(int* p) {
    (p-&gt;~T)();   //<SPAN CLASS="cmnt"> Ill-formed?</SPAN>
  }
</PRE>

<P>Presumably this is an oversight.</P>

<BR><BR><HR>
<A NAME="2565"></A><H4>2565.
  
Invalid types in the <I>parameter-declaration-clause</I> of a <I>requires-expression</I>
</H4>
<B>Section: </B>7.5.8.1&#160; [<A href="https://wg21.link/expr.prim.req.general">expr.prim.req.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2022-04-07
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>Consider:</P>

<PRE>
  template &lt;typename T&gt;
  concept C = requires (typename T::type x) {
    x + 1;
  };

  static_assert(!C&lt;int&gt;);
</PRE>

<P>All implementations accept this translation unit.  However, the
rule in 7.5.8.1 [<A href="https://wg21.link/expr.prim.req.general#5">expr.prim.req.general</A>] paragraph 5 does not cover
the <I>parameter-declaration-clause</I>::</P>

<BLOCKQUOTE>

The substitution of template arguments into
a <I>requires-expression</I> may result in the formation of invalid
types or expressions in its requirements or the violation of the
semantic constraints of those requirements. In such cases,
the <I>requires-expression</I> evaluates to <CODE>false</CODE>; it
does not cause the program to be ill-formed. The substitution and
semantic constraint checking proceeds in lexical order and stops when
a condition that determines the result of
the <I>requires-expression</I> is encountered. If substitution (if
any) and semantic constraint checking succeed,
the <I>requires-expression</I> evaluates to <CODE>true</CODE>.

</BLOCKQUOTE>

<P><B>Proposed resolution (approved by CWG 2023-06-17):</B></P>

<P>Change in 7.5.8.1 [<A href="https://wg21.link/expr.prim.req.general#5">expr.prim.req.general</A>] paragraph 5:</P>

<BLOCKQUOTE>

The substitution of template arguments into
a <I>requires-expression</I> may result in the formation of invalid
types or expressions in <INS>its <I>parameter-declaration-clause</I>
(if any) or</INS> its requirements or the violation of the semantic
constraints of those requirements. In such cases, ...

</BLOCKQUOTE>

<P><B>CWG 2023-11-09</B></P>

<P>The initial example is not the point of the issue, but the very
similar following case:</P>

<PRE>
  template &lt;typename T&gt;
  constexpr bool b = requires (T::type x) { x + 1; };

  static_assert(!b&lt;int&gt;);  //<SPAN CLASS="cmnt"> de-jure ill-formed, but widely accepted by implementations</SPAN>
</PRE>

<P>Users were vocal they wanted this not to be an error, but just a
substitution failure. Reportedly, the original design intent was that
this situation is a hard error, though.</P>

<P>Soliciting guidance from EWG how to handle this issue via
<A HREF="https://github.com/cplusplus/papers/issues/1695">paper issue 1695</A>.</P>

<P><B>EWG 2024-03-18</B></P>

<P>EWG invites a paper to propose a change.</P>

<BR><BR><HR>
<A NAME="3056"></A><H4>3056.
  
Missing semicolons in grammar for <I>type-requirement</I>
</H4>
<B>Section: </B>7.5.8.3&#160; [<A href="https://wg21.link/expr.prim.req.type">expr.prim.req.type</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Peter Bindels
 &#160;&#160;&#160;

 <B>Date: </B>2025-08-14<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/751">#751</A>.)</P>

<P>These lines in the example in 7.5.8.3 [<A href="https://wg21.link/expr.prim.req.type#1">expr.prim.req.type</A>] paragraph 1
are not covered by the grammar:</P>

<PRE>
  typename [:T::r1:];        //<SPAN CLASS="cmnt"> fails if T::r1 is not a reflection of a type</SPAN>
  typename [:T::r2:]&lt;int&gt;;   //<SPAN CLASS="cmnt"> fails if T::r2 is not a reflection of a template Z for which Z&lt;int&gt; is a type</SPAN>
</PRE>

<P><U>Suggested resolution:</U></P>

<P>Change in 7.5.8.3 [<A href="https://wg21.link/expr.prim.req.type#1">expr.prim.req.type</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>
<PRE>
  <I>type-requirement</I>:
    typename <I>nested-name-specifier</I><SUB>opt</SUB> <I>type-name</I> ;
    typename <I>splice-specifier</I> <INS>;</INS>
    typename <I>splice-specialization-specifier</I> <INS>;</INS>
</PRE>
</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2739"></A><H4>2739.
  
Nested requirement not a constant expression
</H4>
<B>Section: </B>7.5.8.5&#160; [<A href="https://wg21.link/expr.prim.req.nested">expr.prim.req.nested</A>]
 &#160;&#160;&#160;

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

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

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


<P>Consider:</P>

<PRE>
  struct NonConstant { static bool f() { return true; } };
  struct True { static constexpr bool f() { return true; } };
  struct False { static constexpr bool f() { return false; } };

  template &lt;class T&gt;
  concept C = requires { requires T::f(); };

  static_assert(!C&lt;NonConstant&gt;);   //<SPAN CLASS="cmnt"> #1</SPAN>
  static_assert(C&lt;True&gt;);
  static_assert(!C&lt;False&gt;);
</PRE>

<P>clang accepts; gcc, MSVC, and EDG all consider #1 to be ill-formed.
Subclause 7.5.8.5 [<A href="https://wg21.link/expr.prim.req.nested#1">expr.prim.req.nested</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

The <I>constraint-expression</I> shall be satisfied
(13.5.3 [<A href="https://wg21.link/temp.constr.decl">temp.constr.decl</A>]) by the substituted template arguments,
if any. Substitution of template arguments into
a <I>nested-requirement</I> does not result in substitution into
the <I>constraint-expression</I> other than as specified in
13.5.2 [<A href="https://wg21.link/temp.constr.constr">temp.constr.constr</A>].

</BLOCKQUOTE>

<P>Neither <TT>C&lt;NonConstant&gt;</TT> nor <TT>C&lt;False&gt;</TT>
are saisfied, but it is unclear whether those two cases should be
treated differently.  Subclause 13.5.2.3 [<A href="https://wg21.link/temp.constr.atomic#3">temp.constr.atomic</A>] paragraph 3
might be relevant:</P>

<BLOCKQUOTE>

To determine if an atomic constraint is <I>satisfied</I>, the
parameter mapping and template arguments are first substituted into
its expression. If substitution results in an invalid type or
expression, the constraint is not satisfied. Otherwise, the
lvalue-to-rvalue conversion (7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]) is performed
if necessary, and E shall be a constant expression of type bool.

</BLOCKQUOTE>

<P>An example from the standard library is:</P>

<PRE>
  template&lt;class G&gt;
   concept uniform_random_bit_generator =
     invocable&lt;G&amp;&gt; &amp;&amp; unsigned_integral&lt;invoke_result_t&lt;G&amp;&gt;&gt; &amp;&amp;
     requires {
       { G::min() } -&gt; same_as&lt;invoke_result_t&lt;G&amp;&gt;&gt;;
       { G::max() } -&gt; same_as&lt;invoke_result_t&lt;G&amp;&gt;&gt;;
       requires bool_constant&lt;(G::min() &lt; G::max())&gt;::value;
    };
</PRE>

<P>Is the <TT>bool_constant</TT> part necessary to ensure
that <TT>G::min() &lt; G::max()</TT> is a constant expression?</P>

<BR><BR><HR>
<A NAME="2284"></A><H4>2284.
  
Sequencing of <I>braced-init-list</I> arguments
</H4>
<B>Section: </B>7.6.1.3&#160; [<A href="https://wg21.link/expr.call">expr.call</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2016-06-30<BR>




<P>As of
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0400r0.html">P0400R0</A>
(Wording for Order of Evaluation of Function Arguments),
we have in subclause 7.6.1.3 [<A href="https://wg21.link/expr.call#8">expr.call</A>] paragraph 8:</P>

<BLOCKQUOTE>

The <I>postfix-expression</I> is sequenced before each expression in
the <I>expression-list</I> and any default argument. The
initialization of a parameter, including every associated value
computation and side effect, is indeterminately sequenced with respect
to that of any other parameter.

</BLOCKQUOTE>

<P>What about the case when the element in the <I>expression-list</I> is
a <I>braced-init-list</I> rather than an expression?
The <I>braced-init-list</I> is certainly evaluated left-to-right, but
is that required to happen after we evaluate
the <I>postfix-expression</I>?
</P>

<BR><BR><HR>
<A NAME="2515"></A><H4>2515.
  
Result of a function call
</H4>
<B>Section: </B>7.6.1.3&#160; [<A href="https://wg21.link/expr.call">expr.call</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Andrey Erokhin
 &#160;&#160;&#160;

 <B>Date: </B>2021-11-06<BR>


<P>The editorial change referred to in the resolution of
<A HREF="cwg_active.html#2495">issue 2495</A> updated the
terminology used to describe the <TT>return</TT> statement
to allow for the fact that the operand could be a
<I>braced-init-list</I> instead of an expression. A similar
problem exists describing the result of a function call in
7.6.1.3 [<A href="https://wg21.link/expr.call#9">expr.call</A>] paragraph 9:</P>

<BLOCKQUOTE>

The result of a function call is the result of the possibly-converted
operand of the <TT>return</TT> statement (8.8.4 [<A href="https://wg21.link/stmt.return">stmt.return</A>]) that
transferred control out of the called function

</BLOCKQUOTE>

<P>It's incorrect to refer to &#8220;converting&#8221; the
operand when it is a <I>braced-init-list</I>.</P>

<BR><BR><HR>
<A NAME="2660"></A><H4>2660.
  
Confusing term "this parameter"
</H4>
<B>Section: </B>7.6.1.3&#160; [<A href="https://wg21.link/expr.call">expr.call</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Anoop Rana
 &#160;&#160;&#160;

 <B>Date: </B>2022-11-23<BR>




<P>Subclause 7.6.1.3 [<A href="https://wg21.link/expr.call#7">expr.call</A>] paragraph 7 specifies:</P>

<BLOCKQUOTE>

If the function is an implicit object member function,
the <TT>this</TT> parameter of the function
(7.5.3 [<A href="https://wg21.link/expr.prim.this">expr.prim.this</A>]) is initialized with a pointer to the
object of the call, converted as if by an explicit type conversion
(7.6.3 [<A href="https://wg21.link/expr.cast">expr.cast</A>]).

</BLOCKQUOTE>

<P>The term "<TT>this</TT> parameter" is undefined.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 7.6.1.3 [<A href="https://wg21.link/expr.call#7">expr.call</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

If the function is an implicit object member function,
the <DEL><TT>this</TT></DEL> <INS>implicit object</INS> parameter of
the function (7.5.3 [<A href="https://wg21.link/expr.prim.this">expr.prim.this</A>]) is initialized with a
pointer to the object of the call, converted as if by an explicit type
conversion (7.6.3 [<A href="https://wg21.link/expr.cast">expr.cast</A>]).

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2688"></A><H4>2688.
  
Calling explicit object member functions
</H4>
<B>Section: </B>7.6.1.3&#160; [<A href="https://wg21.link/expr.call">expr.call</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Matthew House
 &#160;&#160;&#160;

 <B>Date: </B>2023-01-16<BR>


<P>Subclause 7.6.1.3 [<A href="https://wg21.link/expr.call">expr.call</A>] paragraphs 1 and 2 do not
properly handle explicit object member functions.  Such a function can
be called via a function pointer, via an lvalue obtained by
dereferencing a function pointer, and via a class member access
expression.</P>

<BR><BR><HR>
<A NAME="3054"></A><H4>3054.
  
Use of default arguments depending on shape of <I>postfix-expression</I> in a function call
</H4>
<B>Section: </B>7.6.1.3&#160; [<A href="https://wg21.link/expr.call">expr.call</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Benjamin Sch.
 &#160;&#160;&#160;

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


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/744">#744</A>.)</P>

<P>Consider:</P>

<PRE>
  void f(int = 0) {}

  void g() {
    f();          // accepted by all
    (&amp;f)();       // accepted by EDG and clang, rejected by GCC and MSVC
    (*f)();       // accepted by EDG and MSVC, rejected by GCC and clang 
    (0, f)();     // accepted by EDG, rejected by MSVC, GCC and clang
    static_cast&lt;void(&amp;)(int)&gt;(f)();  // accepted by MSVC, rejected by EDG, GCC, and clang
    static_cast&lt;void(*)(int)&gt;(f)();  // rejected by all

    auto p = f;
    p();          // rejected by all
  }
</PRE>

<P>It seems reasonably clear from 12.2.2.2.1 [<A href="https://wg21.link/over.match.call.general">over.match.call.general</A>] that
only the first two cases involve overload resolution for a function
call; the rest does not.  Default arguments are only considered when
overload resolution for a function call selected the function;
7.6.1.3 [<A href="https://wg21.link/expr.call#6">expr.call</A>] paragraph 6 should be clarified.</P>

<P><U>Possible resolution:</U></P>

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

<OL>
<LI>

<P>Change in 7.6.1.3 [<A href="https://wg21.link/expr.call#6">expr.call</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

When a function is called, each parameter
(9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]) is initialized
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>], 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]) with its
corresponding argument, and each precondition assertion of the
function is evaluated (9.4.1 [<A href="https://wg21.link/dcl.contract.func">dcl.contract.func</A>]). If the function is
an explicit object member function and there is an implied object
argument (12.2.2.2.2 [<A href="https://wg21.link/over.call.func">over.call.func</A>]), the list of provided
arguments is preceded by the implied object argument for the purposes
of this correspondence. If <INS>the function to be called is selected
by overload resolution (12.2.2.2.1 [<A href="https://wg21.link/over.match.call.general">over.match.call.general</A>]) and</INS>
there is no corresponding argument, the default argument for the
parameter is used. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.2.2.2.1 [<A href="https://wg21.link/over.match.call.general#2">over.match.call.general</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If the <I>postfix-expression</I> <INS>is of the (possibly
parenthesized) form <TT>&amp; <I>primary-expression</I></TT>, where
the <I>primary-expression</I> is a possibly-parenthesized
<I>id-expression</I> or <I>splice-expression</I> and</INS> is <DEL>the
address of</DEL> an overload set, overload resolution is applied using
that set as described above. ...

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="914"></A><H4>914.
  
Value-initialization of array types
</H4>
<B>Section: </B>7.6.1.4&#160; [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>10 June, 2009
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Although value-initialization is defined for array types and the
<TT>()</TT> initializer is permitted in a <I>mem-initializer</I>
naming an array member of a class, the syntax <TT>T()</TT> (where
<TT></TT> is an array type) is explicitly forbidden by
7.6.1.4 [<A href="https://wg21.link/expr.type.conv#2">expr.type.conv</A>] paragraph 2.  This is inconsistent and
the syntax should be permitted.</P>

<P>Rationale (July, 2009):</P>

<P>The CWG was not convinced of the utility of this extension, especially
in light of questions about handling the lifetime of temporary arrays.
This suggestion needs a proposal and analysis by the EWG before it can be
considered by the CWG.</P>

<P><B>EWG 2022-11-11</B></P>

<P>This is a defect; a paper is needed.
This is tracked in github issue
<A HREF="https://github.com/cplusplus/papers/issues/1372">cplusplus/papers#1372</A>.</P>

<BR><BR><HR>
<A NAME="2705"></A><H4>2705.
  
Accessing ambiguous subobjects
</H4>
<B>Section: </B>7.6.1.5&#160; [<A href="https://wg21.link/expr.ref">expr.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Davis Herring
 &#160;&#160;&#160;

 <B>Date: </B>2023-02-11<BR>


<P>Consider:</P>

<PRE>
  struct A {int i;};
  struct X : A {};
  struct Y : A {};
  struct S : X,Y {};

  void f(S &amp;s) {++s.X::i;}
</PRE>

<P>There is a rule that <TT>&amp;s</TT> be able to "be implicitly
converted to a pointer to the naming class of the right operand"
(11.8.3 [<A href="https://wg21.link/class.access.base#6">class.access.base</A>] paragraph 6), which correctly
selects <TT>X</TT> here, but 7.6.1.5 [<A href="https://wg21.link/expr.ref#6.2">expr.ref</A>] bullet 6.2
merely says that</P>

<BLOCKQUOTE>

If E2 is a non-static data member [...], the expression designates the
corresponding member subobject of the object designated by the first
expression.

</BLOCKQUOTE>

<P>
<TT>E2</TT> (i.e. <TT>X::i</TT>) and <TT>Y::i</TT> equally
denote <TT>A::i</TT> (since name lookup produces declarations), but
there is no rule that indicates which <TT>A::i</TT> is selected as the
"corresponding member subobject". (Note that <TT>s.X::A::i</TT> means
the same as <TT>s.A::i</TT> and is ambiguous.)</P>

<P><U>Suggested resolution:</U></P>

<P>Change 11.8.3 [<A href="https://wg21.link/class.access.base#6">class.access.base</A>] paragraph 6 to actually perform the
conversion it requires, possibly moving it to
7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>] since it is not about access control; the
definition of "naming class" in 11.8.3 [<A href="https://wg21.link/class.access.base#5">class.access.base</A>] paragraph 5
would then need to be italicized.</P>

<BR><BR><HR>
<A NAME="2957"></A><H4>2957.
  
Evaluating a reference member should constitute access
</H4>
<B>Section: </B>7.6.1.5&#160; [<A href="https://wg21.link/expr.ref">expr.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2024-11-06<BR>


<P>(From submissions
<A HREF="https://github.com/cplusplus/CWG/issues/634">#634</A> and
<A HREF="https://github.com/cplusplus/CWG/issues/637">#637</A>.)
</P>

<P>The standard permits that references do not occupy storage.  The
term "access" (3.1 [<A href="https://wg21.link/defns.access">defns.access</A>]) is not applicable to
references.  Yet, references can participate in data races
(6.10.1 [<A href="https://wg21.link/intro.execution#10">intro.execution</A>] paragraph 10, 6.10.2.2 [<A href="https://wg21.link/intro.races#2">intro.races</A>] paragraph 2).  For example:</P>

<PRE>
  int x, y;
  struct S {
    int &amp;r;
  } s{x};

  void thread_1() {
    new (&amp;s) S{y};   //<SPAN CLASS="cmnt"> transparent replacement</SPAN>
  }

  void thread_2() {
    auto&amp; r = s.r; //<SPAN CLASS="cmnt"> OK ?! Refers to x or y?</SPAN>
  }
</PRE>

<P>Also consider the impact on constant evaluation:</P>

<PRE>
  int n{};
  struct S { int&amp; r; };
  constexpr S s{n};
  constexpr volatile S s2{n};

  static_assert(&amp;static_cast&lt;const volatile S&amp;&gt;(s).r == &amp;n); //<SPAN CLASS="cmnt"> GCC rejects</SPAN>
  static_assert(&amp;s2.r == &amp;n); //<SPAN CLASS="cmnt"> GCC and Clang reject</SPAN>
</PRE>



<BR><BR><HR>
<A NAME="2959"></A><H4>2959.
  
Naming enumerators in class member access expressions
</H4>
<B>Section: </B>7.6.1.5&#160; [<A href="https://wg21.link/expr.ref">expr.ref</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2024-11-04<BR>




<P>While lookup for a member enumerator is supported using class
member access syntax (7.6.1.5 [<A href="https://wg21.link/expr.ref#7.5">expr.ref</A>] bullet 7.5, the
following example from 9.8.2 [<A href="https://wg21.link/enum.udecl#2">enum.udecl</A>] paragraph 2 is
ill-formed:</P>

<PRE>
  enum class fruit { orange, apple };
  struct S {
   using enum fruit;       //<SPAN CLASS="cmnt"> OK, introduces </SPAN>orange<SPAN CLASS="cmnt"> and </SPAN>apple<SPAN CLASS="cmnt"> into </SPAN>S
  };
  void f() {
   S s;
   <U>s.orange;           //<SPAN CLASS="cmnt"> OK, names </SPAN>fruit::orange</U>
   S::orange;          //<SPAN CLASS="cmnt"> OK, names </SPAN>fruit::orange
  }
</PRE>

<P>Additional examples to consider:</P>

<PRE>
  enum class fruit { orange };
  struct S { using fruit::orange; } s;
  auto a = s.S::orange; //<SPAN CLASS="cmnt"> OK?</SPAN>
  auto b = s.fruit::orange; //<SPAN CLASS="cmnt"> OK?</SPAN>
  struct T { using fruit::orange; } t;
  auto c = s.T::orange; //<SPAN CLASS="cmnt"> OK?</SPAN>
</PRE>

<P>"Using enum" was introduced by paper
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r5.html">P1099R5</A>.</P>

<P>
<A HREF="cwg_active.html#2557">Issue 2557</A> makes the original example
well-formed, but none of the qualified additional examples.</P>

<BR><BR><HR>
<A NAME="742"></A><H4>742.
  
Postfix increment/decrement with long bit-field operands
</H4>
<B>Section: </B>7.6.1.6&#160; [<A href="https://wg21.link/expr.post.incr">expr.post.incr</A>]
 &#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> (7.6.1.6 [<A href="https://wg21.link/expr.post.incr">expr.post.incr</A>]), which means that the usual arithmetic conversions
(Clause 7 [<A href="https://wg21.link/expr#10">expr</A>] 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 (7.3.7 [<A href="https://wg21.link/conv.prom#3">conv.prom</A>] 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>7.6.1.8&#160; [<A href="https://wg21.link/expr.typeid">expr.typeid</A>]
 &#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>
(7.6.1.8 [<A href="https://wg21.link/expr.typeid#1">expr.typeid</A>] 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="2048"></A><H4>2048.
  
C-style casts that cast away constness vs <TT>static_cast</TT>
</H4>
<B>Section: </B>7.6.1.9&#160; [<A href="https://wg21.link/expr.static.cast">expr.static.cast</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-11-19<BR>




<P>According to 7.6.1.9 [<A href="https://wg21.link/expr.static.cast#1">expr.static.cast</A>] paragraph 1,</P>

<BLOCKQUOTE>

The <TT>static_cast</TT> operator shall not cast away constness
(7.6.1.11 [<A href="https://wg21.link/expr.const.cast">expr.const.cast</A>]).

</BLOCKQUOTE>

<P>However, this phrasing is problematic in the context of a
C-style cast like the following:</P>

<PRE>
   const void *p;
   int *q = (int*)p;
</PRE>

<P>The intent of 7.6.3 [<A href="https://wg21.link/expr.cast">expr.cast</A>] is that this should be
interpreted as a <TT>static_cast</TT> followed by a
<TT>const_cast</TT>.  However, because <TT>int*</TT> to
<TT>const void*</TT> is a valid standard conversion, and
7.6.1.9 [<A href="https://wg21.link/expr.static.cast#7">expr.static.cast</A>] paragraph 7 allows <TT>static_cast</TT>
to perform the inverse of a standard conversion sequence, the
C-style cast is interpreted as just a <TT>static_cast</TT> without
a <TT>const_cast</TT> and is thus ill-formed.</P>

<BR><BR><HR>
<A NAME="3026"></A><H4>3026.
  
Class for pointer-to-member formation
</H4>
<B>Section: </B>7.6.2.2&#160; [<A href="https://wg21.link/expr.unary.op">expr.unary.op</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2025-05-11<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/705">#705</A>.)</P>

<P>Consider:</P>

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

  template &lt;typename&gt; struct Q;
  template &lt;&gt; struct Q&lt;A&gt; {};
  template &lt;typename T&gt; Q&lt;T&gt; f(int T::*);

  Q&lt;A&gt; g() { return f(&amp;B::x); }  // OK
  Q&lt;A&gt; h() { return f(&amp;B::y); }  // OK
</PRE>

<P>For both cases, the pointer to member is of type "pointer to member
of class <TT>A</TT>", but the wording is not clear.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 7.6.2.2 [<A href="https://wg21.link/expr.unary.op#3.1">expr.unary.op</A>] bullet 3.1 as follows:</P>

<BLOCKQUOTE>

The operand of the unary &amp; operator shall be an lvalue of some
type T.
<UL>
<LI>If the operand is a <I>qualified-id</I> naming a
non-static <DEL>or variant</DEL> <INS>class</INS> member <TT>m</TT> <DEL>of some class C</DEL>, other than an explicit
object member function, <INS>then let <TT>C</TT> be
the class, that is not an anonymous union, of which <TT>m</TT> is
a direct member.</INS>
<DEL>the</DEL> <INS>The</INS> result has type &#8220;pointer to member
of class C of type T&#8221; and designates C::m.
<INS>[Note: A <I>qualified-id</I> that names a member of a
namespace-scope anonymous union is considered to be a class member
access expression (7.5.5.1 [<A href="https://wg21.link/expr.prim.id.general">expr.prim.id.general</A>]) and thus cannot be
used to form a pointer to member.-- end note]</INS>
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2609"></A><H4>2609.
  
Padding in class types
</H4>
<B>Section: </B>7.6.2.5&#160; [<A href="https://wg21.link/expr.sizeof">expr.sizeof</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2022-07-19<BR>


<P>Class types may have padding, influencing the result
of <TT>sizeof</TT>.  It is unclear whether the placement and amount of
padding is implementation-defined, unspecified, or something else.  If
it is unspecified, the limits of permissible behavior are unclear.
Empty classes might need special consideration.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 7.6.2.5 [<A href="https://wg21.link/expr.sizeof#2">expr.sizeof</A>] paragraph 2</P>

<BLOCKQUOTE>

... When applied to a class, the result is the number of bytes in an
object of that class including any padding required for placing
objects of that type in an array.
<INS>The amount and placement of padding in a class type is unspecified.</INS>
The result of applying sizeof to a
potentially-overlapping subobject is the size of the type, not the
size of the subobject. [ Footnote: ... ]

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2817"></A><H4>2817.
  
sizeof(abstract class) is underspecified
</H4>
<B>Section: </B>7.6.2.5&#160; [<A href="https://wg21.link/expr.sizeof">expr.sizeof</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2023-02-23<BR>


<P>Subclause 7.6.2.5 [<A href="https://wg21.link/expr.sizeof#1">expr.sizeof</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

The sizeof operator yields the number of bytes occupied by a
non-potentially-overlapping object of the type of its operand. The
operand is either an expression, which is an unevaluated operand
(7.2.3 [<A href="https://wg21.link/expr.context">expr.context</A>]), or a parenthesized <I>type-id</I>. ...

</BLOCKQUOTE>

<P>Since an abstract class can be used only in a situation where it is
a potentially-overlapping object, it is unclear what its size is.</P>

<BR><BR><HR>
<A NAME="267"></A><H4>267.
  
Alignment requirement for <I>new-expression</I>s
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#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 7.6.2.8 [<A href="https://wg21.link/expr.new#10">expr.new</A>] 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 (6.9 [<A href="https://wg21.link/basic.types">basic.types</A>])
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
7.6.1.10 [<A href="https://wg21.link/expr.reinterpret.cast#7">expr.reinterpret.cast</A>] 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
<INS><TT>T1</TT> are an integer multiple of those of <TT>T2</TT></INS>)
and back to its original type yields the original pointer value...

</BLOCKQUOTE>

<P>The same change would also be needed in paragraph 9.</P>

<P><B>Additional note (June, 2022):</B></P>

<P>Subclause 6.8.3 [<A href="https://wg21.link/basic.align#4">basic.align</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

... Every alignment value shall be a non-negative integral power of two.

</BLOCKQUOTE>

<P>Thus, the situation that a stricter alignment is not an integral
multiple of a weaker alignment does not arise.</P>

<BR><BR><HR>
<A NAME="901"></A><H4>901.
  
Deleted <TT>operator delete</TT>
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>20 May, 2009<BR>


<P>It is not clear from 7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>] 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 6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>].)</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>

<P><B>Additional notes (April, 2023):</B></P>



<P>An additional use-case for a deleted deallocation function would be
to ensure that the initialization of the object is not
potentially-throwing.</P>

<P>For cases where the deallocation function is never called from
the constructor, access checking for it should not be done.</P>

<BR><BR><HR>
<A NAME="1628"></A><H4>1628.
  
Deallocation function templates
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-22<BR>




<P>According to 7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>] paragraphs 18-20, an
exception thrown during the initialization of an object allocated
by a <I>new-expression</I> will cause a deallocation
function to be called for the object's storage if a matching
deallocation function can be found.  The rules deal only with
functions, however; nothing is said regarding a mechanism by which
a deallocation function template might be instantiated to free the
storage, although 6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation#2">basic.stc.dynamic.deallocation</A>] paragraph 2 indicates
that a deallocation function can be an instance of a function
template.</P>

<P>One possibility for this processing might be to perform template
argument deduction on any deallocation function templates; if there
is a specialization that matches the allocation function, by the
criteria listed in paragraph 20, that function template would be
instantiated and used, although a matching non-template function would
take precedence as is the usual outcome of overloading between
function template specializations and non-template functions.</P>

<P>Another possibility might be to match non-template deallocation
functions with non-template allocation functions and template
deallocation functions with template allocation functions.</P>

<P>There is a slightly related wording problem in
7.6.2.8 [<A href="https://wg21.link/expr.new#21">expr.new</A>] paragraph 21:</P>

<BLOCKQUOTE>

If a placement deallocation function is called, it is passed the same
additional arguments as were passed to the placement allocation function,
that is, the same arguments as those specified with
the <I>new-placement</I> syntax.

</BLOCKQUOTE>

<P>This wording ignores the possibility of default arguments in the
allocation function, in which case the arguments passed to the
deallocation function might be a superset of those specified in the
<I>new-placement</I>.</P>

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

<BR><BR><HR>
<A NAME="2532"></A><H4>2532.
  
Kind of pointer value returned by <TT>new T[0]</TT>
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Andrey Erokhin
 &#160;&#160;&#160;

 <B>Date: </B>2022-02-17<BR>




<P>A pointer value must have one of the kinds specified in
6.9.4 [<A href="https://wg21.link/basic.compound#3">basic.compound</A>] paragraph 3:</P>

<BLOCKQUOTE>

Every value of pointer type is one of the following:

<UL>
<LI>a pointer to an object or function (the pointer is said to point
to the object or function), or</LI>

<LI>a pointer past the end of an object (7.6.6 [<A href="https://wg21.link/expr.add">expr.add</A>]), or</LI>

<LI>the null pointer value for that type, or</LI>

<LI>an invalid pointer value.</LI>

</UL>

</BLOCKQUOTE>

<P>When allocating an array with no elements,
7.6.2.8 [<A href="https://wg21.link/expr.new#10">expr.new</A>] paragraph 10 is silent on the kind of
pointer value returned:</P>

<BLOCKQUOTE>

When the allocated type is &#8220;array of <TT>N T</TT>&#8221; (that is,
the <I>noptr-new-declarator</I> syntax is used or
the <I>new-type-id</I> or <I>type-id</I> denotes an array type),
the <I>new-expression</I> yields a prvalue of type &#8220;pointer to
<TT>T</TT>&#8221; that points to the initial element (if any) of the
array. Otherwise, let <TT>T</TT> be the allocated type;
the <I>new-expression</I> is a prvalue of type &#8220;pointer to
<TT>T</TT>&#8221; that points to the object created.

</BLOCKQUOTE>

<P>Related to that, are <TT>p</TT> and <TT>q</TT> allowed to compare
equal in the following example?</P>

<BLOCKQUOTE>

<PRE>
T *p = new T[0];
T *q = new T;
</PRE>

</BLOCKQUOTE>

<P>Some implementations return a pointer past the array cookie for
empty arrays, which can compare equal to a pointer to an object
obtained from an unrelated allocation.  However, if <TT>new T[0]</TT>
is specified to yield a pointer to an object, this behavior violates
the rule that pointers to disjoint objects with overlapping lifetimes
must not compare equal.</P>

<BR><BR><HR>
<A NAME="2592"></A><H4>2592.
  
Missing definition for placement allocation/deallocation function
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2022-04-14<BR>


<P>Subclause 7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>] has multiple references to
"placement allocation function" and "placement deallocation function",
but those terms are never defined.  The term "usual deallocation
function" is defined in 6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation#3">basic.stc.dynamic.deallocation</A>] paragraph 3:</P>

<BLOCKQUOTE>

... A usual deallocation function is a deallocation function whose
parameters after the first are

<UL>
<LI>optionally, a parameter of type <TT>std::destroying_delete_t</TT>, then
</LI>

<LI>optionally, a parameter of type <TT>std::size_t</TT>, [ Footnote: ... ]
then</LI>

<LI>optionally, a parameter of type <TT>std::align_val_t</TT>.
</LI>
</UL>

</BLOCKQUOTE>

<P><U>Possible resolution:</U></P>

<OL>

<LI>
<P>Split 6.8.6.5.2 [<A href="https://wg21.link/basic.stc.dynamic.allocation#1">basic.stc.dynamic.allocation</A>] paragraph 1 and change it as follows:</P>

<BLOCKQUOTE>

<P>... The value of the first parameter is interpreted as the
requested size of the allocation. <INS>A <I>usual allocation
function</I> is an allocation function with no parameters after the
first or with a single parameter of type <TT>std::align_val_t</TT>
after the first.</INS>
</P>

<P>An allocation function can be a function template. ...</P>

</BLOCKQUOTE>

</LI>

</OL>

<P><B>CWG 2023-06-17</B></P>

<P>Replace "placement allocation / deallocation function" with "not a
usual allocation / deallocation function".</P>

<BR><BR><HR>
<A NAME="2812"></A><H4>2812.
  
Allocation with explicit alignment
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Tim Song
 &#160;&#160;&#160;

 <B>Date: </B>2023-10-18<BR>




<P>Consider:</P>

<PRE>
  #include &lt;new&gt;
  auto p = new (std::align_val_t{64}) T;
</PRE>

<P>Is this example well-formed for <TT>T = int</TT>?  This invokes the
allocation function</P>

<PRE>
  ::operator new(size_t, align_val_t);
</PRE>

<P>If this is considered a "placement allocation function", the code
is ill-formed per 7.6.2.8 [<A href="https://wg21.link/expr.new#28">expr.new</A>] paragraph 28, because
deallocation function lookup finds a usual deallocation function.  If
this is considered a "usual allocation function", the rules
find <TT>::operator delete(void*)</TT> as the corresponding
deallocation function.</P>

<P>There is implementation divergence: MSVC rejects; clang and gcc
accept, but invoke <TT>::operator delete(void*, align_val_t)</TT> if
the constructor exits via an exception.</P>

<P>If <TT>T</TT> is a type with new-extended alignment, the preferred
allocation function is
<TT>operator new(std::size_t, std::align_val_t, std::align_val_t)</TT>
or, as a fallback, <TT>operator new(std::size_t,
std::align_val_t)</TT>, removing the alignment information
of <TT>T</TT> (7.6.2.8 [<A href="https://wg21.link/expr.new#19">expr.new</A>] paragraph 19).</P>

<P>As another concern, subclause 17.6.3.2 [<A href="https://wg21.link/new.delete.single#11">new.delete.single</A>] paragraph 11 disallows mixing aligned and unaligned
allocation/deallocation functions, and implementations rely on that
precondition.  Thus, it is impossible to deallocate the memory
obtained in the example using a <I>delete-expression</I>; an explicit
deallocation function call appears to be required.</P>

<P><U>Possible resolution:</U></P>

<P>Disallow invocation of one of the allocation functions specified in
17.6.3.2 [<A href="https://wg21.link/new.delete.single">new.delete.single</A>] and 17.6.3.3 [<A href="https://wg21.link/new.delete.array">new.delete.array</A>] if
the <I>new-placement</I> syntax is used with anything but a
single <I>expression</I> of type <TT>std::nothrow_t</TT>.</P>

<P>Alternatively, make this conditionally-supported to offer a richer
feature set on platforms where mixing aligned and unaligned
allocation/deallocation works.</P>

<BR><BR><HR>
<A NAME="2912"></A><H4>2912.
  
Too-large value for size in array new
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mital Ashok
 &#160;&#160;&#160;

 <B>Date: </B>2024-06-20<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/560">#560</A>.)</P>

<P>Consider an implementation with a <TT>size_t</TT> smaller
than <TT>long long</TT>.  An implementation should flag too-large
values for the size in an array "new", in the same manner it flags
negative values. For example:</P>
<PRE>
  int *p = new int[ULLONG_MAX];
</PRE>

<P><U>Possible resolution:</U></P>

<P>Change in 7.6.2.8 [<A href="https://wg21.link/expr.new#8">expr.new</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

If the expression in a <I>noptr-new-declarator</I> is present, it is
implicitly converted to std::size_t. The value of the expression is
invalid if:
<UL>
<LI>the expression is of non-class type and its value before
converting to std::size_t is less than zero <INS>or greater than the
maximum value representable as a <TT>std::size_t</TT></INS>;
</LI>
<LI>the expression is of class type and its value before application
of the second standard conversion (12.2.4.2.3 [<A href="https://wg21.link/over.ics.user">over.ics.user</A>]) [
Footnote: ... ] is less than zero <INS>or greater than the maximum
value representable as a <TT>std::size_t</TT></INS>;</LI>
<LI>its value is such that the size of the allocated object would
exceed the implementation-defined limit (Annex B); or
</LI>
<LI>the <I>new-initializer</I> is a <I>braced-init-list</I> and the
number of array elements for which initializers are provided
(including the terminating '\0' in a <I>string-literal</I>
(5.13.5 [<A href="https://wg21.link/lex.string">lex.string</A>])) exceeds the number of elements to
initialize.</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3011"></A><H4>3011.
  
Parenthesized aggregate initialization for <I>new-expression</I>s
</H4>
<B>Section: </B>7.6.2.8&#160; [<A href="https://wg21.link/expr.new">expr.new</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Benjamin Sch.
 &#160;&#160;&#160;

 <B>Date: </B>2025-03-17<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/685">#685</A>.)</P>

<P>Subclause 7.6.2.8 [<A href="https://wg21.link/expr.new#8">expr.new</A>] paragraph 8 and paragraph 9
contain special cases involving aggregate initialization
using <I>braced-init-list</I>s, which need to be amended for
parenthesized aggregate initialization.  The corresponding rules for
the initialization of variables are in 9.5.1 [<A href="https://wg21.link/dcl.init.general#16.5">dcl.init.general</A>] bullet 16.5 for arrays and in 9.5.1 [<A href="https://wg21.link/dcl.init.general#16.6.2.2">dcl.init.general</A>] bullet 16.6.2.2 for aggregate classes.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 7.6.2.8 [<A href="https://wg21.link/expr.new#8.4">expr.new</A>] bullet 8.4 as follows:</P>

<BLOCKQUOTE>

If the expression in a <I>noptr-new-declarator</I> is present, it is
implicitly converted to std::size_t. The value of the expression is
invalid if
<UL>
<LI>...</LI>
<LI>the <I>new-initializer</I>
is <DEL>a <I>braced-init-list</I></DEL> <INS>present</INS> and the
number of array elements for which initializers are provided
(including the terminating '\0' in a <I>string-literal</I>
(5.13.5 [<A href="https://wg21.link/lex.string">lex.string</A>])) <INS>in a <I>braced-init-list</I> or
parenthesized <I>expression-list</I></INS> exceeds the number of
elements to initialize.</LI>
</UL>

</BLOCKQUOTE>
</LI>
<LI>
<P>Change in 7.6.2.8 [<A href="https://wg21.link/expr.new#9">expr.new</A>] paragraph 9 as follows:</P>


<BLOCKQUOTE>

If the allocated type is an array, the <I>new-initializer</I> is
<DEL>a <I>braced-init-list</I></DEL> <INS>is present and is
not <TT>()</TT></INS>, and the <I>expression</I> is
potentially-evaluated and not a core constant expression, the semantic
constraints of <DEL>copy-</DEL>initializing a hypothetical element of
the array <DEL>from an empty initializer list</DEL> are
checked <INS>as follows:</INS>
<UL>
<LI>
<INS>If the <I>new-initializer</I> is a <I>braced-init-list</I>,
the hypothetical element is copy-initialized from an empty initializer
list</INS> (9.5.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]).</LI>
<LI class="ins">If the <I>new-initializer</I> is a
parenthesized <I>expression-list</I>, the hypothetical element is
value-initialized (9.5.1 [<A href="https://wg21.link/dcl.init.general">dcl.init.general</A>]).</LI>
</UL>
[<I>Note 5:</I> The array can contain more elements than there are
elements in the <DEL><I>braced-init-list</I></DEL>
<INS><I>new-initializer</I></INS>, requiring initialization of the
remainder of the array elements <DEL>from an empty initializer
list</DEL> <INS>as appropriate</INS>. &#8212;<I>end note</I>]

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="196"></A><H4>196.
  
Arguments to deallocation functions </H4>
<B>Section: </B>7.6.2.9&#160; [<A href="https://wg21.link/expr.delete">expr.delete</A>]
 &#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>7.6.2.8 [<A href="https://wg21.link/expr.new#10">expr.new</A>] 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>6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>]

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>.
(7.6.2.9 [<A href="https://wg21.link/expr.delete#2">expr.delete</A>] 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
7.6.2.9 [<A href="https://wg21.link/expr.delete">expr.delete</A>]
 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="2805"></A><H4>2805.
  
Underspecified selection of deallocation function
</H4>
<B>Section: </B>7.6.2.9&#160; [<A href="https://wg21.link/expr.delete">expr.delete</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>L&#233;n&#225;rd Szolnoki
 &#160;&#160;&#160;

 <B>Date: </B>2023-10-12<BR>


<P>Consider:</P>

<PRE>
  #include &lt;memory&gt;

  struct B {
    void operator delete(B* ptr, std::destroying_delete_t);
  };

  struct D : B {
    void operator delete(D* ptr, std::destroying_delete_t);
    using B::operator delete;
  };

  void foo(D* ptr) {
    delete ptr;
  }
</PRE>

<P>The selection rules in 7.6.2.9 [<A href="https://wg21.link/expr.delete#10">expr.delete</A>] paragraph 10 do
not disambiguate this case. There is implementation divergence.</P>

<P>A similar situation arises for the following example:</P>

<PRE>
  struct A {
    void operator delete(void *);
  };

  struct B {
    void operator delete(void *);
  };

  struct C : A, B {
    using A::operator delete;
    using B::operator delete;
  };

  void foo(C* ptr) {
    delete ptr;
  }
</PRE>

<P><B>CWG 2023-10-20</B></P>

<P>The ordered list of preferences should be retained.  Eventual
disambiguation should be via overload resolution, but it is unclear
how to deal with the unspecified choice between overloads with and
without a <TT>std::size_t</TT> parameter.</P>

<BR><BR><HR>
<A NAME="2889"></A><H4>2889.
  
Requiring an accessible destructor for destroying operator delete
</H4>
<B>Section: </B>7.6.2.9&#160; [<A href="https://wg21.link/expr.delete">expr.delete</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Lauri Vasama
 &#160;&#160;&#160;

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


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/532">#532</A>.)</P>

<P>Subclause 7.6.2.9 [<A href="https://wg21.link/expr.delete#6">expr.delete</A>] paragraph 6 specifies that the
destructor must be accessible even if a destroying operator delete is
used:</P>

<BLOCKQUOTE>

If the value of the operand of the <I>delete-expression</I> is not a
null pointer value and the selected deallocation function (see below)
is not a destroying operator delete, evaluating
the <I>delete-expression</I> invokes the destructor (if any) for the
object or the elements of the array being deleted. The destructor
shall be accessible from the point where the <I>delete-expression</I>
appears. In the case of an array, the elements are destroyed in order
of decreasing address (that is, in reverse order of the completion of
their constructor; see 11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]).

</BLOCKQUOTE>

<P>This does not seem to be intended.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 7.6.2.9 [<A href="https://wg21.link/expr.delete#6">expr.delete</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

If the <DEL>value</DEL> <INS>type</INS> of the operand of
the <I>delete-expression</I>
<DEL>is not a null pointer value</DEL>
<INS>is a pointer to a class type or (possibly multidimensional) array
thereof,</INS> and the selected deallocation function (see below) is
not a destroying operator delete<INS>:</INS>
<DEL>, evaluating the <I>delete-expression</I> invokes the destructor
(if any) for the object or the elements of the array being
deleted. The destructor shall be accessible from the point where
the <I>delete-expression</I> appears. In the case of an array, the
elements are destroyed in order of decreasing address (that is, in
reverse order of the completion of their constructor; see
11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]).</DEL>

<UL class="ins">
<LI>The destructor is potentially invoked
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]).</LI>
<LI>If the pointer value is not a null pointer value, evaluating a
single-object delete expression destroys the object pointed to by the
operand, and evaluating an array delete expression destroys each
element of the array pointed to by the operand in order of decreasing
index.
</LI>
</UL>

</BLOCKQUOTE>

<P><B>CWG 2024-05-31</B></P>

<P>This area of the wording is affected by P3144 (Deprecate Delete of
a Pointer to an Incomplete Type).  The wording above requires a class
definition due to the "potentially invoked" phrasing. See also
<A HREF="cwg_defects.html#2880">issue 2880</A>.</P>

<BR><BR><HR>
<A NAME="2878"></A><H4>2878.
  
C-style casts to reference types
</H4>
<B>Section: </B>7.6.3&#160; [<A href="https://wg21.link/expr.cast">expr.cast</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2024-03-20
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/522">#522</A>.)</P>



<P>Consider:</P>

<PRE>
  struct A {};
  struct B : A {};
  const B b;
  void f() {
    (A &amp;&amp;)b;          //<SPAN CLASS="cmnt"> #1</SPAN>
    const_cast&lt;A &amp;&amp;&gt;(static_cast&lt;const A &amp;&gt;(b));
    const_cast&lt;A &amp;&amp;&gt;(static_cast&lt;const volatile A &amp;&amp;&gt;(b));
    const_cast&lt;A &amp;&amp;&gt;(static_cast&lt;A&gt;(b));  //<SPAN CLASS="cmnt"> slicing interpretation</SPAN>
  }
</PRE>

<P>Is #1 ill-formed because of the three alternative valid
interpretations shown in the following lines?</P>

<P>Also consider:</P>

<PRE>
  struct B { };
  const B f();
  B&amp; b1 = const_cast&lt;B&amp;&gt;(static_cast&lt;const B&amp;&gt;(f())); //<SPAN CLASS="cmnt"> OK</SPAN>
  B&amp; b2 = (B&amp;)f(); //<SPAN CLASS="cmnt"> ???</SPAN>
</PRE>

<P>There is implementation divergence: gcc and MSVC accept, clang and
EDG accept <TT>b1</TT> and reject <TT>b2</TT>.  If <TT>f</TT> is
changed to return non-const, gcc also rejects <TT>b2</TT>.</P>

<P>For another example:</P>

<PRE>
  struct A {
    operator const B() = delete;
  } a;

  B&amp; b3 = const_cast&lt;B&amp;&gt;(static_cast&lt;const B&amp;&gt;(a)); //<SPAN CLASS="cmnt"> error, deleted</SPAN>
  B&amp; b4 = (B&amp;)a; //<SPAN CLASS="cmnt"> error or reinterpret_cast?</SPAN>
</PRE>

<P>Implementations agree that <TT>b3</TT> is ill-formed for selecting
the deleted conversion operator function, but <TT>b4</TT> is
considered a <TT>reinterpret_cast</TT> by the majority of
implementations.</P>

<P><B>CWG 2024-05-17</B></P>

<P>Casting away rvalueness in example <TT>b2</TT> is surprising to
perform in a C-style cast.  The <TT>b4</TT> example is also
interesting, because the <TT>reinterpret_cast</TT> interpretation
might be undesirable.  EWG is requested to offer guidance, preferably
in the form of a comprehensive mental model.  The current model
"static_cast, then const_cast" might not be appropriate.</P>

<P>
See <A HREF="https://github.com/cplusplus/papers/issues/1970">paper issue 1970</A>.
</P>

<BR><BR><HR>
<A NAME="2786"></A><H4>2786.
  
Comparing pointers to complete objects
</H4>
<B>Section: </B>7.6.10&#160; [<A href="https://wg21.link/expr.eq">expr.eq</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-08-23<BR>




<P>Subclause 7.6.10 [<A href="https://wg21.link/expr.eq#3.1">expr.eq</A>] bullet 3.1 specifies:</P>

<BLOCKQUOTE>

<UL>
<LI>If one pointer represents the address of a complete object, and
another pointer represents the address one past the last element of a
different complete object, [ Footnote: ... ] the result of the
comparison is unspecified.</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>This phrasing does not properly handle the case where addresses of
subobjects are compared, yet those subobjects happen to have the same
address as their respective complete objects.</P>

<P>The rule in question was introduced by <A HREF="cwg_defects.html#1652">issue 1652</A> for purposes of constant evaluation: comparing a pointer
to an object X with a pointer past the end of another object Y ought
not to be possible during contant evaluation.  However, that issue
resolution also caused a change to runtime behavior, departing from
the prior "address comparison" model.  It turns out that
implementations nowadays rely on that rule for optimization purposes
(see the reflector discussion).</P>

<P><U>Possible resolution:</U></P>

<P>Change in 7.6.10 [<A href="https://wg21.link/expr.eq#3.1">expr.eq</A>] bullet 3.1 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>If one pointer <INS>points to an object and</INS> represents the
address of <INS>the first byte in memory occupied by that
object's</INS> <DEL>a</DEL> complete object, and another <INS>pointer
points past the end of an object whose complete object is different
and</INS> represents the address <INS>of the first byte in memory
after the end of the storage occupied by that object's</INS> <DEL>one
past the last element of a different</DEL> complete object, the result
of the comparison is unspecified.</LI>

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

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3000"></A><H4>3000.
  
Handling of cv-qualified class types in conditional operator
</H4>
<B>Section: </B>7.6.16&#160; [<A href="https://wg21.link/expr.cond">expr.cond</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

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




<P>With <A HREF="cwg_defects.html#2321">issue 2321</A>, the following example
was supposed to be made valid:</P>

<PRE>
   struct A {};
   struct B : A {};
   using T = const B;
   A a = true ? A() : T();
</PRE>

<P>When reaching 7.6.16 [<A href="https://wg21.link/expr.cond#6">expr.cond</A>] paragraph 6, the two
operands have type <TT>A</TT> and <TT>const A</TT>, thus their types
differ.  However, the built-in candidates for the overload resolution
specified in paragraph 6 do not handle class types.</P>

<P>Subclause 7.6.16 [<A href="https://wg21.link/expr.cond#6">expr.cond</A>] paragraph 6 handles the
following case, but should not handle differences in
const-qualification.</P>

<PRE>
  struct A { operator int(); };
  struct B { operator int(); };
  int n = true ? A() : B();
</PRE>

<P>Furthermore, the current wording does not handle this case:</P>

<PRE>
  int const **p;
  int *const *q;
  int const * const * const &amp;r = cond ? p : q; //<SPAN CLASS="cmnt"> Could bind directly, but currently creates a temporary.</SPAN>
</PRE>

<P><U>Possible resolution [SUPERSEDED]:</U></P>

<OL>
<LI>
<P>Change in 7.6.16 [<A href="https://wg21.link/expr.cond#4">expr.cond</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

Otherwise, if the second and third operand have different types and
<DEL>either</DEL> <INS>at least one</INS> has (possibly cv-qualified)
class type, or if both are glvalues <INS>of similar types
(7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>]) and</INS> of the same value
category <DEL>and the same type except for cv-qualification</DEL>, an
attempt is made to form an implicit conversion sequence
(12.2.4.2 [<A href="https://wg21.link/over.best.ics">over.best.ics</A>]) from each of those operands
to <DEL>the</DEL> <INS>a</INS> type <DEL>of</DEL>
<INS>related to</INS> the other.

<P>[<I>Note 2:</I> Properties such as access, whether an operand is a
bit-field, or whether a conversion function is deleted are ignored for
that determination. &#8212;<I>end note</I>]</P>

Attempts are made to form an implicit conversion sequence from an
operand expression E1 of type T1 to a target type related to the type
T2 of the operand expression E2 as follows:
<UL>
<LI>If E2 is an lvalue, the target type is &#8220;lvalue reference to
<DEL>T2</DEL> <INS><TT>T3</TT></INS>&#8221;, <INS>where <TT>T3</TT> is
the qualification-combined type of <TT>T2</TT>
and <TT>T1</TT>;</INS> <DEL>but</DEL> an implicit conversion sequence
can <DEL>only</DEL> be formed <INS>only</INS> if the reference would
bind directly (9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]) to a glvalue.</LI>
<LI>If E2 is an xvalue, the target type is &#8220;rvalue reference to
<DEL>T2</DEL> <INS><TT>T3</TT></INS>&#8221;, <INS>where <TT>T3</TT> is
the qualification-combined type of <TT>T2</TT>
and <TT>T1</TT>;</INS> <DEL>but</DEL> an implicit conversion sequence
can <DEL>only</DEL> be formed <INS>only</INS> if the reference would
bind directly.</LI>
<LI>If E2 is a prvalue or if
neither of the conversion sequences above can be formed and at least
one of the operands has (possibly cv-qualified) class type:
<UL>
<LI>if T1 and T2 are <DEL>the same class type (ignoring
cv-qualification)</DEL> <INS>of similar class types</INS>:
<UL>
<LI>if T2 is at least as cv-qualified as T1, the target type is
T2,</LI>
<LI>otherwise, no conversion sequence is formed for this operand;</LI>
</UL>
</LI>
<LI>otherwise, if T2 is a base class of T1, the target type
is <DEL>cv1 T2, where cv1 denotes the cv-qualifiers of
T1</DEL> <INS>the qualification-combined type of <TT>T2</TT>
and <TT>T1</TT></INS>;
</LI>
<LI>otherwise, the target type is the
type that E2 would have after applying the lvalue-to-rvalue
(7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]), array-to-pointer
(7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>]), and function-to-pointer
(7.3.4 [<A href="https://wg21.link/conv.func">conv.func</A>]) standard conversions.</LI>
</UL>
</LI>
</UL>

Using this process, it is determined whether an implicit conversion
sequence can be formed from the second operand to the target type
determined for the third operand, and vice versa, with the following
outcome:
<UL>
<LI class="del">If both sequences can be formed, or one can be formed
but it is the ambiguous conversion sequence, the program is
ill-formed.
</LI>
<LI>If no conversion sequence can be formed, the operands are left
unchanged and further checking is performed as described below.</LI>
<LI>Otherwise, if exactly one conversion sequence can be formed,
<DEL>that conversion is applied to the chosen operand</DEL>
<INS>the combined target type is defined as the target type of that
conversion.</INS>
</LI>
<LI class="ins">
Otherwise, if both conversion sequences can be formed and the
respective target types are similar, the combined target type is
defined as the qualification-combined type of the target types.
</LI>
<LI class="ins">
Otherwise, the program is ill-formed.
</LI>
</UL>

<INS>If a combined target type is defined above, each operand is
converted to the combined target type</INS> and the
converted <DEL>operand is</DEL> <INS>operands are</INS> is used in
place of the original
<DEL>operand</DEL> <INS>operands</INS> for the remainder of this
subclause.  [<I>Note 3:</I> The
conversion <DEL>might</DEL> <INS>can</INS> be ill-formed even if an
implicit conversion sequence <DEL>could</DEL> <INS>can</INS> be
formed. &#8212;<I>end note</I>]

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 7.6.16 [<A href="https://wg21.link/expr.cond#6">expr.cond</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

Otherwise, the result is a prvalue. If the second and third operands
do not have the same type and <DEL>either</DEL> <INS>at least
one</INS> has (possibly cv-qualified) class type, overload resolution
is used to determine the conversions (if any) to be applied to the
operands (12.2.2.3 [<A href="https://wg21.link/over.match.oper">over.match.oper</A>],
12.5 [<A href="https://wg21.link/over.built">over.built</A>]). If the overload resolution fails, the
program is ill-formed. Otherwise, the conversions thus determined are
applied, and the converted operands are used in place of the original
operands for the remainder of this subclause.

</BLOCKQUOTE>
</LI>

<LI>
<P>Append a row to the table in 12.2.2.3 [<A href="https://wg21.link/over.match.oper#2">over.match.oper</A>] paragraph 2 as follows:</P>

<TABLE BORDER="1">
<TR>
<TD>Subclause</TD>
<TD>Expression</TD>
<TD>As member function</TD>
<TD>As non-member function</TD>
</TR>

<TR>
<TD>12.5 [<A href="https://wg21.link/over.built">over.built</A>]</TD>
<TD><TT>a ? b : c</TT></TD>
<TD></TD>
<TD><TT>operator?:(true, b, c)</TT></TD>
</TR>

</TABLE>
</LI>

<LI>
<P>Change in 12.2.2.3 [<A href="https://wg21.link/over.match.oper#3">over.match.oper</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

For a unary operator @ with an operand of type cv1 T1, <DEL>and</DEL> for a
binary operator @ with a left operand of type cv1 T1 and a right
operand of type cv2 T2, <INS>and for the conditional operator,</INS>
four sets of candidate functions, designated member candidates,
non-member candidates, built-in candidates, and rewritten candidates,
are constructed as follows:

</BLOCKQUOTE>
</LI>
</OL>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 7.6.16 [<A href="https://wg21.link/expr.cond#4">expr.cond</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

Otherwise, if the second and third operand have different types and
<DEL>either</DEL> <INS>at least one</INS> has (possibly cv-qualified)
class type, or if both are glvalues <INS>of similar types
(7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>]) and</INS> of the same value
category <DEL>and the same type except for cv-qualification</DEL>, an
attempt is made to form an implicit conversion sequence
(12.2.4.2 [<A href="https://wg21.link/over.best.ics">over.best.ics</A>]) from each of those operands
to <DEL>the</DEL> <INS>a</INS> type <DEL>of</DEL>
<INS>related to</INS> the other.

<P>[<I>Note 2:</I> Properties such as access, whether an operand is a
bit-field, or whether a conversion function is deleted are ignored for
that determination. &#8212;<I>end note</I>]</P>

Attempts are made to form an implicit conversion sequence from an
operand expression E1 of type T1 to a target type related to the type
T2 of the operand expression E2 as follows:
<UL>
<LI>If E2 is <DEL>an lvalue</DEL> <INS>a glvalue</INS>, the target
type is &#8220;<DEL>lvalue</DEL> reference to <DEL>T2</DEL>
<INS><TT>T3</TT></INS>&#8221;, <INS>where</INS>
<UL class="ins">
<LI>the reference is an lvalue reference if <TT>E2</TT> is an lvalue and
an rvalue reference otherwise and</LI>
<LI>if <TT>T2</TT> is reference-related to <TT>T1</TT>
(9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]), <TT>T3</TT> is such that "pointer
to <TT>T3</TT>" is the qualification-combined type of "pointer
to <TT>T2</TT>" and "pointer to <TT>T1</TT>", otherwise <TT>T3</TT>
is <TT>T2</TT>;
</LI>
</UL>
<DEL>but</DEL> an implicit conversion sequence
can <DEL>only</DEL> be formed <INS>only</INS> if the reference would
bind directly to a glvalue.</LI>
<LI class="del">If E2 is an xvalue, the target type is &#8220;rvalue
reference to T2&#8221;, but an implicit conversion sequence can only
be formed if the reference would bind directly.</LI>
<LI>If E2 is a prvalue or if
<DEL>neither of</DEL> the conversion <DEL>sequences</DEL>
<INS>sequence</INS> above <DEL>can</DEL> <INS>cannot</INS> be formed
<DEL>and at least one of the operands has (possibly cv-qualified) class
type</DEL>:
<UL>
<LI>if <DEL>T1 and T2 are the same class type (ignoring
cv-qualification):</DEL> <INS><TT>T2</TT> is reference-related
to <TT>T1</TT>, the target type <TT>T3</TT> is such that "pointer to <TT>T3</TT>" is the qualification-combined type of "pointer to <TT>T2</TT>" and "pointer to <TT>T1</TT>";</INS>
<UL class="del">
<LI>if T2 is at least as cv-qualified as T1, the target type is
T2,</LI>
<LI>otherwise, no conversion sequence is formed for this operand;</LI>
</UL>
</LI>
<LI class="del">otherwise, if T2 is a base class of T1, the target
type is cv1 T2, where cv1 denotes the cv-qualifiers of T1;
</LI>
<LI>otherwise, the target type is the type that E2 would have after
applying the <DEL>lvalue-to-rvalue (7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]),</DEL>
array-to-pointer (7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>])<DEL>,</DEL> and
function-to-pointer (7.3.4 [<A href="https://wg21.link/conv.func">conv.func</A>]) standard
conversions.</LI>
</UL>
</LI>
</UL>

Using this process, it is determined whether an implicit conversion
sequence can be formed from the second operand to the target type
determined for the third operand, and vice versa, with the following
outcome:
<UL>
<LI class="del">If both sequences can be formed, or one can be formed
but it is the ambiguous conversion sequence, the program is
ill-formed.
</LI>
<LI>If no conversion sequence can be formed, the operands are left
unchanged and further checking is performed as described below.</LI>
<LI>Otherwise, if exactly one conversion sequence can be formed,
<DEL>that conversion is applied to the chosen operand</DEL>
<INS>the common target type is defined as the target type of that
conversion.</INS>
</LI>
<LI class="ins">
Otherwise, if both conversion sequences can be formed and the target
types are the same, the common target type is defined as that
type.</LI>
<LI class="ins">
Otherwise, if both conversion sequences can be formed and one of the
target types is "reference to <TT>T</TT>" and the other is <TT>T</TT>
for some type <TT>T</TT>, the common target type is defined
as <TT>T</TT>.</LI>
<LI class="ins">
Otherwise, the program is ill-formed.
</LI>
</UL>

<INS>If a common target type is defined above, each operand is
converted to the common target type</INS> and the
converted <DEL>operand is</DEL> <INS>operands are</INS> is used in
place of the original
<DEL>operand</DEL> <INS>operands</INS> for the remainder of this
subclause.  [<I>Note 3:</I> The
conversion <DEL>might</DEL> <INS>can</INS> be ill-formed even if an
implicit conversion sequence <DEL>could</DEL> <INS>can</INS> be
formed. &#8212;<I>end note</I>]

</BLOCKQUOTE>
</LI>

<LI>
<P>Change 7.6.16 [<A href="https://wg21.link/expr.cond#6">expr.cond</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

Otherwise, the result is a prvalue. If the second and third operands
do not have the same type and <DEL>either</DEL> <INS>at least
one</INS> has (possibly cv-qualified) class type, overload resolution
is used to determine the conversions (if any) to be applied to the
operands (12.2.2.3 [<A href="https://wg21.link/over.match.oper">over.match.oper</A>],
12.5 [<A href="https://wg21.link/over.built">over.built</A>]). If the overload resolution fails, the
program is ill-formed. Otherwise, the conversions thus determined are
applied, and the converted operands are used in place of the original
operands for the remainder of this subclause.

</BLOCKQUOTE>
</LI>

<LI>
<P>Add an example at the end of 7.6.16 [<A href="https://wg21.link/expr.cond">expr.cond</A>] as follows:</P>

<BLOCKQUOTE class="ins">
<PRE>
template&lt;class T&gt;
T f();

using X0 = decltype(true ? f&lt;int const **&amp;&gt;() : f&lt;int *const *&amp;&gt;());  // X0<SPAN CLASS="cmnt"> is "reference to const pointer to const pointer to const </SPAN>int"

struct B {};
using X1 = decltype(true ? f&lt;const B&amp;&gt;() : f&lt;volatile B&amp;&gt;());  // X1<SPAN CLASS="cmnt"> is "lvalue reference to</SPAN> const volatile B"
using X2 = decltype(true ? f&lt;const B&amp;&gt;() : f&lt;B&gt;());      // X2<SPAN CLASS="cmnt"> is </SPAN>const B

struct C {
  operator B&amp;() const;
};
using X3 = decltype(true ? f&lt;const C&gt;() : f&lt;B&amp;&gt;());      // X3<SPAN CLASS="cmnt"> is "lvalue reference to </SPAN>B"

struct D : B {};
using X4 = decltype(true ? f&lt;const D&amp;&gt;() : f&lt;B&amp;&gt;());       // X4<SPAN CLASS="cmnt"> is </SPAN>const B&amp;
using X5 = decltype(true ? f&lt;const D&gt;() : f&lt;B&gt;());       // X5<SPAN CLASS="cmnt"> is </SPAN>const B
</PRE>

</BLOCKQUOTE>
</LI>

<LI>
<P>Add a new paragraph before 12.2.2.3 [<A href="https://wg21.link/over.match.oper#5">over.match.oper</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<P class="ins">For the conditional operator, overload resolution is
performed only as specified in 7.6.16 [<A href="https://wg21.link/expr.cond">expr.cond</A>]; the
candidate functions for the expression <TT>a ? b : c</TT> are the
built-in candidates for the hypothetical function
call <TT>operator?:(true, b, c)</TT> (12.5 [<A href="https://wg21.link/over.built">over.built</A>]).</P>

<P>For the first parameter of the built-in assignment operators, only
standard conversion sequences (12.2.4.2.2 [<A href="https://wg21.link/over.ics.scs">over.ics.scs</A>]) are
considered.</P>

</BLOCKQUOTE>
</LI>
</OL>

<P>The resolution above also adresses issues <A HREF="cwg_active.html#2023">2023</A> and <A HREF="cwg_defects.html#2865">2865</A>; the resolution
applied for the latter yields a const lvalue, not a prvalue.</P>

<BR><BR><HR>
<A NAME="1542"></A><H4>1542.
  
Compound assignment of <I>braced-init-list</I>
</H4>
<B>Section: </B>7.6.19&#160; [<A href="https://wg21.link/expr.assign">expr.assign</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2012-08-21<BR>


<P>The specification of 7.6.19 [<A href="https://wg21.link/expr.assign#9">expr.assign</A>] paragraph 9 is presumably
intended to allow use of a <I>braced-init-list</I> as the operand of a
compound assignment operator as well as a simple assignment operator,
although the normative wording does not explicitly say so.  (The example
in that paragraph does include</P>

<PRE>
  complex&lt;double&gt; z;
  z += { 1, 2 };      //<SPAN CLASS="cmnt"> meaning </SPAN>z.operator+=({1,2})
</PRE>

<P>for instance, which could be read to imply compound assignment
operators for scalar types as well.)</P>

<P>However, the details of how this is to be implemented are not clear.
Paragraph 7 says,</P>

<BLOCKQUOTE>

The behavior of an expression of the form <TT>E1</TT> <I>op</I>
<TT>=</TT> <TT>E2</TT> is equivalent to <TT>E1 = E1</TT> <I>op</I>
<TT>E2</TT> except that <TT>E1</TT> is evaluated only once.

</BLOCKQUOTE>

<P>Applying this pattern literally to a <I>braced-init-list</I> yields
invalid code: <TT>x&#160;+=&#160;{1}</TT> would become
<TT>x&#160;=&#160;x&#160;+&#160;{1}</TT>, which is non-syntactic.</P>

<P>Another problem is how to apply the prohibition against narrowing
conversions to a compound assignment.  For example,</P>

<PRE>
  char c;
  c += {1};
</PRE>

<P>would presumably always be a narrowing error, because after integral
promotions, the type of <TT>c+1</TT> is <TT>int</TT>.  The similar
<A HREF="cwg_closed.html#1078">issue 1078</A> was classified as "NAD" because
the workaround was simply to add a cast to suppress the error; however,
there is no place to put a similar cast in a compound assignment.</P>

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

<P>The incorrect description of the meaning of a compound assignment
with a <I>braced-init-list</I> should be fixed by CWG.  The question of
whether it makes sense to apply narrowing rules to such assignments
is better addressed by EWG.</P>

<P>See also <A HREF="cwg_defects.html#2399">issue 2399</A>.</P>

<BR><BR><HR>
<A NAME="1256"></A><H4>1256.
  
Unevaluated operands are not necessarily constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

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




<P>The current definition of constant expressions appears to make
unevaluated operands constant expressions; for example,
<TT>new char[10]</TT> would seem to be a constant expression if it
appears as the operand of <TT>sizeof</TT>.  This seems wrong.</P>

<BR><BR><HR>
<A NAME="2192"></A><H4>2192.
  
Constant expressions and order-of-eval undefined behavior
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Peter Sommerlad
 &#160;&#160;&#160;

 <B>Date: </B>2015-10-27<BR>




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

<P>CWG did not wish to require implementations to detect this kind
of undefined behavior in determining whether an expression is constant
or not, but an implementation should be permitted to reject such
expressions. These should be indeterminately sequenced, not
unsequenced. </P>

<BR><BR><HR>
<A NAME="2301"></A><H4>2301.
  
Value-initialization and constexpr constructor evaluation
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-04-18<BR>


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

<PRE>
  union A {
    constexpr A(int) : x(++x) { }
    int x;
    char* y;
  };
  union B {
    A a = 5;
  };
  int arr[B().a.x];
</PRE>

<P>Value-initialization of the object created by <TT>B()</TT>
zero-initializes the object (9.5 [<A href="https://wg21.link/dcl.init#8.2">dcl.init</A>] bullet 8.2),
which should mean that the <TT>++x</TT> in the <I>mem-initilizer</I>
for <TT>A</TT> operates on a zero-initialized object, but current
implementations reject this code as non-constant. It is not clear what
in the current wording justifies this treatment.
</P>

<BR><BR><HR>
<A NAME="2456"></A><H4>2456.
  
Viable user-defined conversions in converted constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2020-08-17<BR>


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

<PRE>
  struct A {
    constexpr A(int i) : val(i) { }
    constexpr operator int() const { return val; }
    constexpr operator float() const { return val; }
  private:
    int val;
  };
  constexpr A a = 42;
  int ary[a];
</PRE>

<P>According to 9.3.4.5 [<A href="https://wg21.link/dcl.array#1">dcl.array</A>] paragraph 1,
the array bound expression</P>

<BLOCKQUOTE>

shall be a converted constant expression of
type <TT>std::size_t</TT> (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]).

</BLOCKQUOTE>

<P>The user-defined conversion to <TT>float</TT> would
involve a floating-integral conversion
(7.3.11 [<A href="https://wg21.link/conv.fpint">conv.fpint</A>]; however, such a conversion is
not permitted by the list of acceptable conversions in
7.7 [<A href="https://wg21.link/expr.const#10">expr.const</A>] paragraph 10:</P>

<BLOCKQUOTE>

<P>A <I>converted constant expression</I> of type <TT>T</TT>
is an expression, implicitly converted to type <TT>T</TT>,
where the converted expression is a constant expression and
the implicit conversion sequence contains only</P>

<UL>
<LI><P>user-defined conversions,</P></LI>

<LI><P> lvalue-to-rvalue conversions
(7.3.2 [<A href="https://wg21.link/conv.lval">conv.lval</A>]),</P></LI>

<LI><P> array-to-pointer conversions
(7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>]),</P></LI>

<LI><P>function-to-pointer conversions
(7.3.4 [<A href="https://wg21.link/conv.func">conv.func</A>]),</P></LI>

<LI><P>qualification conversions
(7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>]),</P></LI>

<LI><P>integral promotions
(7.3.7 [<A href="https://wg21.link/conv.prom">conv.prom</A>]),</P></LI>

<LI><P>integral conversions (7.3.9 [<A href="https://wg21.link/conv.integral">conv.integral</A>])
other than narrowing conversions
(9.5.5 [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]),</P></LI>

<LI><P>null pointer conversions
(7.3.12 [<A href="https://wg21.link/conv.ptr">conv.ptr</A>]) from
<TT>std::nullptr_t</TT>,</P></LI>

<LI><P>null member pointer conversions
(7.3.13 [<A href="https://wg21.link/conv.mem">conv.mem</A>]) from <TT>std::nullptr_t</TT>,
and</P></LI>

<LI><P>function pointer conversions
(7.3.14 [<A href="https://wg21.link/conv.fctptr">conv.fctptr</A>]),</P></LI>

</UL>

<P>and where the reference binding (if any) binds directly.</P>

</BLOCKQUOTE>

<P>It is not clear whether this list is intended to restrict
the set of viable user-defined conversions, and there is
implementation divergence on this point: clang accepts the
example above, while g++ rejects it, presumably on the basis
of an ambiguous conversion.</P>

<P><B>Notes from the August, 2020 teleconference:</B></P>

<P>No direction was established pending information about why
the example is accepted by clang.</P>

<P><B>Additional note, December, 2020:</B></P>

<P>The clang behavior turns out to have been an oversight,
corrected in the current version, so the example is now
rejected by both compilers. However, it is unclear that
this is desirable. In particular, given the example above,
<TT>a</TT> can be used without error as a bit-field width,
as an enumerator value, and as the operand of <TT>alignas</TT>.
Presumably the difference between these integral constant
expression contexts and an array bound is the fact that the
target type is known to be <TT>size_t</TT>. However, both
bit-field widths and <TT>alignas</TT> operands are also
required to be non-negative. Furthermore, the definition of
an &#8220;erroneous&#8221; array bound in
7.6.2.8 [<A href="https://wg21.link/expr.new#9">expr.new</A>] paragraph 9 goes to awkward
lengths to check for negative values as the result of
user-defined conversions, which might argue in favor of
reconsidering the converted constant expression treatment of
array bounds.</P>

<P><B>Notes from the February, 2021 teleconference:</B></P>

<P>CWG agreed with the considerations in the December, 2020
note, feeling that the difference in treatment between
integral constant expressions and a converted constant
expression to a specific integral type is somewhat
gratuitous. However, it was felt that code like that of the
example was unlikely to occur often in real-world code.</P>

<BR><BR><HR>
<A NAME="2536"></A><H4>2536.
  
Partially initialized variables during constant initialization
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2022-02-21
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Consider:</P>

<PRE>
  struct A { int x = 1; int y; };
  constinit A a;                   // <SPAN CLASS="cmnt">static storage duration; #1</SPAN>
</PRE>

<P>The treatment of this example changed with
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1331r2.pdf">P1331R2</A>
(Permitting trivial default initialization in constexpr contexts),
adopted 2019-07. Prior to this paper, the default constructor
of <TT>A</TT> was not <TT>constexpr</TT> because it left a data member
uninitialized.  With paper P1331, the restriction was shifted to
reading uninitialized objects during constant evaluation, and the
variable <TT>a</TT> now satisfies the requirements for
"constant-initialized" in 7.7 [<A href="https://wg21.link/expr.const#2">expr.const</A>] paragraph 2:</P>

<BLOCKQUOTE>

A variable or temporary object o is <I>constant-initialized</I> if
<UL>
<LI>either it has an initializer or its default-initialization results
in some initialization being performed, and</LI>

<LI>the full-expression of its initialization is a constant expression
when interpreted as a constant-expression, except that if o is an
object, that full-expression may also invoke constexpr constructors
for o and its subobjects even if those objects are of non-literal
class types.</LI>
</UL>

</BLOCKQUOTE>

<P>Zero-initialization is not performed prior to
constant-initialization per 6.10.3.2 [<A href="https://wg21.link/basic.start.static#2">basic.start.static</A>] paragraph 2:</P>

<BLOCKQUOTE>

<I>Constant initialization</I> is performed if a variable or temporary
object with static or thread storage duration is constant-initialized
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]). If constant initialization is not
performed, a variable with static storage duration
(6.8.6.2 [<A href="https://wg21.link/basic.stc.static">basic.stc.static</A>]) or thread storage duration
(6.8.6.3 [<A href="https://wg21.link/basic.stc.thread">basic.stc.thread</A>]) is zero-initialized
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]). Together, zero-initialization and constant
initialization are called <I>static initialization</I>; all other
initialization is <I>dynamic initialization</I>.

</BLOCKQUOTE>

<P>Thus, #1 is valid and <TT>a</TT> is statically initialized,
but <TT>a.y</TT> would remain uninitialized, which is surprising for
an object with static storage duration.</P>

<P>Current implementations diagnose an error at #1, because the
variable <TT>a</TT> is actually not considered to be
constant-initialized.</P>

<P>This issue is closely related to <A HREF="cwg_defects.html#2558">issue 2558</A>.</P>

<P><U>Suggested resolution [SUPERSEDED]:</U></P>

Change in 7.7 [<A href="https://wg21.link/expr.const#2">expr.const</A>] paragraph 2:

<BLOCKQUOTE>

A variable or temporary object o is <I>constant-initialized</I> if
<UL>
<LI>either it has an initializer or its default-initialization results
in some initialization being performed, and</LI>

<LI><INS>every non-variant non-static data member and base class subobject
is initialized (11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]), and</INS></LI>

<LI>the full-expression of its initialization is a constant expression
when interpreted as a constant-expression, except that if o is an
object, that full-expression may also invoke constexpr constructors
for o and its subobjects even if those objects are of non-literal
class types.</LI>
</UL>

</BLOCKQUOTE>



<P><U>Alternative suggested resolution (March, 2022) [SUPERSEDED]:</U></P>

<P>Change in 7.7 [<A href="https://wg21.link/expr.const#11">expr.const</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

A constant expression is either a glvalue core constant expression
that refers to an entity that is a permitted result of a constant
expression (as defined below), or a prvalue core constant expression
whose value satisfies the following constraints:

<UL>
<LI>if the value is an object of class type, each non-static data
member of reference type refers to an entity that is a permitted
result of a constant expression,
</LI>

<LI>if the value is of pointer type, it contains the address of an
object with static storage duration, the address past the end of such
an object (7.6.6 [<A href="https://wg21.link/expr.add">expr.add</A>]), the address of a non-immediate
function, or a null pointer value,
</LI>

<LI>if the value is of pointer-to-member-function type, it does not
designate an immediate function, and
</LI>

<LI>if the value is an object of class or array type, each subobject
<INS>is initialized (11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]) and</INS> satisfies
these constraints for the value.</LI>
</UL>

</BLOCKQUOTE>

<P><B>Notes from the November, 2022 meeting</B></P>

<P>CWG preferred to zero-initialize <TT>a.y</TT> in the example, and
keep #1 well-formed.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.10.3.2 [<A href="https://wg21.link/basic.start.static#2">basic.start.static</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<I>Constant initialization</I> is performed if a variable or temporary
object with static or thread storage duration is constant-initialized
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]). 
<DEL>If constant initialization is not performed, a</DEL> <INS>A</INS>
variable with static storage duration (6.8.6.2 [<A href="https://wg21.link/basic.stc.static">basic.stc.static</A>])
or thread storage duration (6.8.6.3 [<A href="https://wg21.link/basic.stc.thread">basic.stc.thread</A>]) <INS>or a
subobject thereof</INS> is zero-initialized
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) <INS>if constant initialization is not
performed or if it does not initialize that subobject</INS>. Together,
zero-initialization and constant initialization are called static
initialization; all other initialization is dynamic
initialization. All static initialization strongly happens before
(6.10.2.2 [<A href="https://wg21.link/intro.races">intro.races</A>]) any dynamic initialization.

</BLOCKQUOTE>

<P><B>CWG 2022-12-02</B></P>

<P>The resolution shown above would leave padding bits
uninitialized. In contrast, zero-initialization does set padding bits
to 0 to possibly facilitate <TT>memcmp</TT>.  Additional example:</P>

<PRE>
  struct C { 
    int a;
    int b;
    C() : b(a) {}   //<SPAN CLASS="cmnt"> #1</SPAN>
  }; 
  constinit C x;    // <SPAN CLASS="cmnt">OK when zero-initializing first, because #1 reads zero-initialized </SPAN>a<SPAN CLASS="cmnt">?</SPAN>
</PRE>

<P><B>2022-12-03</B></P>

<P>Forwarded to EWG with
<A HREF="https://github.com/cplusplus/papers/issues/1380">cplusplus/papers#1380</A>.</P>

<P><B>Additional notes (January, 2023)</B></P>

<P>The standard does not guarantee stable results when reading padding
bits, i.e. bits that are not part of the value representation of some
in-lifetime object.  In C, explicit rules keep padding bits stable;
they are allowed to change only if a store to any class member occurs.</P>

<BR><BR><HR>
<A NAME="2545"></A><H4>2545.
  
Transparently replacing objects in constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

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




<P>7.7 [<A href="https://wg21.link/expr.const#6">expr.const</A>] paragraph 6 specifies
that <TT>std::construct_at</TT> can be used during constant
evaluation:</P>

<BLOCKQUOTE>

Similarly, the evaluation of a call to <TT>std::construct_at</TT> or
<TT>std::ranges::construct_at</TT> does not disqualify <TT>E</TT> from
being a core constant expression unless the first argument, of
type <TT>T*</TT>, does not point to storage allocated
with <TT>std::allocator&lt;T&gt;</TT> or to an object whose lifetime
began within the evaluation of <TT>E</TT>, or the evaluation of the
underlying constructor call disqualifies <TT>E</TT> from being a core
constant expression.

</BLOCKQUOTE>

<P>Apparently, implementations are required to track whether an object
is transparently replaceable (6.8.4 [<A href="https://wg21.link/basic.life#8">basic.life</A>] paragraph 8)
during constant evaluation to satisfy 7.7 [<A href="https://wg21.link/expr.const#5.8">expr.const</A>] bullet 5.8, which requires that undefined behavior be detected and
rejected during constant evaluation:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>
an operation that would have undefined behavior as specified in Clause
4 through Clause 15;
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>For example,</P>

<PRE>
  struct A {
    int x, y;
  };
  struct B {
    float a;
    int b;
  };
  union C {
    A a;
    B b;
  };
  constexpr int f() {
   C c = {};
   std::construct_at(&amp;c.b.b, 5);
   //<SPAN CLASS="cmnt"> Does this return 5 if </SPAN>c.a.y<SPAN CLASS="cmnt"> and </SPAN>c.b.b<SPAN CLASS="cmnt"> are laid out at the same address?</SPAN>
   return c.a.y;
  }
  static_assert(f());  // not a constant-expression
</PRE>

<P>No known implementation diagnoses the violation of the rules for
transparently replaceable in the following example, but there is
implementation divergence for the results of <TT>f()</TT>:</P>

<PRE>
  #include &lt;memory&gt;

  struct A {
    virtual constexpr char f() { return 'A'; }
  };
  struct B : A {
    constexpr char f() override { return 'B'; }
  };

  constexpr char f() {
    B b;
    A *p = &amp;b;
    std::construct_at(p);
    return p-&gt;f();     // <SPAN CLASS="cmnt">#1; alternative:</SPAN> return b.f()
  }
  static_assert(f() == 'A');   //<SPAN CLASS="cmnt"> error: #1 accesses out-of-lifetime object</SPAN>
</PRE>

<P>See also <A HREF="cwg_active.html#2866">issue 2866</A> for concerns about
observing the effects of an attribute if the potentially-overlapping
subobject was introduced via <TT>[[no_unique_address]]</TT>.</P>

<BR><BR><HR>
<A NAME="2559"></A><H4>2559.
  
Defaulted consteval functions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Aaron Ballman
 &#160;&#160;&#160;

 <B>Date: </B>2022-03-29<BR>




<P>Consider:</P>

<PRE>
  template &lt;typename Ty&gt;
  struct S {
    Ty i;
    consteval S() = default;
  };

  template &lt;typename Ty&gt;
  struct T {
    Ty i;
    consteval T() {}
  };

  S&lt;int&gt; one; //<SPAN CLASS="cmnt"> only Clang rejects</SPAN>
  T&lt;int&gt; two; //<SPAN CLASS="cmnt"> Clang, GCC, ICC, MSVC reject</SPAN>

  void locals() {
    S&lt;int&gt; three; //<SPAN CLASS="cmnt"> only Clang rejects</SPAN>
    T&lt;int&gt; four;  //<SPAN CLASS="cmnt"> Clang, GCC, ICC, MSVC reject</SPAN>
  }
</PRE>

<P>A consteval function should always be evaluated at compile time and
never fall back to runtime, thus all four cases should be rejected.
<A HREF="cwg_defects.html#2558">Issue 2558</A> is related.</P>

<BR><BR><HR>
<A NAME="2633"></A><H4>2633.
  
typeid of constexpr-unknown dynamic type
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2022-09-18<BR>


<P>Consider the example in 7.7 [<A href="https://wg21.link/expr.const#7">expr.const</A>] paragraph 7:</P>

<PRE>
extern Swim dc;
constexpr auto&amp; sandeno  = typeid(dc);     //<SPAN CLASS="cmnt"> OK, can only be typeid(Swim)</SPAN>
</PRE>

<P>The comment in the example seems not to be backed by normative
text.  In particular, the dynamic type of <TT>dc</TT> is
constexpr-unknown per 7.7 [<A href="https://wg21.link/expr.const#7">expr.const</A>] paragraph 7:</P>

<BLOCKQUOTE>

During the evaluation of an expression E as a core constant
expression, all <I>id-expression</I>s and uses of <TT>*this</TT> that
refer to an object or reference whose lifetime did not begin with the
evaluation of E are treated as referring to a specific instance of
that object or reference whose lifetime and that of all subobjects
(including all union members) includes the entire constant
evaluation. For such an object that is not usable in constant
expressions, the dynamic type of the object is constexpr-unknown. ...

</BLOCKQUOTE>

<P>Thus, <TT>typeid(dc)</TT> is not a core constant expression per
7.7 [<A href="https://wg21.link/expr.const#5.26">expr.const</A>] bullet 5.26:</P>

<BLOCKQUOTE>

<UL>
<LI>
a dynamic_cast (7.6.1.7 [<A href="https://wg21.link/expr.dynamic.cast">expr.dynamic.cast</A>]) or typeid
(7.6.1.8 [<A href="https://wg21.link/expr.typeid">expr.typeid</A>]) expression on a glvalue that refers to
an object whose dynamic type is constexpr-unknown or that would throw
an exception;
</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2702"></A><H4>2702.
  
Constant destruction of reference members
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2023-02-13<BR>




<P>
<A HREF="cwg_defects.html#2529">Issue 2529</A> says that a constexpr reference
bound to a lifetime-extended temporary is required to have constant
destruction.  However, that rule overlooks constexpr objects with a
reference member bound to a lifetime-extended temporary, recursively,
and the case for <TT>std::initializer_list</TT> lifetime extension.
</P>

<BR><BR><HR>
<A NAME="2734"></A><H4>2734.
  
Immediate forward-declared function templates
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

 <B>Date: </B>2023-05-10<BR>




<P>Consider:</P>

<PRE>
  consteval int a(auto);
  constexpr int g(auto e);
  constexpr int f(auto e);

  constexpr int f(auto e) {
    return a(e);
  }

  auto ff = f&lt;int&gt;;   //<SPAN CLASS="cmnt"> error: f is an immediate function</SPAN>

  auto gg = g&lt;int&gt;;   //<SPAN CLASS="cmnt"> ok?</SPAN>

  constexpr int g(auto e) { //<SPAN CLASS="cmnt"> g is not an immediate function?</SPAN>
    return a(e);
  }
</PRE>

<P>The standard is silent as to what happen if no function body is
available at the point where we need to determine whether a constexpr
function template is an immediate function template.</P>

<P>Furthermore, there is no wording that taking the address of a
constexpr function template specialization instantiates its body to
determine whether it is an immediate function, unlike the handling
of <TT>auto</TT> return types.</P>

<P>Subclause 13.9.2 [<A href="https://wg21.link/temp.inst#5">temp.inst</A>] paragraph 5 specifies:</P>

<BLOCKQUOTE>

Unless a function template specialization is a declared
specialization, the function template specialization is implicitly
instantiated when the specialization is referenced in a context that
requires a function definition to exist or if the existence of the
definition affects the semantics of the program. ...

</BLOCKQUOTE>

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

<BR><BR><HR>
<A NAME="2740"></A><H4>2740.
  
Too many objects have constexpr-unknown type
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2023-02-10<BR>




<P>Consider:</P>

<PRE>
  struct A {
    A();
    virtual constexpr int f() { return 1; }
  };
  struct B : A {
    virtual constexpr int f() { return 2; }
  };
  B b; //<SPAN CLASS="cmnt"> not constexpr</SPAN>
  auto &amp;id = typeid(b); //<SPAN CLASS="cmnt"> error, not constant</SPAN>
</PRE>

<P>The example had been valid, but became invalid under P2280.  The
same happened for <TT>dynamic_cast</TT>. Furthermore, P2280 seems to
be missing a change for <TT>static_cast</TT> from base to derived and
for pointer-to-member access expressions, which both depend on the
dynamic type and have historically been required to work.</P>

<P>Maybe a better rule would be that objects (not references) whose
lifetime did not begin within E are treated as having a dynamic type
that is their declared type.</P>

<BR><BR><HR>
<A NAME="2962"></A><H4>2962.
  
Evaluation of destructor call for variable with constant destruction
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Cody Miller
 &#160;&#160;&#160;

 <B>Date: </B>2024-11-23<BR>




<P>Consider:</P>

<PRE>
  #include &lt;type_traits&gt;

  extern "C" int puts(const char*);

  struct S {
    consteval S(int i) : buf{i} {}
    constexpr ~S() {
      if (!std::is_constant_evaluated())
	puts("Destroyed\n");
    }
    int buf;
  };

  int main() {
    constexpr S s{43};
    return s.buf;
  }
</PRE>

<P>The destruction should be manifestly constant-evaluated.</P>

<P>Also consider:</P>

<PRE>
  struct A {
    constexpr A() {
      if !consteval { puts("constructed"); }
    }
    constexpr ~A() {
      if !consteval { puts("destroyed"); }
    }
  };

  void f() {
    { A a; }
    delete new A;
    A();
  }

  void g() {
    constexpr A a;      //<SPAN CLASS="cmnt"> Usable in constant expressions: destruction is manifestly constant evaluated.</SPAN>
  }
  A a;      //<SPAN CLASS="cmnt"> Constant-initialized, but destruction is not manifestly constant evaluated.</SPAN>
</PRE>

<P><U>Possible resolution:</U></P>

<P>Change in 7.7 [<A href="https://wg21.link/expr.const#21">expr.const</A>] paragraph 21 as follows:</P>

<BLOCKQUOTE>

An expression or conversion is manifestly constant-evaluated if it is<DEL>:</DEL>

<UL>
<LI>...</LI>
<LI>the initializer of a variable that is usable in constant
expressions or has constant initialization
(6.10.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>])<DEL>.</DEL> <INS>,</INS> [ Footnote:
... ] <INS>or</INS> [ Example: ... ]</LI>

<LI class="ins">the destruction of an object that is usable in
constant expressions and has constant destruction.</LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3004"></A><H4>3004.
  
Pointer arithmetic on array of unknown bound
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>A. Jiang
 &#160;&#160;&#160;

 <B>Date: </B>2025-03-07<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/680">#680</A>.)</P>

<P>Consider:</P>

<PRE>
  extern const int arr[];
  constexpr const int *p = arr + N;  //<SPAN CLASS="cmnt"> #1</SPAN>
  constexpr int arr[2] = {0, 1};     //<SPAN CLASS="cmnt"> #2</SPAN>
  constexpr int k = *p;              //<SPAN CLASS="cmnt"> #3</SPAN>
</PRE>

<P>What is the outcome here?  Accept for N == 0 and otherwise #1 is
non-constant (clang)?  Always accept #1, but reject #3 for
out-of-bounds accesses (gcc)?  Always accept #1, but always reject #3,
even for in-bound accesses (EDG)?  Rejecct #2 (MSVC)?</P>

<P>Further, we miss a specification when a both a declaration of type
"array of unknown bound of T" as well as one of the type "array of N
T" is reachable.  We should take the latter as the type.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Add a bullet after 7.7 [<A href="https://wg21.link/expr.const#10.15">expr.const</A>] bullet 10.15 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>a reinterpret_cast (7.6.1.10 [<A href="https://wg21.link/expr.reinterpret.cast">expr.reinterpret.cast</A>]);</LI>
<LI class="ins">pointer arithmetic (7.6.6 [<A href="https://wg21.link/expr.add">expr.add</A>]) where
one (possibly converted) operand points to the first element of an
array of unknown bound and the other (possibly converted) operand is
of integral type with non-zero value</LI>
<LI>...</LI>
</UL>
</BLOCKQUOTE>
</LI>
<LI>
<P>Change in 6.9.1 [<A href="https://wg21.link/basic.types.general#6">basic.types.general</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

A class type (such as &#8220;class X&#8221;) can be incomplete at one
point in a translation unit and complete later on; the type
&#8220;class X&#8221; is the same type at both points. The declared
type of an array <DEL>object</DEL> <INS>variable</INS> can be an array
of incomplete class type <INS><TT>C</TT></INS> and therefore
incomplete; <DEL>if the class type is completed later
on</DEL> <INS>wherever a definition of <INS><TT>C</TT></INS> is
reachable</INS> in the translation unit, the array
type <DEL>becomes</DEL> <INS>is</INS> complete; the array type at
those two points is the same type. The declared type of an array
<DEL>object</DEL> <INS>variable <TT>v</TT> </INS> can be an array of unknown bound
and therefore be incomplete at one point in a translation unit and
<INS>is</INS> complete <DEL>later on</DEL> <INS>wherever a declaration
of <TT>v</TT> with a known bound is reachable</INS>; the array types
at those two points (&#8220;array of unknown bound of T&#8221; and
&#8220;array of N T&#8221;) are different types.

</BLOCKQUOTE>
</LI>
</OL>
<BR><BR><HR>
<A NAME="3009"></A><H4>3009.
  
Unclear rules for constant initialization
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2023-11-08<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/460">#460</A>.)</P>

<P>Consider:</P>

<PRE>
  struct B {
    constexpr ~B(){}      //<SPAN CLASS="cmnt"> #1</SPAN>
  };
  struct A {
    constexpr A(const B&amp;){}  //<SPAN CLASS="cmnt"> #2</SPAN>
    constexpr ~A(){}
  };
  constexpr A a(B{});  //<SPAN CLASS="cmnt"> #3, checks #1 and #2</SPAN>
</PRE>

<P>Subclause 7.7 [<A href="https://wg21.link/expr.const#6.1">expr.const</A>] bullet 6.1 specifies:</P>

<BLOCKQUOTE>

A variable v is <I>constant-initializable</I> if
<UL>
<LI>the full-expression of its initialization is a constant expression
when interpreted as a <I>constant-expression</I>...</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>However, a full-expression need not satisfy the syntax of a
<I>constant-expression</I>, and indeed, for the example at #3, the
only syntactical expression is <TT>B{}</TT>, but the checking of the
constructor of <TT>A</TT> and the destructor of <TT>B</TT> is intended
to be part of the conditions for constant-initializable, which
unsuccessfully attempts to delegate to 7.7 [<A href="https://wg21.link/expr.const#22">expr.const</A>] paragraph 22.</P>

<BR><BR><HR>
<A NAME="3010"></A><H4>3010.
  
constexpr placement-new should require transparent replaceability
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

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




<P>Consider:</P>

<PRE>
  struct A { int n; };
  struct B : A { int m; };

  constexpr int f() {
   B b = {{0}, 0};
   A *p = &amp;b;
   new (p) A{1};     //<SPAN CLASS="cmnt"> does not transparently replace </SPAN>*p
   return p-&gt;n;      //<SPAN CLASS="cmnt"> UB, p refers to out-of-lifetime object</SPAN>
  }
  constexpr int k = f();
</PRE>

<P>It seems unreasonable to expect implementations to track situations
where a placement-new evaluations that don't transparently replace the
original object.</P>

<P>The status quo wording in 7.7 [<A href="https://wg21.link/expr.const#10.18.2">expr.const</A>] bullet 10.18.2
involving "similar" was added by <A HREF="cwg_defects.html#2922">issue 2922</A>.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 7.7 [<A href="https://wg21.link/expr.const#10.18.2">expr.const</A>] bullet 10.18.2 as follows:</P>


<BLOCKQUOTE>

An expression E is a core constant expression unless the evaluation of
E, following the rules of the abstract machine
(6.10.1 [<A href="https://wg21.link/intro.execution">intro.execution</A>]), would evaluate one of the following:

<UL>
<LI>...</LI>
<LI>a <I>new-expression</I> (7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]), unless either
<UL>
<LI>the selected allocation function is a replaceable global
allocation function (17.6.3.2 [<A href="https://wg21.link/new.delete.single">new.delete.single</A>],
17.6.3.3 [<A href="https://wg21.link/new.delete.array">new.delete.array</A>]) and the allocated storage is
deallocated within the evaluation of E, or</LI>
<LI>the selected
allocation function is a non-allocating form
(17.6.3.4 [<A href="https://wg21.link/new.delete.placement">new.delete.placement</A>]) with an allocated type T, where
<UL>
<LI>the placement argument to the <I>new-expression</I> points to an
object <DEL>whose type is similar to T
(7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>])</DEL>
<INS>that is transparently replaceable (6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]) by
the object created by the <I>new-expression</I></INS> or, if T is an
array type, to the first element of <INS>such</INS> an object <DEL>of
a type similar to T</DEL>, and</LI>
<LI>the placement argument points to storage whose duration began
within the evaluation of E;</LI>
</UL>
</LI>
</UL>
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>
<BR><BR><HR>
<A NAME="3059"></A><H4>3059.
  
<TT>throw;</TT> in constant expressions
</H4>
<B>Section: </B>7.7&#160; [<A href="https://wg21.link/expr.const">expr.const</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>L&#233;n&#225;rd Szolnoki
 &#160;&#160;&#160;

 <B>Date: </B>2025-08-28<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/756">#756</A>.)</P>

<P>Consider:</P>

<PRE>
  int main() {
    try {
      throw 0;
    } catch (...) {
      constexpr int x = [] {
       try {
         throw;          //<SPAN CLASS="cmnt"> #1</SPAN>
       } catch (...)
         return 1;
       }
      }();
    }
  }
</PRE>

<P>According to 7.6.18 [<A href="https://wg21.link/expr.throw#3">expr.throw</A>] paragraph 3, #1 rethrows the
currently handled exception as defined in 14.4 [<A href="https://wg21.link/except.handle#10">except.handle</A>] paragraph 10, which would rethrow the runtime exception inside a
constant expression.</P>

<P><U>Suggested resolution:</U></P>

<P>Add a new bullet after 7.7 [<A href="https://wg21.link/expr.const#10.22">expr.const</A>] bullet 10.22 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>a construction of an exception object, unless the exception object
and all of its implicit copies created by invocations of
std::current_exception or std::rethrow_exception
(17.9.7 [<A href="https://wg21.link/propagation">propagation</A>]) are destroyed within the evaluation of
E;</LI>

<LI class="ins">a <I>throw-expression</I>
(7.6.18 [<A href="https://wg21.link/expr.throw">expr.throw</A>]) with no operand, unless there is a
currently handled exception whose exception object was constructed
within the evaluation of E;</LI>

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

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3044"></A><H4>3044.
  
Iterating expansion statements woes
</H4>
<B>Section: </B>8.7&#160; [<A href="https://wg21.link/stmt.expand">stmt.expand</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jakub Jelinek
 &#160;&#160;&#160;

 <B>Date: </B>2025-07-08<BR>


<P>(From submissions
<A HREF="https://github.com/cplusplus/CWG/issues/725">#725</A> and
<A HREF="https://github.com/cplusplus/CWG/issues/730">#730</A>.)</P>

<P>The rewrite of iterating expansion statements contains:

<PRE>
  static constexpr auto <I>iter</I> = <I>begin</I> + i;
</PRE>

where the type of <TT>i</TT> is unspecified, but overload resolution
of <TT>+</TT> depends on the type of <TT>i</TT>.</P>

<P>Furthermore, the rewrite contains

<PRE>
  for (auto i = begin ; i != end ; ++i, ++result);
</PRE>

which might invoke an overloaded comma operator, which is
undesirable.</P>

<P>Furthermore, because of the use of <TT>static</TT> in the rewrite,
the example in 8.7 [<A href="https://wg21.link/stmt.expand#7">stmt.expand</A>] paragraph 7 is ill-formed.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 8.7 [<A href="https://wg21.link/stmt.expand#5.2">stmt.expand</A>] bullet 5.2 as follows:</P>

<BLOCKQUOTE>
Otherwise, if S is an iterating expansion statement, S is equivalent to:
<PRE>
  {
    init-statement
    <DEL>static</DEL> constexpr auto&amp;&amp; range = expansion-initializer ;
    <DEL>static</DEL> constexpr auto begin = begin-expr;    //<SPAN CLASS="cmnt"> see 8.6.5 [<A href="https://wg21.link/stmt.ranged">stmt.ranged</A>]</SPAN>
    <DEL>static</DEL> constexpr auto end = end-expr;        //<SPAN CLASS="cmnt"> see 8.6.5 [<A href="https://wg21.link/stmt.ranged">stmt.ranged</A>]</SPAN>
    S0
    .
    .
    .
    SN-1
  }
</PRE>
where N is the result of evaluating the expression
<PRE>
  [] consteval {
    std::ptrdiff_t result = 0;
    for (auto i = begin ; i != end ; ++i<DEL>, ++result</DEL>) <INS>++result</INS>;
    return result;    //<SPAN CLASS="cmnt"> distance from begin to end</SPAN>
  }()
</PRE>
and Si is
<PRE>
  {
    <DEL>static</DEL> constexpr auto iter = begin + <DEL>i</DEL> <INS><I>i</I></INS>;
    for-range-declaration = *iter ;
    compound-statement
  }
</PRE>
The variables range , begin , end , and iter are defined for
exposition only.  <INS>The <I>identifier</I> <I><TT>i</TT></I> is
considered to be a prvalue of type <TT>decltype(<I>begin</I> - <I>begin</I>)</TT>; the
program is ill-formed if <I>i</I> is not representable as such a
value.</INS> [Note 1 : The instantiation is ill-formed if <I>range</I>
is not a constant expression (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]). -- end note]
</BLOCKQUOTE>
</LI>

<LI>
<P>No change in 8.7 [<A href="https://wg21.link/stmt.expand#7">stmt.expand</A>] paragraph 7:</P>

<BLOCKQUOTE>
[ Example 2:

<PRE>
  consteval int f() {
    constexpr std::array&lt;int, 3&gt; arr {1, 2, 3};
    int result = 0;
    template for (constexpr int s : arr) {      //<SPAN CLASS="cmnt"> OK, iterating expansion statement</SPAN>
      result += sizeof(char[s]);
    }
    return result;
  }
  static_assert(f() == 6);
</PRE>
&#8212;<I>end example</I>]
</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="3048"></A><H4>3048.
  
Empty destructuring expansion statements
</H4>
<B>Section: </B>8.7&#160; [<A href="https://wg21.link/stmt.expand">stmt.expand</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jakub Jelinek
 &#160;&#160;&#160;

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


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/743">#743</A>.)</P>

<P>Consider:</P>

<PRE>
struct S { };
void f() {
  S s;
  template for (auto x : s) { }
}
</PRE>

<P>This destructuring expansion statement is ill-formed, because the syntactic rewrite contains</P>

<PRE>
  auto&amp;&amp; [] = s ;
</PRE>

<P>which is an ill-formed structured binding declaration.</P>

<P>Empty expansion statements are allowed for the other two kinds of
expansion statements.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 8.7 [<A href="https://wg21.link/stmt.expand#5.3">stmt.expand</A>] bullet 5.3 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>Otherwise, S is a destructuring expansion statement and<INS>,
if <I>N</I> is 0, <I>S</I> is equivalent to:</INS>

<PRE class="ins">
<I>init-statement</I>
constexpr<SUB>opt</SUB> auto&amp;&amp; <I>range</I> = <I>expansion-initializer</I> ;
</PRE>

<INS>otherwise,</INS> S is
equivalent to: ... </LI>
</UL>

</BLOCKQUOTE>
<BR><BR><HR>
<A NAME="3061"></A><H4>3061.
  
Trailing comma in an <I>expansion-init-list</I>
</H4>
<B>Section: </B>8.7&#160; [<A href="https://wg21.link/stmt.expand">stmt.expand</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jan Schultke
 &#160;&#160;&#160;

 <B>Date: </B>2025-08-24<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/754">#754</A>.)</P>

<P>Brace-enclosed lists generally allow trailing commas.  But
an <I>expansion-init-list</I> does not; consider:</P>

<PRE>
           for (int x : { 1, }) { }   //<SPAN CLASS="cmnt"> OK</SPAN>
  template for (int x : { 1, }) { }   //<SPAN CLASS="cmnt"> syntax error</SPAN>
</PRE>

<P><U>Suggested resolution:</U></P>

<P>Change in 8.7 [<A href="https://wg21.link/stmt.expand#1">stmt.expand</A>] paragraph 1 as follows:</P>

<PRE>
  <I>expansion-init-list</I> :
       { <I>expression-list</I> <INS>,</INS><SUB>opt</SUB> }
       <INS>{ }</INS>
</PRE>

<BR><BR><HR>
<A NAME="2115"></A><H4>2115.
  
Order of implicit destruction vs release of automatic storage
</H4>
<B>Section: </B>8.8&#160; [<A href="https://wg21.link/stmt.jump">stmt.jump</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-04-16<BR>




<P>The relative ordering between destruction of automatic variables
on exit from a block and the release of the variables' storage is
not specified by the Standard: are all the destructors executed
first and then the storage released, or are they interleaved?</P>

<P><B>Notes from the February, 2016 meeting:</B></P>

<P>CWG agreed that the storage should persist until all destructions
are complete, although the &#8220;as-if&#8221; rule would allow for
unobservable optimizations of this ordering.</P>

<BR><BR><HR>
<A NAME="2495"></A><H4>2495.
  
Glvalue result of a function call
</H4>
<B>Section: </B>8.8.4&#160; [<A href="https://wg21.link/stmt.return">stmt.return</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2021-07-04<BR>




<P>According to 8.8.4 [<A href="https://wg21.link/stmt.return#1">stmt.return</A>] paragraph 1,</P>

<BLOCKQUOTE>

A <TT>return</TT> statement with any other operand shall be
used only in a function whose return type is not <I>cv</I>
<TT>void</TT>; the <TT>return</TT> statement initializes the
glvalue result or prvalue result object of the (explicit or
implicit) function call by copy-initialization
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) from the operand.

</BLOCKQUOTE>

<P>It is not clear what a &#8220;glvalue result&#8221; is or
what it means to initialize it.</P>

<P><U>Suggested resolution:</U></P>

<BLOCKQUOTE>

<P>A <TT>return</TT> statement with any other operand shall be
used only in a function whose return type is not <I>cv</I>
<TT>void</TT><DEL>;</DEL><INS>. If the function call is a
prvalue,</INS> the <TT>return</TT> statement initializes the
<DEL>glvalue result or</DEL> prvalue result object of the
(explicit or implicit) function call by copy-initialization
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) from the operand. <INS>Otherwise,
the <TT>return</TT> statement is equivalent to the following
hypothetical declaration</INS>
</P>

<UL><INS><TT>  T t = </TT><I>e</I><TT>;</TT></INS></UL>

<P><INS>If the operand of the <TT>return</TT>
statement, <I>X</I>, is a comma expression without
parentheses, <I>e</I> is <TT>(</TT><I>X</I><TT>)</TT>,
otherwise <I>e</I> is <I>X</I>. <TT>T</TT> is the return
type of the function call; the invented variable <TT>t</TT>
is the result of the function call.</INS></P>

</BLOCKQUOTE>

<P><B>Notes from the August, 2021 teleconference:</B></P>

<P>A simpler approach would be simply to use a phrase like
&#8220;returned object or reference&#8221; in place of the
current wording referring to glvalues and prvalues. This
change was regarded as editorial. The issue will remain in
"review" status until CWG can look over the wording
change.</P>

<BR><BR><HR>
<A NAME="2995"></A><H4>2995.
  
Meaning of flowing off the end of a function
</H4>
<B>Section: </B>8.8.4&#160; [<A href="https://wg21.link/stmt.return">stmt.return</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2025-02-16<BR>




<P>Consider:</P>

<PRE>
  int foo() {
    struct S {
      ~S() noexcept(false) { throw 1; }
    } s;
  }

  int main() {
    try {
      foo();
    } catch (int x) {
      return x;
    }
  }
</PRE>

<P>Does this program exit with code 1, or does it have undefined
behavior per 8.8.4 [<A href="https://wg21.link/stmt.return#4">stmt.return</A>] paragraph 4?  Implementations
differ.</P>

<P>The crucial question is whether the undefined behaviour caused by
"flowing off the end" is before or after the closing brace of the
function body, which is where the destruction of local variables
occurs.  Current consensus appears to solidify around "after".</P>

<P>This approach is consistent with the observation that the following
two functions, given identical (valid) function bodies, should have
the same semantics:</P>

<PRE>
  void f() {{ ... }}
  void g() { ... }
</PRE>

<P><U>Suggested resolution (option 1):</U></P>

<OL>
<LI>
<P>Change in 6.10.3.1 [<A href="https://wg21.link/basic.start.main#5">basic.start.main</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

A return statement (8.8.4 [<A href="https://wg21.link/stmt.return">stmt.return</A>]) in main has the effect
of leaving the main function (destroying any objects with automatic
storage duration) and calling std::exit with the return value as the
argument. If control flows off the end of
<DEL>the <I>compound-statement</I> of</DEL> main, the effect is
equivalent to a return with operand 0 <DEL>(see also
14.4 [<A href="https://wg21.link/except.handle">except.handle</A>])</DEL>.

</BLOCKQUOTE>
</LI>

<LI>
<P>Add a new paragraph at the end of 8.4 [<A href="https://wg21.link/stmt.block">stmt.block</A>]:</P>

<BLOCKQUOTE>

<P>[<I>Note 1:</I> A compound statement defines a block scope
(6.4 [<A href="https://wg21.link/basic.scope">basic.scope</A>]). A declaration is a statement
(8.10 [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>]). &#8212;<I>end note</I>]</P>

<P class="ins">
Control is said to <I>reach the end of a compound-statement</I>
<UL class="ins">
<LI>when its last statement completes normally and is not
a <I>jump-statement</I> (8.8 [<A href="https://wg21.link/stmt.jump">stmt.jump</A>]) and the
destruction of block variables with automatic storage duration, if
any, completes normally (8.10 [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>]), or</LI>
<LI>when the <I>compound-statement</I> is executed and contains no
statements.</LI>
</UL>
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 8.8.4 [<A href="https://wg21.link/stmt.return#4">stmt.return</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<INS>Control is said to <I>flow off the end</I> of a function when
control reaches the end of its <I>compound-statement</I> or that of
a <I>handler</I> of its <I>function-try-block</I>
(8.4 [<A href="https://wg21.link/stmt.block">stmt.block</A>]).</INS> Flowing off the end of a
constructor, a destructor, or a non-coroutine function with a cv void
return type <DEL>is equivalent to a return with no
operand</DEL> <INS>returns control to the caller,
except as specified in 14.4 [<A href="https://wg21.link/except.handle">except.handle</A>]</INS>. Otherwise,
flowing off the end of a function that is neither main
(6.10.3.1 [<A href="https://wg21.link/basic.start.main">basic.start.main</A>]) nor a coroutine
(9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]) results in undefined behavior.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 8.8.5 [<A href="https://wg21.link/stmt.return.coroutine#3">stmt.return.coroutine</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

If a search for the name <TT>return_void</TT> in the scope of the
promise type finds any declarations, <DEL>flowing
off</DEL> <INS>reaching</INS> the end of a
coroutine's <INS>original</INS> <I>function-body</I> <INS>(8.4 [<A href="https://wg21.link/stmt.block">stmt.block</A>])</INS>
is equivalent to a co_return with no operand; otherwise <DEL>flowing
off</DEL> <INS>reaching</INS> the end of a
coroutine's <INS>original</INS> <I>function-body</I> results in
undefined behavior.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#6">dcl.fct.def.coroutine</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

[<I>Note 1:</I> If <TT>return_void</TT> is found, <DEL>flowing off</DEL> <INS>reaching</INS> the end of a
<DEL>coroutine</DEL> <INS>coroutine's original <I>function-body</I>
(8.4 [<A href="https://wg21.link/stmt.block">stmt.block</A>])</INS> is equivalent to a <TT>co_return</TT>
with no operand.  Otherwise, <DEL>flowing off</DEL>
<INS>reaching</INS> the end of a <DEL>coroutine</DEL>
<INS>coroutine's original <I>function-body</I></INS> results in
undefined behavior (8.8.5 [<A href="https://wg21.link/stmt.return.coroutine">stmt.return.coroutine</A>]). &#8212;<I>end
note</I>]

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#11">dcl.fct.def.coroutine</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

The coroutine state is destroyed when control flows off the end of the
coroutine <INS>(8.8.4 [<A href="https://wg21.link/stmt.return">stmt.return</A>])</INS> or the destroy member
function (17.13.4.6 [<A href="https://wg21.link/coroutine.handle.resumption">coroutine.handle.resumption</A>]) of a coroutine handle
(17.13.4 [<A href="https://wg21.link/coroutine.handle">coroutine.handle</A>]) that refers to the coroutine is
invoked. In the latter case, control in the coroutine is considered to
be transferred out of the function (8.10 [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>]). The
storage for the coroutine state is released by calling a non-array
deallocation function (6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>]). If destroy is
called for a coroutine that is not suspended, the program has
undefined behavior.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 14.4 [<A href="https://wg21.link/except.handle#14">except.handle</A>] paragraph 14 as follows:</P>

<BLOCKQUOTE>

The currently handled exception is rethrown if control reaches the end
<INS>(8.4 [<A href="https://wg21.link/stmt.block">stmt.block</A>])</INS> of a <I>handler</I> of
the <I>function-try-block</I> of a constructor or
destructor. <DEL>Otherwise, flowing off the end of
the <I>compound-statement</I> of a handler of
a <I>function-try-block</I> is equivalent to flowing off the end of
the <I>compound-statement</I> of that function (see
8.8.4 [<A href="https://wg21.link/stmt.return">stmt.return</A>]).</DEL>

</BLOCKQUOTE>
</LI>

</OL>

<P><U>Possible resolution (option 2):</U></P>

<OL>
<LI>
<P>Change in 6.10.3.1 [<A href="https://wg21.link/basic.start.main#5">basic.start.main</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

A return statement (8.8.4 [<A href="https://wg21.link/stmt.return">stmt.return</A>]) in main has the effect
of leaving the main function (destroying any objects with automatic
storage duration) and calling std::exit with the return value as the
argument. <DEL>If control flows off the end of
the <I>compound-statement</I> of main, the effect is equivalent to a
return with operand 0 (see also 14.4 [<A href="https://wg21.link/except.handle">except.handle</A>])</DEL>.
<INS>The statement <TT>return 0;</TT> is appended to the outermost
blocks of <TT>main</TT> (8.4 [<A href="https://wg21.link/stmt.block">stmt.block</A>]).</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Add a new paragraph at the end of 8.4 [<A href="https://wg21.link/stmt.block">stmt.block</A>]:</P>

<BLOCKQUOTE>

<P>[<I>Note 1:</I> A compound statement defines a block scope
(6.4 [<A href="https://wg21.link/basic.scope">basic.scope</A>]). A declaration is a statement
(8.10 [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>]). &#8212;<I>end note</I>]</P>

<DIV class="ins">
<P>The <I>outermost blocks</I> of a function are
<UL>
<LI>the <I>compound-statement</I> of its <I>function-body</I> or
<I>function-try-block</I> (if any) and</LI>
<LI>the <I>compound-statement</I>s of the <I>handler</I>s of its
<I>function-try-block</I> (if any).</LI>
</UL>
[Note: A defaulted or deleted function has no outermost blocks. -- end note]
</P>

<P>
A statement <I>S</I> is <I>appended</I> to a <I>compound-statement</I>
by inserting <I>S</I> immediately prior to the closing <TT>}</TT>.
</P>

<P>The statement <TT>throw;</TT> is appended to
the <I>compound-statement</I>s of the <I>handler</I>s of
a <I>function-try-block</I> of a constructor or destructor.  The
statement <TT>return;</TT> is appended to any other outermost block of
a non-coroutine function with a <I>cv</I> <TT>void</TT> return type or
with no return type.
</P>

<P>
If control flows off the end of an outermost block of a function and
the destruction of block variables with automatic storage duration, if
any, completes normally (8.10 [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>]), the behavior is
undefined.  [Note: Control never flows off the end of <TT>main</TT>
(6.10.3.1 [<A href="https://wg21.link/basic.start.main">basic.start.main</A>]), a constructor, a destructor, or a
void-returning function. -- end note]
</P>
</DIV>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 8.8.4 [<A href="https://wg21.link/stmt.return#4">stmt.return</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE class="del">

Flowing off the end of a constructor, a destructor, or a non-coroutine
function with a cv void return type is equivalent to a return with no
operand. Otherwise, flowing off the end of a function that is neither
main (6.10.3.1 [<A href="https://wg21.link/basic.start.main">basic.start.main</A>]) nor a coroutine
(9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]) results in undefined behavior.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 8.8.5 [<A href="https://wg21.link/stmt.return.coroutine#3">stmt.return.coroutine</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE class="del">

If a search for the name <TT>return_void</TT> in the scope of the
promise type finds any declarations, flowing off the end of a
coroutine's <I>function-body</I> is equivalent to a co_return with no
operand; otherwise flowing offthe end of a coroutine's
<I>function-body</I> results in undefined behavior.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#6">dcl.fct.def.coroutine</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

If searches for the names return_void and return_value in the scope of
the promise type each find any declarations, the program is
ill-formed.
<INS>Otherwise, if the search for the name <TT>return_void</TT> in the
scope of the promise type finds any declarations, the statement
<TT>co_return;</TT> is appended to the coroutine's original
<I>function-body</I> (8.4 [<A href="https://wg21.link/stmt.block">stmt.block</A>],
8.8.5 [<A href="https://wg21.link/stmt.return.coroutine">stmt.return.coroutine</A>]).</INS>
<DEL>[<I>Note 1:</I> If <TT>return_void</TT> is found, flowing off the
end of a coroutine is equivalent to a <TT>co_return</TT> with no
operand. Otherwise, flowing</DEL> <INS>Flowing</INS> off the end of a
<DEL>coroutine</DEL> <INS>coroutine's original
<I>function-body</I></INS> results in undefined behavior
<DEL>(8.8.5 [<A href="https://wg21.link/stmt.return.coroutine">stmt.return.coroutine</A>])</DEL>. <DEL>&#8212;<I>end
note</I>]</DEL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#11">dcl.fct.def.coroutine</A>] paragraph 11 as follows:</P>

<BLOCKQUOTE>

The coroutine state is destroyed <DEL>when control flows off the end
of the coroutine</DEL> <INS>at the end of its
replacement <I>function-body</I> (8.4 [<A href="https://wg21.link/stmt.block">stmt.block</A>])</INS> or
when the destroy member function (17.13.4.6 [<A href="https://wg21.link/coroutine.handle.resumption">coroutine.handle.resumption</A>]) of a
coroutine handle (17.13.4 [<A href="https://wg21.link/coroutine.handle">coroutine.handle</A>]) that refers to the
coroutine is invoked. In the latter case, control in the coroutine is
considered to be transferred out of the function
(8.10 [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>]). The storage for the coroutine state is
released by calling a non-array deallocation function
(6.8.6.5.3 [<A href="https://wg21.link/basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>]). If destroy is called for a coroutine
that is not suspended, the program has undefined behavior.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 14.4 [<A href="https://wg21.link/except.handle#14">except.handle</A>] paragraph 14 as follows:</P>

<BLOCKQUOTE class="del">

The currently handled exception is rethrown if control reaches the end
of a <I>handler</I> of
the <I>function-try-block</I> of a constructor or
destructor. Otherwise, flowing off the end of
the <I>compound-statement</I> of a handler of
a <I>function-try-block</I> is equivalent to flowing off the end of
the <I>compound-statement</I> of that function (see
8.8.4 [<A href="https://wg21.link/stmt.return">stmt.return</A>]).

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="3052"></A><H4>3052.
  
Unclear handling of checks on discarded <TT>return</TT> statements
</H4>
<B>Section: </B>8.8.4&#160; [<A href="https://wg21.link/stmt.return">stmt.return</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

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


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/737">#737</A>.)</P>

<P>Consider:</P>

<PRE>
  auto f() {
    if constexpr (false) return;
    return 3;
  }
</PRE>

<P>Is this well-formed?  The first <TT>return</TT> statement is
discarded, so the return type is not deduced from it.  However,
8.8.4 [<A href="https://wg21.link/stmt.return#2">stmt.return</A>] paragraph 2 still seems to apply; discarded
return statements are not excluded:</P>

<BLOCKQUOTE>

... A return statement with no operand shall be used only in a function
whose return type is cv void, a constructor
(11.4.5 [<A href="https://wg21.link/class.ctor">class.ctor</A>]), or a destructor
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]).  A return statement with an operand of
type void shall be used only in a function that has a cv void return
type. A return statement with any other operand shall be used only in
a function that has a return type other than cv void; ...

</BLOCKQUOTE>

<P><U>Suggested resolution:</U></P>

<P>Change in 8.8.4 [<A href="https://wg21.link/stmt.return#2">stmt.return</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

... A return statement with no operand shall <DEL>be
used</DEL> <INS>appear as a non-discarded statement
(8.5.2 [<A href="https://wg21.link/stmt.if">stmt.if</A>])</INS> only in a function whose return
type is cv void, a constructor (11.4.5 [<A href="https://wg21.link/class.ctor">class.ctor</A>]), or a
destructor (11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]).  A return statement with an
operand of type void shall <DEL>be used</DEL>
<INS>appear as a non-discarded statement</INS> only in a function that
has a cv void return type. A return statement with any other operand
shall <DEL>be used</DEL> <INS>appear as a non-discarded
statement</INS> only in a function that has a return type other than
cv void; <INS>such a non-discarded</INS> return statement initializes
the returned reference or prvalue result object of the (explicit or
implicit) function call by copy-initialization
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) from the operand.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2123"></A><H4>2123.
  
Omitted constant initialization of local static variables
</H4>
<B>Section: </B>8.10&#160; [<A href="https://wg21.link/stmt.dcl">stmt.dcl</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

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




<p>According to 8.10 [<A href="https://wg21.link/stmt.dcl#4">stmt.dcl</A>] paragraph 4,

<BLOCKQUOTE>

The zero-initialization (9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) of all
block-scope variables with static storage duration
(6.8.6.2 [<A href="https://wg21.link/basic.stc.static">basic.stc.static</A>]) or thread storage duration
(6.8.6.3 [<A href="https://wg21.link/basic.stc.thread">basic.stc.thread</A>]) is performed before any other
initialization takes place. Constant initialization
(6.10.3.2 [<A href="https://wg21.link/basic.start.static">basic.start.static</A>]) of a block-scope entity with
static storage duration, if applicable, is performed before
its block is first entered.

</BLOCKQUOTE></p>

<P>The fact that a variable need not be constant-initialized if its
block is not entered appears to allow inspection of the variable
after zero-initialization but before constant initialization:</P>

<PRE>
  constexpr int x = 0;

  auto foo() {
    constexpr static const int *p = &amp;x;
    struct A {
      const int *const &amp;getPtr() { return p; }
    } a;
    return a;
  }

  int xcpy = *decltype(foo()){ }.getPtr();

  int main(void) {
    return xcpy;
  }
</PRE>

<P>For a related example, consider:</P>

<PRE>
  //<SPAN CLASS="cmnt"> tu1.cpp</SPAN>
  extern const int a = 1;
  inline auto f() {
    static const int b = a;
    struct A { auto operator()() { return &amp;b; } } a;
    return a;
  }

  //<SPAN CLASS="cmnt"> tu2.cpp</SPAN>
  extern const int a;
  inline auto f() {
    static const int b = a;
    struct A { auto operator()() { return &amp;b; } } a;
    return a;
  }
  int main() {
    return *decltype(f())()();
  }
</PRE>

<P>Here, <TT>b</TT> may or may not have constant initialization,
but we don't have an ODR violation.</P>

<P>If we want to support such code, the nicest option would be
to say that the ODR requires us to act as if we pick one of the
definitions of the inline function, which requires us to make a
consistent choice for all static storage duration variables
within a given function.  Alternatively, we could say that if
multiple definitions of a variable disagree over whether it has
constant initialization, then it does not, allowing more
implementation simplicity and no functional change outside of
pathological cases.</P>

<P><B>Notes from the February, 2016 meeting:</B></P>

<P>The second example will be dealt with separately under
<A HREF="cwg_defects.html#2242">issue 2242</A>. For the first example,
the Standard should require that local types can be used outside
their function only via a returned object. It was still to be
decided whether this should be undefined behavior or an error
on use of such a type. It was also noted that the same issue can
arise with static member functions.</P>

<BR><BR><HR>
<A NAME="2963"></A><H4>2963.
  
Paradoxical variable-or-function declaration
</H4>
<B>Section: </B>8.11&#160; [<A href="https://wg21.link/stmt.ambig">stmt.ambig</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Davis Herring
 &#160;&#160;&#160;

 <B>Date: </B>2024-11-17<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/643">#643</A>.)
</P>

<P>Consider:</P>

<PRE>
  struct A {
    static int b;
  };
  struct B {
    B(int);
    B operator()();
    using b=int;
  };

  namespace P {
    B A(decltype(A())::b);
  }
</PRE>

<P>If <TT>P::A</TT> is a variable, then <TT>decltype(A())::b</TT> is
its initializer, and the <TT>A</TT> therein refers to the variable.
That implies that the <TT>decltype</TT> is <TT>B</TT>
and <TT>B::b</TT> is <TT>int</TT>, thus the declaration should be a
function declaration instead.</P>

<P>If <TT>P::A</TT> is a function, then its name is not available for
lookup in its parameter list (see 6.4.2 [<A href="https://wg21.link/basic.scope.pdecl#1">basic.scope.pdecl</A>] paragraph 1), so <TT>A</TT> is <TT>::A</TT> and <TT>A::b</TT> is a
varaible, thus the declaration should be a variable declaration
instead.</P>

<P>Implementations agree that <TT>P::A</TT> is a variable, but use the
interpretation of <TT>decltype(A())</TT> that finds <TT>::A</TT>,
presumably from some trial parse.</P>

<P><U>Suggested resolution:</U></P>

<P>Extend the prohibition on using <TT>A</TT> in a template argument
(8.11 [<A href="https://wg21.link/stmt.ambig#3">stmt.ambig</A>] paragraph 3 to <TT>decltype</TT>.</P>

<BR><BR><HR>
<A NAME="157"></A><H4>157.
  
Omitted typedef declarator
</H4>
<B>Section: </B>9.1&#160; [<A href="https://wg21.link/dcl.pre">dcl.pre</A>]
 &#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>9.1 [<A href="https://wg21.link/dcl.pre#3">dcl.pre</A>] 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>
(11.3 [<A href="https://wg21.link/class.name">class.name</A>]
), 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
(11.4.10 [<A href="https://wg21.link/class.bit">class.bit</A>]
), 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
9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]
, 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
9.1 [<A href="https://wg21.link/dcl.pre#3">dcl.pre</A>] 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>9.2.2&#160; [<A href="https://wg21.link/dcl.stc">dcl.stc</A>]
 &#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 9.2.2 [<A href="https://wg21.link/dcl.stc">dcl.stc</A>].  I don't
see it there, or anywhere.</P>

<P>
<U>Gabriel Dos Reis</U>: Or in 6.7 [<A href="https://wg21.link/basic.link">basic.link</A>] 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 6.7 [<A href="https://wg21.link/basic.link#8">basic.link</A>] 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 6.7 [<A href="https://wg21.link/basic.link#5">basic.link</A>] paragraph 5.</P>

<BR><BR><HR>
<A NAME="2232"></A><H4>2232.
  
<TT>thread_local</TT> anonymous unions
</H4>
<B>Section: </B>9.2.2&#160; [<A href="https://wg21.link/dcl.stc">dcl.stc</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Herrick
 &#160;&#160;&#160;

 <B>Date: </B>2016-02-23<BR>


<P>It is not clear from the current wording whether the
<TT>thread_local</TT> specifier can be applied to anonymous unions
or not. According to 9.2.2 [<A href="https://wg21.link/dcl.stc#3">dcl.stc</A>] paragraph 3,</P>

<BLOCKQUOTE>

The <TT>thread_local</TT> specifier indicates that the named entity has
thread storage duration (6.8.6.3 [<A href="https://wg21.link/basic.stc.thread">basic.stc.thread</A>]). It shall be applied
only to the names of variables of namespace or block scope and to the names
of static data members.

</BLOCKQUOTE>

<P>One might think that an anonymous union object would be a
&#8220;variable,&#8221; but the next paragraph seems to treat variables
and anonymous unions as distinct:</P>

<BLOCKQUOTE>

The <TT>static</TT> specifier can be applied only to names of variables and
functions and to anonymous unions (11.5.2 [<A href="https://wg21.link/class.union.anon">class.union.anon</A>]).

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2973"></A><H4>2973.
  
Does an <I>alias-declaration</I> introduce a name for linkage purposes?
</H4>
<B>Section: </B>9.2.4&#160; [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2024-12-19<BR>




<P>Consider:</P>

<PRE>
   using A = struct { int i; };
</PRE>

<P>Does the unnamed class have <TT>A</TT> as its name for linkage
purposes?  There is implementation divergence.</P>

<P><U>Possible resolution (option 1):</U></P>

<OL>
<LI>
<P>Change in 6.7 [<A href="https://wg21.link/basic.link#4">basic.link</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

... The name of an entity that belongs to a namespace scope, that has not
been given internal linkage above, and that is the name of
<UL>
<LI>a variable; or</LI>
<LI>a function; or</LI>
<LI>a named class (11.1 [<A href="https://wg21.link/class.pre">class.pre</A>]), or an unnamed class
defined in a typedef
declaration <INS>or <I>alias-declaration</I></INS> in which the class
has the typedef name for linkage purposes
(9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]); or</LI>
<LI>a named enumeration (9.8.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]), or an unnamed
enumeration defined in a typedef
declaration <INS>or <I>alias-declaration</I></INS> in which the
enumeration has the typedef name for linkage purposes
(9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]); or</LI>
<LI>an unnamed enumeration that has an enumerator as a name for
linkage purposes (9.8.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]); or</LI>
<LI>a template</LI>
</UL>
has its linkage determined as follows: ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.7 [<A href="https://wg21.link/basic.link#5">basic.link</A>] paragraph 5 as follows:</P>
<BLOCKQUOTE>

In addition, a member function, a static data member, a named class or
enumeration that inhabits a class scope, or an unnamed class or
enumeration defined in a typedef declaration <INS>or
<I>alias-declaration</I></INS> that inhabits a class scope such that
the class or enumeration has the typedef name for linkage purposes
(9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]), has the same linkage, if any, as the
name of the class of which it is a member.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.9.1 [<A href="https://wg21.link/basic.types.general#6">basic.types.general</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

... [<I>Note 3:</I> The type of a pointer or reference to array of unknown
bound permanently points to or refers to an incomplete type. An array
of unknown bound named by a typedef declaration <INS>or
<I>alias-declaration</I></INS> permanently refers to an incomplete
type. In either case, the array type cannot be
completed. &#8212;<I>end note</I>] ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.2.4 [<A href="https://wg21.link/dcl.typedef#4">dcl.typedef</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

An unnamed class or enumeration C defined in a typedef
declaration <INS>or <I>alias-declaration</I></INS> has the
first <I>typedef-name</I> declared by the declaration to be of type C
as its typedef name for linkage purposes (6.7 [<A href="https://wg21.link/basic.link">basic.link</A>]).
[<I>Note 2:</I> A typedef declaration <INS>or
<I>alias-declaration</I></INS> involving
a <I>lambda-expression</I> does not itself define the associated
closure type, and so the closure type is not given a typedef name for
linkage purposes. &#8212;<I>end note</I>] [<I>Example 4:</I>
<PRE>
  typedef struct { } *ps, S;    //<SPAN CLASS="cmnt"> S is the typedef name for linkage purposes</SPAN>
  typedef decltype([]{}) C;     //<SPAN CLASS="cmnt"> the closure type has no typedef name for linkage purposes</SPAN>
<INS>  using U = class { };          // U<SPAN CLASS="cmnt"> is the typedef name for linkage purposes</SPAN></INS>
</PRE>
&#8212;<I>end example</I>]

</BLOCKQUOTE>
</LI>
</OL>

<P><U>Possible resolution (option 2):</U></P>

<OL>
<LI>
<P>Change in 6.2 [<A href="https://wg21.link/basic.def#2">basic.def</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

Each entity declared by a <I>declaration</I> is also <I>defined</I> by
that declaration unless:
<UL>
<LI>...</LI>
<LI>it is <DEL>a typedef</DEL> <INS>an alias</INS> declaration
(9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]),</LI>
<LI class="del">it is an <I>alias-declaration</I> (9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]),</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.7 [<A href="https://wg21.link/basic.link#4">basic.link</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

... The name of an entity that belongs to a namespace scope, that has not
been given internal linkage above, and that is the name of
<UL>
<LI>a variable; or</LI>
<LI>a function; or</LI>
<LI>a named class (11.1 [<A href="https://wg21.link/class.pre">class.pre</A>]), or an unnamed class
defined in <DEL>a typedef</DEL> <INS>an alias</INS> declaration in
which the class has the typedef name for linkage purposes
(9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]); or</LI>
<LI>a named enumeration (9.8.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]), or an unnamed
enumeration defined in <DEL>a typedef</DEL> <INS>an alias</INS>
declaration in which the enumeration has the typedef name for linkage
purposes (9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]); or</LI>
<LI>an unnamed enumeration that has an enumerator as a name for
linkage purposes (9.8.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]); or</LI>
<LI>a template</LI>
</UL>
has its linkage determined as follows: ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.7 [<A href="https://wg21.link/basic.link#5">basic.link</A>] paragraph 5 as follows:</P>
<BLOCKQUOTE>

In addition, a member function, a static data member, a named class or
enumeration that inhabits a class scope, or an unnamed class or
enumeration defined in <DEL>a typedef</DEL> <INS>an alias</INS>
declaration that inhabits a class scope such that the class or
enumeration has the typedef name for linkage purposes
(9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]), has the same linkage, if any, as the
name of the class of which it is a member.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.9.1 [<A href="https://wg21.link/basic.types.general#6">basic.types.general</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

... [<I>Note 3:</I> The type of a pointer or reference to array of
unknown bound permanently points to or refers to an incomplete
type. An array of unknown bound named by <DEL>a typedef</DEL> <INS>an
alias</INS> declaration <INS>(9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>])</INS>
permanently refers to an incomplete type. In either case, the array
type cannot be completed. &#8212;<I>end note</I>] ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.1 [<A href="https://wg21.link/dcl.pre#5">dcl.pre</A>] paragraph 5 as follows:</P>



<BLOCKQUOTE>

If the <I>decl-specifier-seq</I> contains the <TT>typedef</TT> specifier, <INS>see 9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>].</INS>
<DEL>the declaration is a <I>typedef declaration</I> and
each <I>declarator-id</I> is declared to be a <I>typedef-name</I>,
synonymous with its associated type (9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]).
[<I>Note 4:</I> Such a <I>declarator-id</I> is an identifier
(11.4.8.3 [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>]). &#8212;<I>end note</I>]</DEL>
Otherwise, if the type associated with a <I>declarator-id</I> is a
function type (9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]), the declaration is a
function declaration. Otherwise, if the type associated with
a <I>declarator-id</I> is an object or reference type, the declaration
is an object declaration. Otherwise, the program is ill-formed.

</BLOCKQUOTE>
</LI>

<LI>
<P>Add a new paragraph after 9.2.4 [<A href="https://wg21.link/dcl.typedef#2">dcl.typedef</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<P>... The <I>defining-type-specifier-seq</I> of the <I>defining-type-id</I>
shall not define a class or enumeration if
the <I>alias-declaration</I> is the declaration of
a <I>template-declaration</I>.
</P>

<P class="ins">
An <I>alias declaration</I> is a typedef declaration or an
<I>alias-declaration</I>.
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.2.4 [<A href="https://wg21.link/dcl.typedef#4">dcl.typedef</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

An unnamed class or enumeration C defined in <DEL>a
typedef</DEL> <INS>an alias</INS> declaration has the
first <I>typedef-name</I> declared by the declaration to be of type C
as its typedef name for linkage purposes (6.7 [<A href="https://wg21.link/basic.link">basic.link</A>]).
[<I>Note 2:</I> <DEL>A typedef</DEL> <INS>An alias</INS> declaration
involving a <I>lambda-expression</I> does not itself define the
associated closure type, and so the closure type is not given a
typedef name for linkage purposes. &#8212;<I>end note</I>] [<I>Example
4:</I>
<PRE>
  typedef struct { } *ps, S;    //<SPAN CLASS="cmnt"> S is the typedef name for linkage purposes</SPAN>
  typedef decltype([]{}) C;     //<SPAN CLASS="cmnt"> the closure type has no typedef name for linkage purposes</SPAN>
<INS>  using U = class { };          // U<SPAN CLASS="cmnt"> is the typedef name for linkage purposes</SPAN></INS>
</PRE>
&#8212;<I>end example</I>]

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="3012"></A><H4>3012.
  
Deviating <TT>constexpr</TT> or <TT>consteval</TT> across translation units
</H4>
<B>Section: </B>9.2.6&#160; [<A href="https://wg21.link/dcl.constexpr">dcl.constexpr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Benjamin Sch.
 &#160;&#160;&#160;

 <B>Date: </B>2025-03-15<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/683">#683</A>.)</P>

<P>Subclause 9.2.6 [<A href="https://wg21.link/dcl.constexpr#1">dcl.constexpr</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

... If any declaration of a function or function template has
a <TT>constexpr</TT> or <TT>consteval</TT> specifier, then all its
declarations shall contain the same specifier.

</BLOCKQUOTE>

<P>This rule should not require a diagnostic if the declarations are
not mutually reachable.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 9.2.6 [<A href="https://wg21.link/dcl.constexpr#1">dcl.constexpr</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

... If any declaration of a function or function template <INS>F</INS>
has a <TT>constexpr</TT> or <TT>consteval</TT> specifier, then all its
declarations shall contain the same specifier<INS>; a diagnostic is
required only if a declaration of F reachable from another declaration
of F deviates</INS>.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2195"></A><H4>2195.
  
Unsolicited reading of trailing volatile members
</H4>
<B>Section: </B>9.2.9.2&#160; [<A href="https://wg21.link/dcl.type.cv">dcl.type.cv</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-11-06<BR>




<P>Consider:</P>

<PRE>
  struct A {
    ~A();
    double d;
    float f;
  };

  struct B : A { volatile int i; };

  A foo(B *bp) { return *static_cast&lt;A *&gt;(bp); }
</PRE>

<P>Is it okay for the memory associated with <TT>bp-&gt;i</TT> to be
accessed by <TT>foo</TT>?</P>

<P>See also 9.2.9.2 [<A href="https://wg21.link/dcl.type.cv#5">dcl.type.cv</A>] paragraph 5</P>

<BLOCKQUOTE>

The semantics of an access through a volatile glvalue are
implementation-defined. If an attempt is made to access an object
defined with a volatile-qualified type through the use of a
non-volatile glvalue, the behavior is undefined.

</BLOCKQUOTE>

<P><B>Additional notes from the November, 2016 meeting:</B></P>

<P>See also national body comment CH2, addressed in March, 2017 by
<A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0612r0.html">P0612R0</A>.</P>

<BR><BR><HR>
<A NAME="3003"></A><H4>3003.
  
Naming a deducible template for class template argument deduction
</H4>
<B>Section: </B>9.2.9.3&#160; [<A href="https://wg21.link/dcl.type.simple">dcl.type.simple</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

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


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/670">#670</A>.)</P>

<P>Consider:</P>

<PRE>
  template &lt;template &lt;typename&gt; class TT&gt;
  void f() { TT x(42); }  //<SPAN CLASS="cmnt"> #1</SPAN>

  template &lt;typename T&gt; struct A { A(T); };

  void g() { f&lt;A&gt;(); }
</PRE>

<P>Using a template template parameter should not enable class
template argument deduction at #1.  However, while the normative rules
are clear, all implementations accept the code above, but fail
(sometimes spectacularly) when parsing situations involving alias
templates:</P>

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

  template &lt;typename T, template &lt;typename&gt; class TT = A&gt;
  using Alias = TT&lt;T&gt;;

  template &lt;typename T&gt;
  using Alias2 = Alias&lt;T&gt;;

  void h() { Alias2 a(42); }
  void h2() { Alias a(42); }
</PRE>

<P><U>Possible resolution:</U></P>

<P>Change in 9.2.9.3 [<A href="https://wg21.link/dcl.type.simple#3">dcl.type.simple</A>] paragraph 3 and split into
numbered paragraphs as follows:</P>

<BLOCKQUOTE>

<P>(3) A <I>placeholder-type-specifier</I> is a placeholder for a type to be
deduced (9.2.9.7 [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]).</P>

<P>(4) A <I>type-specifier</I> of the
form
<PRE>typename/opt <I>nested-name-specifier</I>/opt <I>template-name</I>
</PRE>
is a placeholder for a deduced class type
(9.2.9.8 [<A href="https://wg21.link/dcl.type.class.deduct">dcl.type.class.deduct</A>]). The <I>nested-name-specifier</I>, if
any, shall be non-dependent and the <I>template-name</I> shall name a
deducible template.  A deducible template is either a class template
or is an alias template whose <I>defining-type-id</I> is of the form
typenameopt <I>nested-name-specifieropt</I>
templateopt <I>simple-template-id</I> where
the <I>nested-name-specifier</I> (if any) is non-dependent and
the <I>template-name</I> of the <I>simple-template-id</I> names a
deducible template.  <INS>[Note: A template template parameter
(13.2 [<A href="https://wg21.link/temp.param">temp.param</A>]) does not name a deducible template. -- end
note]</INS> [<I>Note:</I> An <I>injected-class-name</I> is never
interpreted as a <I>template-name</I> in contexts where class template
argument deduction would be performed
(13.8.2 [<A href="https://wg21.link/temp.local">temp.local</A>]). &#8212;<I>end note</I>]</P>

<P>(5) The other <I>simple-type-specifier</I>s specify either a
previously-declared type, a type determined from an expression, or one
of the fundamental types (6.9.2 [<A href="https://wg21.link/basic.fundamental">basic.fundamental</A>]).</P>

<P>(6)Table 17 summarizes the valid combinations
of <I>simple-type-specifier</I> s and the types they specify.</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="144"></A><H4>144.
  
Position of <TT>friend</TT> specifier
</H4>
<B>Section: </B>9.2.9.5&#160; [<A href="https://wg21.link/dcl.type.elab">dcl.type.elab</A>]
 &#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>9.2.9.5 [<A href="https://wg21.link/dcl.type.elab#1">dcl.type.elab</A>] 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="1868"></A><H4>1868.
  
Meaning of &#8220;placeholder type&#8221;
</H4>
<B>Section: </B>9.2.9.7&#160; [<A href="https://wg21.link/dcl.spec.auto">dcl.spec.auto</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Dawn Perchik
 &#160;&#160;&#160;

 <B>Date: </B>2014-02-13<BR>




<P>9.2.9 [<A href="https://wg21.link/dcl.type#2">dcl.type</A>] paragraph 2 describes the <TT>auto</TT>
specifier as &#8220;a placeholder for a type to be deduced.&#8221;
Elsewhere, the Standard refers to the type represented by the
<TT>auto</TT> specifier as a &#8220;placeholder type.&#8221;  This
usage has been deemed confusing by some, requiring either a definition
of one or both terms or rewording to avoid them.</P>

<BR><BR><HR>
<A NAME="2671"></A><H4>2671.
  
friend named by a <I>template-id</I>
</H4>
<B>Section: </B>9.3.4.1&#160; [<A href="https://wg21.link/dcl.meaning.general">dcl.meaning.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Davis Herring
 &#160;&#160;&#160;

 <B>Date: </B>2022-11-18<BR>


<P>Subclause 9.3.4.1 [<A href="https://wg21.link/dcl.meaning.general#1">dcl.meaning.general</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

... If the <I>unqualified-id</I> occurring in a <I>declarator-id</I> is
a <I>template-id</I>, the declarator shall appear in the declaration
of a <I>template-declaration</I>
(13.7 [<A href="https://wg21.link/temp.decls">temp.decls</A>]), <I>explicit-specialization</I>
(13.9.4 [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]), or <I>explicit-instantiation</I>
(13.9.3 [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]).

</BLOCKQUOTE>

<P>However, that is too restrictive and prevents befriending template
specializations, for example:</P>

<PRE>
  template&lt;typename&gt; void f();

  class A {
    friend void f&lt;A&gt;();
  };
</PRE>

<BR><BR><HR>
<A NAME="3030"></A><H4>3030.
  
Initializing array prvalues of unknown bound
</H4>
<B>Section: </B>9.3.4.5&#160; [<A href="https://wg21.link/dcl.array">dcl.array</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2024-02-28<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/509">#509</A>.)</P>

<P>Consider:</P>

<PRE>
  int main(){
    using type = int[];
    type{1,2,3};
  }
</PRE>

<P>Subclause 9.3.4.5 [<A href="https://wg21.link/dcl.array#7">dcl.array</A>] paragraph 7 specifies:</P>

<BLOCKQUOTE>

... An array bound may also be omitted when an object (but not a
non-static data member) of array type is initialized and the
declarator is followed by an initializer (9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>],
11.4 [<A href="https://wg21.link/class.mem">class.mem</A>], 7.6.1.4 [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>],
7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]). In these cases, the array bound is
calculated from the number of initial elements (say, N) supplied
(9.5.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]), and the type of the array is
&#8220;array of N U&#8221;.

</BLOCKQUOTE>

<P>However, there is no "declarator" in the example.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 9.3.4.5 [<A href="https://wg21.link/dcl.array#7">dcl.array</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

... An array bound may also be omitted when an object (but not a
non-static data member) of array type is initialized <DEL>and the
declarator is followed by</DEL> <INS>with</INS> an initializer
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>], 11.4 [<A href="https://wg21.link/class.mem">class.mem</A>],
7.6.1.4 [<A href="https://wg21.link/expr.type.conv">expr.type.conv</A>], 7.6.2.8 [<A href="https://wg21.link/expr.new">expr.new</A>]). In these
cases, the array bound is calculated from the number of initial
elements (say, N) supplied (9.5.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]), and the type
of the array is &#8220;array of N U&#8221;.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1790"></A><H4>1790.
  
Ellipsis following function parameter pack
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Daryle Walker
 &#160;&#160;&#160;

 <B>Date: </B>2013-10-01
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>Although the current wording permits an ellipsis to immediately follow a
function parameter pack, it is not clear that the <TT>&lt;cstdarg&gt;</TT>
facilities permit access to the ellipsis arguments.</P>

<P><B>Rationale (June, 2014):</B></P>

<P>CWG felt that this is a question of language design and thus should
be considered by EWG before any action.</P>

<P><B>EWG 2022-11-11</B></P>

<P>C23 removes the requirement that the last parameter be named
for <TT>va_start</TT>.
This is tracked in github issue
<A HREF="https://github.com/cplusplus/papers/issues/1374">cplusplus/papers#1374</A>.
</P>

<P><B>Additional notes (October, 2023)</B></P>

<P>Paper P2537 (Relax va_start Requirements to Match C)
proposes to relax <TT>va_start</TT> to match C23, tracked via
<A HREF="https://github.com/cplusplus/papers/issues/1200">cplusplus/papers#1200</A>.
</P>

<BR><BR><HR>
<A NAME="2802"></A><H4>2802.
  
Constrained <TT>auto</TT> and redeclaration with non-abbreviated syntax
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2023-09-26<BR>




<P>Consider:</P>

<PRE>
  template&lt;typename T&gt; void f(T);
  void f(auto);
</PRE>

<P>These are redeclarations according to 9.3.4.6 [<A href="https://wg21.link/dcl.fct#22">dcl.fct</A>] paragraph 22:</P>

<BLOCKQUOTE>

... An abbreviated function template is equivalent to a function template
(13.7.7 [<A href="https://wg21.link/temp.fct">temp.fct</A>]) whose <I>template-parameter-list</I>
includes one invented type <I>template-parameter</I> for each generic
parameter type placeholder of the function declaration, in order of
appearance. ...

</BLOCKQUOTE>

<P>The same applies to constrained abbreviated functions:</P>

<PRE>
  template&lt;C T&gt; void g(T);
  void g(C auto);          // <SPAN CLASS="cmnt">redeclaration</SPAN>
</PRE>

<P>However, this leads to a situation where two function templates are
equivalent, but not functionally equivalent:</P>

<PRE>
  template&lt;typename T&gt; requires D&lt;T&gt; void h(C auto); //<SPAN CLASS="cmnt"> #1</SPAN>
  template&lt;typename T, C U&gt; requires D&lt;T&gt; void h(U); //<SPAN CLASS="cmnt"> #2</SPAN>
</PRE>

<P>According to 13.5.3 [<A href="https://wg21.link/temp.constr.decl#3.3">temp.constr.decl</A>] bullet 3.3, #1 has the
associated constraints <TT>D&lt;T&gt; &amp;&amp;
C&lt;auto_param_1&gt;</TT> whereas #2 has the associated
constraints <TT>C&lt;U&gt; &amp;&amp; D&lt;T&gt;</TT> (note reverse
order).  Those are observably different because satisfaction is
checked in lexical order and instantiation of one of the associated
constraints may yield an error not in the immediate context.</P>

<P>A number of options are available:</P>
<UL>
<LI>Change 13.5.3 [<A href="https://wg21.link/temp.constr.decl#3.3">temp.constr.decl</A>] bullet 3.3 to check
constraints from function parameters before those introduced by
a <I>requires-clause</I> in the <I>template-head</I>.
</LI>
<LI>Do not defined the non-abbreviated form to be "equivalent" to the
abbreviated function template in 9.3.4.6 [<A href="https://wg21.link/dcl.fct#22">dcl.fct</A>] paragraph 22.  Redeclarations thus cannot use the other syntax.
</LI>
<LI>The "equivalent" only applies to non-constrained <TT>auto</TT>
parameters.
</LI>
<LI>The "equivalent to" rule could append to
the <I>requires-clause</I> in the <I>template-head</I> instead of
inventing a constrained template parameter.</LI>
</UL>

<BR><BR><HR>
<A NAME="2942"></A><H4>2942.
  
Packs in a function's parameter-type-list
</H4>
<B>Section: </B>9.3.4.6&#160; [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

 <B>Date: </B>2024-10-25<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/629">#629</A>.)
</P>

<P>Subclause 9.3.4.6 [<A href="https://wg21.link/dcl.fct#3">dcl.fct</A>] paragraph 3 highlights a
(singular) pack in a function's parameter-type-list:</P>

<BLOCKQUOTE>

The type of a function is determined using the following rules. The
type of each parameter (including function parameter packs) is
determined from its own <I>parameter-declaration</I>
(9.3 [<A href="https://wg21.link/dcl.decl">dcl.decl</A>]). After determining the type of each
parameter, any parameter of type &#8220;array of T&#8221; or of
function type T is adjusted to be &#8220;pointer to T&#8221;. After
producing the list of parameter types, any
top-level <I>cv-qualifier</I> s modifying a parameter type are deleted
when forming the function type. The resulting list of transformed
parameter types and the presence or absence of the ellipsis or a
function parameter pack is the function's <I>parameter-type-list</I>.

</BLOCKQUOTE>

<P>The property of being a pack is part of the parameter type as
determined by the <I>parameter-declaration</I>, plus there could be
multiple packs involved.</P>

<P><U>Possible resolution</U></P>

<P>Change in 9.3.4.6 [<A href="https://wg21.link/dcl.fct#3">dcl.fct</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

The type of a function is determined using the following rules. The
type of each parameter (including function parameter packs) is
determined from its own <I>parameter-declaration</I>
(9.3 [<A href="https://wg21.link/dcl.decl">dcl.decl</A>]). After determining the type of each
parameter, any parameter of type &#8220;array of T&#8221; or of
function type T is adjusted to be &#8220;pointer to T&#8221;. After
producing the list of parameter types, any
top-level <I>cv-qualifier</I> s modifying a parameter type are deleted
when forming the function type. The resulting list of transformed
parameter types and the presence or absence of the ellipsis <DEL>or a
function parameter pack</DEL> is the function's
<I>parameter-type-list</I>.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="325"></A><H4>325.
  
When are default arguments parsed?
</H4>
<B>Section: </B>9.3.4.7&#160; [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]
 &#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>9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#5">dcl.fct.default</A>] 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 6.4.7 [<A href="https://wg21.link/basic.scope.class#1">basic.scope.class</A>] 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 6.4.7 [<A href="https://wg21.link/basic.scope.class#1">basic.scope.class</A>] 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 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#8">dcl.fct.default</A>] 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>

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

<P>In addition to default arguments, commas in template argument lists
also cause problems in initializers for nonstatic data members:</P>

<PRE>
    struct S {
      int n = T&lt;a,b&gt;(c);  //<SPAN CLASS="cmnt"> ill-formed declarator for member</SPAN> b
                          //<SPAN CLASS="cmnt"> or template argument?</SPAN>
    };
</PRE>

<commmittee_only><P>(This is from #16 of the
<TT>IssuesFoundImplementingC0x.pdf</TT> document on the Bloomington
wiki.</P></commmittee_only>

<P><B>Additional notes (August, 2011):</B></P>

<P>See also issues <A HREF="cwg_defects.html#1352">1352</A> and
<A HREF="cwg_active.html#361">361</A>. </P>

<P><B>Notes from the February, 2012 meeting:</B></P>

<P>It was decided to handle the question of parsing an initializer
like <TT>T&lt;a,b&gt;(c)</TT> (a <I>template-id</I> or two
declarators) in this issue and the remaining questions in <A HREF="cwg_active.html#361">issue 361</A>.  For this issue, a <I>template-id</I> will
only be recognized if there is a preceding declaration of a template.</P>



<P><B>Additional note (November, 2020):</B></P>

<P>Paper P1787R6, adopted at the November, 2020 meeting, partially
addresses this issue.</P>

<BR><BR><HR>
<A NAME="361"></A><H4>361.
  
Forward reference to default argument
</H4>
<B>Section: </B>9.3.4.7&#160; [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]
 &#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>

<P><B>Notes from the February, 2012 meeting:</B></P>

<P>Implementations seem to have come to agreement that this example
is ill-formed.</P>

<P><B>Additional note (March, 2013):</B></P>

<P>Additional discussion has occurred  suggesting
the following examples as illustrations of this issue:</P>

<PRE>
  struct B {
    struct A { int a = 0; };
    B(A = A());    //<SPAN CLASS="cmnt"> Not permitted?</SPAN>
  };
</PRE>

<P>as well as</P>

<PRE>
  struct C {
   struct A { int a = C().n; }; //<SPAN CLASS="cmnt"> can we use the default argument here?</SPAN>
   C(int k = 0);
   int n;
  };

  bool f();
  struct D {
   struct A { bool a = noexcept(B()); }; //<SPAN CLASS="cmnt"> can we use the default initializer here?</SPAN>
   struct B { int b = f() ? throw 0 : 0; };
  };
</PRE>

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

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

<P>
<A HREF="cwg_defects.html#1330">Issue 1330</A> treats
<I>exception-specification</I>s like default arguments, evaluated in the
completed class type.  That raises the same questions regarding
self-referential <TT>noexcept</TT> clauses that apply to default
arguments.</P>

<P><B>Additional note (November, 2020):</B></P>

<P>Paper P1787R6, adopted at the November, 2020 meeting, partially
addresses this issue.</P>

<BR><BR><HR>
<A NAME="1609"></A><H4>1609.
  
Default arguments and function parameter packs
</H4>
<B>Section: </B>9.3.4.7&#160; [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-01-25<BR>




<P>It is not clear from 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>] whether the
following is well-formed or not:</P>

<PRE>
  template&lt;typename... T&gt;
  void f2(int a = 0, T... b, int c = 1);

  f2&lt;&gt;(); //<SPAN CLASS="cmnt"> parameter </SPAN>a<SPAN CLASS="cmnt"> has the value </SPAN>0<SPAN CLASS="cmnt"> and parameter </SPAN>c<SPAN CLASS="cmnt"> has the value </SPAN>1
</PRE>

<P>(<TT>T... b</TT> is a non-deduced context per
13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#5">temp.deduct.type</A>] paragraph 5, so the template arguments must
be specified explicitly.)</P>

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

<P>CWG agreed that the example should be ill-formed.</P>

<P><B>Additional note (August, 2013):</B></P>

<P>9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#4">dcl.fct.default</A>] paragraph 4 explicitly allows for a function
parameter pack to follow a parameter with a default argument:</P>

<BLOCKQUOTE>

In a given function declaration, each parameter subsequent to a parameter
with a default argument shall have a default argument supplied in this or a
previous declaration or shall be a function parameter pack.

</BLOCKQUOTE>

<P>However, any instantiation of such a function template with a non-empty
pack expansion would result in a function declaration in which one or more
parameters without default arguments (from the pack expansion) would follow
a parameter with a default argument and thus would be ill-formed.  Such a
function template declaration thus violates 13.8 [<A href="https://wg21.link/temp.res#8">temp.res</A>] paragraph 8:
</P>

<BLOCKQUOTE>

If every valid specialization of a variadic template requires an empty
template parameter pack, the template is ill-formed, no diagnostic
required.

</BLOCKQUOTE>

<P>Although the drafting review teleconference of 2013-08-26 suggested
closing the issue as NAD, it is being kept open to discuss and resolve this
apparent contradiction.  </P>

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

<P>CWG agreed that this example should be accepted; the restriction on
default arguments applies to the template declaration itself, not to
its specializations.</P>

<BR><BR><HR>
<A NAME="2701"></A><H4>2701.
  
Default arguments in multiple scopes / inheritance of array bounds in the same scope
</H4>
<B>Section: </B>9.3.4.7&#160; [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2020-11-20<BR>




<P>It appears that P1787R6 has inadvertently changed the rules for
where default arguments can be (re-)declared for a
parameter. Consider:</P>

<PRE>
namespace N {
  void f(int a, int b = 1);
}
void N::f(int a = 1, int b) {} //<SPAN CLASS="cmnt"> valid before P1787R6, invalid afterwards</SPAN>
void N::f(int a, int b = 2) {} //<SPAN CLASS="cmnt"> invalid before P1787R6, valid afterwards,</SPAN>
  // <SPAN CLASS="cmnt">but this default argument will either never be used or will make any call using it ill-formed (unclear which)</SPAN>
</PRE>

<P>Subclause 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#4">dcl.fct.default</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

For non-template functions, default arguments can be added in later
declarations of a function that inhabit the same scope. Declarations
that inhabit different scopes have completely distinct sets of default
arguments. ...

</BLOCKQUOTE>

<P>The problem is that the out-of-line declaration of <TT>N::f</TT>
inhabits the global namespace scope, not the scope of
namespace <TT>N</TT>.</P>

<P>A similar problem exists for inheriting array bounds per 9.3.4.5 [<A href="https://wg21.link/dcl.array#8">dcl.array</A>] paragraph 8:</P>

<BLOCKQUOTE>

Furthermore, if there is a reachable declaration of the entity that
inhabits the same scope in which the bound was specified, an omitted
array bound is taken to be the same as in that earlier declaration,
and similarly for the definition of a static data member of a class.

</BLOCKQUOTE>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 6.4.1 [<A href="https://wg21.link/basic.scope.scope#2">basic.scope.scope</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

...
<INS>The <I>host scope</I> of a declaration is the inhabited scope if
that scope is a block scope and the target scope otherwise.</INS> An
entity <I>belongs</I> to a scope S if S is the target scope of a
declaration of the entity.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.3.4.5 [<A href="https://wg21.link/dcl.array#8">dcl.array</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

Furthermore, if there is a reachable declaration of the entity that
<DEL>inhabits</DEL> <INS>has</INS> the same <INS>host</INS> scope in
which the bound was specified, an omitted array bound is taken to be
the same as in that earlier declaration, and similarly for the
definition of a static data member of a class.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#4">dcl.fct.default</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

For non-template functions, default arguments can be added in later
declarations of a function that <DEL>inhabit</DEL> <INS>have</INS> the
same <INS>host</INS> scope. Declarations
that <DEL>inhabit</DEL> <INS>have</INS> different <INS>host</INS>
scopes have completely distinct sets of default arguments. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#9">dcl.fct.default</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

When an overload set contains a declaration of a function <DEL>that
inhabits a</DEL> <INS>whose host</INS> scope <INS>is</INS> S, any
default argument associated with any reachable declaration <DEL>that
inhabits</DEL> <INS>whose host scope is</INS> S is available to the
call.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.2.4.1 [<A href="https://wg21.link/over.match.best.general#4">over.match.best.general</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

If the best viable function resolves to a function for which multiple
declarations were found, and if any two of these
declarations <DEL>inhabit</DEL> <INS>have</INS>
different <INS>host</INS> scopes and specify a default argument that
made the function viable, the program is ill-formed. [ Example: ...

<PRE>
  void use() {
   f(3);       //<SPAN CLASS="cmnt"> OK, default argument was not used for viability</SPAN>
   f();        //<SPAN CLASS="cmnt"> error: found default argument twice</SPAN>
  }
</PRE>
<PRE class="ins">
  int g(int, int = 0, int = 0);
  void h() {
    using ::g;
    int g(int, int, int = 1);
    int a = g(0); //<SPAN CLASS="cmnt"> OK, block scope declaration does not make the function viable;</SPAN>
           //<SPAN CLASS="cmnt">uses default arguments of declaration whose host scope is the global namespace</SPAN>
  }
</PRE>
-- end example ]
</BLOCKQUOTE>
</LI>
</OL>

<P><B>Additional notes (March, 2025)</B></P>

<P>Reflector discussion pointed out that 12.2.4.1 [<A href="https://wg21.link/over.match.best.general#4">over.match.best.general</A>] paragraph 4 confuses "overload candidates" (at most one per function)
with "function declarations" (possibly several per function).</P>

<P>Option 1: Delete 12.2.4.1 [<A href="https://wg21.link/over.match.best.general#4">over.match.best.general</A>] paragraph 4 and move
its example to the end of 12.2.3 [<A href="https://wg21.link/over.match.viable#2">over.match.viable</A>] paragraph 2.
Change in 12.2.3 [<A href="https://wg21.link/over.match.viable#2.3">over.match.viable</A>] bullet 2.3 as follows:</P>

<BLOCKQUOTE>

A candidate function having more than m parameters is viable only if all parameters following the mth have default arguments ([dcl.fct.default]) <INS>introduced by a declaration of the function considered by overload resolution</INS>. <INS>If the candidate function is selected as the best viable function, there shall be a unique host scope in which such a function declaration declares a default argument for the (m+1)st parameter; the default arguments used in a call to the selected function are the default arguments introduced in that host scope.</INS> For the purposes of overload resolution, the parameter list is truncated on the right, so that there are exactly m parameters.
</BLOCKQUOTE>

<P>Option 2: Treat function declarations in distinct host scopes as
different overload candidates if any default arguments would be
used.</P>

<P>Option 3 (EWG): Disallow default arguments in extern "C" and
block-scope declarations.</P>
<BR><BR><HR>
<A NAME="3062"></A><H4>3062.
  
Overlapping specification of default template arguments
</H4>
<B>Section: </B>9.3.4.7&#160; [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2025-08-13<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/750">#750</A>.)</P>

<P>As written, 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>] applies to default
arguments for constant template parameters, which are specified in
13.2 [<A href="https://wg21.link/temp.param">temp.param</A>] and 13.4.3 [<A href="https://wg21.link/temp.arg.nontype">temp.arg.nontype</A>].  Remove the
overlap.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#1">dcl.fct.default</A>] paragraph 1 as follows:</P>


<BLOCKQUOTE>

If an <I>initializer-clause</I> is specified in
a <I>parameter-declaration</I> <INS>other than
a <I>template-parameter</I> (13.2 [<A href="https://wg21.link/temp.param">temp.param</A>]),</INS>
this <I>initializer-clause</I> is used as a default argument.
[<I>Note 1:</I> Default arguments will be used in calls where trailing
arguments are missing (7.6.1.3 [<A href="https://wg21.link/expr.call">expr.call</A>]). &#8212;<I>end
note</I>]

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.3.4.7 [<A href="https://wg21.link/dcl.fct.default#3">dcl.fct.default</A>] paragraph 3 as follows:</P>



<BLOCKQUOTE>

A default argument shall be specified only in
the <I>parameter-declaration-clause</I> of a function declaration
or <I>lambda-declarator</I> <DEL>or in a <I>template-parameter</I>
(13.2 [<A href="https://wg21.link/temp.param">temp.param</A>])</DEL>. A default argument shall not be
specified for <DEL>a template parameter pack or</DEL> a function
parameter pack. <DEL>If it is specified in
a <I>parameter-declaration-clause</I>, it</DEL> <INS>A default
argument</INS> shall not occur within a <I>declarator</I>
or <I>abstract-declarator</I> of a <I>parameter-declaration</I>. [
Footnote: .... ]

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2991"></A><H4>2991.
  
"array size" is vague
</H4>
<B>Section: </B>9.5.1&#160; [<A href="https://wg21.link/dcl.init.general">dcl.init.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2025-01-16<BR>


<P>In 9.5.1 [<A href="https://wg21.link/dcl.init.general#16.5">dcl.init.general</A>] bullet 16.5, the specification
talks about "array size", but it is unclear whether that is the number
of array elements or the size (in bytes) of the array.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 9.5.1 [<A href="https://wg21.link/dcl.init.general#16.5">dcl.init.general</A>] bullet 16.5 as follows:</P>



<BLOCKQUOTE>

Otherwise, if the destination type is an array, the object is
initialized as follows. The initializer shall be of the form
( <I>expression-list</I> ). Let x1 , . . . , xk be the elements of
the <I>expression-list</I>. If the destination type is an array of
unknown bound, it is defined as having k elements. Let n denote the
<INS>number of elements of the</INS> array <DEL>size</DEL> after this
potential adjustment. If k is greater than n, the program is
ill-formed. Otherwise, ...

</BLOCKQUOTE>


<BR><BR><HR>
<A NAME="2128"></A><H4>2128.
  
Imprecise rule for reference member initializer
</H4>
<B>Section: </B>9.5.2&#160; [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-05-19<BR>




<P>According to 11.9.3 [<A href="https://wg21.link/class.base.init#11">class.base.init</A>] paragraph 11,</P>

<BLOCKQUOTE>

<P>A temporary expression bound to a reference member from
a <I>brace-or-equal-initializer</I> is
ill-formed. [<I>Example:</I>
</P>

<PRE>
  struct A {
    A() = default;          //<SPAN CLASS="cmnt"> OK</SPAN>
    A(int v) : v(v) { }     //<SPAN CLASS="cmnt"> OK</SPAN>
    const int&amp; v = 42;      //<SPAN CLASS="cmnt"> OK</SPAN>
  };
  A a1;                     //<SPAN CLASS="cmnt"> error: ill-formed binding of temporary to reference</SPAN>
  A a2(1);                  //<SPAN CLASS="cmnt"> OK, unfortunately</SPAN>
</PRE>

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

</BLOCKQUOTE>

<P>The rule is intended to apply only if an actual
initialization results in such a binding, but it could be
read as applying to the declaration of <TT>A::v</TT> itself.
It would be clearer if the restriction were moved into
bullet 9.1, e.g.,</P>

<UL>
<LI><P>if the entity is a non-static data member that has
a <I>brace-or-equal-initializer</I> and either</P></LI>

<UL>
<LI><P>the constructor's class is a union
(11.5 [<A href="https://wg21.link/class.union">class.union</A>]), and no other variant member of
that union is designated by a <I>mem-initializer-id</I> or</P></LI>

<LI>

<P>the constructor's class is not a union, and, if the entity
is a member of an anonymous union, no other member of that
union is designated by a <I>mem-initializer-id</I>,</P>
</LI>

</UL>

<P>the entity is initialized as specified in
9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]<INS>, and the program is ill-formed
if the entity is a reference member and this initialization
binds it to a temporary</INS>;</P>

</UL>

<BR><BR><HR>
<A NAME="2704"></A><H4>2704.
  
Clarify meaning of "bind directly"
</H4>
<B>Section: </B>9.5.4&#160; [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2022-11-11<BR>


<P>Currently, 9.5.4 [<A href="https://wg21.link/dcl.init.ref#5">dcl.init.ref</A>] paragraph 5 specifies:</P>

<BLOCKQUOTE>

In all cases except the last (i.e., implicitly converting the
initializer expression to the referenced type), the reference is said
to <I>bind directly</I> to the initializer expression.

</BLOCKQUOTE>

<P>This is intended to refer to both sub-bullets of the last bullet
(see <A HREF="cwg_defects.html#1604">issue 1604</A>), but the presentation is
unclear.</P>

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

<OL>

<LI>
<P>Change in 9.5.4 [<A href="https://wg21.link/dcl.init.ref#5.4">dcl.init.ref</A>] bullet 5.4 as follows:</P>

<BLOCKQUOTE>

Otherwise<INS>, the reference is said to <I>bind indirectly</I> to the
initializer expression:</INS>
<UL>
<LI>If T1 or T2 is a class type and T1 is not
reference-related to T2, user-defined conversions are considered using
the rules for copy-initialization of an object of type &#8220;cv1
T1&#8221; by user-defined conversion (9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>],
12.2.2.5 [<A href="https://wg21.link/over.match.copy">over.match.copy</A>], 12.2.2.6 [<A href="https://wg21.link/over.match.conv">over.match.conv</A>]); the
program is ill-formed if the corresponding non-reference
copy-initialization would be ill-formed. The result of the call to the
conversion function, as described for the non-reference
copy-initialization, is then used to direct-initialize the reference.
For this direct-initialization, user-defined conversions are not
considered.
</LI>
<LI>Otherwise, the initializer expression is
implicitly converted to a prvalue of type &#8220;T1&#8221;. The
temporary materialization conversion is applied, considering the type
of the prvalue to be &#8220;cv1 T1&#8221;, and the reference is bound
to the result.
</LI>
</UL>

If T1 is reference-related to T2:
<UL>
<LI>cv1 shall be the same cv-qualification as, or greater
cv-qualification than, cv2; and</LI>
<LI>if the reference is an rvalue reference, the initializer
expression shall not be an lvalue.  [<I>Note 3:</I> This can be
affected by whether the initializer expression is move-eligible
(7.5.5.2 [<A href="https://wg21.link/expr.prim.id.unqual">expr.prim.id.unqual</A>]). &#8212;<I>end note</I>]</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.5.4 [<A href="https://wg21.link/dcl.init.ref#5">dcl.init.ref</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<DEL>In all cases except the last (i.e., implicitly converting the
initializer expression to the referenced type),
the</DEL> <INS>The</INS> reference is said to <I>bind directly</I> to
the initializer expression <INS>if it does not bind indirectly</INS>.
<INS>[ Example:</INS>
<PRE class="ins">
  struct S {
    operator int();
  };
  struct T {
    T(int);
  };
  int&amp;&amp; r1 = S(); //<SPAN CLASS="cmnt"> binds directly</SPAN>
  T&amp;&amp; r2 = int(); //<SPAN CLASS="cmnt"> binds indirectly</SPAN>
  int&amp;&amp; r3 = double(); //<SPAN CLASS="cmnt"> binds indirectly</SPAN>
</PRE>
<INS>-- end example ]</INS>

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2168"></A><H4>2168.
  
Narrowing conversions and +/- infinity
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-08-19<BR>




<P>The intended treatment of a floating point infinity with
respect to narrowing conversions is not clear.  Is
<TT>std::numeric_limits&lt;double&gt;::infinity()</TT> usable
in a constant expression, for example, and should that be
different from a calculation that results in an infinity?</P>

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

<P>CWG requests the assistance of SG6 in resolving this issue.</P>

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

<P>SG6 said that arithmetic operations (not conversions) that
produce infinity are not allowed in a constant expression.
However, using <TT>std::numeric_limits&lt;T&gt;::infinity()</TT>
is okay, but it can't be used as a subexpression. Conversions that
produce infinity from non-infinity values are considered to be
narrowing conversions.</P>

<BR><BR><HR>
<A NAME="3023"></A><H4>3023.
  
Default arguments in list-initialization
</H4>
<B>Section: </B>9.5.5&#160; [<A href="https://wg21.link/dcl.init.list">dcl.init.list</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2025-04-24<BR>




<P>Consider:</P>

<PRE>
  #include &lt;iostream&gt;
  struct I {
    I(int x) { std::cout &lt;&lt; x; }
  };
  struct S {
    S(I, I = 2) {}
  };
  int main() {
    S(1, 2); std::cout &lt;&lt; '\n';  //<SPAN CLASS="cmnt"> unspecified order; prints 12 or 21</SPAN>
    S{1, 2}; std::cout &lt;&lt; '\n';  //<SPAN CLASS="cmnt"> prints 12 (9.5.5 [<A href="https://wg21.link/dcl.init.list#4">dcl.init.list</A>] paragraph 4)</SPAN>
    S{1};                        //<SPAN CLASS="cmnt"> ???</SPAN>
  }
</PRE>

<P>Since no <I>initializer-clause</I> is present for the second argument,
9.5.5 [<A href="https://wg21.link/dcl.init.list#4">dcl.init.list</A>] paragraph 4 does not, but should, prescribe
lexical ordering of the argument evaluations.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 9.5.5 [<A href="https://wg21.link/dcl.init.list#4">dcl.init.list</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>
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 (13.7.4 [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]), 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>.  <INS>If the elements of
the <I>initializer-list</I> are interpreted as arguments of a
constructor call (12.2.2.8 [<A href="https://wg21.link/over.match.list">over.match.list</A>]), any default
arguments are evaluated in the order as-if
an <I>initializer-clause</I> were present for the corresponding
parameter.</INS>
</P>
<P>[<I>Note 4:</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.
<INS>[ Example:</INS>

<PRE class="ins">
  #include &lt;iostream&gt;
  struct I {
    I(int x) { std::cout &lt;&lt; x; }
  };
  struct S {
    S(I, I = 2) {}
  };
  int main() {
    S(1, 2); std::cout &lt;&lt; '\n';  //<SPAN CLASS="cmnt"> unspecified order; prints 12 or 21</SPAN>
    S{1, 2}; std::cout &lt;&lt; '\n';  //<SPAN CLASS="cmnt"> prints 12</SPAN>
    S{1};                        //<SPAN CLASS="cmnt"> prints 12</SPAN>
  }
</PRE>

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


</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1962"></A><H4>1962.
  
Type of <TT>__func__</TT>
</H4>
<B>Section: </B>9.6.1&#160; [<A href="https://wg21.link/dcl.fct.def.general">dcl.fct.def.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-07-04
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Two questions have arisen regarding the treatment of the type of the
<TT>__func__</TT> built-in variable.  First, some implementations
accept</P>

<PRE>
  void f() {
    typedef decltype(__func__) T;
    T x = __func__;
  }
</PRE>

<P>even though <TT>T</TT> is specified to be an array type.</P>

<P>In a related question, it was noted that <TT>__func__</TT>
is implicitly required to be unique in each function, and that
not only the value but the type of <TT>__func__</TT> are
implementation-defined; e.g., in something like</P>

<PRE>
  inline auto f() { return &amp;__func__; }
</PRE>

<P>the function type is implementation-specific.  These concerns could be
addressed by making the value a prvalue of type <TT>const char*</TT>
instead of an array lvalue.</P>

<P><B>Notes from the May, 2015 meeting:</B></P>

<P>CWG agreed with the suggested direction.</P>



<P><B>Rationale (November, 2018):</B></P>

<P>See also <A HREF="cwg_active.html#2362">issue 2362</A>, which asks for the
ability to use <TT>__func__</TT> in a constexpr function. These two
goals are incompatible, so EWG input is requested.</P>

<P><B>EWG 2022-11-11</B></P>

<P>Paper requested.
This is tracked in github issue
<A HREF="https://github.com/cplusplus/papers/issues/1375">cplusplus/papers#1375</A>.
</P>

<BR><BR><HR>
<A NAME="2362"></A><H4>2362.
  
<TT>__func__</TT> should be <TT>constexpr</TT>
</H4>
<B>Section: </B>9.6.1&#160; [<A href="https://wg21.link/dcl.fct.def.general">dcl.fct.def.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Anthony Polukhin
 &#160;&#160;&#160;

 <B>Date: </B>2017-10-23
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>The definition of <TT>__func__</TT> in 9.6.1 [<A href="https://wg21.link/dcl.fct.def.general#8">dcl.fct.def.general</A>] paragraph 8
is:</P>

<PRE>
  static const char __func__[] = "<I>function-name</I>";
</PRE>

<P>This prohibits its use in constant expressions, e.g.,</P>

<PRE>
  int main () {
    //<SPAN CLASS="cmnt"> error: the value of </SPAN>__func__<SPAN CLASS="cmnt"> is not usable in a constant expression</SPAN>
    constexpr char c = __func__[0];
  }
</PRE>

<P><B>Notes from the October, 2018 teleconference:</B></P>

<P>CWG agreed with the proposed change.</P>

<P><B>Rationale (November, 2018):</B></P>

<P>See also <A HREF="cwg_active.html#1962">issue 1962</A>, which asks that the
type of <TT>__func__</TT> be <TT>const char*</TT>. These two
goals are incompatible, so EWG input is requested.</P>

<P><B>EWG 2022-11-11</B></P>

<P>This is tracked in github issue
<A HREF="https://github.com/cplusplus/papers/issues/1378">cplusplus/papers#1378</A>.</P>

<BR><BR><HR>
<A NAME="2993"></A><H4>2993.
  
Body of a destructor
</H4>
<B>Section: </B>9.6.1&#160; [<A href="https://wg21.link/dcl.fct.def.general">dcl.fct.def.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2025-02-14<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/672">#672</A>.)</P>

<P>Subclause 9.6.1 [<A href="https://wg21.link/dcl.fct.def.general#1">dcl.fct.def.general</A>] paragraph 1 specifies additional
implicit actions performed by the body of a constructor, but neglects
destructors.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 9.6.1 [<A href="https://wg21.link/dcl.fct.def.general#1">dcl.fct.def.general</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

... Any informal reference to the body of a function should be interpreted
as a reference to the non-terminal <I>function-body</I><DEL>,
including, for</DEL> <INS>For</INS> a constructor, <INS>this
includes</INS> default member initializers or default initialization
used to initialize a base or member subobject in the absence of
a <I>mem-initializer-id</I> (11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]).
<INS>For a destructor, this includes invocations of destructors for
base and member subobjects.</INS> The
optional <I>attribute-specifier-seq</I> in
a <I>function-definition</I> appertains to the
function. A <I>function-definition</I> with
a <I>virt-specifier-seq</I> shall be a <I>member-declaration</I>
(11.4 [<A href="https://wg21.link/class.mem">class.mem</A>]). A <I>function-definition</I> with
a <I>requires-clause</I> shall define a templated function.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2997"></A><H4>2997.
  
Defaulted functions with deleted definition
</H4>
<B>Section: </B>9.6.2&#160; [<A href="https://wg21.link/dcl.fct.def.default">dcl.fct.def.default</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

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




<P>When a function is defined as defaulted, the defaulted definition
might be deleted. The standard requires that a non-user-provided
defaulted function not be defined until it is odr-used or needed for
constant evaluation (9.6.2 [<A href="https://wg21.link/dcl.fct.def.default#5">dcl.fct.def.default</A>] paragraph 5).</P>

<P>Consider:</P>

<PRE>
  template &lt;class T&gt;
  struct X {
    static_assert(sizeof(T) &gt; 1);
  };

  template &lt;class T&gt;
  struct Y {
    bool operator==(const Y&amp; other) const {
      return true;
    }
  };

  struct Z {
    Y&lt;X&lt;char&gt;&gt; y;
    bool operator==(const Z&amp; other) const = default;
  };

  int main() {
    // Z z;
    // z == z
  }
</PRE>

<P>In order to determine whether the equality operator of <TT>Z</TT>
is deleted, it is necessary to perform argument-dependent lookup for
the equality operator that applies to <TT>Y&lt;X&lt;char&gt;&gt;</TT>,
causing instantiation of the ill-formed definition
of <TT>X&lt;char&gt;</TT>.</P>

<P>Clang, EDG, and MSVC perform the check at the end of
the <I>class-specifier</I> for <TT>Z</TT> , making the program
ill-formed.  In contrast, gcc performs the check later, if/when the
equality operator is actually used.</P>

<P>Whether a defaulted special member function (e.g. the copy
constructor, not the equality operator function) is deleted can make a
difference for class properties such as trivial copyability, affected
calling conventions and thus requiring early checking.  Is it
worthwhile to introduce an inconsistency for the equality operator
here?  On the other hand, special member functions cannot cause
argument-dependent lookup for their default definitions, so the
problem in this issue does not arise in the first place.</P>

<P>A closely related question is how to interpret
13.9.2 [<A href="https://wg21.link/temp.inst#3">temp.inst</A>] paragraph 3. Implicit instantiation of the
definition of a class template specialization instantiates the
definition of a member function only if the member function is
deleted. Does that mean, at the point of instantiation of the class,
the compiler must determine whether a defaulted definition is deleted?
</P>

<P>The issue also arises when attempting to default equality operator
functions for standard library types, e.g.</P>

<PRE>
  template&lt;class T, int N&gt;
  struct A {
    T m[N];
    bool operator==(const A&amp;) const = default;
  };

  struct Incomplete;
  template&lt;class T&gt; struct Holder { T t; };
  using H = Holder&lt;Holder&lt;Incomplete&gt;*&gt;;
  A&lt;H, 2&gt; a;    //<SPAN CLASS="cmnt"> error: data member of incomplete type</SPAN>
</PRE>

<BR><BR><HR>
<A NAME="2562"></A><H4>2562.
  
Exceptions thrown during coroutine startup
</H4>
<B>Section: </B>9.6.4&#160; [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Tomasz Kami&#324;ski
 &#160;&#160;&#160;

 <B>Date: </B>2022-04-06<BR>




<P>Subclause 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>] seems to miss specification
about the behavior of coroutines when an exception is thrown during
the early phases of a coroutine evaluation.  It is unclear at what
point the ownership of the coroutine frame is passed from the compiler
to the user, who then needs to call
<TT>std::coroutine_handle::destroy</TT> to destroy and free the
coroutine frame, including the parameter copies.  The following
situations arise:</P>

<UL>

<LI>Allocation fails, and
<TT>get_return_object_on_allocation_failure()</TT> is
returned.</LI>

<LI>Allocation succeeds, but an exception is thrown before the return
object is initialized (e.g. when initializing the promise or
evaluating <TT>get_return_object</TT>). The coroutine state ought to
be deallocated automatically and the exception propagated.</LI>

<LI>The return object is successfully initialized, but an exception
would leave the coroutine before it would first suspend, either
because <I>initial-suspend</I>'s <TT>await_ready</TT>
or <TT>await_suspend</TT> exits via an exception, or
because <TT>unhandled_exception</TT> rethrows. The coroutine ought to
be suspended at its final suspend point, the return object
destroyed, and the exception propagated; the return object's
destructor is responsible for ensuring the coroutine is
destroyed.</LI>

<LI>The coroutine ever suspends, or the coroutine terminates normally
without ever suspending. The return object is returned to the caller,
carrying with it ownership of the coroutine state.</LI>

</UL>

<P>See also <A HREF="cwg_defects.html#2451">issue 2451</A>.</P>

<BR><BR><HR>
<A NAME="2934"></A><H4>2934.
  
Unclear semantics of exception escaping from <TT>unhandled_exception</TT>
</H4>
<B>Section: </B>9.6.4&#160; [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2024-07-13<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/574">#574</A>.
See also
<A HREF="https://github.com/GorNishanov/coroutines-ts/issues/17">coroutines-ts#17</A> and
<A HREF="https://github.com/GorNishanov/coroutines-ts/issues/30">coroutines-ts#30</A>.)</P>

<P>Subclause 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#14">dcl.fct.def.coroutine</A>] paragraph 14 specifies:</P>

<BLOCKQUOTE>

If the evaluation of the expression
<TT><I>promise</I>.unhandled_exception()</TT> exits via an
exception, the coroutine is considered suspended at the final suspend
point and the exception propagates to the caller or resumer.

</BLOCKQUOTE>

<P>However, implementations destroy the promise object, the parameter
copies, and the coroutine state before propagating the exception,
which is consistent with the as-if code presented in
9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#5">dcl.fct.def.coroutine</A>] paragraph 5.</P>

<P><B>CWG 2024-11-08</B></P>

<P>The implementations are correct; the normative wording needs to be
amended.</P>

<BR><BR><HR>
<A NAME="2935"></A><H4>2935.
  
Destroying the coroutine state when initial-await-resume-called is false
</H4>
<B>Section: </B>9.6.4&#160; [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2024-07-13<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/575">#575</A>.)
</P>

<P>According to 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#11">dcl.fct.def.coroutine</A>] paragraph 11:</P>

<BLOCKQUOTE>

The coroutine state is destroyed when control flows off the end of the
coroutine or the destroy member function
(17.13.4.6 [<A href="https://wg21.link/coroutine.handle.resumption">coroutine.handle.resumption</A>]) of a coroutine handle
(17.13.4 [<A href="https://wg21.link/coroutine.handle">coroutine.handle</A>]) that refers to the coroutine is
invoked.

</BLOCKQUOTE>

<P>Considering the as-if code in 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#5">dcl.fct.def.coroutine</A>] paragraph 5,
if an exception occurs at any point
before <I>initial-await-resume-called</I> becomes <TT>true</TT>, then
there is no requirement to destroy the coroutine state, nor is the
coroutine ever suspended.  Consequently, the coroutine state is
necessarily leaked.  It is unclear whether that is intentional.</P>

<P><B>CWG 2024-11-08</B></P>

<P>It is unclear what the intended outcome is.</P>

<BR><BR><HR>
<A NAME="3040"></A><H4>3040.
  
Mishandling of lambda coroutines
</H4>
<B>Section: </B>9.6.4&#160; [<A href="https://wg21.link/dcl.fct.def.coroutine">dcl.fct.def.coroutine</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2025-07-03<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/721">#721</A>.)</P>

<P>Subclause 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#3">dcl.fct.def.coroutine</A>] paragraph 3 and paragraph 4 do
not properly handle function call operators of lambdas that are
coroutines.  In particular, <TT>*this</TT> does not denote the
lambda's closure object and a captureless lambda should be treated
like a static member function, because the result of a captureless
lambda's conversion function does not take a pointer to the closure
object.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#3">dcl.fct.def.coroutine</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

The promise type of a coroutine is <TT>std::coroutine_traits&lt;R, P1
, . . . , Pn &gt;::promise_type</TT>, where R is the return type of
the function, and P1 . . . Pn is the sequence of types of the
non-object function parameters, preceded by the type of the object
parameter (9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]) if the coroutine is a
non-static member function <INS>that is not a member of the closure
type for a <I>lambda-expression</I> with no <I>lambda-capture</I> and
no explicit object parameter (7.5.6.2 [<A href="https://wg21.link/expr.prim.lambda.closure">expr.prim.lambda.closure</A>])</INS>. The
promise type shall be a class type.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.6.4 [<A href="https://wg21.link/dcl.fct.def.coroutine#4">dcl.fct.def.coroutine</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<INS>A <I>this-eligible function</I> is an implicit object member function
that is not a member of the closure type for
a <I>lambda-expression</I> with no <I>lambda-capture</I>.</INS> In the
following, pi is an lvalue of type Pi , where p1 denotes the object
parameter and pi+1 denotes the ith non-object function parameter for
<DEL>an implicit object member</DEL> <INS>this-eligible</INS>
function, and pi denotes the ith function parameter otherwise.
For <DEL>an implicit object member</DEL> <INS>this-eligible</INS>
function, q1 is an lvalue that denotes <TT>*this</TT> <INS>or, if the
function is a member of a closure type, the closure object</INS>; any
other qi is an lvalue that denotes the parameter copy corresponding to
pi , as described below.

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2340"></A><H4>2340.
  
Reference collapsing and structured bindings
</H4>
<B>Section: </B>9.7&#160; [<A href="https://wg21.link/dcl.struct.bind">dcl.struct.bind</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2017-03-29<BR>


<P>According to 9.7 [<A href="https://wg21.link/dcl.struct.bind#3">dcl.struct.bind</A>] paragraph 3,</P>

<BLOCKQUOTE>

Given the type <TT>T</TT><I><SUB>i</SUB></I> designated
by <TT>std::tuple_element&lt;i, E&gt;::type</TT>,
each <TT>v</TT><I><SUB>i</SUB></I> is a variable of type
&#8220;reference to <TT>T</TT><I><SUB>i</SUB></I>&#8221;
initialized with the initializer, where the reference is an
lvalue reference if the initializer is an lvalue and an rvalue
reference otherwise; the referenced type
is <TT>T</TT><I><SUB>i</SUB></I>.

</BLOCKQUOTE>

<P>If <TT>T</TT><I><SUB>i</SUB></I> is already a reference
type, should this do reference collapsing? Presumably yes,
but reference collapsing is specified in terms of a
<I>typedef-name</I> or <I>decltype-specifier</I>, which are not
used in this description.</P>

<P>See also <A HREF="cwg_defects.html#2313">issue 2313</A>.</P>

<BR><BR><HR>
<A NAME="3046"></A><H4>3046.
  
Enumerations as part of the common initial sequence
</H4>
<B>Section: </B>9.8.1&#160; [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Benjamin Sch.
 &#160;&#160;&#160;

 <B>Date: </B>2025-07-28<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/732">#732</A>.)</P>

<P>Consider:</P>

<PRE>
  #include &lt;iostream&gt;
  #include &lt;type_traits&gt;

  enum E { E0 } e;
  enum F { F0, F1, F2, F3 };
  static_assert(std::is_same_v&lt;std::underlying_type_t&lt;E&gt;, std::underlying_type_t&lt;F&gt;&gt;);  //<SPAN CLASS="cmnt"> assume this passes</SPAN>

  struct A { E e; };
  struct B { F f; };
  union U {
    A a;
    B b;
  } u;

  bool test() {
    return u.a.e == 2;
  }

  auto ptest = test;

  int main() {
    u.b.f = F2;
    std::cout &lt;&lt; ptest();
  }
</PRE>
<P>Both <TT>u.a</TT> and <TT>u.b</TT> are part of the common initial
sequence, allowing <TT>u.a.e</TT> to read the value of <TT>u.a.f</TT>,
even though <TT>E</TT> cannot represent all values of <TT>F</TT>.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 6.9.1 [<A href="https://wg21.link/basic.types.general#10">basic.types.general</A>] paragraph 10 as follows:</P>

<BLOCKQUOTE>

Two enumeration types are <I>layout-compatible enumerations</I> if they have
the same <DEL>underlying type</DEL> <INS>values</INS>.

</BLOCKQUOTE>
<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>9.10&#160; [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]
 &#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>9.10 [<A href="https://wg21.link/namespace.udecl#20">namespace.udecl</A>] paragraph 20 says,</P>

<BLOCKQUOTE>

If a <I>using-declaration</I> uses the keyword <TT>typename</TT> and
specifies a dependent name (13.8.3 [<A href="https://wg21.link/temp.dep">temp.dep</A>]), the name
introduced by the <I>using-declaration</I> is treated as a
<I>typedef-name</I> (9.2.4 [<A href="https://wg21.link/dcl.typedef">dcl.typedef</A>]).

</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 13.8 [<A href="https://wg21.link/temp.res">temp.res</A>] does not appear to describe this case, either.</P>

<P><B>Additional notes (March, 2022):</B></P>

The relevant wording is now in 13.8.1 [<A href="https://wg21.link/temp.res.general#5">temp.res.general</A>] paragraph 5:

<BLOCKQUOTE>

A name that refers to a <I>using-declarator</I> whose terminal name is
dependent is interpreted as a <I>typedef-name</I> if
the <I>using-declarator</I> uses the keyword <TT>typename</TT>.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3028"></A><H4>3028.
  
A <I>using-declarator</I> should bind a name
</H4>
<B>Section: </B>9.10&#160; [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2025-03-24<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/692">#692</A>.)</P>

<P>There is no normative rule that would cause
a <I>using-declarator</I> not naming a constructor to bind
its <I>unqualified-id</I> in the scope it inhabits.</P>

<P>Also, a normative prohibition for something like <TT>using
X::~X;</TT> seems to be missing.</P>

<P><U>Suggested resolution:</U></P>

<OL>
<LI>
<P>Change the grammar before 9.10 [<A href="https://wg21.link/namespace.udecl#1">namespace.udecl</A>] paragraph 1 as follows:</P>

<PRE>
  <I>using-declarator</I>:
    typename<SUB>opt</SUB> <I>nested-name-specifier</I> <DEL><I>unqualified-id</I></DEL> <INS><I>using-declarator-id</I></INS>

<INS>  <I>using-declarator-id</I>:
    <I>identifier</I>
    <I>operator-function-id</I>
    <I>conversion-function-id</I>
    <I>literal-operator-id</I></INS>
</PRE>
</LI>

<LI>
<P>Change in 9.10 [<A href="https://wg21.link/namespace.udecl#1">namespace.udecl</A>] paragraph 1 as follows:</P>



<BLOCKQUOTE>

The component names of a <I>using-declarator</I> are those of
its <I>nested-name-specifier</I> and
<DEL><I>unqualified-id</I></DEL> <INS><I>using-declarator-id</I></INS>.
<INS>The component name of a <I>using-declarator-id</I> is itself.</INS>
Each <I>using-declarator</I> in a <I>using-declaration</I> [ Footnote:
... ] names the set of declarations found by lookup
(6.5.5 [<A href="https://wg21.link/basic.lookup.qual">basic.lookup.qual</A>]) for the <I>using-declarator</I>, except
that class and enumeration declarations that would be discarded are
merely ignored when checking for ambiguity (6.5 [<A href="https://wg21.link/basic.lookup">basic.lookup</A>]),
conversion function templates with a dependent return type are
ignored, and certain functions are hidden as described below. If the
terminal name of the <I>using-declarator</I> is dependent
(13.8.3.2 [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]), the <I>using-declarator</I> is
considered to name a constructor if and only if
<INS>the <I>using-declarator-id</I> is an <I>identifier</I> and</INS>
the <I>nested-name-specifier</I> has a terminal name that is the same
as the <DEL><I>unqualified-id</I></DEL> <INS><I>identifier</I></INS>. If the
lookup in any instantiation finds that a <I>using-declarator</I> that
is not considered to name a constructor does do so, or that
a <I>using-declarator</I> that is considered to name a constructor
does not, the program is ill-formed.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.10 [<A href="https://wg21.link/namespace.udecl#2">namespace.udecl</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

If the <I>using-declarator</I> names a constructor, it declares that
the class inherits the named set of constructor declarations from the
nominated base class.  <INS>Otherwise, the <I>using-declarator</I>
introduces its <I>using-declarator-id</I>.</INS> [<I>Note
1:</I> <DEL>Otherwise, the <I>unqualified-id</I> in
the <I>using-declarator</I> is bound to</DEL>
<INS>During name lookup,</INS> the <I>using-declarator</I><DEL>,
which</DEL> is replaced <DEL>during name lookup</DEL> with the
declarations it names (6.5 [<A href="https://wg21.link/basic.lookup">basic.lookup</A>]). If such a
declaration is of an enumeration, the names of its enumerators are not
bound. For the keyword typename, see
13.8 [<A href="https://wg21.link/temp.res">temp.res</A>]. &#8212;<I>end note</I>]

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 9.10 [<A href="https://wg21.link/namespace.udecl#4">namespace.udecl</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<DEL>[<I>Note 2:</I> Since destructors do not have names,
a <I>using-declaration</I> cannot refer to a destructor for a base
class. &#8212;<I>end note</I>]</DEL> If a constructor or assignment
operator brought from a base class into a derived class ...
</BLOCKQUOTE>

</LI>

<LI>
<P>Remove 9.10 [<A href="https://wg21.link/namespace.udecl#5">namespace.udecl</A>] paragraph 5:</P>

<BLOCKQUOTE class="del">

A <I>using-declaration</I> shall not name a <I>template-id</I>.

<PRE>
  struct A {
    template &lt;class T&gt; void f(T);
    template &lt;class T&gt; struct X { };
  };
  struct B : A {
    using A::f&lt;double&gt;; //<SPAN CLASS="cmnt"> error</SPAN>
    using A::X&lt;int&gt;;    //<SPAN CLASS="cmnt"> error</SPAN>
  };
</PRE>
</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="3037"></A><H4>3037.
  
Name lookup results for <I>using-declarator</I>s
</H4>
<B>Section: </B>9.10&#160; [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Vlad Serebrennikov
 &#160;&#160;&#160;

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




<P>Subclause 9.10 [<A href="https://wg21.link/namespace.udecl#1">namespace.udecl</A>] paragraph 1 subtly changes the
mechanics of name lookup for a <I>using-declarator</I>.  This is
better done in 6.5.1 [<A href="https://wg21.link/basic.lookup.general">basic.lookup.general</A>] to avoid the impression of
conflicting rules.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 6.5.1 [<A href="https://wg21.link/basic.lookup.general#1">basic.lookup.general</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

... If the declarations found by name lookup all denote functions or
function templates, the declarations are said to form an <I>overload
set</I>. Otherwise, if the declarations found by name lookup do not
all denote the same entity, they are <I>ambiguous</I> and the program
is ill-formed<INS>, unless lookup is for a <I>using-declarator</I></INS>. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 6.5.1 [<A href="https://wg21.link/basic.lookup.general#4">basic.lookup.general</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

In certain contexts, only certain kinds of declarations are
included <INS>in the result of the search</INS>.
After <DEL>any</DEL> <INS>applying</INS> such
<DEL>restriction</DEL> <INS>restrictions (if any)</INS>, any
declarations of classes or enumerations are discarded if <INS>lookup
is not for a <I>using-declarator</I> and</INS> any other declarations
are found.  [<I>Note 4:</I> A type (but not a type alias or template)
is therefore hidden by any other entity in its scope. &#8212;<I>end
note</I>] However, if a lookup is type-only, only declarations of
types and templates whose specializations are types are considered;
furthermore, if declarations of a type alias and of its underlying
entity are found, the declaration of the type alias is discarded
instead of the type declaration.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 9.10 [<A href="https://wg21.link/namespace.udecl#1">namespace.udecl</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Each <I>using-declarator</I> in a <I>using-declaration</I> [ Footnote:
... ] names the set of declarations found by lookup
(6.5.5 [<A href="https://wg21.link/basic.lookup.qual">basic.lookup.qual</A>]) for the <I>using-declarator</I>, except
that <DEL>class and enumeration declarations that would be discarded
are merely ignored when checking for ambiguity
(6.5 [<A href="https://wg21.link/basic.lookup">basic.lookup</A>]),</DEL> conversion function templates with a
dependent return type are ignored<DEL>,</DEL> and certain functions
are hidden as described below.

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="1817"></A><H4>1817.
  
Linkage specifications and nested scopes
</H4>
<B>Section: </B>9.12&#160; [<A href="https://wg21.link/dcl.link">dcl.link</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-12-04<BR>




<P>According to 9.1 [<A href="https://wg21.link/dcl.pre#2">dcl.pre</A>] paragraph 2,</P>

<BLOCKQUOTE>

Unless otherwise stated, utterances in
Clause 9 [<A href="https://wg21.link/dcl">dcl</A>] about components in, of, or contained
by a declaration or subcomponent thereof refer only to those
components of the declaration that are not nested within
scopes nested within the declaration.

</BLOCKQUOTE>

<P>This contradicts the intent of 9.12 [<A href="https://wg21.link/dcl.link#4">dcl.link</A>] paragraph 4,
 which says,</P>

<BLOCKQUOTE>

In a <I>linkage-specification</I>, the specified language
linkage applies to the function types of all function
declarators, function names with external linkage, and
variable names with external linkage declared within
the <I>linkage-specification</I>.

</BLOCKQUOTE>

<P>Also, one of the comments in the example in paragraph 4
is inconsistent with the intent:</P>

<PRE>
  extern "C" {
    static void f4(); //<SPAN CLASS="cmnt"> the name of the function f4 has</SPAN>
                      //<SPAN CLASS="cmnt"> internal linkage (not C language</SPAN>
                      //<SPAN CLASS="cmnt"> linkage) and the function's type</SPAN>
                      //<SPAN CLASS="cmnt"> has C language linkage.</SPAN>
  }

  extern "C" void f5() {
    extern void f4(); //<SPAN CLASS="cmnt"> OK: Name linkage (internal)</SPAN>
                      //<SPAN CLASS="cmnt"> and function type linkage (C</SPAN>
                      //<SPAN CLASS="cmnt"> language linkage) gotten from</SPAN>
                      //<SPAN CLASS="cmnt"> previous declaration.</SPAN>
  }
</PRE>

<P>The language linkage for the block-scope declaration of
<TT>f4</TT> is presumably determined by the fact that it
appears in a C-linkage function, not by the previous
declaration.</P>

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

<P>Change 9.12 [<A href="https://wg21.link/dcl.link#4">dcl.link</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>Linkage specifications nest. When linkage specifications nest, the
innermost one determines the language linkage. A linkage specification does
not establish a scope. A <I>linkage-specification</I> shall occur only in
namespace scope (6.4 [<A href="https://wg21.link/basic.scope">basic.scope</A>]). In
a <I>linkage-specification</I>, the specified language linkage applies to
the function types of all function declarators, function names with
external linkage, and variable names with external linkage declared within
the <I>linkage-specification</I><INS>, including those appearing in scopes
nested inside the linkage specification and not inside a nested
<I>linkage-specification</I></INS>. [<I>Example:</I>
</P>

<P>...</P>

<PRE>
  extern "C" {
    static void f4(); //<SPAN CLASS="cmnt"> the name of the function </SPAN>f4<SPAN CLASS="cmnt"> has</SPAN>
                      //<SPAN CLASS="cmnt"> internal linkage (not C language</SPAN>
                      //<SPAN CLASS="cmnt"> linkage) and the function's type</SPAN>
                      //<SPAN CLASS="cmnt"> has C language linkage.</SPAN>
  }

  extern "C" void f5() {
    extern void f4(); //<SPAN CLASS="cmnt"> OK: Name linkage (internal)</SPAN>
                      //<SPAN CLASS="cmnt"> <DEL>and function type linkage (C</DEL></SPAN>
                      //<SPAN CLASS="cmnt"> <DEL>language linkage)</DEL> gotten from</SPAN>
                      //<SPAN CLASS="cmnt"> previous declaration<DEL>.</DEL><INS>; function type</INS></SPAN>
                      //<SPAN CLASS="cmnt"> <INS>linkage (C language</INS></SPAN>
                      //<SPAN CLASS="cmnt"> <INS>linkage) gotten</INS></SPAN>
                      //<SPAN CLASS="cmnt"> <INS>from linkage specification</INS></SPAN>
  }
</PRE>

</BLOCKQUOTE>

<P><B>Additional note, November, 2014:</B></P>

<P>The issue has been returned to "drafting" status to clarify the
circumstances under which a preceding declaration supplies the
language linkage for a declaration (for example, not when the
declaration uses a typedef, which carries the language linkage,
but only when the declaration uses a function declarator).
</P>

<BR><BR><HR>
<A NAME="2866"></A><H4>2866.
  
Observing the effects of <TT>[[no_unique_address]]</TT>
</H4>
<B>Section: </B>9.13&#160; [<A href="https://wg21.link/dcl.attr">dcl.attr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2023-11-12
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Some attributes can cause undefined behavior,
e.g. <TT>[[no_unique_address]]</TT> via attempting to transparently
replace a subobject.  Core language undefined behavior can be detected
during constant evaluation (7.7 [<A href="https://wg21.link/expr.const#5.8">expr.const</A>] bullet 5.8).
For example:</P>

<PRE>
  struct A {
    [[no_unique_address]] int x;
  };
  constexpr int test(auto a) {
    std::construct_at(&amp;a.x, 1);   // <SPAN CLASS="cmnt">#1</SPAN>
    return a.x;
  }
  template&lt;typename T&gt; constexpr bool call(int (*)[test(T())]) { return false; }
  template&lt;typename T&gt; constexpr bool call(...) { return true; }
  bool no_unique_address_works = call&lt;A&gt;(nullptr);
</PRE>

<P>If <TT>[[no_unique_address]]</TT> has an effect, the attempt to
transparently replace the member <TT>A::x</TT> at #1 is undefined
behavior per 6.8.4 [<A href="https://wg21.link/basic.life#8.4">basic.life</A>] bullet 8.4, otherwise the
replacement succeeds.</P>

<P>This behavior conflicts with the note in 9.13.1 [<A href="https://wg21.link/dcl.attr.grammar#6">dcl.attr.grammar</A>] paragraph 6:</P>

<BLOCKQUOTE>

[<I>Note 5:</I> The attributes specified in 9.13 [<A href="https://wg21.link/dcl.attr">dcl.attr</A>]
have optional semantics: given a well-formed program, removing all
instances of any one of those attributes results in a program whose
set of possible executions (4.1.2 [<A href="https://wg21.link/intro.abstract">intro.abstract</A>]) for a given
input is a subset of those of the original program for the same input,
absent implementation-defined guarantees with respect to that
attribute. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>See also <A HREF="cwg_active.html#2545">issue 2545</A> for implementation
divergence and implementation misbehavior when replacing
potentially-overlapping subobjects in constant expressions.</P>

<P>See also <A HREF="cwg_active.html#2403">issue 2403</A>, which might be
resolved to demonstrate different behavior for potentially-overlapping
subobjects (always copies) vs. non-overlapping subobjects (never
copies; guaranteed copy elision).</P>

<P><B>CWG 2024-04-19</B></P>

<P>The note embodies EWG design guidelines for attributes; CWG
requests EWG to address the inconsistency, via
<A HREF="https://github.com/cplusplus/papers/issues/1890">paper issue 1890</A>.</P>

<BR><BR><HR>
<A NAME="3038"></A><H4>3038.
  
Ignorability of attributes, again
</H4>
<B>Section: </B>9.13.1&#160; [<A href="https://wg21.link/dcl.attr.grammar">dcl.attr.grammar</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2025-06-17
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/716">#716</A>.)</P>

<P>The following note added to 9.13.1 [<A href="https://wg21.link/dcl.attr.grammar">dcl.attr.grammar</A>] by
<A HREF="cwg_defects.html#2695">issue 2695</A> embodies the design intent that
attributes can be ignored by implementations:</P>

<BLOCKQUOTE>

[<I>Note 5</I>: The attributes specified in 9.13 [<A href="https://wg21.link/dcl.attr">dcl.attr</A>] have
optional semantics: given a well-formed program, removing all
instances of any one of those attributes results in a program whose
set of possible executions (4.1.2 [<A href="https://wg21.link/intro.abstract">intro.abstract</A>]) for a given
input is a subset of those of the original program for the same input,
absent implementation-defined guarantees with respect to that
attribute. -- <I>end note</I>]

</BLOCKQUOTE>

<P>However, the note is incorrect for attributes that contain a
potentially-evaluated expression such as <TT>[[assume]]</TT>
(9.13.3 [<A href="https://wg21.link/dcl.attr.assume">dcl.attr.assume</A>]).  For example,</P>

<PRE>
  template&lt;int N&gt;
  struct reader {
    friend auto flag(reader);
  };

  template&lt;int N&gt;
  struct setter {
    friend auto flag(reader&lt;N&gt;) {}
  };

  template&lt;int N = 0, auto DifferenceMaker = [] {}&gt;
  consteval int next() {
    if constexpr (requires { flag(reader&lt;N&gt;{}); }) {
     return next&lt;N + 1&gt;();
   } else {
     (void) setter&lt;N&gt;{};
     return N;
   }
  }

  int main() {
    static_assert(next() == 0);
    [[assume(true || next())]];
    static_assert(next() == 2);
  }
</PRE>

<P>While this particular example using stateful friend injection is
addressed by <A HREF="cwg_active.html#2118">issue 2118</A>, similar examples
can be constructed using mainstream facilities introduced by P2996R13
(Reflection); see the compile-time ticket counter example therein.</P>

<P>There are also counterexamples for
<TT>[[no_unique_address]]</TT>.</P>

<P>Forwarded to EWG with
<A HREF="https://github.com/cplusplus/papers/issues/2407">paper issue 2407</A>,
by decision of the CWG chair.
</P>

<BR><BR><HR>
<A NAME="1617"></A><H4>1617.
  
<TT>alignas</TT> and non-defining declarations
</H4>
<B>Section: </B>9.13.2&#160; [<A href="https://wg21.link/dcl.align">dcl.align</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

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




<P>According to 9.13.2 [<A href="https://wg21.link/dcl.align#6">dcl.align</A>] paragraph 6,</P>

<BLOCKQUOTE>

If the defining declaration of an entity has an <I>alignment-specifier</I>,
any non-defining declaration of that entity shall either specify equivalent
alignment or have no <I>alignment-specifier</I>. Conversely, if any
declaration of an entity has an <I>alignment-specifier</I>, every defining
declaration of that entity shall specify an equivalent alignment. No
diagnostic is required if declarations of an entity have
different <I>alignment-specifier</I>s in different translation units.

</BLOCKQUOTE>

<P>Because this is phrased in terms of the definition of an entity,
an example like the following is presumably well-formed (even though
there can be no definition of <TT>n</TT>):</P>

<PRE>
   alignas(8) extern int n;
   alignas(16) extern int n;
</PRE>

<P>Is this intentional?</P>

<BR><BR><HR>
<A NAME="3024"></A><H4>3024.
  
Alignment of references
</H4>
<B>Section: </B>9.13.2&#160; [<A href="https://wg21.link/dcl.align">dcl.align</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2025-05-02<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/703">#703</A>.)</P>

<P>Per 9.13.2 [<A href="https://wg21.link/dcl.align#1">dcl.align</A>] paragraph 1,
an <I>alignment-specifier</I> may be applied to a reference.  However,
it is unclear what "alignment requirements for a reference" actually
means.  There is implementation divergence</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 9.13.2 [<A href="https://wg21.link/dcl.align#1">dcl.align</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

An <I>alignment-specifier</I> may be applied to a variable or to a
<DEL>class</DEL> <INS>non-static</INS> data member, but it shall not
be applied to <INS>a reference,</INS> a bit-field, a function
parameter, or an <I>exception-declaration</I>
(14.4 [<A href="https://wg21.link/except.handle">except.handle</A>]). An <I>alignment-specifier</I> may also be
applied to the declaration of a class (in
an <I>elaborated-type-specifier</I> (9.2.9.5 [<A href="https://wg21.link/dcl.type.elab">dcl.type.elab</A>])
or <I>class-head</I>
(<DEL>Clause 11 [<A href="https://wg21.link/class">class</A>]</DEL> <INS>11.1 [<A href="https://wg21.link/class.pre">class.pre</A>]</INS>),
respectively).  An <I>alignment-specifier</I> with an ellipsis is a
pack expansion (13.7.4 [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]).

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3050"></A><H4>3050.
  
[[deprecated]] for class template partial specializations
</H4>
<B>Section: </B>9.13.4&#160; [<A href="https://wg21.link/dcl.attr.deprecated">dcl.attr.deprecated</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2025-08-12<BR>




<P>Consider:</P>

<PRE>
  template&lt;typename T&gt;
  struct S {
    static constexpr bool value = false;
  };

  template&lt;typename T&gt;
  struct [[deprecated]] S&lt;const T&gt; {
    static constexpr bool value = true;
  };

  static_assert(S&lt;const int&gt;::value, "BOOM!");
</PRE>

<P>Should this trigger the deprecation warning for using the partial
specialization?  There is implementation divergence.</P>

<P>One consistent approach (used by clang) is to instantiate a
declaration of the specialization from the primary template, but to
instantiate the definition from the applicable partial specialization.
Thus, <TT>[[deprecate]]</TT> on a partial specialization comes into
effect when its definition is instantiated.  However, C++ has some
situations where a definition is surprisingly required, e.g.:</P>

<PRE>
  void f(...);

  template&lt;typename T&gt;
  struct S {
    static constexpr bool value = false;
  };

  template&lt;typename T&gt;
  struct [[deprecated]] S&lt;const T&gt; {
    static constexpr bool value = true;
  };

  S&lt;const int&gt; *p;
  void g() { f(p); }
</PRE>


<BR><BR><HR>
<A NAME="2541"></A><H4>2541.
  
Linkage specifications, module purview, and module attachment
</H4>
<B>Section: </B>10.1&#160; [<A href="https://wg21.link/module.unit">module.unit</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nathan Sidwell
 &#160;&#160;&#160;

 <B>Date: </B>2022-02-28<BR>




<P>The interaction between linkage specifications
(9.12 [<A href="https://wg21.link/dcl.link">dcl.link</A>]) and named or global module purview and
attachment (10.1 [<A href="https://wg21.link/module.unit">module.unit</A>]) is confusing. The addition of
linkage declarations attaching their contents to the global module is
not fully integrated into the wording and examples would also
help.</P>

<UL>
<LI>Module purview and attachment are not necessarily the same. This
is never explicitly mentioned.
</LI>

<LI>10.1 [<A href="https://wg21.link/module.unit#7">module.unit</A>] paragraph 7 explicitly calls out
replaceable allocation and deallocation functions as being
(implicitly) attached to the global module. This is unnecessary.
</LI>

<LI>6.10.3.1 [<A href="https://wg21.link/basic.start.main#1">basic.start.main</A>] paragraph 1 specifies that there shall
be a main function in the global namespace, but only in paragraph 3 do
we specify that not attaching it to the global module is ill-formed.
</LI>

</UL>

<P><U>Suggested resolution:</U></P>

<OL>

<LI>
<P>Change 6.10.3.1 [<A href="https://wg21.link/basic.start.main#1">basic.start.main</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A program shall contain exactly one function called <TT>main</TT> that
belongs to the global scope <INS>and is attached to the global
module</INS>. Executing a program starts a main thread of execution
(6.10.2 [<A href="https://wg21.link/intro.multithread">intro.multithread</A>], 32.4 [<A href="https://wg21.link/thread.threads">thread.threads</A>]) in which
the <TT>main</TT> function is invoked. It is implementation-defined
whether a program in a freestanding environment is required to define
a <TT>main</TT> function.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 10.1 [<A href="https://wg21.link/module.unit#7.2">module.unit</A>] bullet 7.2 as follows:</P>

<BLOCKQUOTE>

<UL>

<LI>...</LI>

<LI>
Otherwise, if the declaration
<UL>
<LI>
<DEL>is a replaceable global allocation or deallocation function
(17.6.3.2 [<A href="https://wg21.link/new.delete.single">new.delete.single</A>], 17.6.3.3 [<A href="https://wg21.link/new.delete.array">new.delete.array</A>]), or</DEL>
</LI>

<LI>is a <I>namespace-definition</I> with external linkage<DEL>,</DEL> or
</LI>

<LI>appears within a <I>linkage-specification</I>,
</LI>
</UL>
it is attached to the
global module.
</LI>

<LI>Otherwise, ...</LI>

</UL>

</BLOCKQUOTE>

</LI>

<LI>
Add an example at the end of 10.1 [<A href="https://wg21.link/module.unit#7">module.unit</A>] paragraph 7:

<BLOCKQUOTE>

<P class="ins">[ <I>Example</I>:</P>

<PRE class="ins">
  //<SPAN CLASS="cmnt"> Translation unit #1</SPAN>
  export module Foo;
  void f();              //<SPAN CLASS="cmnt"> module linkage, attached to named module</SPAN> Foo
  extern "C++" {
    export void g();     //<SPAN CLASS="cmnt"> nameable by importers</SPAN>
    void h();            //<SPAN CLASS="cmnt"> nameable in </SPAN>Foo<SPAN CLASS="cmnt">'s purview</SPAN>
  }
</PRE>

<P class="ins">Both <TT>g</TT> and <TT>h</TT> have external linkage, are attached
to the global module, and can thus also be redeclared in other
translation units:</P>

<PRE class="ins">
  //<SPAN CLASS="cmnt"> Legacy header "foo.h"</SPAN>
  extern "C++" void g();

  //<SPAN CLASS="cmnt"> Legacy header "foo-internal.h"</SPAN>
  extern "C++" void h();
</PRE>
<P class="ins">-- <I>end example</I> ]</P>

<P>A <I>module-declaration</I> that contains neither...</P>

</BLOCKQUOTE>
</LI>

<LI>
Change in 10.2 [<A href="https://wg21.link/module.interface#6">module.interface</A>] paragraph 6 as follows:

<BLOCKQUOTE>

A redeclaration of an entity <I>X</I> is implicitly exported
if <I>X</I> was introduced by an exported declaration; otherwise it
shall not be exported <INS>unless it has external linkage</INS>..

</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2727"></A><H4>2727.
  
Importing header units synthesized from source files
</H4>
<B>Section: </B>10.3&#160; [<A href="https://wg21.link/module.import">module.import</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2023-05-04<BR>




<P>Subclause 10.3 [<A href="https://wg21.link/module.import#5">module.import</A>] paragraph 5 specifies:</P>

<BLOCKQUOTE>

A <I>module-import-declaration</I> that specifies a <I>header-name</I>
H imports a synthesized header unit, which is a translation unit
formed by applying phases 1 to 7 of translation
(5.2 [<A href="https://wg21.link/lex.phases">lex.phases</A>]) to the source file or header nominated by
H, which shall not contain a <I>module-declaration</I>. ... An <I>importable
header</I> is a member of an implementation-defined set of headers that
includes all importable C++ library headers
(16.4.2.3 [<A href="https://wg21.link/headers">headers</A>]). H shall identify an importable
header. ...

</BLOCKQUOTE>

<P>This text seems to recognize that header units may be synthesized
from non-headers (i.e. source files), yet
a <I>module-import-declaration</I> of the
form <TT>import <I>header-name</I></TT> is required to name an
(importable) header, not an arbitrary source file turned into header
unit.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 10.3 [<A href="https://wg21.link/module.import#5">module.import</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<DEL>H shall identify an importable header.</DEL>
<INS>If H nominates a header, that header shall be an importable header.</INS>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2971"></A><H4>2971.
  
Specializations for a class are not decl-reachable
</H4>
<B>Section: </B>10.4&#160; [<A href="https://wg21.link/module.global.frag">module.global.frag</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Davis Herring
 &#160;&#160;&#160;

 <B>Date: </B>2024-12-19<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/655">#655</A>.)
</P>

<P>Consider:</P>

<PRE>
  module;
  //<SPAN CLASS="cmnt"> included...</SPAN>
  template&lt;int&gt; struct X {};
  template&lt;&gt; struct X&lt;0&gt; {};
  struct Z;
  template&lt;class&gt; struct Y {};
  template&lt;&gt; struct Y&lt;Z&gt; {};
  //<SPAN CLASS="cmnt"> ...done</SPAN>
  export module M;
  export using ::X;
  export using ::Z;
</PRE>

<P>Subclause 10.4 [<A href="https://wg21.link/module.global.frag#3.5.7">module.global.frag</A>] bullet 3.5.7 implies
that <TT>X&lt;0&gt;</TT>, but not <TT>Y&lt;Z&gt;</TT> is reachable in
importers. This is not helpful when <TT>Y</TT> is a trait defined by
another library and specialized for the library being exposed
as <TT>M</TT>.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 10.4 [<A href="https://wg21.link/module.global.frag#3.5">module.global.frag</A>] bullet 3.5 as follows:</P>

<BLOCKQUOTE>

A declaration D is <I>decl-reachable</I> from a declaration S in the
same translation unit if
<UL>
<LI>...</LI>
<LI>
there exists a declaration M that is not a <I>namespace-definition</I>
for which M is decl-reachable from S and either
<UL>
<LI>D is decl-reachable from M , or</LI>
<LI>D and M declare the same entity, and D neither is a friend
declaration nor inhabits a block scope, or</LI>
<LI>D declares a namespace N and M is a member of N , or</LI>
<LI>one of D and M declares a class or class template C and the other
declares a member or friend of C, or</LI>
<LI>one of D and M declares an enumeration E and the other declares an
enumerator of E, or</LI>
<LI>D declares a function or variable and M is declared in D, [
Footnote: ... ] or</LI>
<LI>one of D and M declares a template and the other declares
a partial or explicit specialization or an implicit or explicit
instantiation of that template, or</LI>
<LI class="ins">
<I>D</I> declares a partial or explicit specialization
or an explicit instantiation and <I>M</I> declares an entity that
appears in <I>D</I>'s (possibly deduced) template arguments, or</LI>
<LI>M declares a class template and D is a deduction guide for that
template, or</LI>
<LI>one of D and M declares a class or enumeration type and the other
introduces a typedef name for linkage purposes for that type.</LI>
</UL>
</LI>
</UL>
</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="511"></A><H4>511.
  
POD-structs with template assignment operators
</H4>
<B>Section: </B>11.2&#160; [<A href="https://wg21.link/class.prop">class.prop</A>]
 &#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 (11.2 [<A href="https://wg21.link/class.prop#1">class.prop</A>] paragraph 1).  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
(11.4.6 [<A href="https://wg21.link/class.copy.assign#12">class.copy.assign</A>] paragraph 12).  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 CLASS="cmnt"> calls </SPAN>X::operator=&lt;X&gt;(X&amp;)
    }
</PRE>

<P>Is this intentional?</P>

<BR><BR><HR>
<A NAME="2463"></A><H4>2463.
  
Trivial copyability and unions with non-trivial members
</H4>
<B>Section: </B>11.2&#160; [<A href="https://wg21.link/class.prop">class.prop</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2020-11-30
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>According to 11.2 [<A href="https://wg21.link/class.prop#1">class.prop</A>] paragraph 1,</P>

<BLOCKQUOTE>

<P>A <I>trivially copyable class</I> is a class:</P>

<UL>
<LI><P>that has at least one eligible copy constructor, move
constructor, copy assignment operator, or move assignment
operator (11.4.4 [<A href="https://wg21.link/special">special</A>],
11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>], 11.4.6 [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]),</P></LI>

<LI><P>where each eligible copy constructor, move
constructor, copy assignment operator, and move assignment
operator is trivial, and</P></LI>

<LI><P>that has a trivial, non-deleted destructor
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]).</P></LI>

</UL>

</BLOCKQUOTE>

<P>This definition has surprising effects in a union whose
members are not trivial. For example:</P>

<PRE>
  struct S {
    S&amp; operator=(const S&amp;);
  };
  union U {
    S s;
  };
</PRE>

<P>In this case, <TT>S</TT> is not trivially copyable because
its assignment operator is non-trivial, although its copy
constructor is trivial. <TT>U</TT>, however, is trivially
copyable because its assignment operator is not eligible
(11.4.4 [<A href="https://wg21.link/special#6">special</A>] paragraph 6) because it is
deleted, but its copy constructor is trivial, thus satisfying
the second bullet.</P>

<P>It is unclear why, for example, a complete object of type
<TT>S</TT> cannot be <TT>memcpy</TT>ed but such an object
can be <TT>memcpy</TT>ed when embedded in a union.</P>

<P>There is implementation divergence in the handling of
this example.</P>

<P><B>CWG 2022-11-10</B></P>

<P>Traditionally, the rule for trivial copyability has been that each
of the potentially user-written ways of copying a class (copy/move
constructors, copy/move assignment operators) have to be trivial (or
deleted). See C++17 subclause 12p6:</P>

<BLOCKQUOTE>

A <I>trivially copyable class</I> is a class:

<UL>
<LI>
where each copy constructor, move constructor, copy assignment
operator, and move assignment operator (15.8, 16.5.3) is either
deleted or trivial,
</LI>

<LI>that has at least one non-deleted copy constructor, move
constructor, copy assignment operator, or move assignment operator,
and</LI>

<LI>
that has a trivial, non-deleted destructor (15.4).</LI>

</UL>

</BLOCKQUOTE>

<P>That seems unhelpful.  The rule should instead be that if there is
any way of copying the class such that the compiler will generate
a <TT>memcpy</TT> (because the corresponding operation is trivial),
the user should be allowed to perform <TT>memcpy</TT>, too. In terms
of wording, this amounts to striking the first bullet and adding
"trivial" to the second bullet. (The wording in the current working
draft considers eligibility, which complicates the treatment slightly
in terms unrelated to the present issue.)</P>

<P>CWG is seeking EWG advice on this issue via
<A HREF="https://github.com/cplusplus/papers/issues/1363">cplusplus/papers#1363</A>.</P>

<P><B>Additional notes (March, 2023)</B></P>

<P>
<TT>std::tuple</TT> with trivially-copyable element types and with
no elements (<TT>std::tuple&lt;&gt;</TT>) ought to be trivially
copyable, but the recent addition of <TT>const</TT>-qualified
assignment operators makes that not so under the status quo core
language rules.</P>

<BR><BR><HR>
<A NAME="2736"></A><H4>2736.
  
Standard layout class with empty base class also in first member
</H4>
<B>Section: </B>11.2&#160; [<A href="https://wg21.link/class.prop">class.prop</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>L&#233;n&#225;rd Szolnoki
 &#160;&#160;&#160;

 <B>Date: </B>2023-05-10<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/317">#317</A>.)</P>

<P>Consider:</P>

<PRE>
  struct A {};
  struct B : A { char c; };

  struct C : A {
    B b;
  };
</PRE>

<P>Class C satisfies all the conditions to be considered
standard-layout, including 11.2 [<A href="https://wg21.link/class.prop#3.7">class.prop</A>] bullet 3.7:
<UL>
<LI>M(C) is the union of {B} and M(B) per 11.2 [<A href="https://wg21.link/class.prop#3.7.2">class.prop</A>] bullet 3.7.2.</LI>
<LI>M(B) is the union of {char} and M(char) per
11.2 [<A href="https://wg21.link/class.prop#3.7.2">class.prop</A>] bullet 3.7.2.</LI>
<LI>M(char) is an empty set per 11.2 [<A href="https://wg21.link/class.prop#3.7.5">class.prop</A>] bullet 3.7.5.</LI>
</UL>

</P>

<P>Thus, M(C) is {char,B}, neither of which is a base class of C, and
thus C is standard-layout, contrary to popular ABI rules that do not
provide pointer interconvertibility between C::b and C.</P>

<P><U>Suggested resolution (reviewed by CWG 2024-03-01, with no consensus):</U></P>

<OL>
<LI>
<P>Change in 11.2 [<A href="https://wg21.link/class.prop#3.7">class.prop</A>] bullet 3.7 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>
has no element of the set M(S) of types as a base class, where for any
type X, M(X) is defined as follows<INS>, where <TT>B(S)</TT> is a set
of types consisting of <TT>S</TT> and each direct and indirect base
class of <TT>S</TT></INS>. [Footnote: ...]  [<I>Note 2:</I> M(X) is
the set of the types of all non-base-class subobjects that can be at a
zero offset in X. &#8212;<I>end note</I>]
<UL>
<LI>If X is a non-union class type with no non-static data members,
the set M(X) is empty.</LI>
<LI>If X is a non-union class type with a non-static data member of
type X0 that is either of zero size or is the first non-static data
member of X (where said member may be an anonymous union), the set
M(X) <DEL>consists of X0</DEL> <INS>is the union of B(X0)</INS>
and <DEL>the elements of</DEL> M(X0).</LI>
<LI>If X is a union type, the set M(X) is the union of all M(Ui) and
<DEL>the set containing</DEL> all <DEL>Ui</DEL> <INS>B(Ui)</INS>,
where each Ui is the type of the ith non-static data member of X.</LI>
<LI>If X is an array type with element type Xe, the set M(X) <DEL>consists
of Xe</DEL> <INS>is the union of B(Xe)</INS> and <DEL>the elements
of</DEL> M(Xe).</LI>
<LI>If X is a non-class, non-array type, the set M(X) is empty.</LI>
</UL>

</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Add more examples in 11.2 [<A href="https://wg21.link/class.prop#4">class.prop</A>] paragraph 4:</P>

<PRE class="ins">

  struct X {};                     // <SPAN CLASS="cmnt">standard-layout class</SPAN>
  struct Y : X { char c; };        // <SPAN CLASS="cmnt">standard-layout class</SPAN>
  struct Z : X { Y y; };           // <SPAN CLASS="cmnt">not a standard-layout class</SPAN>

  struct H {};                     // <SPAN CLASS="cmnt">standard-layout class</SPAN>
  struct I : H {};                 // <SPAN CLASS="cmnt">standard-layout class</SPAN>
  struct J { I i; };               // <SPAN CLASS="cmnt">standard-layout class</SPAN>
  struct K : I { J j; };           // <SPAN CLASS="cmnt">not a standard-layout class</SPAN>
</PRE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="3049"></A><H4>3049.
  
Implicitly deleted move operation should not disable trivial relocation
</H4>
<B>Section: </B>11.2&#160; [<A href="https://wg21.link/class.prop">class.prop</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Pablo Halpern
 &#160;&#160;&#160;

 <B>Date: </B>2025-07-10
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>Consider:</P>

<PRE>
  struct A { const int i; };   //<SPAN CLASS="cmnt"> trivially copyable, but not trivially relocatable (deleted copy-assignment)</SPAN>
  struct B { int&amp; r; };        //<SPAN CLASS="cmnt"> trivially copyable, but not trivially relocatable (deleted copy-assignment)</SPAN>
  struct C trivially_relocatable_if_eligible { C(); C operator=(const C&amp;) = delete; }; //<SPAN CLASS="cmnt"> trivially relocatable</SPAN>
  struct D { C m; };           //<SPAN CLASS="cmnt"> not trivially relocatable</SPAN>
</PRE>

<P>All of <TT>A</TT>, <TT>B</TT>, <TT>D</TT> ought to be trivially
relocatable, but are not per the current Working Draft, because their
copy assignment operators are implicitly deleted.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 11.2 [<A href="https://wg21.link/class.prop#2">class.prop</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A class C is <I>default-movable</I> if
<UL>
<LI>overload resolution for direct-initializing an object of type C
from an xvalue of type C selects a constructor that is a direct member
of C and is neither user-provided nor <INS>explicitly</INS> deleted,</LI>
<LI>overload resolution for assigning to an lvalue of type C from an
xvalue of type C selects an assignment operator function that is a
direct member of C and is neither user-provided
nor <INS>explicitly</INS> deleted, and</LI>
<LI>C has a destructor that is neither user-provided
nor <INS>explicitly</INS> deleted.</LI>
</UL>

</BLOCKQUOTE>

<P><B>Additional notes (August, 2025)</B></P>

<P>Forwarded to EWG to confirm design intent with paper issue
<A HREF="https://github.com/cplusplus/papers/issues/2408">#2408</A>,
by decision of the CWG chair.</P>

<BR><BR><HR>
<A NAME="2188"></A><H4>2188.
  
<I>empty-declaration</I> grammar ambiguity
</H4>
<B>Section: </B>11.4.1&#160; [<A href="https://wg21.link/class.mem.general">class.mem.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-10-21<BR>




<P>(The originally reported ambiguity between <I>simple-declaration</I> and
<I>empty-declaration</I> does not seem to exist.)</P>

<P>There is a grammar ambiguity between</P>

<PRE>
  <I>empty-declaration:</I>
     ;
</PRE>

<P>and</P>

<PRE>
  <I>member-declaration :
      attribute-specifier-seq<sub>opt</sub> decl-specifier-seq<sub>opt</sub> member-declarator-list<sub>opt</sub></I> ;
      ...
      <I>empty-declaration</I>
</PRE>

<BR><BR><HR>
<A NAME="2852"></A><H4>2852.
  
Complete-class contexts and class-scope lambdas
</H4>
<B>Section: </B>11.4.1&#160; [<A href="https://wg21.link/class.mem.general">class.mem.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2023-10-25<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/449">#449</A>
and gcc
<A HREF="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923">bugzilla 111923</A>.)</P>

<P>Subclause 11.5.1 [<A href="https://wg21.link/class.union.general#7">class.union.general</A>] paragraph 7 is overly broad,
presumably including <I>noexcept-specifier</I>s in declarations of
non-static data members of function pointer type and default arguments
in class-scope lambda expressions.</P>

<P><U>Suggested resolution:</U></P>



<BLOCKQUOTE>

A <I>complete-class context</I> of a class <DEL>(template)</DEL>
<INS>or class template <TT>C</TT></INS> is a
<UL>
<LI>function body (9.6.1 [<A href="https://wg21.link/dcl.fct.def.general">dcl.fct.def.general</A>]),</LI>
<LI>default argument (9.3.4.7 [<A href="https://wg21.link/dcl.fct.default">dcl.fct.default</A>]) <INS>of a function declaration</INS>,</LI>
<LI>default template argument (13.2 [<A href="https://wg21.link/temp.param">temp.param</A>]),</LI>
<LI>
<I>noexcept-specifier</I> (14.5 [<A href="https://wg21.link/except.spec">except.spec</A>]) <INS>of a
function declaration</INS>, <DEL>or</DEL>
</LI>
<LI>default member initializer<INS>, or</INS>
</LI>
<LI class="ins">complete-class context of a nested class
(11.4.12 [<A href="https://wg21.link/class.nest">class.nest</A>]) defined in <TT>C</TT>,
recursively,</LI>
</UL>
<INS>where the function, template, non-static data member, or nested
class is declared by a <I>member-declaration</I> of <TT>C</TT></INS>
<DEL>within the <I>member-specification</I> of the class or class
template</DEL>.
<DEL>[<I>Note 4:</I> A complete-class context of a nested class is
also a complete-class context of any enclosing class, if the nested
class is defined within the <I>member-specification</I> of the
enclosing class. &#8212;<I>end note</I>]</DEL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2979"></A><H4>2979.
  
Duplicate declarations of enumerations in class scope
</H4>
<B>Section: </B>11.4.1&#160; [<A href="https://wg21.link/class.mem.general">class.mem.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2024-12-31<BR>




<P>Consider:</P>

<PRE>
  struct S {
    enum B {
      A
    };
    using B::A;
    //<SPAN CLASS="cmnt"> or:</SPAN>
    //<SPAN CLASS="cmnt"> using enum B ;</SPAN>
  };
</PRE>

<P>This is neither prohibited by 11.4.1 [<A href="https://wg21.link/class.mem.general#6">class.mem.general</A>] paragraph 6
(because <I>using-declarator</I>s are not members per
11.4.1 [<A href="https://wg21.link/class.mem.general#3">class.mem.general</A>] paragraph 3) nor by 9.10 [<A href="https://wg21.link/namespace.udecl#8">namespace.udecl</A>] paragraph 8.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 9.10 [<A href="https://wg21.link/namespace.udecl#8">namespace.udecl</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

<INS>[ Note:</INS> If a declaration is named by
two <I>using-declarator</I>s that inhabit the same class scope, the
program is ill-formed <INS>(11.4.1 [<A href="https://wg21.link/class.mem.general">class.mem.general</A>])</INS>.
[<I>Example:</I> ... -- end example ]
<INS>-- end note ]</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.1 [<A href="https://wg21.link/class.mem.general#6">class.mem.general</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

<DEL>A member</DEL> <INS>An entity</INS> shall not be declared <INS>or
named by a <I>using-declarator</I> (9.10 [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>])</INS>
twice in the
<I>member-specification</I>, except that
<UL>
<LI>a nested class or member class template can be declared and then
later defined, and</LI>
<LI>an enumeration can be introduced with an
<I>opaque-enum-declaration</I> and later redeclared with an
<I>enum-specifier</I>.</LI>
</UL>

<INS>[ Example:</INS>
<PRE class="ins">
  struct S {
    class C;
    class C {};      //<SPAN CLASS="cmnt"> OK</SPAN>
    enum E { e };
    using E::e;      //<SPAN CLASS="cmnt"> error: redeclaration of </SPAN>e
  };

</PRE>
<INS>-- end example ]</INS>

<P>[Note 4: A single name can denote several member functions provided
their types are sufficiently different (6.4.1 [<A href="https://wg21.link/basic.scope.scope">basic.scope.scope</A>]).
-- end note]</P>

</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="3051"></A><H4>3051.
  
Missing specification for types of member subobjects
</H4>
<B>Section: </B>11.4.1&#160; [<A href="https://wg21.link/class.mem.general">class.mem.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2025-07-09<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/726">#726</A>.)</P>

<P>The standard does not appear to specify the types of member
subobjects. In particular, the manner in which the cv-qualifiers of
the type of the enclosing class object combine with those of the
member declaration is specified only for member access expressions
(7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]), not for the type of the subobject
itself.</P>

<P><U>Suggested resolution:</U></P>

<OL>
<LI>
<P>Change in 7.6.1.5 [<A href="https://wg21.link/expr.ref#8.2">expr.ref</A>] bullet 8.2 and 8.6 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>Otherwise, if E2 designates a non-static data member <DEL>and the
type of E1 is &#8220;cq1 vq1 X&#8221;, and the type of E2 is
&#8220;cq2 vq2 T&#8221;</DEL>, the expression designates the
corresponding member subobject of the object designated by E1 <INS>and
its type is the type that a member subobject corresponding to the
member designated by <TT>E2</TT> would have in an object whose type is
that of <TT>E1</TT> (11.4.1 [<A href="https://wg21.link/class.mem.general">class.mem.general</A>])</INS>. If E1 is an
lvalue, then E1.E2 is an lvalue; otherwise E1.E2 is an xvalue. <DEL>Let the
notation vq12 stand for the &#8220;union&#8221; of vq1 and vq2 ; that
is, if vq1 or vq2 is volatile, then vq12 is volatile. Similarly, let
the notation cq12 stand for the &#8220;union&#8221; of cq1 and cq2 ;
that is, if cq1 or cq2 is const, then cq12 is const. If the entity
designated by E2 is declared to be a mutable member, then the type of
E1.E2 is &#8220;vq12 T&#8221;. If the entity designated by E2 is not
declared to be a mutable member, then the type of E1.E2 is &#8220;cq12
vq12 T&#8221;.</DEL>
</LI>
<LI>...</LI>
<LI>Otherwise, if E2 designates a direct base class relationship (D,
B) and the type of E1 is cv T, the expression designates the direct
base class subobject of type <DEL>B</DEL>
<INS>"<I>cv</I> <TT>B</TT>"</INS> of the object
designated by E1. If E1 is an lvalue, then E1.E2 is an lvalue;
otherwise, E1.E2 is an xvalue. The type of E1.E2 is &#8220;cv
B&#8221;.
</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.1 [<A href="https://wg21.link/class.mem.general#6">class.mem.general</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

Every object of class type has a unique member subobject corresponding
to each of its direct non-static data members.
<INS>For a non-static data member of non-reference type
"<I>cq2</I> <I>vq2</I> <TT>T</TT>" that is a direct member of an
object whose type is "<I>cq1</I> <I>vq1</I> <TT>C</TT>",
let <I>vq12</I> be <TT>volatile</TT> if either <TT>vq1</TT>
or <TT>vq2</TT> is volatile, and empty otherwise, and let <I>cq12</I>
be <TT>const</TT> if either <I>cq1</I> or <I>cq2</I> is
<TT>const</TT>, and empty otherwise. If the member is declared
<TT>mutable</TT>, then the type of the corresponding subobject is
"<I>vq12</I> <TT>T</TT>"; otherwise, the type of the corresponding
subobject is "<I>cq12</I> <I>vq12</I> <TT>T</TT>".</INS> If any
non-static data member of a class C is of reference type, then let D
be an invented class that is identical to C except that each
non-static member of D corresponding to a member of C of type
&#8220;reference to T&#8221; instead has type &#8220;pointer to
T&#8221;. Every member subobject of a complete object of type C has
the same size, alignment, and offset as that of the
corresponding subobject of a complete object of type D. The size and
alignment of C are the same as the size and alignment of D.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.7.2 [<A href="https://wg21.link/class.mi#4">class.mi</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

A base class specifier that does not contain the keyword virtual
specifies a non-virtual base class. A base class specifier that
contains the keyword virtual specifies a virtual base class. For each
distinct occurrence of a non-virtual base class <INS><TT>A</TT></INS>
in the class lattice of the most derived class <INS><TT>C</TT></INS>,
<DEL>the</DEL> <INS>a</INS> most derived object
(6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) <INS>of type "<I>cv</I> <TT>C</TT>"</INS>
shall contain a corresponding distinct base class subobject
of <DEL>that</DEL> type <INS>"<I>cv</I> <TT>A</TT>"</INS>. For each
distinct base class <INS><TT>B</TT></INS> that is specified virtual,
the most derived object shall contain a single base class subobject of
that type <INS>"<I>cv</I> <TT>B</TT>"</INS>.

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2787"></A><H4>2787.
  
Kind of explicit object copy/move assignment function
</H4>
<B>Section: </B>11.4.4&#160; [<A href="https://wg21.link/special">special</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

 <B>Date: </B>2023-08-08<BR>


<P>Consider:</P>

<PRE>
  struct S {
    auto &amp; operator=(this S &amp;, S&amp;&amp;);
    auto &amp; operator=(this S &amp;, const S&amp;);
  };
</PRE>

<P>The rule in 11.4.4 [<A href="https://wg21.link/special#5">special</A>] paragraph 5 does not treat
explicit-object member functions correctly:</P>

<BLOCKQUOTE>

Two special member functions are of the same kind if:
<UL>
<LI>they are both default constructors,</LI>
<LI>they are both copy or move constructors with the same first
parameter type, or</LI>
<LI>they are both copy or move assignment operators with the same
first parameter type and the same <I>cv-qualifier</I>s
and <I>ref-qualifier</I>, if any.</LI>
</UL>

</BLOCKQUOTE>

<P><U>Possible resolution:</U></P>

<P>Change in 11.4.4 [<A href="https://wg21.link/special#5">special</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

Two special member functions are of the same kind if:
<UL>
<LI>they are both default constructors,</LI>
<LI>they are both copy or move constructors with the same first
parameter type, or</LI>
<LI>they are both copy or move assignment operators with the same
first <INS>non-object</INS> parameter type <DEL>and</DEL><INS>,</INS>
the same <DEL><I>cv-qualifier</I>s</DEL> <INS>object parameter
type,</INS> and <INS>either both are implicit object member functions
with no</INS> <I>ref-qualifier</I>, <DEL>if any</DEL> <INS>or neither
of them is</INS>.</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2841"></A><H4>2841.
  
When do const objects start being const?
</H4>
<B>Section: </B>11.4.5.1&#160; [<A href="https://wg21.link/class.ctor.general">class.ctor.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-12-14<BR>




<P>Subclause 11.4.5.1 [<A href="https://wg21.link/class.ctor.general#5">class.ctor.general</A>] paragraph 5 specifies:</P>

<BLOCKQUOTE>

A constructor can be invoked for a const, volatile or const volatile
object. const and volatile semantics (9.2.9.2 [<A href="https://wg21.link/dcl.type.cv">dcl.type.cv</A>])
are not applied on an object under construction. They come into effect
when the constructor for the most derived object
(6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) ends.

</BLOCKQUOTE>

<P>This is referring to the "constructor ending", but
6.8.4 [<A href="https://wg21.link/basic.life#1.3">basic.life</A>] bullet 1.3 refers to "the initialization
is complete".  These two points in the evaluation are different at
least for delegating constructors and named return value
optimization, and thus the rules are in conflict.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 11.4.5.1 [<A href="https://wg21.link/class.ctor.general#5">class.ctor.general</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<INS>[ Note:</INS> A constructor can be invoked for a const, volatile
or const volatile object. const and volatile semantics
(9.2.9.2 [<A href="https://wg21.link/dcl.type.cv">dcl.type.cv</A>]) are not applied on an object under
construction<DEL>. They</DEL> <INS>; they</INS> come into effect when
the <DEL>constructor for the most derived object
(6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) ends</DEL> <INS>initialization of the
result object completes (6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>])</INS>. <INS>--
end note ]</INS>

</BLOCKQUOTE>

<P><B>CWG 2024-02-02</B></P>

<P>There are various properties that come to be for an object during
its initialization.  For example, the vtable is fully set up and the
destructor will be invoked once the non-delegating constructor
completes (<A HREF="cwg_active.html#2756">issue 2756</A>).  The main property
of a const object is its immutability from an optimizer perspective.
With NRVO (11.9.6 [<A href="https://wg21.link/class.copy.elision">class.copy.elision</A>]), it is possible to have
multiple defining declarations for the same object, for example:</P>
<PRE>
  struct A {
    int x;
  };
  int foo(const A* p)
  {
    A a{10};            // #1
    a.x = 1 + p-&gt;x;     // <SPAN CLASS="cmnt">what's the value of</SPAN> a.x<SPAN CLASS="cmnt">?</SPAN>
    return a;
  }
  const A g = foo(&amp;g);  // #2
</PRE>

<P>Given NRVO, both #1 and #2 are declarations of the same object.
Those declarations may differ in their cv-qualification for the
object.  CWG tentatively agreed on the direction that the innermost
declaration defines the object's properties, in particular whether it
has been initialized and whether it is const.</P>

<P>While NRVO is disallowed in constant evaluation, it was noted that
user code can determine whether NRVO occurs at runtime by comparing a
pointer to the local object with a pointer to the object in the
surrounding context.</P>

<BR><BR><HR>
<A NAME="2999"></A><H4>2999.
  
Trivial unions changing existing behavior
</H4>
<B>Section: </B>11.4.5.2&#160; [<A href="https://wg21.link/class.default.ctor">class.default.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2025-02-14
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Consider:</P>

<PRE>
  union U { int a, b; };
  template&lt;U u&gt; class X {};
  constexpr U make() { U u; return u; }
  void f(X&lt;make()&gt;) {}
</PRE>

<P>Before P3074R7, the template argument of <TT>X</TT> was a union
object with no active member.  Now, the default construction
of <TT>U</TT> starts the lifetime of <TT>U::a</TT> because it has
implicit-lifetime type (11.4.5.2 [<A href="https://wg21.link/class.default.ctor#4">class.default.ctor</A>] paragraph 4).</P>

<P>This changes the mangling of <TT>f</TT>, because a union with no
active member is different from a union with the first member active.
More importantly, it is now ill-formed, because <TT>U::a</TT> is
in-lifetime, but uninitialized (7.7 [<A href="https://wg21.link/expr.const#22.2">expr.const</A>] bullet 22.2).</P>

<P>Also consider the following implementation divergence</P>

<PRE>
  struct E { };
  union U { E e; };
  template&lt;U u&gt; class X {};

  constexpr U make() { U u; return u; }
  constexpr U make2() { U u{}; return u; }

  void f(X&lt;make()&gt;) {}
  void f(X&lt;make2()&gt;) {}    //<SPAN CLASS="cmnt"> OK with clang; redefinition error with gcc</SPAN>
</PRE>

<P>If any of those behavior changes are intended, an Annex C entry is
needed.</P>

<P><B>Additional notes (September, 2025)</B></P>

<P>See also <A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3726r0.html">P3726R0</A>
(Adjustments to Union Lifetime Rules).</P>

<P>Forwarding to EWG to clarify the intent with
<A HREF="https://github.com/cplusplus/papers/issues/2418">paper issue #2418</A>.</P>

<BR><BR><HR>
<A NAME="1548"></A><H4>1548.
  
Copy/move construction and conversion functions
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

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




<P>The current wording of 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#31">class.copy.ctor</A>] paragraph 31
refers only to constructors and destructors:</P>

<BLOCKQUOTE>

When certain criteria are met, an implementation is allowed to omit
the copy/move construction of a class object, even if the constructor
selected for the copy/move operation and/or the destructor for the
object have side effects.

</BLOCKQUOTE>

<P>However, in some cases (e.g., <TT>auto_ptr</TT>) a conversion function
is also involved in the copying, and it could presumably also have visible
side effects that would be eliminated by copy elision.  (Some additional
contexts that may also require changes in this regard are mentioned in the
resolution of <A HREF="cwg_defects.html#535">issue 535</A>.)</P>

<P><B>Additional note (September, 2012):</B></P>

<P>The default arguments of an elided constructor can also have side
effects and should be mentioned, as well; however, the elision should
not change the odr-use status of functions and variables appearing in
those default arguments. </P>

<BR><BR><HR>
<A NAME="2743"></A><H4>2743.
  
Copying non-trivial objects nested within a union
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2023-06-05<BR>


<P>Consider:</P>

<PRE>
  #include&lt;new&gt;

  struct A {
    ~A();
  };

  union U {
    alignas(A) unsigned char buf[sizeof(A)];
  };

  void f() {
    U u;
    ::new (u.buf) A();  //<SPAN CLASS="cmnt"> object of type </SPAN>A<SPAN CLASS="cmnt"> is nested within </SPAN>u<SPAN CLASS="cmnt"> because </SPAN>u<SPAN CLASS="cmnt"> provides storage</SPAN>
    U v = u;            // #1
  }
</PRE>

<P>Subclause 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#15">class.copy.ctor</A>] paragraph 15 specifies:</P>

<BLOCKQUOTE>

The implicitly-defined copy/move constructor for a union X copies the
object representation (6.9.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]) of X. For each
object nested within (6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) the object that is
the source of the copy, a corresponding object o nested within the
destination is identified (if the object is a subobject) or created
(otherwise), and the lifetime of o begins before the copy is
performed.

</BLOCKQUOTE>

<P>Thus, the rule seems to require that #1 creates an object of
type <TT>A</TT> inside <TT>v.buf</TT> (without invoking a constructor
of <TT>A</TT>), and then a copy of the object representation is
performed.  Creating an object out of thin air can plausibly work only
for implicit-lifetime types (11.2 [<A href="https://wg21.link/class.prop#9">class.prop</A>] paragraph 9), and
meaningfully copying the object representation works only for
trivially copyable types (6.9.1 [<A href="https://wg21.link/basic.types.general#3">basic.types.general</A>] paragraph 3).  The
rule about nested objects should be suitably limited.</P>

<P>Subclause 11.4.6 [<A href="https://wg21.link/class.copy.assign#13">class.copy.assign</A>] paragraph 13 has a similar rule
for copy/move assignment:</P>

<BLOCKQUOTE>

The implicitly-defined copy/move assignment operator for a union X
copies the object representation (6.9.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]) of X. If
the source and destination of the assignment are not the same object,
then for each object nested within (6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) the
object that is the source of the copy, a corresponding object o nested
within the destination is created, and the lifetime of o begins before
the copy is performed.

</BLOCKQUOTE>

<P><U>Possible resolution:</U></P>

<OL>

<LI>
<P>Change in 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#15">class.copy.ctor</A>] paragraph 15 as follows:</P>

<BLOCKQUOTE>

The implicitly-defined copy/move constructor for a union X copies the
object representation (6.9.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]) of X. For each
object <INS>of implicit-lifetime type
(6.9.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>])</INS> nested within
(6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) the object that is the source of the
copy, a corresponding object o nested within the destination is
identified (if the object is a subobject) or created (otherwise), and
the lifetime of o begins before the copy is performed.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.6 [<A href="https://wg21.link/class.copy.assign#13">class.copy.assign</A>] paragraph 13 as follows:</P>

<BLOCKQUOTE>

The implicitly-defined copy/move assignment operator for a union X
copies the object representation (6.9.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]) of X. If
the source and destination of the assignment are not the same object,
then for each object <INS>of implicit-lifetime type
(6.9.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>])</INS> nested within
(6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) the object that is the source of the
copy, a corresponding object o nested within the destination is
created, and the lifetime of o begins before the copy is performed.

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="2837"></A><H4>2837.
  
Instantiating and inheriting by-value copy constructors
</H4>
<B>Section: </B>11.4.5.3&#160; [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2023-11-29<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/474">#474</A>.)</P>

<P>Subclause 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#5">class.copy.ctor</A>] paragraph 5 specifies:</P>

<BLOCKQUOTE>

A declaration of a constructor for a class X is ill-formed if its
first parameter is of type cv X and either there are no other
parameters or else all other parameters have default arguments. A
member function template is never instantiated to produce such a
constructor signature.

</BLOCKQUOTE>

<P>It is unclear what happens when such a constructor signature is
inherited from a base class.  Also, the wording "never instantiated"
is not detailed enough.</P>

<P><U>Suggested resolution:</U></P>

<OL>
<LI>
<P>Add a paragraph before 9.10 [<A href="https://wg21.link/namespace.udecl#13">namespace.udecl</A>] paragraph 13 as follows:</P>

<BLOCKQUOTE>

<P class="ins">
The set of declarations named by a <I>using-declarator</I> that
inhabits a class <TT>C</TT> does not include any constructor whose
first parameter has type <I>cv</I> <TT>C</TT> and all of whose
remaining parameters (if any) have default arguments.
</P>

<P>
Constructors that are named by a <I>using-declaration</I> are
treated as though they were constructors of the derived class ...
</P>
</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#5">class.copy.ctor</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

A declaration of a constructor for a class X is ill-formed if its
first parameter is of type cv X and either there are no other
parameters or else all other parameters have default arguments. <DEL>A
member function template is never instantiated to produce such a
constructor signature.</DEL> <INS>During type deduction for a
constructor template of <TT>X</TT> (13.10.3.1 [<A href="https://wg21.link/temp.deduct.general">temp.deduct.general</A>]),
if substitution produces such a constructor signature, type deduction
fails.</INS>
[ Example 5:
<PRE>
  struct S {
    template&lt;typename T&gt; S(T);
    S();
  };
  S g;
  void h() {
    S a(g);  //<SPAN CLASS="cmnt"> <DEL>does not instantiate the member template to produce S::S&lt;S&gt;(S);</DEL> <INS>no candidate generated from the member template;</INS></SPAN>
             //<SPAN CLASS="cmnt"> <DEL>uses</DEL> the implicitly declared copy constructor <INS>is used</INS></SPAN>
  }
</PRE>
-- end example]

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2329"></A><H4>2329.
  
Virtual base classes and generated assignment operators
</H4>
<B>Section: </B>11.4.6&#160; [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-10-31<BR>


<P>An example like the following,</P>

<PRE>
  class A {
  private:
    A&amp; operator=(const A&amp;);
  };

  class B : virtual public A {
  public:
    B&amp; operator = (const B&amp; src);
  };

  class C: public B {
  public:
    void f(const C* psrc) {
      *this = *psrc;
    }
  };
</PRE>

<P>is presumably well-formed, even though the copy assignment
operator of <TT>A</TT> is inaccessible in <TT>C</TT>, because
11.4.6 [<A href="https://wg21.link/class.copy.assign#12">class.copy.assign</A>] paragraph 12 says that only direct,
not virtual, base class object assignment operators are invoked
by the generated assignment operator (although there is
implementation divergence on this question).</P>

<P>Should the example also be well-formed if <TT>A</TT> were a
direct virtual base of <TT>C</TT>? That is, if a direct virtual
base also has an indirect derivation path, its direct derivation
can be ignored for generated assignment operators.</P>

<P>Possibly relevant to this question is the permission for an
implementation to assign virtual base class objects more than
once:</P>

<BLOCKQUOTE>

It is unspecified whether subobjects representing virtual base
classes are assigned more than once by the implicitly-defined
copy/move assignment operator.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2897"></A><H4>2897.
  
Copying potentially-overlapping union subobjects
</H4>
<B>Section: </B>11.4.6&#160; [<A href="https://wg21.link/class.copy.assign">class.copy.assign</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2024-05-30<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/542">#542</A>.)</P>

<P>Consider:</P>

<PRE>
  union U {};
  struct S {
    U u [[no_unique_address]];
    char c;
  };
  S s;
  s.c = 1;
  s.u = U();   // <SPAN CLASS="cmnt">#1</SPAN>
</PRE>

<P>As specified, the move-assignment at #1 might disturb the value
of <TT>s.c</TT>.</P>

<P><U>Suggested resolution:</U></P>

<P>(Note that the value representation of a union arguably depends on
which of its members is active.)</P>

<OL>
<LI>
<P>Change in 11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#15">class.copy.ctor</A>] paragraph 15 as follows:</P>

<BLOCKQUOTE>

The implicitly-defined copy/move constructor for a union X copies the
<DEL>object</DEL> <INS>value</INS> representation
(6.9.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]) of X. For each object nested within
(6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) the object that is the source of the
copy, a corresponding object o nested within the destination is
identified (if the object is a subobject) or created (otherwise), and
the lifetime of o begins before the copy is performed.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.4.6 [<A href="https://wg21.link/class.copy.assign#13">class.copy.assign</A>] paragraph 13 as follows:</P>

<BLOCKQUOTE>

The implicitly-defined copy/move assignment operator for a union X
copies the <DEL>object</DEL> <INS>value</INS> representation
(6.9.1 [<A href="https://wg21.link/basic.types.general">basic.types.general</A>]) of X. If the source and destination of
the assignment are not the same object, then for each object nested
within (6.8.2 [<A href="https://wg21.link/intro.object">intro.object</A>]) the object that is the source of
the copy, a corresponding object o nested within the destination is
created, and the lifetime of o begins before the copy is performed.

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="1977"></A><H4>1977.
  
Contradictory results of failed destructor lookup
</H4>
<B>Section: </B>11.4.7&#160; [<A href="https://wg21.link/class.dtor">class.dtor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2014-07-21<BR>




<P>According to 11.4.7 [<A href="https://wg21.link/class.dtor#12">class.dtor</A>] paragraph 12,</P>

<BLOCKQUOTE>

At the point of definition of a virtual destructor (including an implicit
definition (11.4.5.3 [<A href="https://wg21.link/class.copy.ctor">class.copy.ctor</A>])), the non-array deallocation
function is looked up in the scope of the destructor's class
(6.5.2 [<A href="https://wg21.link/class.member.lookup">class.member.lookup</A>]), and, if no declaration is found, the function
is looked up in the global scope. If the result of this lookup is ambiguous
or inaccessible, or if the lookup selects a placement deallocation function
or a function with a deleted definition (9.6 [<A href="https://wg21.link/dcl.fct.def">dcl.fct.def</A>]), the
program is ill-formed. [<I>Note:</I> This assures that a deallocation
function corresponding to the dynamic type of an object is available for
the <I>delete-expression</I> (11.4.11 [<A href="https://wg21.link/class.free">class.free</A>]). &#8212;<I>end
note</I>]

</BLOCKQUOTE>

<P>However, bullet 5.3 of that section says that such a lookup failure
causes the destructor to be defined as deleted, rather than making the
program ill-formed.  It appears that paragraph 12 was overlooked when
deleted functions were added to the language.  See also
11.4.11 [<A href="https://wg21.link/class.free#7">class.free</A>] paragraph 7.</P>

<BR><BR><HR>
<A NAME="2839"></A><H4>2839.
  
Explicit destruction of base classes
</H4>
<B>Section: </B>11.4.7&#160; [<A href="https://wg21.link/class.dtor">class.dtor</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2023-12-07<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/478">#478</A>.)</P>

<P>Consider:</P>

<PRE>
  struct B {};
  struct D1 : virtual B {};
  struct D2 : virtual B {};
  struct D : D1, D2 {};

  void f() {
    D *d = new D;
    static_cast&lt;D2&amp;&gt;(*d).~D2();
  }
</PRE>

<P>According to 11.4.7 [<A href="https://wg21.link/class.dtor#13">class.dtor</A>] paragraph 13, invoking a
destructor for a most derived object is different from invoking it for
a base class subobject:</P>

<BLOCKQUOTE>

After executing the body of the destructor and destroying any objects
with automatic storage duration allocated within the body, a
destructor for class X calls the destructors for X's direct
non-variant non-static data members, the destructors for X's
non-virtual direct base classes and, if X is the most derived class
(11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]), its destructor calls the destructors
for X's virtual base classes.

</BLOCKQUOTE>

<P>However, there is no means to convey the difference in an explicit
destructor call.  As an aside, potentially-overlapping subobjects
cannot be transparently replaced, thus any attempt at replacement
would implicitly end the lifetime of the complete object due to
storage reuse.</P>

<P><U>Possible resolution:</U></P>

<P>Split 7.6.1.3 [<A href="https://wg21.link/expr.call#4">expr.call</A>] paragraph 4 and amend, as follows:</P>

<BLOCKQUOTE>
<P>..., even if the type of the function actually called is
different.</P>

<P>
<INS>If the <I>postfix-expression</I> <I>P</I> names a destructor or a
pseudo-destructor, the <I>postfix-expression</I> is a
possibly-parenthesized class member access.  If <I>P</I> names a
destructor, the behavior is undefined if the object expression denotes
a base class subobject and that base class is or has a virtual base
class or a virtual function (11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]).</INS>
If <DEL>the <I>postfix-expression</I></DEL> <INS><I>P</I></INS> names
a pseudo-destructor <DEL>(in which case the <I>postfix-expression</I>
is a possibly-parenthesized class member access)</DEL>, the function
call destroys the object of scalar type denoted by the object
expression of the class member access (7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>],
6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]).
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3041"></A><H4>3041.
  
Overly aggressive rule for deleting the destructor of a union
</H4>
<B>Section: </B>11.4.7&#160; [<A href="https://wg21.link/class.dtor">class.dtor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2025-07-03<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/722">#722</A>.)</P>

<P>Paper P3074R7 added an overly aggressive rule to delete destructors
of unions, making the following example have a deleted destructor:</P>

<PRE>
  union U {
    U(int i) : i(i) { }
    int i;
  };
</PRE>

<P><U>Suggested resolution:</U></P>

<P>Change in 11.4.7 [<A href="https://wg21.link/class.dtor#7">class.dtor</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

A defaulted destructor for a class X is defined as deleted if
<UL>
<LI>X is a non-union class and any non-variant potentially constructed
subobject has class type M (or possibly multidimensional array
thereof) where M has a destructor that is deleted or is inaccessible
from the defaulted destructor,
</LI>
<LI>X is a union and <INS>there is a subobject <I>S</I> of class
type <TT>M</TT> (or possibly multi-dimensional array thereof)
where <TT>M</TT> has a destructor that is deleted, inaccessible from
the defaulted destructor, or non-trivial, and either</INS>
<UL>
<LI>overload resolution to select a constructor to default-initialize
an object of type X either fails or selects a constructor that is
either deleted or <DEL>not trivial</DEL> <INS>user-provided</INS>, or</LI>
<LI>
<DEL>X has a variant member V of class type M (or possibly
multi-dimensional array thereof) where V</DEL> <INS><I>S</I></INS> has a default member
initializer <DEL>and M has a destructor that is non-trivial</DEL>, or,</LI>
</UL>
</LI>
<LI>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.</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2513"></A><H4>2513.
  
Ambiguity with <I>requires-clause</I> and <I>operator-function-id</I>
</H4>
<B>Section: </B>11.4.8.3&#160; [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2021-12-09<BR>


<P>An ambiguity can occur with a <I>requires-clause</I> that
ends in an <I>operator-function-id</I>:</P>

<PRE>
  template&lt;typename T&gt; requires T::operator int
  const //<SPAN CLASS="cmnt"> part of operator-type-id or return type?</SPAN>
  unsigned f();

  template&lt;typename T&gt; requires T::operator int
  [[attr]] //<SPAN CLASS="cmnt"> appertains to type </SPAN>int<SPAN CLASS="cmnt"> or to declaration of </SPAN>g<SPAN CLASS="cmnt">?</SPAN>
  void g();
</PRE>

<P>Such cases are always ill-formed, because they involve
an atomic constraint of non-<TT>bool</TT> type.</P>

<BR><BR><HR>
<A NAME="1283"></A><H4>1283.
  
Static data members of classes with typedef name for linkage purposes
</H4>
<B>Section: </B>11.4.9.3&#160; [<A href="https://wg21.link/class.static.data">class.static.data</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-29<BR>


<P>According to 11.4.9.3 [<A href="https://wg21.link/class.static.data#4">class.static.data</A>] paragraph 4,</P>

<BLOCKQUOTE>

Unnamed classes and classes contained directly or indirectly within
unnamed classes shall not contain static data members.

</BLOCKQUOTE>

<P>There is no such restriction on member functions, and there is
no rationale for this difference, given that both static data members
and member functions can be defined outside a unnamed class with a
typedef name for linkage purposes.  (<A HREF="cwg_defects.html#406">Issue 406</A>
acknowledged the lack of rationale by removing the specious note in
11.4.9.3 [<A href="https://wg21.link/class.static.data">class.static.data</A>] that attempted to explain the restriction
but left the normative prohibition in place.)</P>

<P>It would be more consistent to remove the restriction for classes
with a typedef name for linkage purposes.</P>

<P><B>Additional note (August, 2012):</B></P>

<P>It was observed that, since no definition of a <TT>const</TT>
static data member is required if it is not odr-used, there is no
reason to prohibit such members in an unnamed class even without a
typedef name for linkage purposes. </P>

<BR><BR><HR>
<A NAME="2950"></A><H4>2950.
  
Value preservation in enumeration vs. integer bit-fields
</H4>
<B>Section: </B>11.4.10&#160; [<A href="https://wg21.link/class.bit">class.bit</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Geoffrey Romer
 &#160;&#160;&#160;

 <B>Date: </B>2024-05-13<BR>


<P>Subclause 11.4.10 [<A href="https://wg21.link/class.bit#4">class.bit</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

If a value of integral type (other than bool) is stored into a
bit-field of width N and the value would be representable in a
hypothetical signed or unsigned integer type with width N and the same
signedness as the bit-field's type, the original value and the value
of the bit-field compare equal. If the value true or false is stored
into a bit-field of type bool of any size (including a one bit
bit-field), the original bool value and the value of the bit-field
compare equal. If a value of an enumeration type is stored into a
bit-field of the same type and the width is large enough to hold all
the values of that enumeration type (9.8.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]), the
original value and the value of the bit-field compare equal.

</BLOCKQUOTE>

<P>Thus, for bit-fields of integral type, it is sufficient for the
actual value to fit into the bit-field.  In contrast, for bit-fields
of enumeration type, all values of the enumeration type are required
to fit even if the actual value being stored is small and would
fit.  For example:</P>

<PRE>
  enum E : uint8_t { E0 = 0, E1 = 1 };
  struct S {
    int i : 1;
    E e : 1;
  };

  void f() {
    S s = { .i = 1, .e = 1 };
    assert(s.i == 1);    // guaranteed to hold
    assert(s.e == 1);    // may not hold
  }
</PRE>

<P><U>Suggested resolution:</U></P>

<P>Change in 11.4.10 [<A href="https://wg21.link/class.bit#4">class.bit</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

If a value of integral type (other than bool) <INS>or of enumeration
type</INS> is stored into a bit-field of width N and the value would
be representable in a hypothetical signed or unsigned integer type
with width N and the same signedness as the bit-field's type<INS> or,
respectively, its underlying type</INS>, the original value and the
value of the bit-field compare equal. If the value true or false is
stored into a bit-field of type bool of any size (including a one bit
bit-field), the original bool value and the value of the bit-field
compare equal. <DEL>If a value of an enumeration type is stored into a
bit-field of the same type and the width is large enough to hold all
the values of that enumeration type (9.8.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]), the
original value and the value of the bit-field compare equal.</DEL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="57"></A><H4>57.
  
Empty unions
</H4>
<B>Section: </B>11.5&#160; [<A href="https://wg21.link/class.union">class.union</A>]
 &#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 11.5 [<A href="https://wg21.link/class.union">class.union</A>]
 against a declaration
like</P>
<PRE>
    union { int : 0; } x;
</PRE>
Should that be valid?  If so, 9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]

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="1404"></A><H4>1404.
  
Object reallocation in unions
</H4>
<B>Section: </B>11.5&#160; [<A href="https://wg21.link/class.union">class.union</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-10-19<BR>




<P>According to 11.5 [<A href="https://wg21.link/class.union#4">class.union</A>] paragraph 4,</P>

<BLOCKQUOTE>

<P>[<I>Note:</I> In general, one must use explicit destructor
calls and placement new operators to change the active member of
a union.  &#8212;<I>end note</I>] [<I>Example:</I> Consider an
object <TT>u</TT> of a union type <TT>U</TT> having non-static
data members <TT>m</TT> of type <TT>M</TT> and <TT>n</TT> of type
<TT>N</TT>. If <TT>M</TT> has a non-trivial destructor and
<TT>N</TT> has a non-trivial constructor (for instance, if they
declare or inherit virtual functions), the active member of
<TT>u</TT> can be safely switched from <TT>m</TT> to <TT>n</TT>
using the destructor and placement new operator as follows:</P>

<PRE>
  u.m.~M();
  new (&amp;u.n)  N;
</PRE>

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

</BLOCKQUOTE>

<P>This pattern is only &#8220;safe&#8221; if the original object
that is being destroyed does not involve any const-qualified or
reference types, i.e., satisfies the requirements of 6.8.4 [<A href="https://wg21.link/basic.life#7">basic.life</A>] paragraph 7,
 bullet 3:</P>

<UL><LI><P>the type of the original object is not
const-qualified, and, if a class type, does not contain any
non-static data member whose type is const-qualified or a
reference type</P></LI></UL>

<P>Although paragraph 4 of 11.5 [<A href="https://wg21.link/class.union">class.union</A>] is a note and an
example, it should at least refer to the lifetime issues described
in 6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>].</P>

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

<P>See also <A HREF="cwg_defects.html#1776">issue 1776</A>, which suggests
possibly changing the restriction in 6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>].  If
such a change is made, this issue may become moot.</P>

<BR><BR><HR>
<A NAME="2675"></A><H4>2675.
  
<TT>start_lifetime_as</TT>, placement-new, and active union members
</H4>
<B>Section: </B>11.5.1&#160; [<A href="https://wg21.link/class.union.general">class.union.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nina Ranns
 &#160;&#160;&#160;

 <B>Date: </B>2022-12-06<BR>




<P>Consider:</P>

<PRE>
  struct A { int i;};
  struct B { int j;};
  union U { A a; B b; };
  U u1{A{}};
  start_lifetime_as&lt;B&gt;(&amp;u1.a); //<SPAN CLASS="cmnt"> #1</SPAN>
  start_lifetime_as&lt;B&gt;(&amp;u1);   //<SPAN CLASS="cmnt"> #2</SPAN>
  U u2{B{}};
  start_lifetime_as&lt;U&gt;(&amp;u2);   //<SPAN CLASS="cmnt"> #3</SPAN>
  start_lifetime_as&lt;B&gt;(&amp;u1.b); //<SPAN CLASS="cmnt"> #4</SPAN>
</PRE>

<P>It is unclear which of these constructs changes the active member
of the union, and whether a union might have more than one active
member.  Subclause 11.5.1 [<A href="https://wg21.link/class.union.general#2">class.union.general</A>] paragraph 2 appears
contradictory if several members can be in-lifetime:</P>

<BLOCKQUOTE>

In a union, a non-static data member is active if its name refers to
an object whose lifetime has begun and has not ended
(6.8.4 [<A href="https://wg21.link/basic.life">basic.life</A>]). At most one of the non-static data
members of an object of union type can be active at any time, that is,
the value of at most one of the non-static data members can be stored
in a union at any time.

</BLOCKQUOTE>

<P>Similar questions arise for placement-new and
for <TT>construct_at</TT>; for the latter also during constant
evaluation.</P>

<BR><BR><HR>
<A NAME="2767"></A><H4>2767.
  
Non-defining declarations of anonymous unions
</H4>
<B>Section: </B>11.5.2&#160; [<A href="https://wg21.link/class.union.anon">class.union.anon</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-06<BR>




<P>Currently, the specification permits this example:</P>

<PRE>
  namespace {
    extern union { int x, y; };
    union { int x, y; };
  };
</PRE>

<P>However, those non-defining declarations seem to be mostly useless,
because any definition attempt would violate the one-definition rule
(6.3 [<A href="https://wg21.link/basic.def.odr">basic.def.odr</A>]).</P>

<P><U>Possible resolution (updated 2023-10-21):</U></P>

<P>This resolution also addresses <A HREF="cwg_active.html#1702">issue 1702</A>.</P>

<OL>
<LI>
<P>Split 11.5.2 [<A href="https://wg21.link/class.union.anon#1">class.union.anon</A>] paragraph 1 and change as follows:</P>

<BLOCKQUOTE>

<P>
<DEL>A union of the form</DEL>
<INS>A <I>simple-declaration</I> or <I>member-declaration</I> of the
form</INS>
<PRE class="ins">
   <I>attribute-specifier-seq</I><SUB>opt</SUB> <I>decl-specifier-seq</I> ;
</PRE>
<INS>where one of the <I>decl-specifier</I>s is a <I>class-specifier</I>
of the form</INS>
<PRE>
  union <INS><I>attribute-specifier-seq</I><SUB>opt</SUB></INS> { <I>member-specification</I> } <DEL>;</DEL>
</PRE>
<DEL>is called</DEL> <INS>declares</INS> an <I>anonymous union</I>; it
defines an unnamed type <INS><TT>T</TT></INS> and an unnamed object
of <DEL>that</DEL> type <INS><I>cv</I> <TT>T</TT></INS> called an
anonymous union member if it is a non-static data member or an
anonymous union variable otherwise<INS>, where <I>cv</I> is determined
from the <I>cv-qualifier</I>s of the declaration</INS>.
<INS>The optional <I>attribute-specifier-seq</I> in
the <I>simple-declaration</I> or <I>member-declaration</I> appertains
to the data member or variable, respectively.
The <I>storage-class-specifier</I> <TT>extern</TT>
(9.2.2 [<A href="https://wg21.link/dcl.stc">dcl.stc</A>]) shall not be among
the <I>decl-specifier</I>s declaring an anonymous union.  The
declaration of an anonymous union shall not be
the <I>name-declaration</I> of a <I>linkage-specification</I>
(9.12 [<A href="https://wg21.link/dcl.link">dcl.link</A>]).</INS>
</P>

<P>
Each <I>member-declaration</I> in the <I>member-specification</I> of
an anonymous union shall either define one or more public non-static
data members or be a static_<I>assert-declaration</I>. Nested types,
anonymous unions, and functions shall not be declared within an
anonymous union. The names of the members of an anonymous union are
bound in the scope inhabited by the union declaration.
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.5.2 [<A href="https://wg21.link/class.union.anon#2">class.union.anon</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<DEL>Anonymous unions declared in the scope of</DEL> <INS>An anonymous
union whose declaration inhabits</INS> a namespace <INS>scope</INS>
with external linkage shall be declared <TT>static</TT>.
<DEL>Anonymous unions declared at block scope shall be declared with
any storage class allowed for a block variable, or with no storage
class.  A storage class is not allowed in a declaration of an
anonymous union in a class scope.</DEL>
<INS>An anonymous union whose declaration inhabits a class scope shall
not be declared with a <I>storage-class-specifier</I>.</INS>

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2773"></A><H4>2773.
  
Naming anonymous union members as class members
</H4>
<B>Section: </B>11.5.2&#160; [<A href="https://wg21.link/class.union.anon">class.union.anon</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-16<BR>




<P>Consider:</P>

<PRE>
  template&lt;typename T&gt;
  int f(T *tp) { return tp-&gt;x; }

  static union { int x = f(this); };
</PRE>

<P>According to 11.5.2 [<A href="https://wg21.link/class.union.anon#1">class.union.anon</A>] paragraph 1:</P>

<BLOCKQUOTE>

... The names of the members of an anonymous union are bound in the scope
inhabited by the union declaration.

</BLOCKQUOTE>

<P>Thus, the example above is ill-formed, because the member names are
not bound in the scope of the class of the anonymous union.  However,
there is implementation divergence: clang and gcc accept the example
(contrary to the wording), icc rejects.
Notwithstanding, <TT>this</TT> refers to the anonymous union itself,
not to an enclosing class, per 7.5.3 [<A href="https://wg21.link/expr.prim.this">expr.prim.this</A>].  This rule
causes rejection of</P>

<PRE>
  struct A {
    int foo();
    union { int x = foo(); };  // <SPAN CLASS="cmnt">error</SPAN>
  };
  A a;
</PRE>

<P>Alternatively, <TT>this</TT> could be made to refer to the
enclosing class object (already the status quo for some
implementations).  However, that would cause inconsistent treatment
for examples like the following:</P>

<PRE>
  struct A {
    int n;
    union {
      void *p = this; //<SPAN CLASS="cmnt"> A*</SPAN>
    };
  };
</PRE>
vs.
<PRE>
  struct B {
    int n;
    union {
      void *p = this; //<SPAN CLASS="cmnt"> decltype(u)*</SPAN>
    } u;
  };
</PRE>

<P><U>Possible resolution:</U></P>

<P>tbd</P>

<BR><BR><HR>
<A NAME="3035"></A><H4>3035.
  
Lambda expressions in anonymous unions
</H4>
<B>Section: </B>11.5.2&#160; [<A href="https://wg21.link/class.union.anon">class.union.anon</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2025-05-12<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/706">#706</A>.)</P>

<P>Consider:</P>

<PRE>
  static union {
    int x = [] { return 42; }();
  };
</PRE>

<P>According to 11.5.2 [<A href="https://wg21.link/class.union.anon#1">class.union.anon</A>] paragraph 1, this is
ill-formed, because the closure type is declared as a nested type of
the anonymous union (7.5.6.2 [<A href="https://wg21.link/expr.prim.lambda.closure#3">expr.prim.lambda.closure</A>] paragraph 3, but some
implementations do not yield a diagnostic.</P>

<P>On the other hand, the code shown in the example is reasonable and
ought to be allowed.</P>

<P><U>Suggested resolution (emphasizing the prohibition):</U></P>

<P>Change in 11.5.2 [<A href="https://wg21.link/class.union.anon#1">class.union.anon</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

... Nested types, <INS>including closure types
(7.5.6.2 [<A href="https://wg21.link/expr.prim.lambda.closure">expr.prim.lambda.closure</A>]) and</INS> anonymous unions, and
functions shall not be declared within an anonymous union....

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1699"></A><H4>1699.
  
Does befriending a class befriend its friends?
</H4>
<B>Section: </B>11.8.4&#160; [<A href="https://wg21.link/class.friend">class.friend</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-12
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>According to 11.8.4 [<A href="https://wg21.link/class.friend#2">class.friend</A>] paragraph 2,</P>

<BLOCKQUOTE>

Declaring a class to be a friend implies that the names of private and
protected members from the class granting friendship can be accessed in
the <I>base-specifier</I>s and member declarations of the befriended class.

</BLOCKQUOTE>

<P>A <TT>friend</TT> declaration is a <I>member-declaration</I>, but it
is not clear how far the granting of friendship goes in a <TT>friend</TT>
declaration.  For example:</P>

<PRE>
  class c {
    class n {};
    friend struct s;
  };

  struct s {
    friend class c::n;          //<SPAN CLASS="cmnt"> #1</SPAN>
    friend c::n g();            //<SPAN CLASS="cmnt"> #2</SPAN>
    friend void f() { c::n(); } //<SPAN CLASS="cmnt"> #3</SPAN>
  };
</PRE>

<P>In particular, if a friend function is defined inside the class
definition, as in #3, does its definition have access to the private
and protected members of the befriending class?  Implementations vary
on this point.</P>



<P><B>Additional note (June, 2021):</B></P>

<P>The initial opinion of CWG (at the September, 2013 meeting)
was that &#8220;member declarations&#8221; was intended to be
the English equivalent of the syntactic nonterminal
<I>member-declaration</I>, including a <TT>friend</TT>
declaration/definition inside
the <I>member-specification</I> of a class, making #3
well-formed. However, recent discussion  has expressed concern over the different
treatment of in-class and out-of-class definitions of friend
functions and observed that there is still divergence among
implementations. </P>

<P><B>Rationale (November, 2021):</B></P>

<P>There are two lines of analysis that lead to opposite
conclusions. The first is that a friend defined within the
<I>member-specification</I> is written by the class author and
is effectively part of the class, not subject to hijacking by
other declarations, and thus should be afforded the same access
as all other declarations that are part of the class. The
second is that giving different access to a friend function
based simply on whether it was defined inside or outside of its
befriending class is confusing.</P>

<P>CWG considered this to be a design-level question, not
simply to be determined by the usual relationship between
English and grammar terms, and thus is asking EWG for its
opinion.</P>

<P><B>Additional note (May, 2023)</B></P>

<P>Forwarded to EWG via
<A HREF="https://github.com/cplusplus/papers/issues/1573">cplusplus/papers#1573</A>.</P>

<BR><BR><HR>
<A NAME="472"></A><H4>472.
  
Casting across protected inheritance
</H4>
<B>Section: </B>11.8.5&#160; [<A href="https://wg21.link/class.protected">class.protected</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>16 Jun 2004<BR>


<P>Does the restriction in 11.8.5 [<A href="https://wg21.link/class.protected">class.protected</A>] 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.8.5 [<A href="https://wg21.link/class.protected">class.protected</A>]
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.8.3 [<A href="https://wg21.link/class.access.base#4">class.access.base</A>] 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.8.5 [<A href="https://wg21.link/class.protected">class.protected</A>].</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.8.5 [<A href="https://wg21.link/class.protected">class.protected</A>].</P>



<P><B>Proposed resolution (April, 2011)</B></P>

<P>Change 11.8.3 [<A href="https://wg21.link/class.access.base#4">class.access.base</A>] 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 <DEL>or</DEL> <INS>(but not a</INS> protected
<INS>[<I>Footnote:</I> A protected invented member is disallowed here
for the same reason the additional check of 11.8.5 [<A href="https://wg21.link/class.protected">class.protected</A>]
is applied to member access: it would allow casting a pointer to a
derived class to a protected base class that might be a subobject of
an object of a class that is different from the class context in which
the reference occurs.  &#8212;<I>end footnote</I>])</INS> 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 CLASS="cmnt">OK because class </SPAN>S<SPAN CLASS="cmnt"> satisfies the fourth condition</SPAN>
                        // <SPAN CLASS="cmnt">above: </SPAN>B<SPAN CLASS="cmnt"> is a base class of </SPAN>N<SPAN CLASS="cmnt"> accessible in </SPAN>f()<SPAN CLASS="cmnt"> because</SPAN>
                        // B<SPAN CLASS="cmnt"> is an accessible base class of </SPAN>S<SPAN CLASS="cmnt"> and </SPAN>S<SPAN CLASS="cmnt"> is an accessible</SPAN>
                        // <SPAN CLASS="cmnt">base class of </SPAN>N.
      }
    };
<INS>
    class N2: protected B { };

    class P2: public N2 {
      void f2(N2* n2p) {
        B* bp = n2p;    // <SPAN CLASS="cmnt">error: invented member would be protected and naming</SPAN>
                        // <SPAN CLASS="cmnt">class </SPAN>N2<SPAN CLASS="cmnt"> not the same as or derived from the referencing</SPAN>
                        // <SPAN CLASS="cmnt">class </SPAN>P2
        n2p-&gt;m = 0;     // <SPAN CLASS="cmnt">error (cf 11.8.5 [<A href="https://wg21.link/class.protected">class.protected</A>]) for the same reason</SPAN>
      }
    };</INS>
</PRE>

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

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2244"></A><H4>2244.
  
Base class access in aggregate initialization
</H4>
<B>Section: </B>11.8.5&#160; [<A href="https://wg21.link/class.protected">class.protected</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

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




<P>The rules in 11.8.5 [<A href="https://wg21.link/class.protected">class.protected</A>] assume an object expression,
perhaps implicit, that can be used to determine whether access to protected
members is permitted or not. It is not clear how that applies to aggregates
and constructors. For example:</P>

<PRE>
  struct A {
  protected:
    A();
  };
  struct B : A {
    friend B f();
    friend B g();
    friend B h();
  };
  B f() { return {}; }     //<SPAN CLASS="cmnt"> ok? </SPAN>
  B g() { return {{}}; }   //<SPAN CLASS="cmnt"> ok? </SPAN>
  B h() { return {A{}}; }  //<SPAN CLASS="cmnt"> ok?</SPAN>
</PRE>

<P><B>Notes from the December, 2016 teleconference:</B></P>

<P>The consensus favored accepting <TT>f</TT> and <TT>g</TT> while
rejecting <TT>h</TT>.</P>

<P><B>Notes from the March, 2018 meeting:</B></P>

<P>CWG affirmed the earlier direction and felt that there should be an
implicit object expression assumed for these cases. </P>

<BR><BR><HR>
<A NAME="1915"></A><H4>1915.
  
Potentially-invoked destructors in non-throwing constructors
</H4>
<B>Section: </B>11.9.3&#160; [<A href="https://wg21.link/class.base.init">class.base.init</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Aaron Ballman
 &#160;&#160;&#160;

 <B>Date: </B>2014-04-15
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>The requirement in 11.9.3 [<A href="https://wg21.link/class.base.init#10">class.base.init</A>] paragraph 10,</P>

<BLOCKQUOTE>

In a non-delegating constructor, the destructor for each potentially
constructed subobject of class type is potentially invoked
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]). [<I>Note:</I> This provision ensures that
destructors can be called for fully-constructed sub-objects in case an
exception is thrown (14.3 [<A href="https://wg21.link/except.ctor">except.ctor</A>]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>is needlessly restrictive, preventing otherwise-reasonable code like</P>

<PRE>
  class Base {
  protected:
    Base(int i) noexcept {}
    Base() = delete;
    ~Base() = delete;
  };

  class Derived : public Base {
  public:
    Derived() noexcept : Base(1) {}
    ~Derived() = delete;
  };
</PRE>

<P>Since the derived class constructor is non-throwing, the deleted
base class destructor need not be referenced.</P>

<P><U>Suggested resolution:</U></P>

<P>Change 11.9.3 [<A href="https://wg21.link/class.base.init#10">class.base.init</A>] paragraph 10 as follows:</P>

<BLOCKQUOTE>

In a non-delegating constructor <INS>without a
non-throwing <I>exception-specification</I>
(14.5 [<A href="https://wg21.link/except.spec">except.spec</A>])</INS>, the destructor for each potentially
constructed subobject of class type is potentially invoked
(11.4.7 [<A href="https://wg21.link/class.dtor">class.dtor</A>]). [<I>Note:</I> This provision ensures that
destructors can be called for fully-constructed sub-objects in case an
exception is thrown (14.3 [<A href="https://wg21.link/except.ctor">except.ctor</A>]) <INS>but does not
prevent explicitly deleted destructors in the presence of a non-throwing
constructor</INS>. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P><B>Rationale (June, 2014):</B></P>

<P>This request for a language change should be evaluated by EWG
before any action is taken.</P>

<P><B>EWG 2022-11-11</B></P>

<P>This is a defect, but has ABI impact that should be explored in a
paper to EWG.
This is tracked in github issue
<A HREF="https://github.com/cplusplus/papers/issues/1371">cplusplus/papers#1371</A>.</P>

<BR><BR><HR>
<A NAME="2056"></A><H4>2056.
  
Member function calls in partially-initialized class objects
</H4>
<B>Section: </B>11.9.3&#160; [<A href="https://wg21.link/class.base.init">class.base.init</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-12-11<BR>




<P>According to 11.9.3 [<A href="https://wg21.link/class.base.init#16">class.base.init</A>] paragraph 16,</P>

<BLOCKQUOTE>

Member functions (including virtual member functions,
11.7.3 [<A href="https://wg21.link/class.virtual">class.virtual</A>]) can be called for an object under
construction.  Similarly, an object under construction can
be the operand of the <TT>typeid</TT> operator
(7.6.1.8 [<A href="https://wg21.link/expr.typeid">expr.typeid</A>]) or of a <TT>dynamic_cast</TT>
(7.6.1.7 [<A href="https://wg21.link/expr.dynamic.cast">expr.dynamic.cast</A>]). However, if these operations
are performed in a <I>ctor-initializer</I> (or in a function
called directly or indirectly from
a <I>ctor-initializer</I>) before all
the <I>mem-initializer</I>s for base classes have completed,
the result of the operation is undefined.

</BLOCKQUOTE>

<P>The example in that paragraph reads, in significant part,</P>

<PRE>
  class B {
  public:
    int f();
  };

  class C {
  public:
    C(int);
  };

  class D : public B, C {
  public:
    D() : C(f())  //<SPAN CLASS="cmnt"> undefined: calls member function</SPAN>
                  //<SPAN CLASS="cmnt"> but base \tcode{C} not yet initialized</SPAN>
    {}
  };
</PRE>

<P>However, the construction of <TT>B</TT>, the object for which the
member function is being called) has completed its construction, so
it is not clear why this should be undefined behavior.</P>

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

<BR><BR><HR>
<A NAME="2669"></A><H4>2669.
  
Lifetime extension for aggregate initialization
</H4>
<B>Section: </B>11.9.3&#160; [<A href="https://wg21.link/class.base.init">class.base.init</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Ed Catmur
 &#160;&#160;&#160;

 <B>Date: </B>2022-12-18
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>
<A HREF="cwg_defects.html#1815">Issue 1815</A> presented a subset of the
following examples:</P>

<PRE>
  struct A {};
  struct B { A&amp;&amp; a = A{}; };
  B b1;          //<SPAN CLASS="cmnt"> #1, default-initialization</SPAN>
  B b2{A{}};     //<SPAN CLASS="cmnt"> #2, aggregate initialization</SPAN>
  B b3{};        //<SPAN CLASS="cmnt"> #3, aggregate initialization</SPAN>
  B b4 = B();    //<SPAN CLASS="cmnt"> #4, value-initialization</SPAN>
  B b5(A{});     //<SPAN CLASS="cmnt"> #5, aggregate initialized via parentheses (9.5.1 [<A href="https://wg21.link/dcl.init.general#16.6.2.2">dcl.init.general</A>] bullet 16.6.2.2)</SPAN>
  struct C { int i; A&amp;&amp; a = A{}; };
  C c6(1);       //<SPAN CLASS="cmnt"> #6, aggregate initialized via parentheses</SPAN>
  A a7 = C(1).a; //<SPAN CLASS="cmnt"> #7, aggregate initialized via parentheses</SPAN>
</PRE>

<P>
<A HREF="cwg_defects.html#1696">Issue 1696</A> was adopted, ostensibly
resolving <A HREF="cwg_defects.html#1815">issue 1815</A>, but the wording
changes in 11.9.3 [<A href="https://wg21.link/class.base.init#11">class.base.init</A>] paragraph 11 affected only the
behavior of constructors, not of aggregate initialization:</P>

<BLOCKQUOTE>

A temporary expression bound to a reference member from a default
member initializer is ill-formed. [ Example:

<PRE>
  struct A {
    A() = default;          //<SPAN CLASS="cmnt"> OK</SPAN>
    A(int v) : v(v) { }     //<SPAN CLASS="cmnt"> OK</SPAN>
    const int&amp; v = 42;      //<SPAN CLASS="cmnt"> OK</SPAN>
  };
  A a1;     //<SPAN CLASS="cmnt"> error: ill-formed binding of temporary to reference</SPAN>
  A a2(1);  //<SPAN CLASS="cmnt"> OK, unfortunately</SPAN>
</PRE>

-- end example]

</BLOCKQUOTE>

<P>There is considerable implementation variance: #1 is rejected by
clang, but accepted by gcc and EDG (with early destruction of the
temporary); #2 is uniformly accepted and the lifetime of the temporary
is extended; #3 is uniformly accepted, but only gcc, clang, and MSVC
extend the lifetime of the temporary, whereas EDG does not.</P>

<P>Note that 9.5.1 [<A href="https://wg21.link/dcl.init.general#7">dcl.init.general</A>] paragraph 7 specifies
that default-initialization of aggregates is as-if the
initializer <TT>()</TT> is used:</P>

<BLOCKQUOTE>

To <I>default-initialize</I> an object of type T means:

<UL>

<LI> If T is a (possibly cv-qualified) class type
(Clause 11 [<A href="https://wg21.link/class">class</A>]), constructors are considered. The applicable
constructors are enumerated (12.2.2.4 [<A href="https://wg21.link/over.match.ctor">over.match.ctor</A>]), and the
best one for the initializer () is chosen through overload resolution
(12.2 [<A href="https://wg21.link/over.match">over.match</A>]). The constructor thus selected is called,
with an empty argument list, to initialize the object.
</LI>

<LI>If T is an array type, each element is default-initialized.
</LI>

<LI>Otherwise, no initialization is performed.
</LI>

</UL>

</BLOCKQUOTE>

<P>Such treatment causes early destruction of temporaries per 6.8.7 [<A href="https://wg21.link/class.temporary#6.10">class.temporary</A>] bullet 6.10:</P>

<BLOCKQUOTE>

The exceptions to this lifetime rule are:

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

<LI>A temporary object bound to a reference element of an aggregate of
class type initialized from a parenthesized <I>expression-list</I>
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]) persists until the completion of the
full-expression containing the <I>expression-list</I>.</LI>
</UL>

</BLOCKQUOTE>

<P><B>CWG 2023-05-12</B></P>

<P>CWG is soliciting the design guidance of EWG to resolve this issue,
in particular for examples #3 and #6.  For each of the presented
examples, the standard should say whether the use is well-formed or not
and whether the lifetime of the temporary is extended.  It is also
conceivable to implicitly delete the constructor being invoked (if
any).

<UL>
<LI>#1 is default-initialization, invoking the default constructor
of <TT>B</TT>.  This is ill-formed per 11.9.3 [<A href="https://wg21.link/class.base.init#11">class.base.init</A>] paragraph 11.  The rationale is that the temporary would not be
lifetime-extended, causing a dangling reference as soon as the
constructor returns.  The presence of a hypothetically
lifetime-extended temporary cannot be persisted from the constructor
invocation to the eventual destruction of the object.
</LI>

<LI>#2 is aggregate initialization; the temporary in
the <I>braced-init-list</I> is lifetime-extended per
6.8.7 [<A href="https://wg21.link/class.temporary#6">class.temporary</A>] paragraph 6.  Since the temporary is created
in the initializer and not inside a constructor invocation, tracking
the lifetime of the temporary is equivalent to tracking the lifetime
of the variable <TT>b2</TT>, so extending the lifetime of the
temporary is feasible and avoids a dangling reference.</LI>

<LI>#3 might be perceived as value-initialization, but is in fact also
aggregate initialization; the status quo wording lifetime-extend the
temporary per 6.8.7 [<A href="https://wg21.link/class.temporary#6">class.temporary</A>] paragraph 6. However, that is
inconsistent with #4.</LI>

<LI>#4 is value-initialization; the default constructor is invoked per
9.5.1 [<A href="https://wg21.link/dcl.init.general#16.6.2.1">dcl.init.general</A>] bullet 16.6.2.1, which is ill-formed
similar to #1.</LI>

<LI>#5 is aggregate-by-parentheses initialization. Consistent with
other parenthesized initialization, the lifetime of temporaries is not
extended (6.8.7 [<A href="https://wg21.link/class.temporary#6.10">class.temporary</A>] bullet 6.10).</LI>

<LI>#6 is also aggregate-by-parentheses initialization; a constructor
is not invoked and the lifetime of the temporary is not extended per
6.8.7 [<A href="https://wg21.link/class.temporary#6.10">class.temporary</A>] bullet 6.10, causing a dangling reference.
However, despite the hidden temporary, this use is not ill-formed,
because 11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>] does not apply to aggregate
initialization.</LI>

<LI>Finally, #7 shows a situation where, unlike #6, the short lifetime
of the hidden temporary is not an issue.</LI>

</UL>

CWG recommends to leave #3 as-is and to make #6 (and thus #7)
ill-formed.  The trigger is the use of a default member initializer
for a reference member that causes binding a temporary to that
reference.
</P>

<P>Forwarded to EWG via
<A HREF="https://github.com/cplusplus/papers/issues/1511">cplusplus/papers#1511</A>.</P>

<BR><BR><HR>
<A NAME="1517"></A><H4>1517.
  
Unclear/missing description of behavior during construction/destruction
</H4>
<B>Section: </B>11.9.5&#160; [<A href="https://wg21.link/class.cdtor">class.cdtor</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-07-07<BR>


<P>The current wording of 11.9.5 [<A href="https://wg21.link/class.cdtor#4">class.cdtor</A>] paragraph 4 does
not describe the behavior of calling a virtual function in a
<I>mem-initializer</I> for a base class, only for a non-static data
member.  Also, the changes for <A HREF="cwg_defects.html#1202">issue 1202</A>
should have been, but were not, applied to the description of the
behavior of <TT>typeid</TT> and <TT>dynamic_cast</TT> in paragraphs 5
and 6.</P>

<P>In addition, the resolution of <A HREF="cwg_defects.html#597">issue 597</A>
allowing the out-of-lifetime conversion of pointers/lvalues to
non-virtual base classes, should have been, but were not, applied to
paragraph 3.</P>

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

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

<OL>
<LI><P>Change 11.9.5 [<A href="https://wg21.link/class.cdtor#1">class.cdtor</A>] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

For an object with a non-trivial constructor, referring to any
non-static member or <INS>virtual</INS> base class of the object
before the constructor begins execution results in undefined behavior.
For an object with a non-trivial destructor, referring to any
non-static member or <INS>virtual</INS> base class of the object after
the destructor finishes execution results in undefined
behavior. [<I>Example:</I>

<PRE>
  struct X { int i; };
  struct Y : X { Y(); };                       //<SPAN CLASS="cmnt"> non-trivial</SPAN>
  struct A { int a; };
  struct B : <DEL>public</DEL> <INS>virtual</INS> A { int j; Y y; }; //<SPAN CLASS="cmnt"> non-trivial</SPAN>

  extern B bobj;
  B* pb = &amp;bobj;                               //<SPAN CLASS="cmnt"> OK</SPAN>
  int* p1 = &amp;bobj.a;                           //<SPAN CLASS="cmnt"> undefined, refers to base class member</SPAN>
  int* p2 = &amp;bobj.y.i;                         //<SPAN CLASS="cmnt"> undefined, refers to member's member</SPAN>

  A* pa = &amp;bobj;                               //<SPAN CLASS="cmnt"> undefined, upcast to a <INS>virtual</INS> base class type</SPAN>
  B bobj;                                      //<SPAN CLASS="cmnt"> definition of </SPAN>bobj

  extern X xobj;
  int* p3 = &amp;xobj.i;                           //<SPAN CLASS="cmnt">OK, </SPAN>X<SPAN CLASS="cmnt"> is a trivial class</SPAN>
  X xobj;
</PRE>

</BLOCKQUOTE>

<LI><P>Change 11.9.5 [<A href="https://wg21.link/class.cdtor">class.cdtor</A>] paragraphs 3-6 as follows:</P></LI>

<BLOCKQUOTE>

<P>To explicitly or implicitly convert a pointer (a glvalue) referring to
an object of class <TT>X</TT> to a pointer (reference) to a direct or
indirect <INS>virtual</INS> base class <TT>B</TT> of <TT>X</TT>, the
construction of <TT>X</TT> and the construction of all of its direct or
indirect bases <DEL>that directly or indirectly derive from</DEL>
<INS>for which</INS> <TT>B</TT> <INS>is a direct or indirect virtual
base</INS> shall have started and the destruction of these classes
shall not have completed, otherwise the conversion results in
undefined behavior. To form a pointer to (or access the value of) a
direct non-static member...</P>

<P>
<DEL>Member functions, including virtual functions
(11.7.3 [<A href="https://wg21.link/class.virtual">class.virtual</A>]), can be called during construction or
destruction (11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]).  When a virtual function is
called directly or indirectly from a constructor or from a destructor,
including during the construction or destruction of the class's non-static
data members, and the object to which the call applies is the object (call
it <TT>x</TT>) under construction or destruction, the function called is
the final overrider in the constructor's or destructor's class and not one
overriding it in a more-derived class.  If the virtual function call uses
an explicit class member access (7.6.1.5 [<A href="https://wg21.link/expr.ref">expr.ref</A>]) and the object
expression refers to the complete object of x or one of that object's base
class subobjects but not to <TT>x</TT> or one of its base class subobjects,
the behavior is undefined.</DEL>

<INS>The <I>period of construction</I> of an object or subobject whose type
is a class type <TT>C</TT> begins immediately after the construction of all
its base class subobjects is complete and concludes when the last
constructor of class <TT>C</TT> exits.  The <I>period of destruction</I> of
an object or subobject whose type is a class type <TT>C</TT> begins when
the destructor for <TT>C</TT> begins execution and concludes immediately
before beginning the destruction of its base class
subobjects. A <I>polymorphic operation</I> is a virtual function call
(7.6.1.3 [<A href="https://wg21.link/expr.call">expr.call</A>]), the <TT>typeid</TT> operator
(7.6.1.8 [<A href="https://wg21.link/expr.typeid">expr.typeid</A>]) when applied to a glvalue of polymorphic type,
or the <TT>dynamic_cast</TT> operator (7.6.1.7 [<A href="https://wg21.link/expr.dynamic.cast">expr.dynamic.cast</A>]) when
applied to a pointer to or glvalue of a polymorphic type. A <I>polymorphic
operand</I> is the object expression in a virtual function call or the
operand of a polymorphic <TT>typeid</TT>
or <TT>dynamic_cast</TT>.</INS>
</P>

<P>
<INS> During the period of construction or period of destruction of
an object or subobject whose type is a class type <TT>C</TT> (call
it <TT>x</TT>), the effect of performing a polymorphic operation in
which the polymorphic operand designates <TT>x</TT> or a base class
subobject thereof is as if the dynamic type of the object were
class <TT>C</TT>.  [<I>Footnote:</I> This is true even if <TT>C</TT>
is an abstract class, which cannot be the type of a most-derived
object. &#8212;<I>end footnote</I>] If a polymorphic operand refers to
an object or subobject having class type <TT>C</TT> before its period
of construction begins or after its period of destruction is complete,
the behavior is undefined. [<I>Note:</I> This includes the evaluation
of an expression appearing in a <I>mem-initializer</I> of <TT>C</TT>
in which the <I>mem-initializer-id</I> designates <TT>C</TT> or one of
its base classes. &#8212;<I>end note</I>]</INS> [<I>Example:</I>
</P>

<PRE>
  struct V {
<INS>    V();
    V(int);</INS>
    virtual void f();
    virtual void g();
  };

  struct A : virtual V {
    virtual void f();
<INS>    virtual int h();
    A() : V(h()) { }     //<SPAN CLASS="cmnt"> undefined behavior: virtual function </SPAN>h<SPAN CLASS="cmnt"> called</SPAN>
                         //<SPAN CLASS="cmnt"> before </SPAN>A<SPAN CLASS="cmnt">'s period of construction begins</SPAN></INS>
  };

  struct B : virtual V {
    virtual void g();
    B(V*, A*);
  };

  struct D : A, B {
    virtual void f();
    virtual void g();
    D() : B((A*)this, this) { }
  };

  B::B(V* v, A* a) {
    f();                 //<SPAN CLASS="cmnt"> calls </SPAN>V::f<SPAN CLASS="cmnt">, not </SPAN>A::f
    g();                 //<SPAN CLASS="cmnt"> calls </SPAN>B::g<SPAN CLASS="cmnt">, not </SPAN>D::g
    v-&gt;g();              //<SPAN CLASS="cmnt"> </SPAN>v<SPAN CLASS="cmnt"> is base of </SPAN>B<SPAN CLASS="cmnt">, the call is well-defined, calls </SPAN>B::g
    a-&gt;f();              //<SPAN CLASS="cmnt"> undefined behavior, </SPAN>a<SPAN CLASS="cmnt">'s type not a base of </SPAN>B
<INS>    typeid(*this);       //<SPAN CLASS="cmnt"> </SPAN>type_info<SPAN CLASS="cmnt"> for </SPAN>B
    typeid(*v);          //<SPAN CLASS="cmnt"> well-defined: </SPAN>*v<SPAN CLASS="cmnt"> has type </SPAN>V<SPAN CLASS="cmnt">, a base of </SPAN>B<SPAN CLASS="cmnt">,</SPAN>
                         //<SPAN CLASS="cmnt"> so its period of construction is complete;</SPAN>
                         //<SPAN CLASS="cmnt"> yields </SPAN>type_info<SPAN CLASS="cmnt"> for </SPAN>B
    typeid(*a);          //<SPAN CLASS="cmnt"> undefined behavior: </SPAN>A<SPAN CLASS="cmnt"> is not a base of </SPAN>B<SPAN CLASS="cmnt">,</SPAN>
                         //<SPAN CLASS="cmnt"> so its period of construction has not begun</SPAN>
    dynamic_cast&lt;B*&gt;(v); //<SPAN CLASS="cmnt"> well-defined: </SPAN>v<SPAN CLASS="cmnt"> has type </SPAN>V*<SPAN CLASS="cmnt">, </SPAN>V<SPAN CLASS="cmnt"> is a base of </SPAN>B<SPAN CLASS="cmnt">,</SPAN>
                         //<SPAN CLASS="cmnt"> so its period of construction is complete;</SPAN>
                         //<SPAN CLASS="cmnt"> results in </SPAN>this
    dynamic_cast&lt;B*&gt;(a); //<SPAN CLASS="cmnt"> undefined behavior: </SPAN>A<SPAN CLASS="cmnt"> is not a base of </SPAN>B<SPAN CLASS="cmnt">,</SPAN>
                         //<SPAN CLASS="cmnt"> so its period of construction has not begun</SPAN></INS>
  }
</PRE>

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

<P>
<DEL>The <TT>typeid</TT> operator (7.6.1.8 [<A href="https://wg21.link/expr.typeid">expr.typeid</A>]) can be
used during construction or destruction
(11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]). When <TT>typeid</TT> is used in a
constructor (including the <I>mem-initializer</I> or
<I>brace-or-equal-initializer</I> for a non-static data member) or in a
destructor, or used in a function called (directly or indirectly) from a
constructor or destructor, if the operand of <TT>typeid</TT> refers to the
object under construction or destruction,
<TT>typeid</TT> yields the <TT>std::type_info</TT> object representing
the constructor or destructor's class. If the operand of
<TT>typeid</TT> refers to the object under construction or destruction
and the static type of the operand is neither the constructor or
destructor's class nor one of its bases, the result of <TT>typeid</TT>
is undefined.</DEL>
</P>

<P>
<DEL><TT>dynamic_cast</TT>s (7.6.1.7 [<A href="https://wg21.link/expr.dynamic.cast">expr.dynamic.cast</A>]) can be used
during construction or destruction (11.9.3 [<A href="https://wg21.link/class.base.init">class.base.init</A>]).  When
a <TT>dynamic_cast</TT> is used in a constructor (including
the <I>mem-initializer</I> or <I>brace-or-equal-initializer</I> for a
non-static data member) or in a destructor, or used in a function called
(directly or indirectly) from a constructor or destructor, if the operand
of the <TT>dynamic_cast</TT> refers to the object under construction or
destruction, this object is considered to be a most derived object that has
the type of the constructor or destructor's class. If the operand of
the <TT>dynamic_cast</TT> refers to the object under construction or
destruction and the static type of the operand is not a pointer to or
object of the constructor or destructor's own class or one of its bases,
the <TT>dynamic_cast</TT> results in undefined behavior.
[<I>Example:</I></DEL>
</P>

<PRE>
<DEL>  struct V {
    virtual void f();
  };

  struct A : virtual V { };

  struct B : virtual V {
    B(V*, A*);
  };

  struct D : A, B {
    D() : B((A*)this, this) { }
  };

  B::B(V* v, A* a) {
    typeid(*this);       //<SPAN CLASS="cmnt"> </SPAN>type_info<SPAN CLASS="cmnt"> for </SPAN>B
    typeid(*v);          //<SPAN CLASS="cmnt"> well-defined: </SPAN>*v<SPAN CLASS="cmnt"> has type </SPAN>V<SPAN CLASS="cmnt">, a base of </SPAN>B
                         //<SPAN CLASS="cmnt"> yields </SPAN>type_info<SPAN CLASS="cmnt"> for </SPAN>B
    typeid(*a);          //<SPAN CLASS="cmnt"> undefined behavior: type </SPAN>A<SPAN CLASS="cmnt"> not a base of </SPAN>B
    dynamic_cast&lt;B*&gt;(v); //<SPAN CLASS="cmnt"> well-defined: </SPAN>v<SPAN CLASS="cmnt"> of type </SPAN>V*<SPAN CLASS="cmnt">, </SPAN>V<SPAN CLASS="cmnt"> base of </SPAN>B
                         //<SPAN CLASS="cmnt"> results in </SPAN>B*
    dynamic_cast&lt;B*&gt;(a); //<SPAN CLASS="cmnt"> undefined behavior,</SPAN>
                         //<SPAN CLASS="cmnt"> </SPAN>a<SPAN CLASS="cmnt"> has type </SPAN>A*<SPAN CLASS="cmnt">, </SPAN>A<SPAN CLASS="cmnt"> not a base of </SPAN>B</DEL>
</PRE>

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

</BLOCKQUOTE>

</OL>



<BR><BR><HR>
<A NAME="1049"></A><H4>1049.
  
Copy elision through reference parameters of inline functions
</H4>
<B>Section: </B>11.9.6&#160; [<A href="https://wg21.link/class.copy.elision">class.copy.elision</A>]
 &#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
11.4.5.3 [<A href="https://wg21.link/class.copy.ctor#34.3">class.copy.ctor</A>] bullet 34.3:</P>

<UL><LI><P>when a temporary class object that has not been bound
to a reference (6.8.7 [<A href="https://wg21.link/class.temporary">class.temporary</A>]) 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_closed.html#6">issue 6</A>.
</P>

<P><B>CWG 2023-05-12</B></P>

<P>This is a plausible optimization opportunity whose detailed
specification requires a paper.</P>



<BR><BR><HR>
<A NAME="3007"></A><H4>3007.
  
Access checking during synthesis of defaulted comparison operator, take 2
</H4>
<B>Section: </B>11.10.1&#160; [<A href="https://wg21.link/class.compare.default">class.compare.default</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2025-03-13
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>
<A HREF="cwg_defects.html#2568">Issue 2568</A> sought to make the following
situation well-formed:</P>

<PRE>
   struct Base {
   protected:
     bool operator==(const Base&amp; other) const = default;
   };

   struct Child : Base {
     int i;
     bool operator==(const Child&amp; other) const = default;
   };

   bool b = Child() == Child(); //<SPAN CLASS="cmnt"> error: deleted operator==</SPAN>
</PRE>

<P>However, the applied resolution of that issue failed to achieve the
intent, because the object expression has type <TT>Base</TT> when
invoking <TT>Base::operator==</TT> in the synthesized body
of <TT>Child::operator==</TT>, per 11.10.1 [<A href="https://wg21.link/class.compare.default#5">class.compare.default</A>] paragraph 5 together with 11.10.2 [<A href="https://wg21.link/class.eq#2">class.eq</A>] paragraph 2 and
11.10.3 [<A href="https://wg21.link/class.spaceship#2">class.spaceship</A>] paragraph 2.  The synthesized body
of <TT>Child::operator==</TT> looks like this:</P>

<PRE>
   bool Child::operator==(const Child&amp; other) const
   {
     return (static_cast&lt;const Base&amp;&gt;(*this) == static_cast&lt;const Base&amp;&gt;(other)); //<SPAN CLASS="cmnt"> error, protected</SPAN>
   }
</PRE>

<P><B>Additional notes (March, 2025)</B></P>

<P>EWG should decide whether the design intent is to allow access
to <TT>Base::operator==</TT> in the example.  Forwarded to EWG with
<A HREF="https://github.com/cplusplus/papers/issues/2239">paper issue #2239</A>
by decision of the CWG chair.</P>

<P><B>EWG 2025-06-16</B></P>

<P>EWG decided that the access check should succeed for the example.</P>

<BR><BR><HR>
<A NAME="3031"></A><H4>3031.
  
Finding declarations for conversion operators for access checking
</H4>
<B>Section: </B>12.2.2.1&#160; [<A href="https://wg21.link/over.match.funcs.general">over.match.funcs.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2025-03-29<BR>




<P>Consider:</P>

<PRE>
  class B {
    protected:
      operator int&amp;() { static int x; return x; }
  };

  struct D : B { using B::operator int&amp;; };

  int x = D();   //<SPAN CLASS="cmnt"> OK</SPAN>
</PRE>

<P>The function <TT>B::operator int&amp;</TT> is a candidate, but
the <I>using-declaration</I> in <TT>D</TT> is not considered when
checking accessibility, because name lookup is not actually performed.</P>

<P>
<U>Suggested resolution</U>:</P>

<P>Change in 12.2.2.1 [<A href="https://wg21.link/over.match.funcs.general#7">over.match.funcs.general</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE>

In each case where conversion functions of a class S are considered
for initializing an object or reference of type T, the candidate
functions include the result of a search for
the <I>conversion-function-id</I> operator T in S.  [<I>Note 3:</I>
This search can find a specialization of a conversion function
template (6.5 [<A href="https://wg21.link/basic.lookup">basic.lookup</A>]). &#8212;<I>end note</I>] Each such
case also defines sets of permissible types for explicit and
non-explicit conversion functions; <INS>for</INS> each (non-template) conversion
function <INS><TT>F</TT></INS> that
<UL>
<LI class="del">is a non-hidden member of S,</LI>
<LI>yields a permissible type <INS><TT>U</TT></INS><DEL>,</DEL> and,</LI>
<LI>for the former set, is non-explicit<INS>,</INS>
</LI>
</UL>
<DEL>is also a candidate function</DEL>
<INS>if looking up <TT>operator U</TT> in the scope of <TT>S</TT>
succeeds and finds a declaration of <TT>F</TT>, that declaration is
added to the candidate set</INS>. If initializing an object, for any
permissible type cv U, any cv2 U, cv2 U&amp;, or cv2 U&amp;&amp; is
also a permissible type. If the set of permissible types for explicit
conversion functions is empty, any candidates that are explicit are
discarded.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2189"></A><H4>2189.
  
Surrogate call template
</H4>
<B>Section: </B>12.2.2.2.3&#160; [<A href="https://wg21.link/over.call.object">over.call.object</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-10-22<BR>




<P>Consider:</P>

<PRE>
  template &lt;class T&gt;
  using Fn = void (*)(T);

  struct A
  {
    template &lt;class T&gt;
    operator Fn&lt;T&gt;();
  };

  int main()
  {
    A()(42);
  }
</PRE>

12.2.2.2.3 [<A href="https://wg21.link/over.call.object">over.call.object</A>] describes how conversion functions to pointer/reference to 
function work in overload resolution, but is silent about conversion 
function templates.  Generalizing the wording there, in this case we 
could generate a surrogate conversion template

<PRE>
template &lt;class T&gt;
  void /surrogate/ (Fn&lt;T&gt; f, T a) { return f(a); }
</PRE>

which would work as expected.  But it seems that implementations don't 
actually do this currently. 



<BR><BR><HR>
<A NAME="3055"></A><H4>3055.
  
Misleading body for surrogate call function
</H4>
<B>Section: </B>12.2.2.2.3&#160; [<A href="https://wg21.link/over.call.object">over.call.object</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2025-08-11<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/747">#747</A>.)</P>

<P>Subclause 12.2.2.2.3 [<A href="https://wg21.link/over.call.object#2">over.call.object</A>] paragraph 2 defines the
surrogate call function has having a function body.  However, this
body will never be evaluated, because 12.4.4 [<A href="https://wg21.link/over.call#1">over.call</A>] paragraph 1 specifies the behavior when a surrogate call function is
selected by overload resolution.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 12.2.2.2.3 [<A href="https://wg21.link/over.call.object#2">over.call.object</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

..., a <I>surrogate call function</I> with the unique name <I>call-function</I>
and having the form
<PRE>
    R <I>call-function</I> ( <I>conversion-type-id</I> F, P1 a1, ... , Pn an) <DEL>{ return F (a1, ..., an); }</DEL> <INS>;</INS>
</PRE>
is also considered as a candidate function.
<INS>[ Note: If a surrogate call function is selected by overload
resolution, the behavior is as described in
12.4.4 [<A href="https://wg21.link/over.call">over.call</A>]. -- end note ]</INS> Similarly,...
</BLOCKQUOTE>
<BR><BR><HR>
<A NAME="545"></A><H4>545.
  
User-defined conversions and built-in operator overload resolution
</H4>
<B>Section: </B>12.2.2.3&#160; [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]
 &#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 CLASS="cmnt"> memptr to </SPAN>B1

    class B2 {};
    typedef void (B2::*PB2) (); //<SPAN CLASS="cmnt"> memptr to </SPAN>B2

    class D1 : public B1, public B2 {};
    typedef void (D1::*PD) (); //<SPAN CLASS="cmnt"> memptr to </SPAN>D1

    struct S {
         operator PB1(); //<SPAN CLASS="cmnt"> can be converted to </SPAN>PD
    } s;
    struct T {
         operator PB2(); //<SPAN CLASS="cmnt"> can be converted to </SPAN>PD
    } t;

    void foo() {
         s == t; //<SPAN CLASS="cmnt"> Is this an error?</SPAN>
    }
</PRE>

<P>According to 12.5 [<A href="https://wg21.link/over.built#16">over.built</A>] 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
12.2.2.3 [<A href="https://wg21.link/over.match.oper#3">over.match.oper</A>] 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 12.2.4.2 [<A href="https://wg21.link/over.best.ics">over.best.ics</A>].&#8221; 12.2.4.2.3 [<A href="https://wg21.link/over.ics.user">over.ics.user</A>]
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,
7.6.10 [<A href="https://wg21.link/expr.eq">expr.eq</A>], or composite pointer type, 7.6.9 [<A href="https://wg21.link/expr.rel">expr.rel</A>]), 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 CLASS="cmnt"> changes the set of candidate functions to include</SPAN>
            //<SPAN CLASS="cmnt"> </SPAN>operator==(U&lt;B1&gt;,U&lt;B1&gt;)<SPAN CLASS="cmnt">?</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="1919"></A><H4>1919.
  
Overload resolution for <TT>!</TT> with explicit conversion operator
</H4>
<B>Section: </B>12.2.2.3&#160; [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2014-04-30<BR>




<P>Although the intent is that the <TT>!</TT> operator should be
usable with an operand that is a class object having an explicit
conversion to <TT>bool</TT> (i.e., its operand is
&#8220;contextually converted to <TT>bool</TT>&#8221;), the
selection of the conversion operator is done via
12.2.2.3 [<A href="https://wg21.link/over.match.oper">over.match.oper</A>], 12.2.3 [<A href="https://wg21.link/over.match.viable">over.match.viable</A>], and
12.2.4 [<A href="https://wg21.link/over.match.best">over.match.best</A>], which do not make specific allowance
for this special characteristic of the <TT>!</TT> operator and
thus will not select the explicit conversion function.</P>

<P><B>Notes from the June, 2014 meeting:</B></P>

<P>CWG noted that this same issue affects <TT>&amp;&amp;</TT>
and <TT>||</TT>.</P>

<BR><BR><HR>
<A NAME="2730"></A><H4>2730.
  
Comparison templates on enumeration types
</H4>
<B>Section: </B>12.2.2.3&#160; [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Tobias Loew
 &#160;&#160;&#160;

 <B>Date: </B>2023-05-11<BR>


<P>Equality and relational comparisons are supported for all
enumeration types, even for scoped enumerations, as specified in
12.5 [<A href="https://wg21.link/over.built#15">over.built</A>] paragraph 15 and 7.6.9 [<A href="https://wg21.link/expr.rel#6">expr.rel</A>] paragraph 6:</P>

<BLOCKQUOTE>

If both operands (after conversions) are of arithmetic or enumeration
type, each of the operators shall yield true if the specified
relationship is true and false if it is false.

</BLOCKQUOTE>

<P>The comparisons can be overloaded using a non-template function,
for example:</P>

<PRE>
  enum class F {
    a, b
  };
  
  bool operator&lt;(F,F) = delete;
  bool b = F::a &lt; F::b;   // error, as intended
</PRE>

<P>However, using a function template does not work:</P>

<PRE>
  template&lt;typename E&gt;
  inline constexpr bool X = false;  //<SPAN CLASS="cmnt"> specialize to disable comparisons on </SPAN>E

  template &lt;typename E&gt; requires X&lt;E&gt;
  void operator&lt;(E, E) = delete;

  template &lt;&gt;
  inline constexpr bool X&lt;F&gt; = true;

  bool b = F::a &lt; F::b;             //<SPAN CLASS="cmnt"> ok, selects built-in comparison per 12.2.4.1 [<A href="https://wg21.link/over.match.best.general#2.4">over.match.best.general</A>] bullet 2.4</SPAN>
</PRE>

<P>The reason is that the built-in operator candidates are not
suppressed if they compete with a template specialization.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 12.2.2.3 [<A href="https://wg21.link/over.match.oper#3.3.4">over.match.oper</A>] bullet 3.3.4 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>
do not have the same <I>parameter-type-list</I> as any non-member
candidate or rewritten non-member candidate <DEL>that is not a function
template specialization</DEL>.
</LI>
</UL>

</BLOCKQUOTE>


<BR><BR><HR>
<A NAME="2804"></A><H4>2804.
  
Lookup for determining rewrite targets
</H4>
<B>Section: </B>12.2.2.3&#160; [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2023-10-13
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Consider:</P>

<PRE>
  struct X {
    operator int();
    friend bool operator==(X, int);
    friend bool operator!=(X, int);  // <SPAN CLASS="cmnt">#1</SPAN>
  } x;

  bool bx = x == x;    // <SPAN CLASS="cmnt">error: lookup for rewrite target determination does not find hidden friend #1</SPAN>

  struct Y {
    operator int();
    friend bool operator==(Y, int);   // <SPAN CLASS="cmnt">#2</SPAN>
  } y;

  bool operator!=(Y, int);            // <SPAN CLASS="cmnt">#3</SPAN>

  bool by = y == y;                   // <SPAN CLASS="cmnt">OK, #2 is not a rewrite target because lookup finds #3</SPAN>
</PRE>

<P>A similar issue arises for function-scope declarations:</P>

<PRE>
  struct X { operator int(); };

  bool f(X x) {
    bool operator==(X, int);
    return x == x;              // <SPAN CLASS="cmnt">error</SPAN>
  }

  bool g(X x) {
    bool operator==(X, int);
    bool operator!=(X, int);
    return x == x;              // <SPAN CLASS="cmnt">error</SPAN>
  }

  bool operator!=(X, int);

  bool h(X x) {
    bool operator==(X, int);
    return x == x;              // <SPAN CLASS="cmnt">OK</SPAN>
  }

  bool i(X x) {
    bool operator==(X, int);
    bool operator!=(X, int);
    return x == x;              // <SPAN CLASS="cmnt">OK</SPAN>
  }
</PRE>

<P>Are these outcomes as intended?  For the <TT>bx</TT> case at least,
probably not.</P>

<P><B>CWG 2023-10-20</B></P>

<P>CWG seeks the advice of EWG whether fine-tuning of the "rewrite
target" rules is desired, and what exactly those rules should be.
See <A HREF="https://github.com/cplusplus/papers/issues/1688">paper issue #1688</A>.</P>

<P><B>EWG 2023-11-07</B></P>

<P>The intent is to check for the existence of a declaration that
differs only in the operator name (ie, <TT>bx</TT> should
work, <TT>by</TT> should be ill-formed).</P>

<P>This outcome also resolves <A HREF="cwg_active.html#2797">issue 2797</A>,
but, more importantly, partially reverts
<A HREF="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2468r2.html">P2468R2</A>
(The Equality Operator You Are Looking For), applied in July 2022.  In
particular, the following example added thereby is no longer
well-formed:</P>

<PRE>
  struct B {
    bool operator==(const B&amp;); //<SPAN CLASS="cmnt"> #2</SPAN>
  };
  struct C : B {
    C();
    C(B);
    bool operator!=(const B&amp;); //<SPAN CLASS="cmnt"> #3</SPAN>
  };
  bool c1 = B() == C(); //<SPAN CLASS="cmnt"> OK, calls #2; reversed #2 is not a candidate because search for operator!= in C finds #3</SPAN>
</PRE>

<P>Back to EWG for confirmation.</P>

<P><B>Additional notes (November, 2023)</B></P>

<P>P2468R2 also made the following example (derived from real-world
code) ambiguous between the reversed built-in candicate and the
user-provided <TT>operator==</TT>:</P>

<PRE>
  template&lt;class T&gt;
  struct Ptr
  {
    bool operator==(T* p) const noexcept { return m_p == p; }
    operator T*() const noexcept { return m_p; }

    T* m_p;
  };

  void foo(Ptr&lt;int&gt; a, Ptr&lt;int&gt; b)
  {
    assert(a == b);
  }
</PRE>

<P><B>EWG 2024-03-18</B></P>

<P>EWG invites a paper to propose a change.</P>

<BR><BR><HR>
<A NAME="2844"></A><H4>2844.
  
Enumerating a finite set of built-in candidates
</H4>
<B>Section: </B>12.2.2.3&#160; [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-14<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/362">#362</A>.)</P>

<P>Consider the following example, which is accepted by clang, but
rejected by gcc:</P>

<PRE>
  #include &lt;concepts&gt;

  struct S1 {
    operator int*() { return nullptr; }
  };

  struct S2 {
    template &lt;class T&gt;
    operator T() requires std::same_as&lt;T, int*&gt; {
      return nullptr;
    }
  };

  int main() {
    S1 s1;
    S2 s2;
    return s1 - s2;
  }
</PRE>

<P>The question is whether the implementation is required to find the
built-in candidate <TT>std::ptrdiff_t operator-(int*, int*)</TT>, and
select that candidate. Subclause 12.5 [<A href="https://wg21.link/over.built">over.built</A>] specifies
an infinite number of built-in candidates, such as <TT>std::ptrdiff_t
operator-(T*, T*)</TT> for every object type <TT>T</TT>.  If there are
infinitely many built-in candidates, the implementation cannot iterate
through all of them to determine whether each candidate is viable.</P>

<P>The rule in 12.2.2.3 [<A href="https://wg21.link/over.match.oper#3.3">over.match.oper</A>] paragraph 3.3 is insufficient:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>
... For all other operators, the built-in candidates include all of the
candidate operator functions defined in 12.5 [<A href="https://wg21.link/over.built">over.built</A>]
that, compared to the given operator,
<UL>
<LI>have the same operator
name, and</LI>
<LI>accept the same number of operands, and</LI>
<LI>accept operand types to which the given
operand or operands can be converted according to
12.2.4.2 [<A href="https://wg21.link/over.best.ics">over.best.ics</A>], and</LI>
<LI>do not have the same
parameter-type-list as any non-member candidate or rewritten
non-member candidate that is not a function template specialization.</LI>
</UL>
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P><U>Suggested resolution:</U></P>

<OL>
<LI>
<P>Add a new paragraph before 12.5 [<A href="https://wg21.link/over.built#3">over.built</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<P class="ins">
For the purposes of this subclause, a type <TT>T</TT> is <I>admissible
for an operand E</I> if a standard conversion sequence
(12.2.4.2.2 [<A href="https://wg21.link/over.ics.scs">over.ics.scs</A>]) exists from <I>E</I> to <TT>T</TT>.
If <I>E</I> has a class type, then <TT>T</TT> is also admissible
for <I>E</I> if <I>E</I>'s class has a non-template conversion
function <TT>F</TT> (11.4.8.3 [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>]) that would be
viable (12.2.3 [<A href="https://wg21.link/over.match.viable">over.match.viable</A>]) for a call of the
form <TT>(<I>E</I>).<I>N</I>()</TT>, where <I>N</I> is a
hypothetical <I>id-expression</I> that names <I>F</I>, and a standard
conversion sequence to <TT>T</TT> exists from the type specified
by <TT>F</TT>. If <I>E</I> denotes an overload set
(12.3 [<A href="https://wg21.link/over.over">over.over</A>]), then <TT>T</TT> is admissible
for <I>E</I> if <I>E</I> contains any non-template function for
which <TT>T</TT> is admissible.
</P>

<P>In the remainder of this subclause, vq represents either
<TT>volatile</TT> or no cv-qualifier.</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.5 [<A href="https://wg21.link/over.built#4">over.built</A>] paragraph 4 through 6 as follows:</P>

<BLOCKQUOTE>

<P>For every pair (T , vq), where T is a cv-unqualified arithmetic type
other than bool or a cv-unqualified pointer to (possibly cv-qualified)
object type, there exist candidate operator functions of the form
<PRE>
vq T&amp; operator++(vq T&amp;);
T operator++(vq T&amp;, int);
vq T&amp; operator--(vq T&amp;);
T operator--(vq T&amp;, int);
</PRE>
<INS>if <TT><I>vq</I> <I>T</I>&amp;</TT> is admissible for the operand.</INS>
</P>

<P>
For every (possibly cv-qualified) object type T and for every function
type T that has neither <I>cv-qualifier</I>s nor a <I>ref-qualifier</I>,
there exist candidate operator functions of the form
<PRE>T&amp; operator*(T *);</PRE>
<INS>if <TT><I>T</I>*</TT> is admissible for the operand.</INS>
</P>

<P>
For every type T <INS>such that <TT><I>T</I>*</TT> is admissible for
the operand,</INS> there exist candidate operator functions of the
form
<PRE>
T* operator+(T *);
</PRE>
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.5 [<A href="https://wg21.link/over.built#9">over.built</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

For every quintuple (C1 , C2 , T , cv1, cv2 ), where C2 is a class
type, C1 is the same type as C2 or is a derived class of C2 , and T is
an object type or a function type, there exist candidate operator
functions of the form
<PRE>
cv12 T &amp; operator-&gt;*(cv1 C1 *, cv2 T C2 ::*);
</PRE>
where cv12 is the union of cv1 and cv2<INS>,
if <TT><I>cv2</I> <I>T</I> <I>C2</I>::*</TT> is admissible for the
second operand</INS>. The return type is shown for exposition only;
see 7.6.4 [<A href="https://wg21.link/expr.mptr.oper">expr.mptr.oper</A>] for the determination of the operator's
result type.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.5 [<A href="https://wg21.link/over.built#13">over.built</A>] paragraph 13 through 16 as follows:</P>

<BLOCKQUOTE>

<P>For every cv-qualified or cv-unqualified object type T there exist
candidate operator functions of the form
<PRE>
T* operator+(T *, std::ptrdiff_t);
T&amp; operator[](T *, std::ptrdiff_t);
T* operator-(T *, std::ptrdiff_t);
</PRE>
<INS>if <TT><I>T</I>*</TT> is admissible for the first operand.</INS>
</P>

<P>
<INS>For every cv-qualified or cv-unqualified object type T there exist
candidate operator functions of the form</INS>
<PRE>
T* operator+(std::ptrdiff_t, T *);
T&amp; operator[](std::ptrdiff_t, T *);
</PRE>
<INS>if <TT><I>T</I>*</TT> is admissible for the second operand.</INS>
</P>

<P>For every T , where T is a pointer to object type <INS>and is
admissible for the left or right operand</INS>, there exist candidate
operator functions of the form
<PRE>
std::ptrdiff_t operator-(T , T );
</PRE>
</P>

<P>For every T, where T is an enumeration type<INS>,</INS> or a
pointer type <INS>that is admissible for the left or right
operand</INS>, there exist candidate operator functions of the form
<PRE>
bool operator==(T , T );
bool operator!=(T , T );
bool operator&lt;(T , T);
bool operator&gt;(T , T );
bool operator&lt;=(T , T );
bool operator&gt;=(T , T );
R operator&lt;=&gt;(T , T );
</PRE>
where R is the result type specified in 7.6.8 [<A href="https://wg21.link/expr.spaceship">expr.spaceship</A>].
</P>

<P>
For every T, where T is a pointer-to-member type <INS>and is
admissible for the left or right operand,</INS> or <INS>T
is</INS> <TT>std::nullptr_t</TT>, there exist candidate operator
functions of the form
<PRE>
bool operator==(T, T );
bool operator!=(T , T );
</PRE>
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.5 [<A href="https://wg21.link/over.built#19">over.built</A>] paragraph 19 through 21 as follows:</P>

<BLOCKQUOTE>

<P>
For every pair (T , vq), where T is any type, there exist candidate
operator functions of the form

<PRE>
T *vq &amp; operator=(T *vq &amp;, T *);
</PRE>
<INS>if <TT><I>T</I> <I>vq</I>&amp;</TT> is admissible for the left
operand or <TT>T*</TT> is admissible for the right operand.</INS>
</P>

<P>
For every pair (T , vq), where T is an enumeration <INS>type,</INS> or
<INS><TT><I>T</I></TT> is a</INS> pointer-to-member type <INS>such
that <TT><I>vq</I> <I>T</I>&amp;</TT> is admissible for the left
operand or <TT><I>T</I></TT> is admissible for the right
operand</INS>, there exist candidate operator functions of the form
<PRE>
vq T &amp; operator=(vq T &amp;, T );
</PRE>
</P>

<P>
For every pair (T , vq), where T is a cv-qualified or cv-unqualified
object type, there exist candidate operator functions of the form
<PRE>
T *vq &amp;  operator+=(T *vq &amp;, std::ptrdiff_t);
T *vq &amp;  operator-=(T *vq &amp;, std::ptrdiff_t);
</PRE>
<INS>if <TT><I>T</I>*<I>vq</I>&amp;</TT> is admissible for the left
operand.</INS>
</P>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 12.5 [<A href="https://wg21.link/over.built#25">over.built</A>] paragraph 25 as follows:</P>

<BLOCKQUOTE>

For every type T, where <DEL>T is a pointer, pointer-to-member, or scoped
enumeration type,</DEL>
<UL class="ins">
<LI>
<TT><I>T</I></TT> is admissible for the second or third operand
and is a pointer or pointer-to-member type, or</LI>
<LI>
<TT><I>T</I></TT> is a scoped enumeration type,</LI>
</UL>
there exist candidate operator functions of the form
<PRE>
operator?:(bool, T, T);
</PRE>

</BLOCKQUOTE>
</LI>
</OL>

<P><B>Additional notes (March, 2025)</B></P>

<P>The following cases where infinitely many candidates exist are not addressed:</P>

<PRE>
struct A { operator int(); };
+A();    //<SPAN CLASS="cmnt"> if an implementation supports an unbounded set of extended integer types</SPAN>
</PRE>

<P>(Also, the wording above does not change 12.5 [<A href="https://wg21.link/over.built#10">over.built</A>] paragraph 10.)
</P>

<PRE>
struct A { operator nullptr_t(); };
A() + 0;   // nullptr_t<SPAN CLASS="cmnt"> has a standard conversion sequence to every pointer type</SPAN>
</PRE>

<PRE>
struct A {};
template&lt;typename T&gt; struct B : A {};
using U = int A::*;
struct C { operator U(); };
C() == C();  //<SPAN CLASS="cmnt"> unbounded set of possible derived classes, when converting to </SPAN>int B&lt;T&gt;::*<SPAN CLASS="cmnt"> for any </SPAN>T
</PRE>

<BR><BR><HR>
<A NAME="2967"></A><H4>2967.
  
Explicit conversion functions
</H4>
<B>Section: </B>12.2.2.7&#160; [<A href="https://wg21.link/over.match.ref">over.match.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2024-06-11<BR>




<P>Consider:</P>

<PRE>
  struct T {
    T(T&amp;&amp;);
  };

  struct U {
    explicit operator T&amp;&amp;();
  };

  int main() {
    T t(U{});
  }
</PRE>

<P>To perform the direct-initialization of <TT>t</TT> using the move
constructor of <TT>T</TT>, we have to find an implicit conversion
sequence from <TT>U</TT> to <TT>T&amp;&amp;</TT>, which is covered by
9.5.4 [<A href="https://wg21.link/dcl.init.ref#5.3.2">dcl.init.ref</A>] bullet 5.3.2.  The corresponding overload
resolution in 12.2.2.7 [<A href="https://wg21.link/over.match.ref#1">over.match.ref</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

The permissible types for non-explicit conversion functions are the
members of R where &#8220;cv1 T&#8221; is reference-compatible
(9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]) with &#8220;cv2 T2&#8221;. For
direct-initialization, the permissible types for explicit conversion
functions are the members of R where T2 can be converted to type T
with a (possibly trivial) qualification conversion
(7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>]); otherwise there are none.

</BLOCKQUOTE>

<P>However, the reference in question is not direct-initialized (the
first parameter of the constructor is copy-initialized), thus the
explicit conversion function is not considered.  However, all
implementations agree that the example is valid.</P>

<P>Subclause 12.2.2.5 [<A href="https://wg21.link/over.match.copy#1.2">over.match.copy</A>] paragraph 1.2 already handles
this case for passing values.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 12.2.2.7 [<A href="https://wg21.link/over.match.ref#1">over.match.ref</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

... The permissible types for non-explicit conversion functions are
the members of R where &#8220;cv1 T&#8221; is reference-compatible
(9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]) with &#8220;cv2 T2&#8221;. For
direct-initialization<INS>, and for copy-initialization of the first
parameter of a constructor where the constructor is called with a
single argument in the context of direct-initialization of an object
of type "cv3 T"</INS>, the permissible types for explicit conversion
functions are the members of R where T2 can be converted to type T
with a (possibly trivial) qualification conversion
(7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>]); otherwise there are none.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2311"></A><H4>2311.
  
Missed case for guaranteed copy elision
</H4>
<B>Section: </B>12.2.2.8&#160; [<A href="https://wg21.link/over.match.list">over.match.list</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

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




<P>Consider:</P>

<PRE>
  struct X {
    X();
  };
  X make();
  X x{make()}; 
</PRE>

<P>We reach 9.5.5 [<A href="https://wg21.link/dcl.init.list#3.7">dcl.init.list</A>] bullet 3.7:</P>

<BLOCKQUOTE>

Otherwise, if <TT>T</TT> is a class type, constructors are
considered. The applicable constructors are enumerated and the best
one is chosen through overload resolution (12.2 [<A href="https://wg21.link/over.match">over.match</A>],
12.2.2.8 [<A href="https://wg21.link/over.match.list">over.match.list</A>]).

</BLOCKQUOTE>

<P>This means we perform a redundant copy.  If <TT>T</TT> were an
aggregate, 9.5.5 [<A href="https://wg21.link/dcl.init.list#3.2">dcl.init.list</A>] bullet 3.2 would avoid the
redundant copy:</P>

<BLOCKQUOTE>

If <TT>T</TT> is an aggregate class and the initializer list has a
single element of type <I>cv</I> <TT>U</TT>, where <TT>U</TT>
is <TT>T</TT> or a class derived from <TT>T</TT>, the object is
initialized from that element (by copy-initialization for
copy-list-initialization, or by direct-initialization for
direct-list-initialization).

</BLOCKQUOTE>

<P>See also issues <A HREF="cwg_defects.html#2137">2137</A> and
<A HREF="cwg_active.html#2327">2327</A>.</P>

<BR><BR><HR>
<A NAME="2425"></A><H4>2425.
  
Confusing wording for deduction from a type
</H4>
<B>Section: </B>12.2.2.9&#160; [<A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Dawn Perchik
 &#160;&#160;&#160;

 <B>Date: </B>2019-08-06<BR>


<P>In 12.2.2.9 [<A href="https://wg21.link/over.match.class.deduct#3">over.match.class.deduct</A>] paragraph 3 we read:</P>

<BLOCKQUOTE>

<P>The arguments of a template <TT>A</TT> are said to be
deducible from a type <TT>T</TT> if, given a class
template</P>

<PRE>
  template &lt;typename&gt; class AA;
</PRE>

<P>with a single partial specialization whose template
parameter list is that of <TT>A</TT> and whose template
argument list is a specialization of <TT>A</TT> with the
template argument list of <TT>A</TT>
(13.8.3.2 [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]), AA&lt;T&gt; matches the
partial specialization.</P>

</BLOCKQUOTE>

<P>The relationship between <TT>A</TT>, <TT>AA</TT> and its
partial specialization, and the argument list of <T>A</T> is
not clear. An example would be very helpful here. Also, using
a different name than <TT>A</TT> would help, since <TT>A</TT>
is used in close proximity to this wording to denote an alias
template, while this wording applies to both class and alias
templates. Finally, there should be a cross-reference to
13.7.6.2 [<A href="https://wg21.link/temp.spec.partial.match">temp.spec.partial.match</A>] for matching the partial
specialization.</P>

<BR><BR><HR>
<A NAME="2680"></A><H4>2680.
  
Class template argument deduction for aggregates with designated initializers
</H4>
<B>Section: </B>12.2.2.9&#160; [<A href="https://wg21.link/over.match.class.deduct">over.match.class.deduct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Christof Meerwald
 &#160;&#160;&#160;

 <B>Date: </B>2023-01-09<BR>




<P>Consider:</P>

<PRE>
   template&lt;typename T&gt;
   struct X
   {
    int i{};
    T t;
   };

   X x{ .t = X&lt;int&gt;{ 1, 2 } }; //<SPAN CLASS="cmnt"> should deduce X&lt;X&lt;int&gt;&gt; (not X&lt;int&gt;)</SPAN>
</PRE>

<P>and</P>

<PRE>
   template&lt;typename T&gt;
   struct Y
   {
    int i;
    T t;
    int j;
   };

   template&lt;typename T&gt;
   Y(int, T) -&gt; Y&lt;T&gt;;

   Y y{ .t = 'c', .j = 2 }; //<SPAN CLASS="cmnt"> should be ill-formed</SPAN>
</PRE>

<P>Class template argument deduction does not limit deduction to the
aggregate deduction candidate when a designated initializer list is
used.</P>

<P><U>Suggested resolution:</U></P>

<OL>

<LI>

<P>Change in 12.2.2.9 [<A href="https://wg21.link/over.match.class.deduct#1">over.match.class.deduct</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

... <INS>If the initializer has a <I>designated-initializer-list</I>, any
guide that is not an aggregate deduction candidate is not viable; for
an aggregate deduction candidate,
the <I>designated-initializer-list</I> is replaced by an
initializer-list with the same elements.</INS> In addition, if C
is defined and inherits constructors (9.10 [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]) from a
direct base class ...

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 12.2.2.9 [<A href="https://wg21.link/over.match.class.deduct#3.5">over.match.class.deduct</A>] bullet 3.5 as follows:</P>

<BLOCKQUOTE>

<UL>

<LI>...</LI>

<LI>If f was generated from a <I>deduction-guide</I>
(13.7.2.3 [<A href="https://wg21.link/temp.deduct.guide">temp.deduct.guide</A>]), then f' is considered to be so as
well.</LI>

<LI><INS>If f was generated from an aggregate deduction guide, then f' is
considered to be so as well.</INS></LI>

</UL>

</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2735"></A><H4>2735.
  
List-initialization and conversions in overload resolution
</H4>
<B>Section: </B>12.2.4&#160; [<A href="https://wg21.link/over.match.best">over.match.best</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-03-23<BR>




<P>There is implementation divergence in handling the following example:</P>

<PRE>
  template &lt;typename _Tp&gt; struct optional {
    template &lt;typename _Up&gt; explicit optional(_Up);
    template &lt;typename _Up = _Tp&gt; void operator=(_Up);
  };
  struct SourceBrush {
    struct Brush {
     int brush;
    };
    void setPattern() { m_brush = {42}; }
    optional&lt;Brush&gt; m_brush;
  };
</PRE>

<P>The following example is ambiguous per <A HREF="cwg_closed.html#1228">issue 1228</A>:</P>

<PRE>
  #include &lt;unordered_set&gt;
  #include &lt;string&gt;

  template&lt;typename T&gt; struct wrap {
    template&lt;typename ...Ts&gt; explicit wrap(Ts &amp;&amp;...args) : v(std::forward&lt;Ts&gt;(args)...) {}
    explicit wrap(const T &amp;v) : v(v) {}
    explicit wrap(T &amp;&amp;v) : v(v) {}
    wrap(const wrap&amp;) = delete;
    T v;
  };

  void f() {
    wrap&lt;std::unordered_set&lt;std::string&gt;&gt; wrapped_set({"foo", "bar", "baz"});
  }
</PRE>

<P>The copy constructor of <TT>wrap&lt;...&gt;</TT> becomes viable, by
way of constructing another <TT>wrap</TT> object from the given
initializer list using the explicit constructor template.  It looks
like a deleted copy constructor is used to remove a level of braces,
and then picking an explicit constructor to construct the source of
the copy.</P>

<P>Another example:</P>

<PRE>
  #include &lt;string&gt;
  #include &lt;map&gt;

  struct X {
    explicit X(const std::map&lt;std::string, std::string&gt; &amp;map);
  };

  struct Y {
    Y() : x({{"foo", "bar"}}) {}
    X x;
  };
</PRE>

<P>The intent is to construct the map with a single key-value pair,
but the list-initialization is ambiguous with invoking the copy
constructor and creating a map from a pair of iterators given
by <TT>{"foo", "bar"}</TT>.</P>

<P>And another example:</P>

<PRE>
  struct Z {};

  struct X {          
    explicit X(const Z &amp;z = {});
  };

  struct Y {   
    Y() : x({}) {}                                            
    X x;
  };
</PRE>

<P>The ambiguity is between
<UL>
<LI>calling the <TT>X(const Z&amp;)</TT> constructor with <TT>{}</TT> and</LI>
<LI>calling the <TT>X(const X&amp;)</TT> constructor and using the explicit default constructor to construct a temporary <TT>X</TT>.</LI>
</UL>

</P>

<P>Core <A HREF="cwg_defects.html#2267">issue 2267</A> is also related.</P>

<P><U>Suggested resolution:</U></P>

<P>Insert before 12.2.4.1 [<A href="https://wg21.link/over.match.best.general#2.4">over.match.best.general</A>] bullet 2.4 as follows:</P>

<BLOCKQUOTE>

<UL>

<LI>...</LI>

<LI class="ins">
<TT>F2</TT> is a copy or move special member function where the
implicit conversion sequence for its (non-object) argument is a
user-defined conversion sequence specified by a non-converting
constructor (considered under 12.2.2.8 [<A href="https://wg21.link/over.match.list">over.match.list</A>])
and <TT>F1</TT> is not, or, if not that, [ Example:

<PRE>
  struct Z {};

  struct X {
    explicit X();            //<SPAN CLASS="cmnt"> #1</SPAN>
    explicit X(const Z &amp;z);  //<SPAN CLASS="cmnt"> #2</SPAN>
  };

  struct Y {
    Y() : x({}) {}  //<SPAN CLASS="cmnt"> OK, calls #2, not ambiguous with the copy constructor of </SPAN>X<SPAN CLASS="cmnt"> using a temporary initialized by #1</SPAN>
    X x;
  };
</PRE>
-- end example ]
</LI>

<LI>F1 is not a function template specialization and F2 is a function
template specialization, or, if not that,</LI>

<LI>...</LI>

</UL>

</BLOCKQUOTE>


<BR><BR><HR>
<A NAME="2525"></A><H4>2525.
  
Incorrect definition of implicit conversion sequence
</H4>
<B>Section: </B>12.2.4.2.1&#160; [<A href="https://wg21.link/over.best.ics.general">over.best.ics.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2021-09-25<BR>


<P>According to 12.2.4.2.1 [<A href="https://wg21.link/over.best.ics.general">over.best.ics.general</A>]
paragraphs 1 and 9,</P>

<BLOCKQUOTE>

<P>An <I>implicit conversion sequence</I> is a sequence of
conversions used to convert an argument in a function call
to the type of the corresponding parameter of the function
being called. The sequence of conversions is an implicit
conversion as defined in 7.3 [<A href="https://wg21.link/conv">conv</A>], which
means it is governed by the rules for initialization of an
object or reference by a single expression
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>], 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]).</P>

<P>If no sequence of conversions can be found to convert an
argument to a parameter type, an implicit conversion
sequence cannot be formed.</P>

</BLOCKQUOTE>

<P>However, 7.3.1 [<A href="https://wg21.link/conv.general#3">conv.general</A>] paragraph 3 says,</P>

<BLOCKQUOTE>

An expression <I>E</I> can be <I>implicitly converted</I> to
a type <TT>T</TT> if and only if the declaration <TT>T
t=E;</TT> is well-formed, for some invented temporary
variable <TT>t</TT> (9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>]).

</BLOCKQUOTE>

<P>This definition is too restrictive in the context of
overload resolution's implicit conversion sequences.
The intent, as stated in 12.2.1 [<A href="https://wg21.link/over.match.general">over.match.general</A>]
note 1, is that overload resolution ignores some
factors that would make such an initialization
ill-formed, and these are applied only after the best
match is determined:</P>

<BLOCKQUOTE>

[<I>Note 1:</I> The function selected by overload resolution
is not guaranteed to be appropriate for the context. Other
restrictions, such as the accessibility of the function, can
make its use in the calling context
ill-formed. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>For example,</P>

<PRE>
  struct A{
    A(int) = delete;
  };
  struct B{
     B(int) {}
  };
  void fun(A); //<SPAN CLASS="cmnt"> #1</SPAN>
  void fun(B); //<SPAN CLASS="cmnt"> #2</SPAN>
  int main() {
    fun(0);    //<SPAN CLASS="cmnt"> #3</SPAN>
  }
</PRE>

<P>The intent is that overload #1 be viable with a valid
implicit conversion sequence, making the call at #3
ambiguous, even though the hypothetical declaration</P>

<PRE>
  A t = 1;
</PRE>

<P>would be ill-formed.</P>

<P><B>Proposed resolution (approved by CWG 2022-12-02):</B></P>

<P>Change 12.2.4.2.1 [<A href="https://wg21.link/over.best.ics.general#1">over.best.ics.general</A>] paragraph 1, merging it with
paragraph 2,as follows:</P>

<BLOCKQUOTE>

An <I>implicit conversion sequence</I> is a sequence of conversions
used to convert an argument in a function call to the type of the
corresponding parameter of the function being called. The sequence of
conversions is an implicit conversion as defined in
7.3 [<A href="https://wg21.link/conv">conv</A>]<DEL>, which means</DEL><INS>;</INS> it
is <DEL>governed by</DEL> <INS>thus based on</INS> the rules for
initialization of an object or reference by a single expression
(9.5 [<A href="https://wg21.link/dcl.init">dcl.init</A>], 9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>])<DEL>.
Implicit</DEL><INS>, except that implicit</INS> conversion sequences
are concerned only with the type, cv-qualification, and value category
of the argument and how these are converted to match the corresponding
properties of the parameter.  [Note: ... ]

</BLOCKQUOTE>

<P><B>CWG 2023-02-06</B></P>

<P>Additional drafting is needed to cover e.g. conversions from
literal 0 to null pointer constants.</P>

<BR><BR><HR>
<A NAME="2679"></A><H4>2679.
  
Implicit conversion sequence with a null pointer constant
</H4>
<B>Section: </B>12.2.4.2.1&#160; [<A href="https://wg21.link/over.best.ics.general">over.best.ics.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>L&#233;n&#225;rd Szolnoki
 &#160;&#160;&#160;

 <B>Date: </B>2023-01-07<BR>


<P>Subclause 12.2.4.2.1 [<A href="https://wg21.link/over.best.ics.general#1">over.best.ics.general</A>] paragraph 1, as modified by
<A HREF="cwg_active.html#2525">issue 2525</A>, claims that only the type,
cv-qualification, and value category of the argument are relevant in
forming an implicit conversion sequence.  This is inaccurate for the
following situations:</P>

<UL>

<LI>A literal <TT>0</TT> can be implicitly converted to a parameter of
type <TT>void*</TT> (and in practice, an implicit conversion sequence
does exist), yet the literal <TT>0</TT> has the same type,
cv-qualification, and value category as the literal <TT>1</TT> despite
no such implicit conversion being allowed for the latter.</LI>

<LI>An initializer list does not have a type, cv-qualification, or
value category at all.</LI>

<LI>An overload set does not have a single (function) type.</LI>

</UL>

<BR><BR><HR>
<A NAME="2829"></A><H4>2829.
  
Redundant case in restricting user-defined conversion sequences
</H4>
<B>Section: </B>12.2.4.2.1&#160; [<A href="https://wg21.link/over.best.ics.general">over.best.ics.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Krystian Stasiowski
 &#160;&#160;&#160;

 <B>Date: </B>2020-03-13<BR>


<P>(From editorial issue
<A HREF="https://github.com/cplusplus/draft/issues/3871">3871</A>.)</P>

<P>Subclause 12.2.4.2.1 [<A href="https://wg21.link/over.best.ics.general#4">over.best.ics.general</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

However, if the target is
<UL>
<LI>the first parameter of a constructor or</LI>
<LI>...</LI>
</UL>
and the constructor ... is a candidate by
<UL>
<LI>12.2.2.4 [<A href="https://wg21.link/over.match.ctor">over.match.ctor</A>], when the argument is the temporary
in the second step of a class copy-initialization,</LI>
<LI>12.2.2.5 [<A href="https://wg21.link/over.match.copy">over.match.copy</A>], 12.2.2.6 [<A href="https://wg21.link/over.match.conv">over.match.conv</A>], or
12.2.2.7 [<A href="https://wg21.link/over.match.ref">over.match.ref</A>] (in all cases), or</LI>
<LI>...</LI>
</UL>
user-defined conversion sequences are not considered.

</BLOCKQUOTE>

<P>A temporary is no longer created in 9.5.1 [<A href="https://wg21.link/dcl.init.general#16.6.3">dcl.init.general</A>] bullet 16.6.3 "for the remaining copy-initialization cases".
Instead, that section directly branches to
12.2.2.5 [<A href="https://wg21.link/over.match.copy">over.match.copy</A>], which is covered by the fourth bullet
above.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 12.2.4.2.1 [<A href="https://wg21.link/over.best.ics.general#4">over.best.ics.general</A>] paragraph 4 as follows:</P>


<BLOCKQUOTE>

However, if the target is
<UL>
<LI>...</LI>
</UL>
and the constructor ... is a candidate by
<UL>
<LI><DEL>12.2.2.4 [<A href="https://wg21.link/over.match.ctor">over.match.ctor</A>], when the argument is the temporary
in the second step of a class copy-initialization,</DEL></LI>
<LI>12.2.2.5 [<A href="https://wg21.link/over.match.copy">over.match.copy</A>], 12.2.2.6 [<A href="https://wg21.link/over.match.conv">over.match.conv</A>], or
12.2.2.7 [<A href="https://wg21.link/over.match.ref">over.match.ref</A>] (in all cases), or</LI>
<LI>...</LI>
</UL>
user-defined conversion sequences are not considered.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2731"></A><H4>2731.
  
List-initialization sequence with a user-defined conversion
</H4>
<B>Section: </B>12.2.4.2.3&#160; [<A href="https://wg21.link/over.ics.user">over.ics.user</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2023-05-11<BR>




<P>Consider:</P>

<PRE>
  struct C {
    C(int);
  };

  struct A {
    A(C);
  };

  struct B {
    B(C);
  };

  int f(const A&amp;);
  int f(B&amp;&amp;);

  int x = f({1});
</PRE>

<P>Subclause 12.2.4.2.3 [<A href="https://wg21.link/over.ics.user#1">over.ics.user</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

A user-defined conversion sequence consists of an initial standard
conversion sequence followed by a user-defined conversion
(11.4.8 [<A href="https://wg21.link/class.conv">class.conv</A>]) followed by a second standard conversion
sequence. If the user-defined conversion is specified by a constructor
(11.4.8.2 [<A href="https://wg21.link/class.conv.ctor">class.conv.ctor</A>]), the initial standard conversion
sequence converts the source type to the type of the first parameter
of that constructor. ...

</BLOCKQUOTE>

<P>However, there is no "source type" for an initializer list, making
the treatment of the example unclear.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 12.2.4.2.6 [<A href="https://wg21.link/over.ics.list#7.2">over.ics.list</A>] bullet 7.2 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>Otherwise, the implicit conversion sequence is a user-defined
conversion sequence <INS>whose user-defined conversion is specified by
the constructor <TT>C</TT> and </INS> whose <INS>first and</INS>
second standard conversion <DEL>sequence is an</DEL> <INS>sequences
are</INS> identity <DEL>conversion</DEL> <INS>conversions</INS>.</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="3057"></A><H4>3057.
  
Ranking of derived-to-base conversions should ignore reference binding
</H4>
<B>Section: </B>12.2.4.2.5&#160; [<A href="https://wg21.link/over.ics.ref">over.ics.ref</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Evan Girardin
 &#160;&#160;&#160;

 <B>Date: </B>2025-07-31<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/733">#733</A>.)</P>

<P>The derived-to-base tiebreaker rules in 12.2.4.3 [<A href="https://wg21.link/over.ics.rank#4">over.ics.rank</A>] paragraph 4 should apply regardless of whether one destination type is
a reference and the other one is not.  Major implementations agree.</P>

<P><U>Suggested resolution:</U></P>

<OL>
<LI>
<P>Change in 12.2.4.2.5 [<A href="https://wg21.link/over.ics.ref#1">over.ics.ref</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

When a parameter of type &#8220;reference to cv T&#8221; binds
directly (9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]) to an argument expression:
<UL>
<LI>
If the argument expression has a type <INS><TT>D</TT></INS> that is a
derived class of <DEL>the parameter type</DEL> <INS><TT>T</TT></INS>,
the implicit conversion sequence is a derived-to-base conversion
<INS>from <TT>D</TT> to <TT>T</TT></INS>
(12.2.4.2 [<A href="https://wg21.link/over.best.ics">over.best.ics</A>]).
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P> Change in 12.2.4.3 [<A href="https://wg21.link/over.ics.rank#4.5">over.ics.rank</A>] bullet 4.5 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>
If class B is derived directly or indirectly from class A and class C
is derived directly or indirectly from B,
<UL>
<LI>conversion of C* to B* is better than conversion of C* to A*,
[<I>Example 10:</I> ... &#8212;<I>end example</I>]</LI>
<LI class="del">binding of an expression of type C to a reference to
type B is better than binding an expression of type C to a reference
to type A,</LI>
<LI>conversion of A::* to B::* is better than conversion of A::* to
C::*,</LI>
<LI>conversion of C to B is better than conversion of C to A,</LI>
<LI> conversion of B* to A* is better than conversion of C* to
A*,</LI>
<LI class="del">binding of an expression of type B to a reference to type A is
better than binding an expression of type C to a reference to type
A,</LI>
<LI>conversion of B::* to C::* is better than conversion of A::* to
C::*, and</LI>
<LI>conversion of B to A is better than conversion of C to A.</LI>
</UL>
[ Note: ... ]
</LI>
</UL>

</BLOCKQUOTE>

</LI>

</OL>

<BR><BR><HR>
<A NAME="2169"></A><H4>2169.
  
Narrowing conversions and overload resolution
</H4>
<B>Section: </B>12.2.4.2.6&#160; [<A href="https://wg21.link/over.ics.list">over.ics.list</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

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


<P>Current implementations ignore narrowing conversions during
overload resolution, emitting a diagnostic if calling the
selected function would involve narrowing.  For example:</P>

<PRE>
  struct s { long m };
  struct ss { short m; };

  void f( ss );
  void f( s );
  void g() {
    f({ 1000000 }); //<SPAN CLASS="cmnt"> Ambiguous in spite of narrowing for </SPAN>f(ss)
  }
</PRE>

<P>However, the current wording of 12.2.4.2.6 [<A href="https://wg21.link/over.ics.list#7">over.ics.list</A>] paragraph 7
says,</P>

<BLOCKQUOTE>

Otherwise, if the parameter has an aggregate type which can
be initialized from the initializer list according to the
rules for aggregate initialization
(9.5.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]), the implicit conversion
sequence is a user-defined conversion sequence with the
second standard conversion sequence an identity conversion.

</BLOCKQUOTE>

<P>In the example above, <TT>ss</TT> cannot be initialized
from <TT>{ 1000000 }</TT> because of the narrowing conversion,
so presumably <TT>f(ss)</TT> should not be considered.  If
this is not the intended outcome, paragraph 7 should be
restated in terms of having an implicit conversion sequence,
as in, e.g., bullet 9.1, instead of a valid initialization.</P>

<P><B>Rationale (March, 2016):</B></P>

<P>This is a question of language design and thus more suited
to consideration by EWG.</P>

<P><B>EWG (January, 2021):</B></P>

<P>Adjust the standard to follow existing implementations.
See <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1018r8.html#CWG2169">vote</A>.</P>



<P><B>Additional notes (March, 2023)</B></P>

<P>A narrowing conversion is but one of the many circumstances that
could make a conversion ill-formed despite the existence of an
implicit conversion sequence. Other examples (with implementation
divergence) are invoking a private or deleted function, binding a
non-const reference to a bit-field, invoking an explicit constructor
in list-initialization, invoking a consteval constructor with
unsuitable arguments, or initializing an aggregate with
incorrectly-ordered designated initializers.  A resolution of this
issue should thus not be focused on narrow conversions.</P>

<BR><BR><HR>
<A NAME="2492"></A><H4>2492.
  
Comparing user-defined conversion sequences in list-initialization
</H4>
<B>Section: </B>12.2.4.2.6&#160; [<A href="https://wg21.link/over.ics.list">over.ics.list</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2021-01-11<BR>


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

<PRE>
  #include &lt;initializer_list&gt;
  struct A{
    operator short(){
      return 0;
    }
  };
  struct B{
    operator bool(){
      return 0;
    }
  };
  void fun(std::initializer_list&lt;int&gt;){}
  void fun(std::initializer_list&lt;bool&gt;){}
  int main(){
    fun({A{},B{}});
  }
</PRE>

<P>According to 12.2.4.2.6 [<A href="https://wg21.link/over.ics.list#6">over.ics.list</A>] paragraph 6,</P>

<BLOCKQUOTE>

Otherwise, if the parameter type is
<TT>std::initializer_list&lt;X&gt;</TT> and all the elements
of the initializer list can be implicitly converted
to <TT>X</TT>, the implicit conversion sequence is the worst
conversion necessary to convert an element of the list
to <TT>X</TT>, or if the initializer list has no elements,
the identity conversion. This conversion can be a
user-defined conversion even in the context of a call to an
initializer-list constructor.

</BLOCKQUOTE>

<P>In this example, all of the conversions from list elements
to the <TT>initializer_list</TT> template argument type are
user-defined conversions. According to 12.2.4.3 [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>]
bullet 3.3,</P>

<BLOCKQUOTE>

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 or they initialize the
same class in an aggregate initialization and in either case
the second standard conversion sequence of <TT>U1</TT> is
better than the second standard conversion sequence
of <TT>U2</TT>.

</BLOCKQUOTE>

<P>Since in both cases the two elements of the
initializer-list argument involve different user-defined
conversion functions, the two user-defined conversion
sequences for the elements cannot be distinguished, so the
determination of the &#8220;worst conversion&#8221; for the
two candidates does not consider the second standard
conversion sequence. This presumably makes it impossible to
distinguish the conversion sequences for the two candidates in
the function call, making the call ambiguous.</P>

<P>However, there is implementation divergence on
the handling of this example, with g++ reporting an
ambiguity and clang, MSVC, and EDG calling the <TT>int</TT>
overload, presumably on the basis
that <TT>short-&gt;int</TT> is a promotion
while <TT>short-&gt;bool</TT> is a conversion.</P>

<P><B>Notes from the August, 2021 teleconference:</B></P>

<P>CWG agreed with the reasoning expressed in the analysis,
that conversions involving different user-defined conversion
functions cannot be compared, and thus the call is
ambiguous. The use of the phrase &#8220;worst
conversion&#8221; is insufficiently clear, however, and
requires definition.</P>

<P><B>Proposed resolution, August, 2021:</B></P>

<P>Change 12.2.4.2.6 [<A href="https://wg21.link/over.ics.list">over.ics.list</A>] paragraphs 5 and 6 as
follows:</P>

<BLOCKQUOTE>

<P>Otherwise, if the parameter type is
<TT>std::initializer_list&lt;X&gt;</TT> and <INS>either the
initializer list is empty or</INS> all the elements of the
initializer list can be implicitly converted to <TT>X</TT>,
the implicit conversion sequence is the <DEL>worst conversion</DEL>
<INS><I>worst conversion</I></INS> necessary to convert an
element of the list to <TT>X</TT>, <DEL>or
if</DEL> <INS>defined as follows. If</INS> the initializer
list has no elements, the
<INS>worst conversion is the</INS> identity conversion.
<INS>Otherwise, the worst conversion is an implicit
conversion sequence for a list element that is not better
than any other implicit conversion sequence required by list
elements, compared as described in
12.2.4.3 [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>]. If more than one implicit
conversion sequence satisfies this criterion, then if they
are user-defined conversion sequences that do not all
contain the same user-defined conversion function or
constructor, the worst conversion sequence is the ambiguous
conversion sequence (12.2.4.2.1 [<A href="https://wg21.link/over.best.ics.general">over.best.ics.general</A>]);
otherwise, it is unspecified which of those conversion
sequences is chosen as worst.</INS> This conversion can be a
user-defined conversion even in the context of a call to an
initializer-list constructor.  [<I>Example 2</I>:</P>

<PRE>
  void f(std::initializer_list&lt;int&gt;);
  f( {} );        //<SPAN CLASS="cmnt"> OK: </SPAN>f(initializer_list&lt;int&gt;)<SPAN CLASS="cmnt"> identity conversion</SPAN>
  f( {1,2,3} );   //<SPAN CLASS="cmnt"> OK: </SPAN>f(initializer_list&lt;int&gt;)<SPAN CLASS="cmnt"> identity conversion</SPAN>
  f( {'a','b'} ); //<SPAN CLASS="cmnt"> OK: </SPAN>f(initializer_list&lt;int&gt;)<SPAN CLASS="cmnt"> integral promotion</SPAN>
  f( {1.0} );     //<SPAN CLASS="cmnt"> error: narrowing</SPAN>

  struct A {
    A(std::initializer_list&lt;double&gt;);            //<SPAN CLASS="cmnt"> #1</SPAN>
    A(std::initializer_list&lt;complex&lt;double&gt;&gt;);   //<SPAN CLASS="cmnt"> #2</SPAN>
    A(std::initializer_list&lt;std::string&gt;);       //<SPAN CLASS="cmnt"> #3</SPAN>
  };
  A a{ 1.0,2.0 };        //<SPAN CLASS="cmnt"> OK, uses #1</SPAN>

  void g(A);
  g({ "foo", "bar" });   //<SPAN CLASS="cmnt"> OK, uses #3</SPAN>

  typedef int IA[3];
  void h(const IA&amp;);
  h({ 1, 2, 3 });        //<SPAN CLASS="cmnt"> OK: identity conversion</SPAN>

<INS>  void x(std::initializer_list&lt;int&gt;);
  void x(std::initializer_list&lt;bool&gt;);
  struct S1 { operator short(); };
  struct S2 { operator bool(); };
  void y() {
    x({S1{}, S2{}});   //<SPAN CLASS="cmnt"> error: ambiguous. The ICSes for each list element are indistinguishable because</SPAN>
                       //<SPAN CLASS="cmnt"> they do not contain the same conversion function, so the worst conversion is</SPAN>
                       //<SPAN CLASS="cmnt"> the ambiguous conversion sequence.</SPAN>
  }</INS>
</PRE>

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

<P>Otherwise, if the parameter type is &#8220;array of <TT>N
X</TT> &#8221; or &#8220;array of unknown bound
of <TT>X</TT>&#8221;, if there exists an implicit conversion
sequence from each element of the initializer list (and from
<TT>{}</TT> in the former case if <TT>N</TT> exceeds the
number of elements in the initializer list) to <TT>X</TT>,
the implicit conversion sequence is the worst <DEL>such
implicit conversion sequence</DEL> <INS>conversion necessary
to convert an element of the list (including, if there are
too few list elements, <TT>{}</TT>) to
<TT>X</TT>, determined as described above for a
<TT>std::initializer_list&lt;X&gt;</TT> with a non-empty
initializer list</INS>.</P>

</BLOCKQUOTE>

<P><B>CWG 2023-06-13</B></P>

<P>An ambiguous conversion for the function selected by overload
resolution is ill-formed per 12.2.4.2.1 [<A href="https://wg21.link/over.best.ics.general">over.best.ics.general</A>].  Instead
of attempting to define "worst conversion" (possibly with focusing on
the second standard conversion sequence in user-defined conversions),
it might be more consistent overall to use the rules for a succession
of function arguments/parameters when comparing list-initializations.</P>

<BR><BR><HR>
<A NAME="2741"></A><H4>2741.
  
Implicit conversion sequence from empty list to array of unknown bound
</H4>
<B>Section: </B>12.2.4.2.6&#160; [<A href="https://wg21.link/over.ics.list">over.ics.list</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2023-06-01<BR>




<P>Consider:</P>

<PRE>
  int f(int const(&amp;)[]) { return 1; }   //<SPAN CLASS="cmnt"> #1</SPAN>
  int f(int const(&amp;)[2]) { return 2; }  //<SPAN CLASS="cmnt"> #2</SPAN>
  int x = f({});
</PRE>

<P>Subclause 12.2.4.2.6 [<A href="https://wg21.link/over.ics.list#6">over.ics.list</A>] paragraph 6 specifies:</P>

<BLOCKQUOTE>

Otherwise, if the parameter type is &#8220;array of N X&#8221; or
&#8220;array of unknown bound of X&#8221;, if there exists an implicit
conversion sequence from each element of the initializer list (and
from {} in the former case if N exceeds the number of elements in the
initializer list) to X, the implicit conversion sequence is the worst
such implicit conversion sequence.

</BLOCKQUOTE>

<P>What is the "worst [...] implicit conversion sequence" when the
initializer list is empty? Should #1 even be viable for this call,
given that it's not valid to initialize an <TT>int const
(&amp;)[]</TT> from <TT>{}</TT>?</P>

<P>There is implementation divergence: Clang and MSVC treat #1 as
being non-viable; GCC calls #1 and creates a temporary of type
`int[0]` (even in -pedantic-errors mode).  Should the "worst
conversion sequence" over an empty set be the identity conversion,
selecting #1 and then failing the parameter initialization?</P>

<BR><BR><HR>
<A NAME="2790"></A><H4>2790.
  
Aggregate initialization and user-defined conversion sequence
</H4>
<B>Section: </B>12.2.4.2.6&#160; [<A href="https://wg21.link/over.ics.list">over.ics.list</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2023-08-18<BR>




<P>Subclause 12.2.4.2.6 [<A href="https://wg21.link/over.ics.list#8">over.ics.list</A>] paragraph 8 specifies:</P>

<BLOCKQUOTE>

Otherwise, if the parameter has an aggregate type which can be
initialized from the initializer list according to the rules for
aggregate initialization (9.5.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]), the implicit
conversion sequence is a user-defined conversion sequence whose second
standard conversion sequence is an identity conversion.

</BLOCKQUOTE>

<P>However, a user-defined conversion sequence cannot contain an
aggregate initialization per 12.2.4.2.3 [<A href="https://wg21.link/over.ics.user#1">over.ics.user</A>] paragraph 1:</P>

<BLOCKQUOTE>

A <I>user-defined conversion sequence</I> consists of an initial
standard conversion sequence followed by a user-defined conversion
(11.4.8 [<A href="https://wg21.link/class.conv">class.conv</A>]) followed by a second standard conversion
sequence.

</BLOCKQUOTE>

<P>To complete the argument, subclause 11.4.8 [<A href="https://wg21.link/class.conv#1">class.conv</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

Type conversions of class objects can be specified by constructors and
by conversion functions. These conversions are called <I>user-defined
conversions</I>...

</BLOCKQUOTE>

<P><U>Possible resolution:</U></P>

<P>Change in 12.2.4.2.3 [<A href="https://wg21.link/over.ics.user#1">over.ics.user</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A <I>user-defined conversion sequence</I> consists of an initial
standard conversion sequence<INS>,</INS> followed by a user-defined
conversion (11.4.8 [<A href="https://wg21.link/class.conv">class.conv</A>]) <INS>or an aggregate
initialization (9.5.2 [<A href="https://wg21.link/dcl.init.aggr">dcl.init.aggr</A>]),</INS> followed by a
second standard conversion sequence.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1459"></A><H4>1459.
  
Reference-binding tiebreakers in overload resolution
</H4>
<B>Section: </B>12.2.4.3&#160; [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2012-02-07<BR>


<P>Both paragraph 3 and paragraph 4 of 12.2.4.3 [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>] have
overload resolution tiebreakers for reference binding.  It might be
possible to merge those into a single treatment.</P>

<BR><BR><HR>
<A NAME="1789"></A><H4>1789.
  
Array reference vs array decay in overload resolution
</H4>
<B>Section: </B>12.2.4.3&#160; [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Faisal Vali
 &#160;&#160;&#160;

 <B>Date: </B>2013-10-01<BR>




<P>The current rules make an example like</P>

<PRE>
  template&lt;class T, size_t N&gt; void foo(T (&amp;)[N]);
  template&lt;class T&gt; void foo(T *t);

  int arr[3]{1, 2, 3};
  foo(arr);
</PRE>

<P>ambiguous, even though the first is an identity match and the
second requires an lvalue transformation.  Is this desirable?</P>

<P><B>Proposed resolution (June, 2021):</B></P>

<P>Add the following as a new bullet following 12.2.4.3 [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>]
bullet 3.2.6:</P>

<BLOCKQUOTE>

<P>Two implicit conversion sequences of the same form are
indistinguishable conversion sequences unless one of the
following rules applies:</P>

<UL>
<LI><P>List-initialization sequence <TT>L1</TT> is a
better conversion sequence...</P></LI>

<LI><P>Standard conversion sequence <TT>S1</TT> is a better
conversion sequence than standard conversion
sequence <TT>S2</TT> if</P></LI>

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

<LI><P>
<TT>S1</TT> and <TT>S2</TT> include reference
bindings (9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]), and the types to
which the references refer are the same type except for
top-level cv-qualifiers, and the type to which the reference
initialized by <TT>S2</TT> refers is more cv-qualified than
the type to which the reference initialized by <TT>S1</TT>
refers. [<I>Example 6:</I>...</P></LI>

<LI>
<P><INS><TT>S1</TT> is a reference binding to an array
and <TT>S2</TT> is an array-to-pointer conversion
(7.3.3 [<A href="https://wg21.link/conv.array">conv.array</A>]). [<I>Example  7:</I></INS></P>

<PRE>
<INS>  template&lt;class T, unsigned N&gt; void f(T (&amp;)[N]); //<SPAN CLASS="cmnt"> #1</SPAN>
  template&lt;class T&gt; void f(T *t);                 //<SPAN CLASS="cmnt"> #2</SPAN>
  int r[3]{1, 2, 3};
  void g() {
    f(r);    //<SPAN CLASS="cmnt"> OK: calls #1</SPAN>
  }</INS>
</PRE>

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

</UL>

</UL>

</BLOCKQUOTE>

<P><B>CWG 2023-02-06</B></P>

<P>The proposed resolution prefers the <TT>T&amp;</TT> overload over
the <TT>T*</TT> overload in the example below, which is undesirable.
The wording needs to be amended to limit the tiebreaker to situations
where the array declarator appears in the signature.</P>

<BLOCKQUOTE>

<PRE>
template&lt;class T&gt;
int f(T&amp;);
template&lt;class T&gt;
int f(T*);
int x[5];
int z = f(x);
</PRE>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2337"></A><H4>2337.
  
Incorrect implication of logic ladder for conversion sequence tiebreakers
</H4>
<B>Section: </B>12.2.4.3&#160; [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2017-03-02<BR>


<P>The bulleted list of 12.2.4.3 [<A href="https://wg21.link/over.ics.rank#3">over.ics.rank</A>] paragraph 3
consists of a logic ladder of the form &#8220;A is better than B if
[<I>some predicate relating A to B</I>], or, if not that, ...&#8221;
For example, bullet 3.1 says,</P>

<UL>
<LI><P>List-initialization sequence <TT>L1</TT> is a better
conversion sequence than list-initialization sequence <TT>L2</TT>
if</P></LI>

<UL>
<LI><P>
<TT>L1</TT> converts
to <TT>std::initializer_list&lt;X&gt;</TT> for some <TT>X</TT>
and <TT>L2</TT> does not, or, if not that,</P></LI>

<LI><P>
<TT>L1</TT> converts to type &#8220;array of <TT>N1
T</TT>&#8221;, <TT>L2</TT> converts to type &#8220;array
of <TT>N2 T</TT>&#8221;, and <TT>N1</TT> is smaller
than <TT>N2</TT> ,</P></LI>

</UL>

</UL>

<P>The intent is not to fall into the array case if <TT>L2</TT>
converts to <TT>std::initializer_list&lt;X&gt;</TT> and <TT>L1</TT>
does not &#8212; i.e., the inverse predicate holds &#8212; but that
intent is not well reflected in the actual wording.</P>

<BR><BR><HR>
<A NAME="2842"></A><H4>2842.
  
Preferring an <TT>initializer_list</TT> over a single value
</H4>
<B>Section: </B>12.2.4.3&#160; [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2022-12-10<BR>




<P>Consider:</P>

<PRE>
  #include &lt;initializer_list&gt;
  struct A { A(int) {} };
  void f(int) = delete;
  void f(std::initializer_list&lt;A&gt;) {}   // <SPAN CLASS="cmnt">#1</SPAN>
  int main() { f({10}); }
</PRE>

<P>The intent of <A HREF="cwg_defects.html#1467">issue 1467</A> was to make
this example well-formed by choosing #1, according to this rule and a
corresponding example in 12.2.4.3 [<A href="https://wg21.link/over.ics.rank#3.1">over.ics.rank</A>] bullet 3.1:</P>

<BLOCKQUOTE>

<UL>
<LI>List-initialization sequence L1 is a better conversion sequence than
list-initialization sequence L2 if
<UL>
<LI>L1 converts to std::initializer_list&lt;X&gt; for some X and L2
does not, or, if not that,</LI>
<LI>...</LI>
</UL>
even if one of the other rules in this paragraph would otherwise
apply.
</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<P>See also <A HREF="cwg_defects.html#2137">issue 2137</A> and
<A HREF="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64665">gcc issue 64665</A>.
</P>

<P><U>Possible resolution:</U></P>

<P>Move 12.2.4.3 [<A href="https://wg21.link/over.ics.rank#2">over.ics.rank</A>] paragraph 2 into paragraph 3 as follows:</P>

<BLOCKQUOTE>

<P class="del">
When comparing the basic forms of implicit conversion sequences (as
defined in 12.2.4.2 [<A href="https://wg21.link/over.best.ics">over.best.ics</A>])
<UL class="del">
<LI>a standard conversion sequence (12.2.4.2.2 [<A href="https://wg21.link/over.ics.scs">over.ics.scs</A>])
is a better conversion sequence than a user-defined conversion
sequence or an ellipsis conversion sequence, and</LI>
<LI>a user-defined conversion sequence
(12.2.4.2.3 [<A href="https://wg21.link/over.ics.user">over.ics.user</A>]) is a better conversion sequence than
an ellipsis conversion sequence
(12.2.4.2.4 [<A href="https://wg21.link/over.ics.ellipsis">over.ics.ellipsis</A>]).</LI>
</UL>
</P>

<P>
Two implicit conversion sequences <DEL>of the same form</DEL> are
indistinguishable conversion sequences unless one of the following
rules applies:
<UL>
<LI>List-initialization sequence L1 is a better conversion sequence than
list-initialization sequence L2 if
<UL>
<LI>L1 converts to std::initializer_list&lt;X&gt; for some X and L2
does not, or, if not that,</LI>
<LI>...</LI>
</UL>
<DEL>even if one of the other rules in this paragraph would otherwise
apply</DEL>.
</LI>

<LI class="ins">
Otherwise, a standard conversion sequence (12.2.4.2.2 [<A href="https://wg21.link/over.ics.scs">over.ics.scs</A>])
is a better conversion sequence than a user-defined conversion
sequence or an ellipsis conversion sequence, and</LI>
<LI class="ins">a user-defined conversion sequence
(12.2.4.2.3 [<A href="https://wg21.link/over.ics.user">over.ics.user</A>]) is a better conversion sequence than
an ellipsis conversion sequence
(12.2.4.2.4 [<A href="https://wg21.link/over.ics.ellipsis">over.ics.ellipsis</A>]).</LI>

<LI>Standard conversion sequence S1 is a better conversion sequence
than ...</LI>
</UL>
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2958"></A><H4>2958.
  
Overload resolution involving lvalue transformation and qualification conversion
</H4>
<B>Section: </B>12.2.4.3&#160; [<A href="https://wg21.link/over.ics.rank">over.ics.rank</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Vincent X
 &#160;&#160;&#160;

 <B>Date: </B>2024-11-10<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/639">#639</A>.)
</P>

<P>The following example in 12.2.4.3 [<A href="https://wg21.link/over.ics.rank#3.2.5">over.ics.rank</A>] bullet 3.2.5 is not in harmony with the normative rules:</P>

<PRE>
  int g(const int*);         //<SPAN CLASS="cmnt">#1</SPAN>
  int g(const volatile int* const&amp;); //<SPAN CLASS="cmnt">#3</SPAN>
  int* p;
  int k = g(p);          //<SPAN CLASS="cmnt"> calls g(const int*)</SPAN>
</PRE>

<P>The invocation of #1 requires an lvalue-to-rvalue conversion
followed by a qualification conversion; #2 requires only a
qualification conversion.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 12.2.4.3 [<A href="https://wg21.link/over.ics.rank#3.2.5">over.ics.rank</A>] bullet 3.2.5 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>...</LI>
<LI>S1 and S2 differ only in their qualification conversion
(7.3.6 [<A href="https://wg21.link/conv.qual">conv.qual</A>])<INS>, ignoring any Lvalue
Transformation,</INS> and yield similar types T1 and T2, respectively
(where a standard conversion sequence that is a reference binding is
considered to yield the cv-unqualified referenced type), where T1 and
T2 are not the same type, and const T2 is reference-compatible with T1
(9.5.4 [<A href="https://wg21.link/dcl.init.ref">dcl.init.ref</A>]) ...</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2873"></A><H4>2873.
  
Taking the address of a function involving template argument deduction
</H4>
<B>Section: </B>12.3&#160; [<A href="https://wg21.link/over.over">over.over</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Anoop Rana
 &#160;&#160;&#160;

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


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/516">#516</A>.)</P>

<P>Consider:</P>

<PRE>
  template &lt;typename T&gt;
  int f(T&amp;&amp;);
 
  void g();                      // #1

  template &lt;typename T&gt;
  void g();                      // #2

  int x = f(&amp;g);
</PRE>

<P>All major implementations reject.  However, 12.3 [<A href="https://wg21.link/over.over#3">over.over</A>] paragraph 3 seems to say that templates are ignored if template
argument deduction fails ("if any"):</P>

<BLOCKQUOTE>

The specialization, if any, generated by template argument deduction
(13.10.4 [<A href="https://wg21.link/temp.over">temp.over</A>], 13.10.3.3 [<A href="https://wg21.link/temp.deduct.funcaddr">temp.deduct.funcaddr</A>],
13.10.2 [<A href="https://wg21.link/temp.arg.explicit">temp.arg.explicit</A>]) for each function template named is
added to the set of selected functions considered.

</BLOCKQUOTE>

<P>For the following example, prior core issues <A HREF="cwg_defects.html#2608">2608</A> and <A HREF="cwg_defects.html#2848">2848</A> have indicated that
"deduction" should always consider default template arguments.  Yet,
only gcc accepts the example.</P>

<PRE>
  template&lt;typename T&gt; int f(T);
  template&lt;typename T = int&gt; void g();
  int x = f(&amp;g);
</PRE>

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

<P>Subclause 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#5.6.3">temp.deduct.type</A>] bullet 5.6.3 makes the
parameter of <TT>f</TT> a non-deduced context for these situations.
However, 13.10.2 [<A href="https://wg21.link/temp.arg.explicit#4">temp.arg.explicit</A>] paragraph 4 allows omitting the
template argument list if all template parameters can be deduced or
obtained from default template arguments. Thus, <TT>&amp;g</TT> can be
considered to refer to both a function template and a function
template specialization.</P>

<P>The special treatment in overload resolution for <TT>f</TT> yields
inconsistent outcomes where overload resolution is not applied:</P>

<PRE>
  void g(int);
  void g(auto);

  decltype(&amp;g) p;    // <SPAN CLASS="cmnt">rejected by implementations for no reason in the wording</SPAN>
</PRE>

<BR><BR><HR>
<A NAME="1549"></A><H4>1549.
  
Overloaded comma operator with <TT>void</TT> operand
</H4>
<B>Section: </B>12.4.3&#160; [<A href="https://wg21.link/over.binary">over.binary</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2012-09-04<BR>




<P>Even though a function cannot take a parameter of type <TT>void</TT>,
the current rules for overload resolution require consideration of
overloaded operators when one operand has a user-defined or enumeration
type and the other has type <TT>void</TT>.  This can result in side
effects and possibly errors, for example:</P>

<PRE>
  template &lt;class T&gt; struct A {
    T t;
    typedef T type;
  };

  struct X {
    typedef A&lt;void&gt; type;
  };

  template &lt;class T&gt; void operator ,(typename T::type::type, T) {}

  int main() {
    X(), void(); //<SPAN CLASS="cmnt"> OK</SPAN>
    void(), X(); //<SPAN CLASS="cmnt"> error: </SPAN>A&lt;void&gt;<SPAN CLASS="cmnt"> is instantiated with a field of</SPAN>
                 //<SPAN CLASS="cmnt"> type </SPAN>void
  }
</PRE>



<BR><BR><HR>
<A NAME="260"></A><H4>260.
  
User-defined conversions and built-in <TT>operator=</TT>
</H4>
<B>Section: </B>12.5&#160; [<A href="https://wg21.link/over.built">over.built</A>]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#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 12.5 [<A href="https://wg21.link/over.built#18">over.built</A>] 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
(12.5 [<A href="https://wg21.link/over.built#18">over.built</A>] 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="954"></A><H4>954.
  
Overload resolution of conversion operator templates with built-in types
</H4>
<B>Section: </B>12.5&#160; [<A href="https://wg21.link/over.built">over.built</A>]
 &#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 12.5 [<A href="https://wg21.link/over.built#12">over.built</A>] 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="1620"></A><H4>1620.
  
User-defined literals and extended integer types
</H4>
<B>Section: </B>12.6&#160; [<A href="https://wg21.link/over.literal">over.literal</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-02-12<BR>




<P>Although numeric literals can have extended integer types,
user-defined literal operators cannot have a parameter of an
extended integer type.  This seems like an oversight.</P>

<BR><BR><HR>
<A NAME="2904"></A><H4>2904.
  
Introducing <I>template-name</I>s
</H4>
<B>Section: </B>13.1&#160; [<A href="https://wg21.link/temp.pre">temp.pre</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2024-06-14<BR>




<P>
A <I>template-declaration</I> should, but does not, introduce
the <I>identifier</I> in its <I>declarator-id</I> as
a <I>template-name</I>.  Subclause 13.2 [<A href="https://wg21.link/temp.param#3">temp.param</A>] paragraph 3
already does so for template <I>template-parameter</I>s.
</P>

<P><U>Possible resolution (based on <A HREF="cwg_active.html#2862">issue 2862</A>):</U></P>

<OL>
<LI>
<P>Change in 9.2.4 [<A href="https://wg21.link/dcl.typedef#2">dcl.typedef</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A <I>typedef-name</I> can also be introduced by
an <I>alias-declaration</I>. The <I>identifier</I> following the using
keyword is not looked up; <INS>if the <I>alias-declaration</I> does
not introduce an alias template (13.1 [<A href="https://wg21.link/temp.pre">temp.pre</A>]), the
<I>identifier</I></INS> <DEL>it</DEL> becomes
a <I>typedef-name</I> <DEL>and the</DEL><INS>. The</INS>
optional <I>attribute-specifier-seq</I> following
the <I>identifier</I> appertains to that <I>typedef-name</I>
<INS>or, if the <I>identifier</I> is a <I>template-name</I>, to
that <I>template-name</I></INS>.  Such a <I>typedef-name</I> has the
same semantics as if it were introduced by the typedef specifier. In
particular, it does not define a new type.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 11.1 [<A href="https://wg21.link/class.pre#1">class.pre</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A class is a type. <DEL>Its name becomes a <I>class-name</I>
(11.3 [<A href="https://wg21.link/class.name">class.name</A>]) within its scope.</DEL>
<PRE>
  <I>class-name</I> :
      <I>identifier
      simple-template-id</I>
</PRE>
...  Otherwise, the <I>class-name</I> is an <I>identifier</I>; it is
not looked up, and <INS>if the <I>class-specifier</I> does not
introduce a class template (13.1 [<A href="https://wg21.link/temp.pre">temp.pre</A>]),</INS>
the <I>class-specifier</I> introduces <DEL>it</DEL> <INS>the
<I>identifier</I> as a <I>class-name</I>.</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.1 [<A href="https://wg21.link/temp.pre#3">temp.pre</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>
<UL>
<LI>A class template is introduced by a <I>template-declaration</I>
whose declaration is a <I>simple-declaration</I> that either contains
a <I>class-specifier</I> in its <I>decl-specifier-seq</I> or consists
solely of an <I>elaborated-type-specifier</I>.
</LI>
<LI>A function template is introduced by a <I>template-declaration</I>
whose declaration declares a function.</LI>
<LI>An alias template is introduced by a <I>template-declaration</I>
whose declaration is an <I>alias-declaration</I>.</LI>
<LI>A variable template is introduced by a <I>template-declaration</I>
whose declaration declares a variable.</LI>
</UL>

<INS>The declaration of a class template, alias template, or variable
template introduces its respective name as a
<I>template-name</I>.</INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.7.8 [<A href="https://wg21.link/temp.alias#1">temp.alias</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A <I>template-declaration</I> in which the declaration is
an <I>alias-declaration</I> (9.1 [<A href="https://wg21.link/dcl.pre">dcl.pre</A>]) declares the
identifier to be an alias template. An alias template is a name for a
family of types. <DEL>The name of the alias template is
a <I>template-name</I>.</DEL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.7.9 [<A href="https://wg21.link/temp.concept#2">temp.concept</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A <I>concept-definition</I> declares a concept. Its <I>identifier</I>
becomes a <INS><I>template-name</I> and a</INS> <I>concept-name</I>
referring to that concept within its scope. The optional
<I>attribute-specifier-seq</I> appertains to the concept.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.3 [<A href="https://wg21.link/temp.names#3">temp.names</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<DEL>[ Note:</DEL> If the name is an <I>identifier</I>, it is then
interpreted as a <I>template-name</I>. <INS>[ Note:</INS> The keyword
<TT>template</TT> is used to indicate that a dependent qualified name
(13.8.3.2 [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]) denotes a template where an expression
might appear. &#8212;<I>end note</I>]

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2994"></A><H4>2994.
  
Allowing template parameters following template parameter packs that are pack expansions
</H4>
<B>Section: </B>13.2&#160; [<A href="https://wg21.link/temp.param">temp.param</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jan Schultke
 &#160;&#160;&#160;

 <B>Date: </B>2025-01-20<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/666">#666</A>.)</P>

<P>Consider:</P>

<PRE>
  template &lt;class Head, class... Tail&gt;
  struct test {
    template &lt;Tail..., Head&gt;
    static void make() {}       // <SPAN CLASS="cmnt">clang accepts, MSVC rejects</SPAN>
  };

  int main() {
    test&lt;char, int, float&gt;::make&lt;4, 6.f, 'a'&gt;();
  }
</PRE>

<P>There is implementation divergence for the treatment of this
example.  It ought to be allowed.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 13.2 [<A href="https://wg21.link/temp.param#14">temp.param</A>] paragraph 14 as follows:</P>

<BLOCKQUOTE>

... <DEL>If a</DEL> <INS>A</INS> <I>template-parameter</I> <INS>pack</INS> of a function template <DEL>declares a
template parameter pack, it</DEL> shall not be followed by
another <I>template-parameter</I> <INS>P</INS> unless
<UL>
<LI>
<DEL>that template parameter</DEL> <INS>P</INS> is deducible from
the <I>parameter-type-list</I> (9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>]) of the
function template <DEL>or</DEL> <INS>,</INS>
</LI>
<LI>
<INS>P</INS> has a default
argument (13.10.3 [<A href="https://wg21.link/temp.deduct">temp.deduct</A>])<INS>, or</INS>
</LI>
<LI>
<INS>that template parameter pack is also a pack
expansion</INS>.</LI>
</UL>...

</BLOCKQUOTE>

<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>13.3&#160; [<A href="https://wg21.link/temp.names">temp.names</A>]
 &#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, 13.3 [<A href="https://wg21.link/temp.names#3">temp.names</A>] 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>

<P><B>Additional note (January, 2014):</B></P>

<P>A similar problem exists for an <TT>operator&gt;</TT> template:</P>

<PRE>
  struct S;
  template&lt;void (*)(S, S)&gt; struct X {};
  void operator&gt;(S, S);
  X&lt;operator&gt; &gt; x;
</PRE>

<P>Somehow the specification must be written to avoid taking the
<TT>&gt;</TT> token in the operator name as the end of the template
argument list for <TT>X</TT>.</P>

<BR><BR><HR>
<A NAME="2920"></A><H4>2920.
  
The <TT>template</TT> keyword for base classes
</H4>
<B>Section: </B>13.3&#160; [<A href="https://wg21.link/temp.names">temp.names</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

 <B>Date: </B>2024-07-15<BR>




<P>Consider:</P>

<PRE>
  template&lt;int T&gt;
  struct BaseT {
    void Foo() {}
  };

  template&lt;int T&gt;
  struct DerivedT : BaseT&lt;T&gt; {
    void Inner() {
      this-&gt;template /* unnecessary keyword before CWG1835 */ BaseT&lt;T&gt;::Foo();
    }
  };
</PRE>

<P>The resolution of <A HREF="cwg_defects.html#1835">issue 1835</A> in P1787
now requires the <TT>template</TT> keyword in this situation.  This
breaks code in several large projects.</P>

<P>The reason to require the <TT>template</TT> keyword is that the
injected-class-name, like any other member, is inherited from the base
class, but the base class is dependent, and thus name lookup does not
consider base class members when parsing the template definition.  For
example:</P>

<PRE>
  namespace N
  {
    template&lt;int I&gt;
    struct A { };

    template&lt;int I&gt;
    struct B
    {
      using C = A&lt;I&gt;;

      template&lt;int J&gt;
      using D = A&lt;J&gt;;
    };
  }

  //<SPAN CLASS="cmnt"> impossible to determine the injected-class-name of the base class in the definition context since 'N::B' could be specialized.</SPAN>
  //<SPAN CLASS="cmnt"> it might not be the injected-class-name of a template, and it might not even be 'C'/'D'!</SPAN>

  template&lt;int I&gt;
  struct X : N::B&lt;I&gt;::C { }; 

  template&lt;int I&gt;
  struct Y : N::B&lt;I&gt;::template D&lt;I&gt; { };
</PRE>

<P>
Even if we specified how to find the injected-class-name of a dependent base class for a subset of cases, we would reintroduce the problem that the resolution to <A HREF="cwg_defects.html#1835">issue 1835</A> solves:
</P>

<PRE>
  template&lt;int I&gt;
  struct A
  {
    int A;
  };

  bool f();

  template&lt;int I&gt;
  struct B : A&lt;I&gt;
  {
    bool g()
    {
      return this-&gt;A &lt; I; //<SPAN CLASS="cmnt"> do we interpret '&lt;' as the start of a template-argument-list here?</SPAN>
    }

    bool h()
    {
      return this-&gt;A &lt; I &gt; ::f(); //<SPAN CLASS="cmnt"> how about here?</SPAN>
    }
  };
</PRE>

<P>
Using the unqualified lookup results from the template definition
context for disambiguation when the object expression is dependent is
also wrong since they are discarded if we find a member in the
template instantiation context. Consider:
</P>

<PRE>
  namespace N
  {
    template&lt;int I&gt;
    struct A
    {
      int B;
    };
  }

  template&lt;int I&gt;
  using B = N::A&lt;I&gt;;

  template&lt;int I&gt;
  struct C : B&lt;I&gt;
  {
    bool f()
    {
      return this-&gt;B &lt; I;
    }
  };
</PRE>

<P>
Since the lookup context of <TT>B</TT> in <TT>this-&gt;B</TT> is
dependent, we cannot determine whether it would be invalid as a
complete class member access expression.  We also cannot parse past
the '&lt;' to determine whether <TT>B</TT> is the terminal name of a
member-qualified <TT>nested-name-specifier</TT>, so we do not know if
unqualified name lookup should happen.  <A HREF="cwg_defects.html#1835">Issue 1835</A> resolves this by treating <TT>this-&gt;B</TT> as a
complete class member access expression. Using the results of
unqualified name lookup to determine whether <TT>B</TT> is the name of
a template is incorrect because it may refer to a non-template member
when <TT>C</TT> is instantiated.
</P>

<P><B>CWG 2024-08-16</B></P>

<P>The resolution for <A HREF="cwg_defects.html#1835">issue 1835</A> in P1787
has addressed real concerns.  CWG recognizes that real-world code now
no longer compiles, although the fix for the affected source code is
trivial.  A limited exception to support some of the existing code
might be feasible.  CWG solicits a paper with specification and
analysis.</P>

<BR><BR><HR>
<A NAME="2980"></A><H4>2980.
  
Constraints on template template parameters
</H4>
<B>Section: </B>13.3&#160; [<A href="https://wg21.link/temp.names">temp.names</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2024-12-23<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/658">#658</A>.)
</P>

<P>Subclause 13.3 [<A href="https://wg21.link/temp.names#8">temp.names</A>] paragraph 8 specifies:</P>

<BLOCKQUOTE>

When the <I>template-name</I> of a <I>simple-template-id</I> names a
constrained non-function template or a constrained
template <I>template-parameter</I> , and all <I>template-argument</I>s
in the <I>simple-template-id</I> are non-dependent
(13.8.3.7 [<A href="https://wg21.link/temp.dep.temp">temp.dep.temp</A>]), the associated constraints
(13.5.3 [<A href="https://wg21.link/temp.constr.decl">temp.constr.decl</A>]) of the constrained template shall be
satisfied (13.5.2 [<A href="https://wg21.link/temp.constr.constr">temp.constr.constr</A>]).

</BLOCKQUOTE>

<P>For template template parameters, it is unclear how this provision
interacts with instantiation or substitution.  In particular,
13.4.4 [<A href="https://wg21.link/temp.arg.template#3">temp.arg.template</A>] paragraph 3 allows for the template template
parameter to be more constrained than the argument provided; however,
once the parameter is replaced by the corresponding argument, the
constraints of the parameter seemingly disappear. Consider:</P>

<PRE>
  template &lt;typename T&gt;
  concept C = false;

  template &lt;typename&gt; struct Q;

  template &lt;template &lt;C&gt; class TT&gt;
  struct A {
    template &lt;typename T&gt; void f(TT&lt;T&gt; *) {}
  };

  template void A&lt;Q&gt;::f(Q&lt;int&gt; *);
</PRE>

<P>Implementations accept this example.  For the reverse situation,
where 13.4.4 [<A href="https://wg21.link/temp.arg.template#3">temp.arg.template</A>] paragraph 3 allows <TT>P</TT> to be
unconstrained, also consider:</P>

<PRE>
  template &lt;typename T&gt;
  concept C = false;

  template &lt;typename&gt; struct Q;

  template &lt;template &lt;typename&gt; class TT, typename T&gt;
  using Alias = TT&lt;T&gt;;

  template &lt;template &lt;C&gt; class TT&gt;
  struct A {
    Alias&lt;TT, int&gt; *p;
  };

  A&lt;Q&gt; a;
</PRE>

<P>Implementations (other than gcc and clang, which seem not to
implement the basic feature at all) appear to use the constraints
of <TT>TT</TT> from <TT>A</TT> despite the <I>simple-template-id</I>
emanating from <TT>Alias</TT>.</P>

<P>Maybe the constraints from template template parameters should be
checked where they appear (including within an alias template) --- or are
substituted into an alias template --- to form a <I>simple-template-id</I>
once the arguments are known.  That is, the associated constraints of both</P>
<UL>
<LI>template template parameters of alias templates and</LI>
<LI>template template parameters used as arguments to alias templates</LI>
</UL>
<P>are checked for <I>simple-template-id</I>s appearing in an alias
template.</P>

<P>Also consider:</P>

<PRE>
  template &lt;typename T&gt;
  concept C = true;

  template &lt;typename T&gt;
  concept CandMore = C&lt;T&gt; &amp;&amp; true;

  template &lt;typename&gt; struct Q;

  template &lt;template &lt;C&gt; class P, typename T&gt;
  using Alias = P&lt;T&gt;;

  template &lt;template &lt;CandMore&gt; class TT&gt;
  struct A {
    Alias&lt;TT, int&gt; *p;  //<SPAN CLASS="cmnt"> #1</SPAN>
  };

  A&lt;Q&gt; a;
</PRE>

<P>The <TT>P</TT> for <TT>Alias</TT> is not at least as specialized as
the argument <TT>TT</TT> given at #1, if we take the <TT>TT</TT>
constraints as written.  However, the actual argument for <TT>TT</TT>
may be such that <TT>P</TT> is at least as specialized as the
argument <TT>TT</TT>. There is implementation divergence.</P>

<BR><BR><HR>
<A NAME="2105"></A><H4>2105.
  
When do the arguments for a parameter pack end?
</H4>
<B>Section: </B>13.4&#160; [<A href="https://wg21.link/temp.arg">temp.arg</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-03-17<BR>




<P>There does not appear to be a clear statement in the Standard
that the first template parameter pack in a template parameter
list corresponds to all remaining arguments in the template
argument list.  For example:</P>

<PRE>
  template &lt;int&gt; struct A;

  template &lt;int ...N, typename T&gt; void foo(A&lt;N&gt; *..., T);
  void bar() {
   foo&lt;0&gt;(0, 0);      //<SPAN CLASS="cmnt"> okay: </SPAN>N<SPAN CLASS="cmnt"> consists of one template parameter, </SPAN>0<SPAN CLASS="cmnt">. </SPAN>T<SPAN CLASS="cmnt"> is deduced to </SPAN>int
   foo&lt;0, int&gt;(0, 0); //<SPAN CLASS="cmnt"> error: </SPAN>int<SPAN CLASS="cmnt"> does not match the form of the corresponding parameter </SPAN>N
  }
</PRE>

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

<P><B>Notes from the February, 2016 meeting:</B></P>

<P>The comments in the example reflect the intent.</P>

<BR><BR><HR>
<A NAME="3032"></A><H4>3032.
  
Template argument disambiguation
</H4>
<B>Section: </B>13.4.1&#160; [<A href="https://wg21.link/temp.arg.general">temp.arg.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2025-02-03<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/669">#669</A>.)</P>

<P>For the <I>template-argument</I> grammar in
13.3 [<A href="https://wg21.link/temp.names">temp.names</A>], there is a parsing ambiguity introduced by
P2841R7 between <I>nested-name-specifier<SUB>opt</SUB>
template-name</I> and <I>type-id</I> (via
<I>simple-type-specifier</I>) naming a placeholder for deduced
class type (9.2.9.8 [<A href="https://wg21.link/dcl.type.class.deduct">dcl.type.class.deduct</A>]).  For example:</P>

<PRE>
  void g();

  template &lt;typename T&gt;
  struct A {
    static void f() {
      g&lt;T::TT&gt;((A *)0);
    }
  };

  template &lt;typename T&gt; void g(void *);
  template &lt;auto&gt; void g(void *);
  template &lt;template &lt;typename&gt; class&gt; void g(void *);

  struct Expr { enum { TT = 0 }; };
  struct Type { using TT = int; };
  struct Tmpl { template &lt;typename&gt; struct TT; };
  void h() {
    A&lt;Expr&gt;::f(); //<SPAN CLASS="cmnt"> all accept</SPAN>
    A&lt;Type&gt;::f(); //<SPAN CLASS="cmnt"> EDG, MSVC accept; GCC, Clang rejects</SPAN>
    A&lt;Tmpl&gt;::f(); //<SPAN CLASS="cmnt"> EDG, MSVC accept; GCC, Clang rejects</SPAN>
  }
</PRE>

<P>P1787R6 established the direction that the <TT>template</TT>
disambiguator is needed only when introducing
a <I>template-argument-list</I> (13.3 [<A href="https://wg21.link/temp.names#6">temp.names</A>] paragraph 6).
(Reflection made this assumption false.)  All examples should be
accepted.</P>

<P>See 13.8.2 [<A href="https://wg21.link/temp.local">temp.local</A>] for the use of an
injected-class-name as a template argument.</P>

<P>Example:</P>

<PRE>
  void g();

  template &lt;typename T&gt;
  struct A {
    static void f() {
      g&lt;A&gt;((A *)0);     //<SPAN CLASS="cmnt"> all accept</SPAN>
      g&lt;A&gt;((A *)0, 0);  //<SPAN CLASS="cmnt"> Clang, GCC, EDG accept; MSVC rejects</SPAN>
    }
  };

  template &lt;typename T&gt; void g(void *);
  template &lt;template &lt;typename&gt; class&gt; void g(void *, int);

  void h() { A&lt;int&gt;::f(); }
</PRE>

<P><U>Possible resolution:</U></P>

<P>Strategy: Introduce a new grammar production
akin <I>reflection-name</I>, as a preferred option
for <I>template-argument</I>, and say what it means in the various
cases.</P>

<OL>
<LI>
<P>Change in 13.3 [<A href="https://wg21.link/temp.names#1">temp.names</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>
<PRE>
<I>template-argument:
   <INS>template-argument-name</INS>
   constant-expression
   type-id</I>
   <DEL><I>nested-name-specifier<SUB>opt</SUB> template-name</I></DEL>
   <DEL><I>nested-name-specifier</I> template <I>template-name</I></DEL>

<INS><I>template-argument-name:
   nested-name-specifier<SUB>opt</SUB> identifier
   nested-name-specifier</I> template <I>identifier</I></INS>
</PRE>
</BLOCKQUOTE>
</LI>

<LI>
<P>Insert a new paragraph before 13.3 [<A href="https://wg21.link/temp.names#7">temp.names</A>] paragraph 7 as follows:</P>

<BLOCKQUOTE class="ins">

The component names of a <I>template-argument-name</I> are those of
its <I>nested-name-specifier</I> (if any) and its <I>identifier</I>.
The terminal name of a <I>template-argument-name</I> of the
form <I>nested-name-specifier</I> <TT>template</TT> <I>identifier</I>
shall denote a template.

</BLOCKQUOTE>

<BLOCKQUOTE>
<P>A <I>template-id</I> is valid if ...</P>
</BLOCKQUOTE>
</LI>

<LI>
<P>Insert a new paragraph before 13.4.1 [<A href="https://wg21.link/temp.arg.general#3">temp.arg.general</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE class="ins">

<P>
If a <I>template-argument</I> <I>A</I> matches the
form <I>template-argument-name</I>, it is interpreted as such;
the <I>identifier</I> is looked up and its meaning is
determined as follows:
<UL>
<LI>If lookup finds an injected-class-name (13.8.2 [<A href="https://wg21.link/temp.local">temp.local</A>]), then:
<UL>
<LI>If <I>A</I> is for a type template template parameter,
<I>A</I> denotes the corresponding class template.</LI>
<LI>Otherwise, it denotes a <I>type-name</I>.</LI>
</UL>
</LI>

<LI>Otherwise, if lookup finds a template,
<I>A</I> denotes that template.</LI>

<LI>Otherwise, if lookup finds a type alias or a type, <I>A</I>
denotes the underlying type and is interpreted as a <I>type-id</I>.
</LI>

<LI>Otherwise, <I>A</I> shall be a <I>constant-expression</I>.
</LI>
</UL>
</P>
</BLOCKQUOTE>

<BLOCKQUOTE>
In a <I>template-argument</I>, an ambiguity between a <I>type-id</I>
and an expression is resolved to a <I>type-id</I>, regardless of the
form of the corresponding <I>template-parameter</I>...
</BLOCKQUOTE>

</LI>
</OL>

<BR><BR><HR>
<A NAME="2961"></A><H4>2961.
  
Checking of ill-formed types in <I>constraint-expression</I>s
</H4>
<B>Section: </B>13.5&#160; [<A href="https://wg21.link/temp.constr">temp.constr</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2024-11-18<BR>


<P>There is implementation divergence in the handling of the following
example:</P>

<PRE>
  template &lt;typename T&gt;
  concept C = true;

  template &lt;typename T&gt;
  void f() requires C&lt;T *&gt; {
   //<SPAN CLASS="cmnt"></SPAN>
  }

  void g() {
   f&lt;int &amp;&gt;();
  }
</PRE>

<P>Is the constraint not satisfied because an intermediate invalid
type "pointer to reference to <TT>T</TT>" is formed?  Or is the
constraint satisfied because <TT>T</TT> is never actually used?
</P>

<BR><BR><HR>
<A NAME="2686"></A><H4>2686.
  
Pack expansion into a non-pack parameter of a concept
</H4>
<B>Section: </B>13.5.2&#160; [<A href="https://wg21.link/temp.constr.constr">temp.constr.constr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Micha&#322; Dominiak
 &#160;&#160;&#160;

 <B>Date: </B>2021-10-15<BR>




<P>Consider:</P>

<PRE>
  template&lt;typename T&gt;  concept A = true;
  template&lt;typename... T&gt; concept B = A&lt;T...&gt;;
</PRE>

<P>Is this valid? MSVC accepts; gcc and clang reject.  See also
<A HREF="cwg_active.html#1430">issue 1430</A> for the equivalent question for
alias templates.</P>

<BR><BR><HR>
<A NAME="2996"></A><H4>2996.
  
Impenetrable definition of atomic constraint
</H4>
<B>Section: </B>13.5.2.3&#160; [<A href="https://wg21.link/temp.constr.atomic">temp.constr.atomic</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2025-01-30<BR>




<P>The definition of "atomic constraint" is hard to read.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 13.5.2.3 [<A href="https://wg21.link/temp.constr.atomic#1">temp.constr.atomic</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<P class="del">
An <I>atomic constraint</I> is formed from an expression E and a mapping from
the template parameters that appear within E to template arguments
that are formed via substitution during constraint normalization in
the declaration of a constrained entity (and, therefore, can involve
the unsubstituted template parameters of the constrained entity),
called the parameter mapping (13.5.3 [<A href="https://wg21.link/temp.constr.decl">temp.constr.decl</A>]).</P>

<P class="ins">
An <I>atomic constraint</I> is a pair (<I>E</I>, <I>M</I>)
where <I>E</I> is an expression and <I>M</I> is a mapping from the
template parameters that appear within <I>E</I> to template arguments
expressed using the normalizing context of the atomic constraint.  The
<I>parameter mapping</I> of an atomic constraint is <I>M</I>.
The <I>normalizing context</I> of an atomic constraint is</P>
<UL class="ins">
<LI>
the surrounding context of the last <I>concept-id</I> for which
arguments were substituted into the parameter mapping via constraint
normalization (13.5.4 [<A href="https://wg21.link/temp.constr.normal">temp.constr.normal</A>]), if any, and</LI>
<LI>the surrounding context where E appears otherwise.</LI>
</UL>
<P class="ins">[Note: The atomic constraints in the associated
constraints of a constrained entity have parameter mappings that map
the template parameters that appear within their expressions to
template arguments expressed using the context of the declaration of
the constrained entity, which may involve the unsubstituted template
parameters of the constrained entity. -- end note]
</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2975"></A><H4>2975.
  
Effect of concept <I>template-head</I> on parameter mappings
</H4>
<B>Section: </B>13.5.4&#160; [<A href="https://wg21.link/temp.constr.normal">temp.constr.normal</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2024-12-24<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/659">#659</A>.)
</P>

<P>Consider:</P>

<PRE>
  template &lt;auto&gt; constexpr bool B = true;

  template &lt;unsigned X0&gt; concept C = B&lt;X0&gt;;
  template &lt;unsigned short X1&gt; concept C2 = C&lt;X1&gt;;

  template &lt;unsigned X&gt; void f() requires C&lt;X&gt;; //<SPAN CLASS="cmnt"> #1</SPAN>
  template &lt;unsigned X&gt; int f() requires C2&lt;X&gt; &amp;&amp; true; //<SPAN CLASS="cmnt"> #2</SPAN>

  void g() {
    return f&lt;65536&gt;(); //<SPAN CLASS="cmnt"> should probably call #1</SPAN>
  }
  void h() {
    f&lt;0&gt;(); //<SPAN CLASS="cmnt"> ambiguous?</SPAN>
  }
</PRE>

<P>The rules in 13.5.4 [<A href="https://wg21.link/temp.constr.normal#1.4">temp.constr.normal</A>] bullet 1.4 do not
specify how the type of the non-type template parameter <TT>X1</TT> in
the definition of concept <TT>C2</TT> affects the parameter mapping.
There is implementation divergence: gcc and MSVC reject the call
in <TT>g</TT> and accept the call in <TT>h</TT>, resolving to #2 in
both cases.  Clang and EDG accept the call in <TT>g</TT> (resolving to
#1) and reject the call in <TT>h</TT> as ambiguous.</P>

<P>As a suggested resolution, introduce a shadow constraint that
checks the validity of the template argument for the concept's
template parameter when normalizing the use of <TT>C2</TT> from #2.
This would reject the call to #2 from <TT>g</TT> (choosing #1) and
select #2 as more constrained for the call from <TT>h</TT>.</P>

<BR><BR><HR>
<A NAME="3021"></A><H4>3021.
  
Subsumption rules for fold expanded constraints
</H4>
<B>Section: </B>13.5.5&#160; [<A href="https://wg21.link/temp.constr.order">temp.constr.order</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2025-03-25<BR>




<P>Consider:</P>

<PRE>
  template &lt;typename T&gt;
  concept C = false;

  template &lt;typename ...T&gt;
  concept CC = (C&lt;T&gt; &amp;&amp; ...);

  template &lt;typename T&gt; requires CC&lt;T&gt;
  struct A;

  template &lt;typename T&gt; requires CC&lt;&gt; &amp;&amp; true
  struct A&lt;T&gt;; //<SPAN CLASS="cmnt"> okay, surprisingly</SPAN>
</PRE>

<P>The subsumption rules for fold expanded constraints
(13.5.5 [<A href="https://wg21.link/temp.constr.order#1.3">temp.constr.order</A>] bullet 1.3 with the definition of
"compatible for subsumption" in 13.5.2.5 [<A href="https://wg21.link/temp.constr.fold#5">temp.constr.fold</A>] paragraph 5) do not properly account for fold-expressions in concept
definitions.  For the example above, the partial specialization is
considered to be more specialized (and its associated constraints can
be satisfieid), even though the constraints of the primary template
can never be satisifed.</P>
			  
<P>Additionally, replacing fold expressions in a constraint expression
with an analogous use of a defined concept breaks subsumption
relationships:</P>

<PRE>
  template &lt;typename, unsigned = 0&gt; constexpr bool Atomic = true;

  template &lt;typename T&gt; concept C = Atomic&lt;T&gt;;
  template &lt;typename T&gt; concept C2 = C&lt;T&gt; &amp;&amp; Atomic&lt;T, 1&gt;;

  template &lt;typename ...T&gt; concept CC = (C&lt;T&gt; &amp;&amp; ...);
  template &lt;typename ...T&gt; concept CC2 = (C2&lt;T&gt; &amp;&amp; ...);

  template &lt;typename ...T&gt; requires (C&lt;T&gt; &amp;&amp; ...)
  struct A;
  template &lt;typename ...T&gt; requires (C2&lt;T&gt; &amp;&amp; ...)
  struct A&lt;T ...&gt;; //<SPAN CLASS="cmnt"> okay, compatible for subsumption</SPAN>

  template &lt;typename ...T&gt; requires CC&lt;T ...&gt;
  struct AA;
  template &lt;typename ...T&gt; requires CC2&lt;T ...&gt;
  struct AA&lt;T ...&gt;; //<SPAN CLASS="cmnt"> error</SPAN>
</PRE>

<P>Introducing parameter mappings for such fold expanded constraints
might be an approach to fixing the issue.</P>

<BR><BR><HR>
<A NAME="3027"></A><H4>3027.
  
Equivalence of <I>pack-index-specifier</I>s
</H4>
<B>Section: </B>13.6&#160; [<A href="https://wg21.link/temp.type">temp.type</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

 <B>Date: </B>2025-04-14<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/700">#700</A>.)</P>

<P>Subclause 13.6 [<A href="https://wg21.link/temp.type#5">temp.type</A>] paragraph 5 and paragraph 6 specify:</P>

<BLOCKQUOTE>
<P>For a type template parameter pack T, T...[constant-expression]
denotes a unique dependent type.</P>
<P>
If the <I>constant-expression</I> of a <I>pack-index-specifier</I> is
value-dependent, two such <I>pack-index-specifier</I> s refer to the
same type only if their <I>constant-expression</I>s are equivalent
(13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]). Otherwise, two
such <I>pack-index-specifier</I> s refer to the same type only if
their indexes have the same value.</P>

</BLOCKQUOTE>

<P>That seems to imply that <I>pack-index-specifier</I>s referring to
different template parameter packs could be equivalent.</P>

<P><U>Possible resolution:</U></P>

<P>Change and merge in 13.6 [<A href="https://wg21.link/temp.type#5">temp.type</A>] paragraph 5 and
paragraph 6 as follows:</P>

<BLOCKQUOTE>
For a type template parameter
pack <TT>T</TT>, <TT>T</TT>...[<I>constant-expression</I>] denotes a
unique dependent type.
<DEL>If the <I>constant-expression</I> of
a <I>pack-index-specifier</I> is value-dependent, two</DEL>
<INS>Two</INS> such <I>pack-index-specifier</I>s
(9.2.9.4 [<A href="https://wg21.link/dcl.type.pack.index">dcl.type.pack.index</A>]) refer to the same type only if
<INS>their <I>typedef-name</I>s refer to the same template parameter
pack and</INS> their <I>constant-expression</I>s are
equivalent <INS>if value-dependent</INS>
(13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]) <INS>or otherwise have the same
value.</INS>
<DEL>Otherwise, two such <I>pack-index-specifier</I> s refer to the
same type only if their indexes have the same value.</DEL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2951"></A><H4>2951.
  
Distinguishing a primary template
</H4>
<B>Section: </B>13.7.1&#160; [<A href="https://wg21.link/temp.decls.general">temp.decls.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Christopher Di Bella
 &#160;&#160;&#160;

 <B>Date: </B>2023-04-22<BR>


<P>Consider:</P>

<PRE>
  template&lt;class...&gt;
  struct S {};

  template&lt;&gt;
  struct S&lt;&gt; {};
</PRE>

<P>According to 13.7.1 [<A href="https://wg21.link/temp.decls.general#2">temp.decls.general</A>] paragraph 2:</P>

<BLOCKQUOTE>

A <I>primary template</I> declaration is one in which the name of the
template is not followed by a <I>template-argument-list</I>. ...

</BLOCKQUOTE>

<P>In the example's <I>template-id</I>, the name of the
template <TT>S</TT> is, in fact not followed by
a <I>template-argument-list</I> (it is absent).</P>

<P><U>Possible resolution:</U></P>

<P>Change in 13.7.1 [<A href="https://wg21.link/temp.decls.general#2">temp.decls.general</A>] paragraph 2</P>

<BLOCKQUOTE>

A <I>primary template</I> declaration is one in which the name of the
template is not followed by <DEL>a</DEL> <INS><TT>&lt;</TT></INS> <I>template-argument-list<INS><SUB>opt</SUB></INS></I> <INS><TT>&gt;</TT></INS>. ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1432"></A><H4>1432.
  
Newly-ambiguous variadic template expansions
</H4>
<B>Section: </B>13.7.4&#160; [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-12-17<BR>


<P>With the new core rules in regard to variadic pack expansions
the library specification of the traits template
<TT>common_type</TT> is now broken, the reason is that it is
defined as a series of specializations of the primary template</P>

<PRE>
    template &lt;class ...T&gt;
    struct common_type;
</PRE>

<P>The broken one is this pair:</P>

<PRE>
  template &lt;class T, class U&gt;
  struct common_type&lt;T, U&gt; {
   typedef decltype(true ? declval&lt;T&gt;() : declval&lt;U&gt;()) type;
  };

  template &lt;class T, class U, class... V&gt;
  struct common_type&lt;T, U, V...&gt; {
   typedef typename common_type&lt;typename common_type&lt;T, U&gt;::type, V...&gt;::type type;
  };
</PRE>

<P>With the new rules both specializations would now be ambiguous
for an instantiation like <TT>common_type&lt;X, Y&gt;</TT>.</P>

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

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

<P>It is possible that 13.7.6.3 [<A href="https://wg21.link/temp.spec.partial.order">temp.spec.partial.order</A>] may resolve this
problem.</P>

<P><B>CWG 2022-11-11</B></P>

<P>Resolved by <A HREF="cwg_defects.html#1395">issue 1395</A>; see the special
rule about trailing packs in 13.10.3.5 [<A href="https://wg21.link/temp.deduct.partial#11">temp.deduct.partial</A>] paragraph 11.</P>

<P><B>Additional notes (March, 2025)</B></P>

<P>
<A HREF="cwg_defects.html#1395">Issue 1395</A> covers only function
parameter packs, but the example in the present issue does not have
any.  Reopening the issue for further consideration.  See also
13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#9.1">temp.deduct.type</A>] bullet 9.1.</P>

<BR><BR><HR>
<A NAME="2118"></A><H4>2118.
  
Stateful metaprogramming via friend injection
</H4>
<B>Section: </B>13.7.5&#160; [<A href="https://wg21.link/temp.friend">temp.friend</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-04-27<BR>




<P>Defining a friend function in a template, then referencing that
function later provides a means of capturing and retrieving
metaprogramming state.  This technique is arcane and should be
made ill-formed.</P>

<P><B>Notes from the May, 2015 meeting:</B></P>

<P>CWG agreed that such techniques should be ill-formed,
although the mechanism for prohibiting them is as yet
undetermined.</P>

<BR><BR><HR>
<A NAME="708"></A><H4>708.
  
Partial specialization of member templates of class templates
</H4>
<B>Section: </B>13.7.6&#160; [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]
 &#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="2173"></A><H4>2173.
  
Partial specialization with non-deduced contexts
</H4>
<B>Section: </B>13.7.6&#160; [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2015-09-14<BR>


<P>During the discussion of <A HREF="cwg_defects.html#1315">issue 1315</A>,
it was observed that the example</P>

<PRE>
  template &lt;int I, int J&gt; struct B {};
  template &lt;int I&gt; struct B&lt;I, I*2&gt; {};
</PRE>

<P>is ill-formed because the deduction succeeds in both directions.
This seems surprising.  It was suggested that perhaps a
non-deduced context should be considered more specialized than
a deduced context.</P>

<BR><BR><HR>
<A NAME="2948"></A><H4>2948.
  
Late ambiguity for partial template specialization
</H4>
<B>Section: </B>13.7.6.1&#160; [<A href="https://wg21.link/temp.spec.partial.general">temp.spec.partial.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mauro Russo
 &#160;&#160;&#160;

 <B>Date: </B>2024-11-01<BR>




<P>If a partial specialization is introduced later than where it would
have been used, the program is ill-formed, no diagnostic required.
The same should apply if the late declaration would have caused an
ambiguity.</P>

<P>Also consider removing the redundancy between
13.4.4 [<A href="https://wg21.link/temp.arg.template#2">temp.arg.template</A>] paragraph 2 and 13.7.6.1 [<A href="https://wg21.link/temp.spec.partial.general#1">temp.spec.partial.general</A>] paragraph 1 for that matter.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 13.4.4 [<A href="https://wg21.link/temp.arg.template#2">temp.arg.template</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

Any partial specializations (13.7.6 [<A href="https://wg21.link/temp.spec.partial">temp.spec.partial</A>]) associated
with the primary template are considered when a specialization based
on the template <I>template-parameter</I> is instantiated. <DEL>If a
specialization is not reachable from the point of instantiation, and
it would have been selected had it been reachable, the program is
ill-formed, no diagnostic required.</DEL>
<INS>[ Note: A partial specialization cannot be introduced after its
first potential use (13.7.6.1 [<A href="https://wg21.link/temp.spec.partial.general">temp.spec.partial.general</A>]). -- end note
] </INS>

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 13.7.6.1 [<A href="https://wg21.link/temp.spec.partial.general#1">temp.spec.partial.general</A>] paragraph 1 as follows:</P>

<BLOCKQUOTE>

A partial specialization of a template provides an alternative
definition of the template that is used instead of the primary
definition when the arguments in a specialization match those given in
the partial specialization (13.7.6.2 [<A href="https://wg21.link/temp.spec.partial.match">temp.spec.partial.match</A>]). A
declaration of the primary template shall precede any partial
specialization of that template. A partial specialization shall be
reachable from any <DEL>use of a template specialization that would
make use of the partial specialization as the result of an implicit or
explicit</DEL> <INS>point of</INS> instantiation <INS>where that
partial specialization would have been selected or would have
contributed to ambiguity</INS>; no diagnostic is required.

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="310"></A><H4>310.
  
Can function templates differing only in parameter cv-qualifiers be overloaded?
</H4>
<B>Section: </B>13.7.7.2&#160; [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]
 &#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 13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]
and the following sentence from 13.10.3.2 [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>] "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
13.10.3.2 [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>].</P>

<P>13.10.3.3 [<A href="https://wg21.link/temp.deduct.funcaddr">temp.deduct.funcaddr</A>], 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="2584"></A><H4>2584.
  
Equivalent types in function template declarations
</H4>
<B>Section: </B>13.7.7.2&#160; [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jim X
 &#160;&#160;&#160;

 <B>Date: </B>2022-04-08<BR>


<P>According to 6.4.1 [<A href="https://wg21.link/basic.scope.scope#4">basic.scope.scope</A>] paragraph 4:</P>

<BLOCKQUOTE>

Two declarations correspond if they (re)introduce the same name, both
declare constructors, or both declare destructors, unless

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

<LI>
each declares a function or function template,
except when
<UL>
<LI>...</LI>

<LI>
both declare function templates with equivalent
non-object-parameter-type-lists, return types (if
any), <I>template-head</I>s, and trailing <I>requires-clause</I>s (if
any), and, if both are non-static members, they have corresponding
object parameters.
</LI>
</UL>
</LI>
</UL>

</BLOCKQUOTE>

<P>Assuming that two non-object-parameter-type-lists are equivalent if
they have the same length and corresponding types are equivalent, the
question remains when two (possibly dependent) types are equivalent.
Subclause 13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>] should provide an answer, but
only covers expressions appearing in such types (paragraph 5):</P>

<BLOCKQUOTE>

Two expressions involving template parameters are considered
<I>equivalent</I> if...

</BLOCKQUOTE>

<P>For example, the standard should specify whether these
declarations correspond:</P>

<PRE>
  template&lt;class T&gt; T   f();
  template&lt;class T&gt; T&amp;&amp; f();

  template&lt;class T, class U&gt; void g(decltype(T::foo));
  template&lt;class T, class U&gt; void g(decltype(U::foo));
</PRE>

<P>A related issue is the determination whether two names are the same;
for example:</P>

<PRE>
  struct A {
    template&lt;class T&gt;
    operator T();

    template&lt;class T&gt;
    operator T&amp;&amp;();
  };
</PRE>

<P>The latter issue could probably be fixed by amending
11.4.8.3 [<A href="https://wg21.link/class.conv.fct">class.conv.fct</A>] to state that
two <I>conversion-function-id</I>s are the same if
their <I>conversion-type-id</I>s denote equivalent types, with a
cross-reference to 13.7.7.2 [<A href="https://wg21.link/temp.over.link">temp.over.link</A>].</P>

<BR><BR><HR>
<A NAME="2946"></A><H4>2946.
  
Dependent call equivalence in non-ADL cases
</H4>
<B>Section: </B>13.7.7.2&#160; [<A href="https://wg21.link/temp.over.link">temp.over.link</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2024-10-30<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/631">#631</A>.)
</P>

<P>It is unclear whether the resolution of <A HREF="cwg_defects.html#1321">issue 1321</A> covers cases where argument-dependent lookup is not used,
for example because a callable object or a block-scope extern
declartion was found. There is implementation divergence (EDG accepts,
others reject) for the following example:</P>

<PRE>
  template &lt;typename ...T&gt;
  struct Blob : T ... {
    using T::operator() ...;
  };
  template &lt;typename T&gt; constexpr bool IsInt = false;
  template &lt;&gt; constexpr bool IsInt&lt;int&gt; = true;
  template &lt;typename T&gt; concept C = IsInt&lt;T&gt;;
  namespace N {
    constexpr auto f() {
      int f(int);
      return [](auto x) requires C&lt;decltype(f(x))&gt; { return true; };
    }
  }
  namespace M {
    constexpr auto f() {
      short f(int);
      return [](auto x) requires C&lt;decltype(f(x))&gt; || (sizeof(x) == 4) {};
    }
  }
  template &lt;typename ...T&gt;
  constexpr Blob&lt;T ...&gt; blobber(T ...) { return {}; }
  static_assert(blobber(N::f(), M::f())(0));
</PRE>

<P>The wording says the example is well-formed, because the use
of <TT>C</TT> in <TT>N::f</TT> subsumes the use of <TT>C</TT>
in <TT>M::f</TT>, despite the fact that the use of <TT>C</TT>
in <TT>M::f</TT> can never be satisfied.</P>

<P>Additionally, a call of the form <TT>(f)(x,y)</TT> (with a
parenthesized <I>postfix-expression</I>) is not considered a dependent
call per 13.8.3.1 [<A href="https://wg21.link/temp.dep.general#2">temp.dep.general</A>] paragraph 2, leaving the issue
addressed by <A HREF="cwg_defects.html#1321">issue 1321</A> open for such
cases.</P>

<P><U>Suggested resolution (incomplete):</U></P>

<OL>
<LI>
<P>Change in 13.7.7.2 [<A href="https://wg21.link/temp.over.link#5">temp.over.link</A>] paragraph 5 as follows, adding bullets:</P>

<BLOCKQUOTE>

...  For determining whether two dependent names
(13.8.3 [<A href="https://wg21.link/temp.dep">temp.dep</A>]) are equivalent, <INS>the following rules
apply:</INS>

<UL>
<LI class="ins">If name lookup finds a non-function, that entity is
considered.</LI>
<LI class="ins">Otherwise, if name lookup finds a set of block-scope
declarations (including <I>using-declarations</I>), that set is
considered.</LI>
<LI class="ins">Otherwise, if the name appears in a class scope, the
lookup set for the name, merged with any
dependent <I>using-declaration</I>s, is considered.</LI>
<LI class="ins">Otherwise, if the parenthesized name is
the <I>postfix-expression</I> of a dependent call, the name itself and
the namespace scope is considered, not the result of name lookup.</LI>
<LI>
<INS>Otherwise, if the name is the <I>postfix-expression</I> in a
dependent call,</INS> only the name itself is considered, not the
result of name lookup.</LI>
</UL>
[Note 5: If such a dependent name is unqualified, it is looked up from
a first declaration of the function template
(13.8.1 [<A href="https://wg21.link/temp.res.general">temp.res.general</A>]).  &#8212;<I>end note</I>]

</BLOCKQUOTE>

</LI>

<LI>
<P>Change in 13.8.3.1 [<A href="https://wg21.link/temp.dep.general#2">temp.dep.general</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A <I>dependent call</I> is an expression, possibly formed as a
non-member candidate for an operator (12.2.2.3 [<A href="https://wg21.link/over.match.oper">over.match.oper</A>]),
of the form:
<PRE>
  <I>postfix-expression</I> ( <I>expression-list<SUB>opt</SUB></I> )
</PRE>
where the <I>postfix-expression</I> is <DEL>an</DEL>
<INS>a (possibly parenthesized)</INS> <I>unqualified-id</I> and
<UL>
<LI>any of the expressions in the <I>expression-list</I> is a pack
expansion (13.7.4 [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]), or</LI>
<LI>any of the expressions or <I>braced-init-list</I>s in
the <I>expression-list</I> is type-dependent
(13.8.3.3 [<A href="https://wg21.link/temp.dep.expr">temp.dep.expr</A>]), or</LI>
<LI>the <I>unqualified-id</I> is a <I>template-id</I> in which any of
the template arguments depends on a template parameter.</LI>
</UL>

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR>
<A NAME="402"></A><H4>402.
  
More on partial ordering of function templates
</H4>
<B>Section: </B>13.7.7.3&#160; [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]
 &#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
13.10.3.2 [<A href="https://wg21.link/temp.deduct.call#2">temp.deduct.call</A>] 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>13.7.7.3&#160; [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]
 &#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/2011/n3296.html#CA7">N3092 comment
  CA&#160;7<BR></A>

<P>13.7.7.3 [<A href="https://wg21.link/temp.func.order#3">temp.func.order</A>] paragraph 3 says,</P>

<BLOCKQUOTE>

To produce the transformed template, for each type,
non-type, or template template parameter (including template
parameter packs (13.7.4 [<A href="https://wg21.link/temp.variadic">temp.variadic</A>]) 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 CLASS="cmnt"> #1</SPAN>
    //<SPAN CLASS="cmnt"> synthetic </SPAN>T1<SPAN CLASS="cmnt"> has member </SPAN>T1::u
  template &lt;typename T&gt; void foo(A&lt;T, typename T::u::v&gt; *) { } //<SPAN CLASS="cmnt"> #2</SPAN>
    //<SPAN CLASS="cmnt"> synthetic </SPAN>T2<SPAN CLASS="cmnt"> has member </SPAN>T2::u<SPAN CLASS="cmnt"> and member </SPAN>T2::u::v
    //<SPAN CLASS="cmnt"> </SPAN>T<SPAN CLASS="cmnt"> in #1 deduces to synthetic </SPAN>T2<SPAN CLASS="cmnt"> in partial ordering;</SPAN>
    //<SPAN CLASS="cmnt"> deduced </SPAN>A<SPAN CLASS="cmnt"> for the parameter is </SPAN>A&lt;T2, T2::u&gt; *<SPAN CLASS="cmnt"> --this is not necessarily compatible</SPAN>
    //<SPAN CLASS="cmnt"> with </SPAN>A&lt;T2, T2::u::v&gt; *<SPAN CLASS="cmnt"> and it does not need to be. See Note 1. The effect is that</SPAN>
    //<SPAN CLASS="cmnt"> (in the call below) the compatibility of </SPAN>B::u<SPAN CLASS="cmnt"> and </SPAN>B::u::v<SPAN CLASS="cmnt"> is respected.</SPAN>
    //<SPAN CLASS="cmnt"> </SPAN>T<SPAN CLASS="cmnt"> in #2 cannot be successfully deduced in partial ordering from </SPAN>A&lt;T1, T1::u&gt; *;
    //<SPAN CLASS="cmnt"> invalid type </SPAN>T1::u::v<SPAN CLASS="cmnt"> will be formed when </SPAN>T1<SPAN CLASS="cmnt"> 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 CLASS="cmnt"> 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 13.10.3.5 [<A href="https://wg21.link/temp.deduct.partial#9">temp.deduct.partial</A>] 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 CLASS="cmnt"> #2.1</SPAN>
      //<SPAN CLASS="cmnt"> synthetic </SPAN>T1<SPAN CLASS="cmnt"> has member non-union class </SPAN>T1::u
  template &lt;typename T, typename U&gt;
    void foo(A&lt;T, U , U&gt; *); //<SPAN CLASS="cmnt"> #2.2</SPAN>
      //<SPAN CLASS="cmnt"> synthetic </SPAN>T2<SPAN CLASS="cmnt"> and </SPAN>U2<SPAN CLASS="cmnt"> has no required properties</SPAN>
      //<SPAN CLASS="cmnt"> </SPAN>T<SPAN CLASS="cmnt"> in #2.1 cannot be deduced in partial ordering from </SPAN>A&lt;T2, U2, U2&gt; *;
      //<SPAN CLASS="cmnt"> invalid types </SPAN>T2::u<SPAN CLASS="cmnt"> and </SPAN>T2::u::u<SPAN CLASS="cmnt"> will be formed when </SPAN>T2<SPAN CLASS="cmnt"> is substituted in nondeduced contexts.</SPAN>
      //<SPAN CLASS="cmnt"> </SPAN>T<SPAN CLASS="cmnt"> and </SPAN>U<SPAN CLASS="cmnt"> in #2.2 deduces to, respectively, </SPAN>T1<SPAN CLASS="cmnt"> and </SPAN>T1::u<SPAN CLASS="cmnt"> from </SPAN>A&lt;T1, T1::u, struct
T1::u::u&gt; *<SPAN CLASS="cmnt"> unless</SPAN>
      //<SPAN CLASS="cmnt"> </SPAN>struct T1::u::u<SPAN CLASS="cmnt"> does not refer to the injected-class-name of the class </SPAN>T1::u<SPAN CLASS="cmnt"> (if that is possible).</SPAN>
  struct B {
    struct u { };
  };
  int main() {
    foo((A&lt;B, B::u, struct B::u::u&gt; *)0); //<SPAN CLASS="cmnt"> 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>

<P><B>Additional notes (March, 2025)</B></P>

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


.</P>

<BR><BR><HR>
<A NAME="2160"></A><H4>2160.
  
Issues with partial ordering
</H4>
<B>Section: </B>13.7.7.3&#160; [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-07-16<BR>


<P>(From <A HREF="https://github.com/cplusplus/draft/issues/523">this
editorial issue</A>.)</P>

<P><B>Consistency of deduced values</B></P>

<PRE>
  template &lt;typename T&gt; void foo(T, T); //<SPAN CLASS="cmnt"> (1)</SPAN>
  template &lt;typename T, typename U&gt; void foo(T, U); //<SPAN CLASS="cmnt"> (2)</SPAN>
</PRE>

<P>13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#2">temp.deduct.type</A>] paragraph 2 makes it clear
that there must be exactly one set of deduced values for the
<TT>P</TT>s. But there is no such statement in the partial ordering
rule. The algorithm described only does pairwise <TT>P</TT>/<TT>A</TT>
matching, so a synthesized call from (2) to (1) via <TT>foo(U{},
V{})</TT> could succeed in deduction. Both gcc and clang agree
that (1) is more specialized.</P>

<P><B>Type Synthesis Template Instantiation</B></P>

<PRE>
  template &lt;typename T&gt;
  struct identity { using type = T; };

  template&lt;typename T&gt; void bar(T, T ); //<SPAN CLASS="cmnt"> (1) </SPAN>
  template&lt;typename T&gt; void bar(T, typename identity&lt;T&gt;::type ); //<SPAN CLASS="cmnt"> (2)</SPAN>
</PRE>

<P>Here, if synthesized for (2) <TT>Unique2</TT> and <TT>typename
identity&lt;Unique2&gt;::type == Unique2</TT> , then type
deduction would succeed in both directions and the call
<TT>bar(0,0)</TT> would be ambiguous. However, it seems that
both compilers instead simply treat <TT>typename
identity&lt;Unique2&gt;::type</TT> as <TT>Unique2_b</TT>,
thus making template deduction from (2) to (1) fail (based
on the implied missing Consistency rule).</P>

<P><B>Non-deduced Context Omission</B></P>

<P>This is the same as the previous example, except now define</P>

<PRE>
  template &lt;typename T&gt; struct identity;
  template &lt;&gt; struct identity&lt;int&gt; { using type = int; };
</PRE>

<P>With no template instantiation during synthesis and
consistency, the (2) ==&gt; (1) deduction fails. But if we
consider the (1) ==&gt; (2) call, we'd match <TT>T</TT> against
<TT>Unique1</TT> and then have the non-deduced
context <TT>typename identity&lt;Unique1&gt;::type</TT> to
match against <TT>Unique1</TT>, but that would be a
substitution failure. It seems that the approach taken by
gcc and clang (both of which prefer (1) here) is to ignore
the non-deduced context argument, as long as that parameter
type is deduced from a different template parameter type
that did get matched.</P>

<P><B>Notes from the February, 2016 meeting:</B></P>

<P>None of these examples appears to reflect a defect in the
current wording; in particular, the second and third
examples involve a dependent type and there could be a later
specialization of <TT>identity</TT>, so it's impossible to
reason about those cases in the template definition
context. The issue will be left open to allow for possible
clarification of the intent of the wording.</P>

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

<BR><BR><HR>
<A NAME="2949"></A><H4>2949.
  
Treatment of ellipsis during partial ordering
</H4>
<B>Section: </B>13.7.7.3&#160; [<A href="https://wg21.link/temp.func.order">temp.func.order</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Artyom Kolpakov
 &#160;&#160;&#160;

 <B>Date: </B>2024-11-02<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/632">#632</A>.)
</P>

<P>The partial ordering rules in 13.7.7.3 [<A href="https://wg21.link/temp.func.order#6">temp.func.order</A>] paragraph 6 do not consider the possible presence of an ellipsis in the
function parameter list:</P>

<UL>
<LI>The length of a <I>template-parameter-list</I> is not defined.</LI>
<LI>The term "function parameter list" is not defined.</LI>
<LI>The length of a function parameter list is not defined: Does an
ellipsis count towards the length?</LI>
<LI>What does it mean for corresponding function parameter to be of
the same type, if one of those parameters is an ellipsis?</LI>
</UL>

<P><U>Suggested resolution:</U></P>

<P>Change in 13.7.7.3 [<A href="https://wg21.link/temp.func.order#6">temp.func.order</A>] paragraph 6 and add bullets as
follows:</P>

<BLOCKQUOTE>

If deduction against the other template succeeds for both transformed
templates, constraints can be considered as follows:
<UL>
<LI>If
<UL>
<LI>their <I>template-parameter-list</I>s (possibly
including <I>template-parameter</I>s invented for an abbreviated
function template (9.3.4.6 [<A href="https://wg21.link/dcl.fct">dcl.fct</A>])) <INS>have different
numbers of <I>template-parameter</I>s</INS> or
</LI>
<LI class="del">function parameter lists differ in length</LI>
<LI class="ins">their parameter-type-lists have different numbers of
parameters or</LI>
<LI>
<INS>either, but not both, of their parameter-type-lists has an
ellipsis</INS>,</LI>
</UL>
neither template is more specialized than the other.</LI>
<LI>Otherwise: ...</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1286"></A><H4>1286.
  
Equivalence of alias templates
</H4>
<B>Section: </B>13.7.8&#160; [<A href="https://wg21.link/temp.alias">temp.alias</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-04-03<BR>




<P>
<A HREF="cwg_defects.html#1244">Issue 1244</A> was resolved by changing the
example in 13.6 [<A href="https://wg21.link/temp.type#1">temp.type</A>] paragraph 1 from</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>to</P>

<PRE>
  template&lt;class T&gt; struct X { };
  template&lt;class&gt; struct Y { };
  template&lt;class T&gt; using Z = Y&lt;T&gt;;
  X&lt;Y&lt;int&gt; &gt; y;
  X&lt;Z&lt;int&gt; &gt; z;
</PRE>

<P>In fact, the original intent was that the example should have been
correct as written; however, the normative wording to make it so was
missing.  The current wording of 13.7.8 [<A href="https://wg21.link/temp.alias">temp.alias</A>] deals
only with the equivalence of a specialization of an alias template
with the <I>type-id</I> after substitution.  Wording needs to be added
specifying under what circumstances an alias template itself is
equivalent to a class template.</P>

<P><B>Proposed resolution (September, 2012):</B></P>

<OL>
<LI><P>Add the following as a new paragraph following 13.7.8 [<A href="https://wg21.link/temp.alias#2">temp.alias</A>] paragraph 2:</P></LI>

<BLOCKQUOTE>

<P><INS>When the <I>type-id</I> in the declaration of alias template (call
it <TT>A</TT>) consists of a <I>simple-template-id</I> in which the
<I>template-argument-list</I> consists of a list of <I>identifier</I>s
naming each <I>template-parameter</I> of <TT>A</TT> exactly once in
the same order in which they appear in <TT>A</TT>'s
<I>template-parameter-list</I>, the alias template is equivalent to
the template named in the <I>simple-template-id</I> (call it
<TT>T</TT>) if <TT>A</TT> and <TT>T</TT> have the same number of
<I>template-parameter</I>s. [<I>Footnote:</I> This rule is transitive:
if an alias template <TT>A</TT> is equivalent to another alias
template <TT>B</TT> that is equivalent to a class template <TT>C</TT>,
then <TT>A</TT> is also equivalent to <TT>C</TT>, and <TT>A</TT> and
<TT>B</TT> are also equivalent to each other. &#8212;<I>end
footnote</I>] [<I>Example:</I></INS></P>

<PRE>
<INS>  template&lt;typename T, U = T&gt; struct A;

  template&lt;typename V, typename W&gt;
    using B = A&lt;V, W&gt;;                //<SPAN CLASS="cmnt"> equivalent to </SPAN>A

  template&lt;typename V, typename W&gt;
    using C = A&lt;V&gt;;                   //<SPAN CLASS="cmnt"> not equivalent to </SPAN>A<SPAN CLASS="cmnt">:</SPAN>
                                      //<SPAN CLASS="cmnt"> not all parameters used</SPAN>

  template&lt;typename V&gt;
    using D = A&lt;V&gt;;                   //<SPAN CLASS="cmnt"> not equivalent to </SPAN>A<SPAN CLASS="cmnt">:</SPAN>
                                      //<SPAN CLASS="cmnt"> different number of parameters</SPAN>

  template&lt;typename V, typename W&gt;
    using E = A&lt;W, V&gt;;                //<SPAN CLASS="cmnt"> not equivalent to </SPAN>A<SPAN CLASS="cmnt">:</SPAN>
                                      //<SPAN CLASS="cmnt"> template-arguments in wrong order</SPAN>

  template&lt;typename V, typename W = int&gt;
    using F = A&lt;V, W&gt;;                //<SPAN CLASS="cmnt"> equivalent to </SPAN>A<SPAN CLASS="cmnt">:</SPAN>
                                      //<SPAN CLASS="cmnt"> default arguments not considered</SPAN>

  template&lt;typename V, typename W&gt;
    using G = A&lt;V, W&gt;;                //<SPAN CLASS="cmnt"> equivalent to </SPAN>A<SPAN CLASS="cmnt"> and </SPAN>B

  template&lt;typename V, typename W&gt;
    using H = E&lt;V, W&gt;;                //<SPAN CLASS="cmnt"> equivalent to </SPAN>E

  template&lt;typename V, typename W&gt;
    using I = A&lt;V, typename W::type&gt;; //<SPAN CLASS="cmnt"> not equivalent to </SPAN>A<SPAN CLASS="cmnt">:</SPAN>
                                      //<SPAN CLASS="cmnt"> argument not identifier</SPAN></INS>

</PRE>

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

</BLOCKQUOTE>

<LI><P>Change 13.6 [<A href="https://wg21.link/temp.type#1">temp.type</A>] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>Two <I>template-id</I>s refer to the same class or function if</P>

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

<LI><P>their corresponding template <I>template-argument</I>s refer to
the same <INS>or equivalent (13.7.8 [<A href="https://wg21.link/temp.alias">temp.alias</A>])</INS>
template<INS>s</INS>.
</P></LI>

</UL>

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

<P>...declares <TT>x2</TT> and <TT>x3</TT> to be of the same type. Their type differs from the types of <TT>x1</TT> and <TT>x4</TT>.</P>

<PRE>
  template&lt;<DEL>class T</DEL> <INS>template&lt;class&gt; class TT</INS>&gt; struct X { };
  template&lt;class&gt; struct Y { };
  template&lt;class T&gt; using Z = Y&lt;T&gt;;
  X&lt;<DEL>Y&lt;int&gt;</DEL> <INS>Y</INS>&gt; y;
  X&lt;<DEL>Z&lt;int&gt;</DEL> <INS>Z</INS>&gt; z;
</PRE>

<P>declares <TT>y</TT> and <TT>z</TT> to be of the same type.
&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

</OL>

<P><B>Additional note, November, 2014:</B></P>

<P>Concern has been expressed over the proposed resolution with
regard to its handling of default template arguments that differ
between the template and its alias, e.g.,</P>

<PRE>
   template&lt;typename T, typename U = int&gt; struct A {};
   template&lt;typename T, typename U = char&gt; using B = A&lt;T, U&gt;;
   template&lt;template&lt;typename...&gt; typename C&gt; struct X { C&lt;int&gt; c; };
</PRE>



<P><B>Notes from the May, 2015 meeting:</B></P>

<P>See also <A HREF="cwg_active.html#1979">issue 1979</A>, which CWG
is suggesting to be resolved by defining a
&#8220;simple&#8221; alias, one in which the SFINAE
conditions are the same as the referenced template and that
uses all template parameters.</P>

<BR><BR><HR>
<A NAME="1430"></A><H4>1430.
  
Pack expansion into fixed alias template parameter list
</H4>
<B>Section: </B>13.7.8&#160; [<A href="https://wg21.link/temp.alias">temp.alias</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2011-12-13<BR>




<P>Originally, a pack expansion could not expand into a
fixed-length template parameter list, but this was changed in
N2555.  This works fine for most templates, but causes issues
with alias templates.</P>

<P>In most cases, an alias template is transparent; when it's
used in a template we can just substitute in the dependent
template arguments.  But this doesn't work if the
<I>template-id</I> uses a pack expansion for non-variadic
parameters.  For example:</P>

<PRE>
    template&lt;class T, class U, class V&gt;
    struct S {};

    template&lt;class T, class V&gt;
    using A = S&lt;T, int, V&gt;;

    template&lt;class... Ts&gt;
    void foo(A&lt;Ts...&gt;);
</PRE>

<P>There is no way to express <TT>A&lt;Ts...&gt;</TT> in terms of
<TT>S</TT>, so we need to hold onto the <TT>A</TT> until we have
the <TT>Ts</TT> to substitute in, and therefore it needs to be
handled in mangling.</P>

<P>Currently, EDG and Clang reject this testcase, complaining
about too few template arguments for A.  G++ did as well, but I
thought that was a bug.  However, on the ABI list John Spicer
argued that it should be rejected.</P>

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

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

<P>The consensus of CWG was that this usage should be prohibited,
disallowing use of an alias template when a dependent argument can't
simply be substituted directly into the <I>type-id</I>.</P>

<P><B>Additional note, April, 2013:</B></P>

<P>For another example, consider:</P>

<PRE>
  template&lt;class... x&gt; class list{};
  template&lt;class a, class... b&gt; using tail=list&lt;b...&gt;;
  template &lt;class...T&gt; void f(tail&lt;T...&gt;);

  int main() {
    f&lt;int,int&gt;({});
  }
</PRE>

<P>There is implementation variance in the handling of this
example. </P>

<P><B>CWG 2022-11-11</B></P>

<P>There is no more implementation divergence; all known
implementations reject the example.</P>

<P><B>Additional notes (January, 2025)</B></P>

<P>Using <I>pack-index-specifier</I>s allows to express
some such substitutions, but not others.  In the below example, we
cannot express <TT>X</TT>.  And while we can express <TT>Y</TT>, we
cannot deduce through the replacement.</P>

<PRE>
  template&lt;typename A, typename...T&gt; using X = std::tuple&lt;T...&gt;;
  template&lt;typename A, typename...T&gt; using Y = A;

  template&lt;typename ...U&gt; void f(X&lt;U...&gt; x, Y&lt;U...&gt; y);
</PRE>

<P><B>Additional notes (March, 2025)</B></P>

<P>There is still implementation divergence for the following example:</P>

<PRE>
   template &lt;template &lt;typename...&gt; class T&gt; struct Template {
   template &lt;typename... Us&gt; using type = T&lt;Us...&gt;;
   };

   template &lt;class T&gt; struct X { static constexpr T value = T(); };
   template &lt;class T&gt; using alias = X&lt;T&gt;;

   int main() { return Template&lt;alias&gt;::type&lt;int&gt;::value; }
</PRE>

<P>GCC and EDG accept, clang rejects.</P>

<P>Also consider:</P>

<PRE>
  template &lt;template &lt;int...&gt; class T&gt; struct Template {
    template &lt;int... Us&gt; using type = T&lt;Us...&gt;; 
  };
  template &lt;T1 N&gt; struct X { static constexpr int value = 0; };
  template &lt;T2 N&gt; using alias = X&lt;N&gt;;
</PRE>

<P>If T1 = T2 = int, GCC and EDG accept and MSVC and Clang reject.
If T1 = int and T2 = short, GCC accepts and everyone else rejects.
If T1 = short and T2 = int, EDG accepts and everyone else rejects.
See also issues <A HREF="cwg_active.html#1979">1979</A> and
<A HREF="cwg_active.html#1286">1286</A>; the alias template above would be
considered "simple" only if T1 = T2.</P>

<BR><BR><HR>
<A NAME="2794"></A><H4>2794.
  
Uniqueness of lambdas in alias templates
</H4>
<B>Section: </B>13.7.8&#160; [<A href="https://wg21.link/temp.alias">temp.alias</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Ilya Biryukov
 &#160;&#160;&#160;

 <B>Date: </B>2023-04-19<BR>




<P>Consider:</P>

<PRE>
  template&lt;class T&gt; using A = decltype([]{});

  static_assert(std::same_as&lt;A&lt;int&gt;, A&lt;int&gt;&gt;);
</PRE>

<P>There is implementation divergence: GCC and MSVC accept, clang
rejects. A similar question arises if token-identical alias templates
appear in different translation units:</P>

<PRE>
  // <SPAN CLASS="cmnt">appearing in multiple translation units</SPAN>
  template&lt;typename T&gt; using A = decltype([]{});
  inline A&lt;int&gt; f() { return {}; }
</PRE>

<P>An alias template is a templated entity per 13.1 [<A href="https://wg21.link/temp.pre#8.1">temp.pre</A>] paragraph 8.1, thus it is a definable item (6.3 [<A href="https://wg21.link/basic.def.odr#1.5">basic.def.odr</A>] paragraph 1.5) and thus there is effectively only a single definition
of it (6.3 [<A href="https://wg21.link/basic.def.odr#15">basic.def.odr</A>] paragraph 15).</P>

<P>However, that reasoning does not address the question
whether <TT>A&lt;int&gt;</TT> denotes the same type when it appears
repeatedly in the same translation unit.  Consider
13.7.7.2 [<A href="https://wg21.link/temp.over.link#5">temp.over.link</A>] paragraph 5:</P>

<BLOCKQUOTE>

Two <I>lambda-expression</I>s are never considered equivalent.

</BLOCKQUOTE>

<P>and 13.7.8 [<A href="https://wg21.link/temp.alias#2">temp.alias</A>] paragraph 2</P>

<BLOCKQUOTE>

When a <I>template-id</I> refers to the specialization of an alias
template, it is equivalent to the associated type obtained by
substitution of its <I>template-argument</I>s for
the <I>template-parameter</I> s in the <I>defining-type-id</I> of the
alias template.

</BLOCKQUOTE>

<P>This means that a <I>template-id</I> referring to an alias template
performs a fresh substitution each time it appears.  There is no
concept of instantiating an alias template to produce an alias
declaration.  Subclause 13.7.8 [<A href="https://wg21.link/temp.alias#5">temp.alias</A>] paragraph 5
specifies:</P>

<BLOCKQUOTE>

The type of a <I>lambda-expression</I> appearing in an alias template
declaration is different between instantiations of that template, even
when the <I>lambda-expression</I> is not dependent.

</BLOCKQUOTE>

<P>The outcome seems unfortunate; the first example ought to be
well-formed.</P>

<P><B>Additional notes (January, 2025)</B></P>

<P>Another example:</P>

<PRE>
  template&lt;typename T, typename F = decltype([](){} )&gt;
  struct Type {};
  template&lt;typename A&gt;
  using C = Type&lt;A&gt;;

  static_assert(std::same_as&lt;Type&lt;int&gt;,Type&lt;int&gt;&gt;); //<SPAN CLASS="cmnt"> #1</SPAN>
  static_assert(std::same_as&lt;C&lt;int&gt;,C&lt;int&gt;&gt;); //<SPAN CLASS="cmnt"> #2</SPAN>
</PRE>

<P>
All of clang, EDG, gcc, and MSVC reject #1; clang additionally rejects #2.
</P>

<P>There is also implementation divergence for the following example:</P>

<PRE>
  template&lt;typename T&gt; using A = decltype([]{});
  template&lt;typename T&gt; void f(A&lt;T&gt;) {}
  template&lt;typename T&gt; void f(A&lt;T&gt;) {}  //<SPAN CLASS="cmnt"> Duplicate definition?</SPAN>
</PRE>

<P>MSVC and gcc reject as a redefinition; clang and EDG accept.  Even
if only a single definition is present, implementations differ about
whether <TT>f</TT> has internal or external linkage and what
properties the mangled name has.</P>

<P>
<A HREF="cwg_active.html#1979">Issue 1979</A> is related and suggests to
treat simple alias templates differently (those would not have
specializations, but be transparent for template argument deduction)
from more complicated ones (those would have specializations and be
morally equivalent to a <TT>struct</TT> with a member typedef).</P>

<BR><BR><HR>
<A NAME="1257"></A><H4>1257.
  
Instantiation via non-dependent references in uninstantiated templates
</H4>
<B>Section: </B>13.8&#160; [<A href="https://wg21.link/temp.res">temp.res</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-09<BR>




<P>The Standard does not appear to specify whether a non-dependent
reference to a template specialization in a template definition that is
never instantiated causes the implicit instantiation of the referenced
specialization.</P>

<BR><BR><HR>
<A NAME="2067"></A><H4>2067.
  
Generated variadic templates requiring empty pack
</H4>
<B>Section: </B>13.8&#160; [<A href="https://wg21.link/temp.res">temp.res</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2015-01-09<BR>




<P>According to 13.8 [<A href="https://wg21.link/temp.res#8">temp.res</A>] paragraph 8,</P>

<BLOCKQUOTE>

If every valid specialization of a variadic template
requires an empty template parameter pack, the template is
ill-formed, no diagnostic required.

</BLOCKQUOTE>

<P>I'm inclined to think that this rule should only apply to
code the user wrote. That is, if every valid instantiation
of an entity (that was not itself instantiated) requires at
least one of the enclosing template argument lists to
include an empty template argument pack, then the program is
ill-formed (no diagnostic required).</P>

<BR><BR><HR>
<A NAME="2462"></A><H4>2462.
  
Problems with the omission of the <TT>typename</TT> keyword
</H4>
<B>Section: </B>13.8.1&#160; [<A href="https://wg21.link/temp.res.general">temp.res.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mark Hall
 &#160;&#160;&#160;

 <B>Date: </B>2020-12-03<BR>


<P>According to 13.8.2 [<A href="https://wg21.link/temp.local#5">temp.local</A>] paragraph 5,</P>

<BLOCKQUOTE>

<P>A <I>qualified-id</I> is assumed to name a type if</P>

<UL>
<LI><P>it is a qualified name in a type-id-only context
(see below), or</P></LI>

<LI><P>it is a <I>decl-specifier</I> of
the <I>decl-specifier-seq</I> of a</P></LI>

<UL>
<LI><P>
<I>simple-declaration</I> or
a <I>function-definition</I> in namespace scope,</P></LI>

<LI><P>
<I>member-declaration</I>,</P></LI>

<LI><P>
<I>parameter-declaration</I> in
a <I>member-declaration</I><SUP>140</SUP>, unless
that <I>parameter-declaration</I> appears in a default
argument,</P></LI>

<LI><P>
<I>parameter-declaration</I> in a declarator of a
function or function template declaration
whose <I>declarator-id</I> is qualified, unless
that <I>parameter-declaration</I> appears in a default
argument,</P></LI>

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

</UL>

</UL>

</BLOCKQUOTE>

<P>There are two possible problems with this specification. First,
consider an example like</P>

<PRE>
   template&lt;typename T&gt; struct S {
     static void (*pfunc)(T::name);                               //<SPAN CLASS="cmnt"> Omitted </SPAN>typename<SPAN CLASS="cmnt"> okay because it is a</SPAN>
                                                                  //<SPAN CLASS="cmnt"> member-declaration</SPAN>
   };
   template&lt;typename T&gt; void (*S&lt;T&gt;::pfunc)(T::name) = nullptr;   //<SPAN CLASS="cmnt"> Omitted </SPAN>typename<SPAN CLASS="cmnt"> ill-formed because not a function</SPAN>
                                                                  //<SPAN CLASS="cmnt"> or function template declaration</SPAN>
</PRE>

<P>Should bullet 5.2.4 be extended to include function pointer and
member function pointer declarations, as well as function and
function template declarations?</P>

<P>Second, given an example like</P>

<PRE>
   template&lt;typename T&gt; struct Y {};
   template&lt;typename T&gt; struct S {
     Y&lt;int(T::type)&gt; m;  //<SPAN CLASS="cmnt"> Omitted </SPAN>typename<SPAN CLASS="cmnt"> okay because it is in a member-declaration?</SPAN>
  };

</PRE>

<P>Should bullet 5.2.3 be restricted to <I>parameter-declaration</I>s
of the member being declared, rather than simply &#8220;in&#8221;
such a <I>member-declaration</I>?</P>

<P><B>Notes from the December, 2020 teleconference:</B></P>

<P>The second issue was split off into
<A HREF="cwg_active.html#2468">issue 2468</A> to allow the resolutions
to proceed independently.</P>

<BR><BR><HR>
<A NAME="2468"></A><H4>2468.
  
Omission of the <TT>typename</TT> keyword in a member template parameter list
</H4>
<B>Section: </B>13.8.1&#160; [<A href="https://wg21.link/temp.res.general">temp.res.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mark Hall
 &#160;&#160;&#160;

 <B>Date: </B>2020-12-03<BR>


<P>According to 13.8.2 [<A href="https://wg21.link/temp.local#5">temp.local</A>] paragraph 5,</P>

<BLOCKQUOTE>

<P>A <I>qualified-id</I> is assumed to name a type if</P>

<UL>
<LI><P>it is a qualified name in a type-id-only context
(see below), or</P></LI>

<LI><P>it is a <I>decl-specifier</I> of
the <I>decl-specifier-seq</I> of a</P></LI>

<UL>
<LI><P>
<I>simple-declaration</I> or
a <I>function-definition</I> in namespace scope,</P></LI>

<LI><P>
<I>member-declaration</I>,</P></LI>

<LI><P>
<I>parameter-declaration</I> in
a <I>member-declaration</I><SUP>140</SUP>, unless
that <I>parameter-declaration</I> appears in a default
argument,</P></LI>

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

</UL>

</UL>

</BLOCKQUOTE>

<P>This specification would appear to allow an example
like:</P>

<PRE>
   template&lt;typename T&gt; struct Y {};
   template&lt;typename T&gt; struct S {
     Y&lt;int(T::type)&gt; m;  //<SPAN CLASS="cmnt"> Omitted </SPAN>typename<SPAN CLASS="cmnt"> okay because it is in a member-declaration?</SPAN>
  };

</PRE>

<P>The affected <I>parameter-declaration</I>s should be
only those of the member declarator, not in a member
template's template parameter list.</P>

<P>(Note: this issue was spun off from
<A HREF="cwg_active.html#2462">issue 2462</A> to allow the
resolutions to proceed independently.)</P>

<BR><BR><HR>
<A NAME="186"></A><H4>186.
  
Name hiding and template <I>template-parameter</I>s
</H4>
<B>Section: </B>13.8.2&#160; [<A href="https://wg21.link/temp.local">temp.local</A>]
 &#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
(13.8.2 [<A href="https://wg21.link/temp.local#4">temp.local</A>] 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="1619"></A><H4>1619.
  
Definition of current instantiation
</H4>
<B>Section: </B>13.8.3.2&#160; [<A href="https://wg21.link/temp.dep.type">temp.dep.type</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-04<BR>




<P>The definition of the current instantiation, given in
13.8.3.2 [<A href="https://wg21.link/temp.dep.type#1">temp.dep.type</A>] paragraph 1, is phrased in terms of the
meaning of a name (&#8220;A name refers to the <I>current
instantiation</I> if it is...&#8221;); it does not define when a type
is the current instantiation.  Thus the interpretation of <TT>*this</TT>
and of phrases like &#8220;member of a class that is the current
instantiation&#8221; is not formally specified.</P>

<BR><BR><HR>
<A NAME="2774"></A><H4>2774.
  
Value-dependence of <I>requires-expression</I>s
</H4>
<B>Section: </B>13.8.3.4&#160; [<A href="https://wg21.link/temp.dep.constexpr">temp.dep.constexpr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Christof Meerwald
 &#160;&#160;&#160;

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




<P>Consider:</P>

<PRE>
   template&lt;typename T&gt;
   struct A
   {
     static_assert(sizeof(T) == 3);    // <SPAN CLASS="cmnt">#1</SPAN>
   };

   template&lt;bool B&gt;
   struct C
   {
     static_assert(B);                 // <SPAN CLASS="cmnt">#2</SPAN>
   };

   template&lt;typename T, typename U&gt;
   int f(typename C&lt;requires { typename T::type; }&gt;::type, typename A&lt;T&gt;::type, U);

   int i = f&lt;char&gt;(0, 1, 2);
</PRE>

<P>Is the <I>requires-expression</I> value-dependent after
substituting the explicit template argument, thus failing at #2
instead of at #1?</P>

<P><U>Suggested resolution:</U></P>

<OL>
<LI>
<P>Change in 13.8.3.3 [<A href="https://wg21.link/temp.dep.expr#4">temp.dep.expr</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

Expressions of the following forms are never type-dependent (because
the type of the expression cannot be dependent):

<PRE>
  ...
  noexcept ( <I>expression</I> )
  <INS><I>requires-expression</I></INS>
</PRE>

</BLOCKQUOTE>

</LI>

<LI>
<P>Insert a new paragraph before 13.8.3.4 [<A href="https://wg21.link/temp.dep.constexpr#5">temp.dep.constexpr</A>] paragraph 5:</P>

<BLOCKQUOTE>

<P class="ins">
A <I>requires-expression</I> is value-dependent if it depends on a
template parameter.
</P>

<P>An expression of the form &amp;<I>qualified-id</I> where
the <I>qualified-id</I> names a dependent member ...</P>

</BLOCKQUOTE>
</LI>
</OL>

<P><B>CWG 2023-08-25</B></P>

<P>The first change has consensus and is progressed via
<A HREF="cwg_defects.html#2785">issue 2785</A>; the second change should use an
approach of recursive decomposition for <I>requires-expression</I>,
similar to other paragraphs in 13.8.3.4 [<A href="https://wg21.link/temp.dep.constexpr">temp.dep.constexpr</A>].  The
implementation divergence is believed to be an independent bug in one
implementation.</P>

<BR><BR><HR>
<A NAME="2984"></A><H4>2984.
  
Value-dependent structured bindings
</H4>
<B>Section: </B>13.8.3.4&#160; [<A href="https://wg21.link/temp.dep.constexpr">temp.dep.constexpr</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Michael Park
 &#160;&#160;&#160;

 <B>Date: </B>2025-01-14<BR>


<P>Consider:</P>

<PRE>
  struct S { int x; };

  template &lt;S s&gt;
  void f() {
   constexpr auto [x] = s;
   constexpr bool b = (x == 0); // x<SPAN CLASS="cmnt"> ought to be value-dependent</SPAN>
  }
</PRE>

<P>The rules in 13.8.3.4 [<A href="https://wg21.link/temp.dep.constexpr">temp.dep.constexpr</A>] do not seem to cover the
case of structured bindings.</P>

<P><U>Possible resolution (January, 2025) [SUPERSEDED]:</U></P>

<P>Change in 13.8.3.4 [<A href="https://wg21.link/temp.dep.constexpr#2">temp.dep.constexpr</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

An <I>id-expression</I> is value-dependent if
<UL>
<LI>it is a <I>concept-id</I> and any of its arguments are
dependent,</LI>
<LI>it is type-dependent,</LI>
<LI>it is the name of a non-type template parameter,</LI>
<LI>it names a static data member that is a dependent member of the
current instantiation and is not initialized in a
<I>member-declarator</I>,</LI>
<LI>it names a static member function that is a dependent member of
the current instantiation, <DEL>or</DEL>
</LI>
<LI>it names a potentially-constant variable
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) that is initialized with an expression that
is value-dependent<DEL>.</DEL> <INS>, or</INS>
</LI>
<LI class="ins">it names a structured binding whose associated
variable (9.7 [<A href="https://wg21.link/dcl.struct.bind">dcl.struct.bind</A>]) is value-dependent.</LI>
</UL>

</BLOCKQUOTE>

<P><U>Possible resolution (February, 2025):</U></P>

<OL>
<LI>
<P>Change in 13.8.3.4 [<A href="https://wg21.link/temp.dep.constexpr#2">temp.dep.constexpr</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

An <I>id-expression</I> is value-dependent if
<UL>
<LI>it is a <I>concept-id</I> and any of its arguments are
dependent,</LI>
<LI>it is type-dependent,</LI>
<LI>it is the name of a non-type template parameter,</LI>
<LI>it names a static data member that is a dependent member of the
current instantiation and is not initialized in a
<I>member-declarator</I>,</LI>
<LI>it names a static member function that is a dependent member of
the current instantiation, <DEL>or</DEL>
</LI>
<LI>it names a potentially-constant variable
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) that is initialized with an expression that
is value-dependent<DEL>.</DEL> <INS>, or</INS>
</LI>
<LI class="ins">it names a structured binding whose structured binding
declaration (9.7 [<A href="https://wg21.link/dcl.struct.bind">dcl.struct.bind</A>]) has a
<I>brace-or-equal-initializer</I> that is value-dependent.</LI>
</UL>

</BLOCKQUOTE>

</LI>

<LI>
<P>Add after 13.8.3.4 [<A href="https://wg21.link/temp.dep.constexpr#6">temp.dep.constexpr</A>] paragraph 6 as follows:</P>

<BLOCKQUOTE>

<P>... An expression of the form &amp;<I>cast-expression</I> is also
value-dependent if evaluating <I>cast-expression</I> as a core
constant expression (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]) succeeds and the result
of the evaluation refers to a templated entity that is an object with
static or thread storage duration or a member function.</P>

<P class="ins">A <I>braced-init-list</I> is value-dependent if any element is
value-dependent or is a pack expansion.</P>

</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="2090"></A><H4>2090.
  
Dependency via non-dependent base class
</H4>
<B>Section: </B>13.8.3.7&#160; [<A href="https://wg21.link/temp.dep.temp">temp.dep.temp</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Maxim Kartashev
 &#160;&#160;&#160;

 <B>Date: </B>2015-02-27<BR>




<P>According to 13.8.3.7 [<A href="https://wg21.link/temp.dep.temp#3">temp.dep.temp</A>] paragraph 3,</P>

<BLOCKQUOTE>

a non-type <I>template-argument</I> is dependent if 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.

</BLOCKQUOTE>

<P>Members of non-dependent base classes are members of the
current instantiation, but using one as a non-type template
argument should not be considered dependent.</P>

<BR><BR><HR>
<A NAME="3002"></A><H4>3002.
  
Template parameter/argument confusion
</H4>
<B>Section: </B>13.8.3.7&#160; [<A href="https://wg21.link/temp.dep.temp">temp.dep.temp</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

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


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/668">#668</A>.)</P>

<P>Subclause 13.8.3.7 [<A href="https://wg21.link/temp.dep.temp#4">temp.dep.temp</A>] paragraph 4 confuses template
parameters and arguments.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 13.8.3.7 [<A href="https://wg21.link/temp.dep.temp#4">temp.dep.temp</A>] paragraph 4 as follows:</P>



<BLOCKQUOTE>

A template template <DEL>parameter</DEL> <INS>argument</INS> is
dependent if it names a template parameter or its terminal name is
dependent.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2250"></A><H4>2250.
  
Implicit instantiation, destruction, and TUs
</H4>
<B>Section: </B>13.8.4.1&#160; [<A href="https://wg21.link/temp.point">temp.point</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Dawn Perchik
 &#160;&#160;&#160;

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




<P>Consider:</P>

<PRE>
  template&lt;class T&gt; struct A {
    T* p;
    A();
    ~A() {
	if (0 &lt; sizeof (T))
	  delete p;
    }
  };
  struct U;
  struct C {
    C();
    ~C();
    A&lt;U&gt; u;
  };
  int main() {
    C c;
    return 0;
  }
</PRE>

<P>The intent is that <TT>A&lt;U&gt;::~A</TT> is instantiated where
the special member functions of <TT>C</TT> are defined (at which
point <TT>U</TT> is ostensibly complete). Preventing instantiation
(and thus avoiding the completeness check) in the present translation
unit is necessary for the <TT>unique_ptr</TT>-based pimpl idiom to
work.</P>

<P>
<B>Notes from the December, 2016 teleconference:</B>
</P>

<P>The problem is that the current wording only connects name lookup
with point of instantiation; other semantic checks, such as the
requirement for completeness of a class, should also be performed at
that point.</P>

<BR><BR><HR>
<A NAME="2435"></A><H4>2435.
  
Alias template specializations
</H4>
<B>Section: </B>13.9&#160; [<A href="https://wg21.link/temp.spec">temp.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Krystian Stasiowski
 &#160;&#160;&#160;

 <B>Date: </B>2019-09-28<BR>


<P>According to 13.9 [<A href="https://wg21.link/temp.spec#4">temp.spec</A>] paragraph 4,</P>

<BLOCKQUOTE>

An instantiated template specialization can be either
implicitly instantiated (13.9.2 [<A href="https://wg21.link/temp.inst">temp.inst</A>]) for a
given argument list or be explicitly instantiated
(13.9.3 [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]). A specialization is a class,
variable, function, or class member that is either
instantiated or explicitly specialized
(13.9.4 [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]).

</BLOCKQUOTE>

<P>The definition of &#8220;specialization&#8221; does not
cover alias templates, although the terms &#8220;specialization
of an alias template&#8221; and &#8221;alias template
specialization&#8221; are used in 13.7.8 [<A href="https://wg21.link/temp.alias">temp.alias</A>].
(Note that there are differences between alias specializations
and the specializations mentioned here; in particular, an
alias template cannot be explicitly specialized, and it is
not the result of instantiation (paragraph 1) but simply of
substitution (13.7.8 [<A href="https://wg21.link/temp.alias#2">temp.alias</A>] paragraph 2).)</P>

<BR><BR><HR>
<A NAME="1856"></A><H4>1856.
  
Indirect nested classes of class templates
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-02-11<BR>


<P>During the discussion of <A HREF="cwg_defects.html#1484">issue 1484</A>, it was
observed that the current rules do not adequately address indirect nested
classes of class templates (i.e., member classes of member classes of class
templates) in regard to their potential separate instantiation.</P>

<BR><BR><HR>
<A NAME="3034"></A><H4>3034.
  
Infinite recursion should hit an implementation limit
</H4>
<B>Section: </B>13.9.2&#160; [<A href="https://wg21.link/temp.inst">temp.inst</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Timur Doumler
 &#160;&#160;&#160;

 <B>Date: </B>2025-07-04<BR>




<P>Infinite recursion during template instantiation is specified to
yield undefined behavior in 13.9.2 [<A href="https://wg21.link/temp.inst#16">temp.inst</A>] paragraph 16.
However, instantiation should be subject to compile-time
implementation limits and not cause runtime undefined behavior.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 13.9.2 [<A href="https://wg21.link/temp.inst#16">temp.inst</A>] paragraph 16 as follows:</P>

<BLOCKQUOTE>

There is an implementation-defined quantity that specifies the limit
on the total depth of recursive instantiations
(Clause Annex B [<A href="https://wg21.link/implimits">implimits</A>]), which could involve more than one
template. <DEL>The result of an infinite recursion in instantiation is
undefined.</DEL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="293"></A><H4>293.
  
Syntax of explicit instantiation/specialization too permissive
</H4>
<B>Section: </B>13.9.3&#160; [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]
 &#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>13.9.3 [<A href="https://wg21.link/temp.explicit">temp.explicit</A>] 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 13.9.4 [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]:</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>13.9.3&#160; [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]
 &#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 13.9.3 [<A href="https://wg21.link/temp.explicit#10">temp.explicit</A>] 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="3006"></A><H4>3006.
  
Vague restrictions for explicit instantiations of class templates
</H4>
<B>Section: </B>13.9.3&#160; [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2021-02-11<BR>




<P>Consider:</P>

<PRE>
  template&lt;typename T&gt; struct X { };

  extern template struct X&lt;int&gt;;       //<SPAN CLASS="cmnt"> OK</SPAN>
  extern template struct X&lt;int&gt;::X;    //<SPAN CLASS="cmnt"> well-formed explicit instantiation of </SPAN>X&lt;int&gt;<SPAN CLASS="cmnt"> ?</SPAN>
</PRE>

<P>At issue is the phrasing "shall include" in
13.9.3 [<A href="https://wg21.link/temp.explicit#4">temp.explicit</A>] paragraph 4:</P>

<BLOCKQUOTE>

If the explicit instantiation is for a class or member class,
the <I>elaborated-type-specifier</I> in the declaration shall include
a <I>simple-template-id</I>; otherwise, the declaration shall be
a <I>simple-declaration</I> whose <I>init-declarator-list</I>
comprises a single <I>init-declarator</I> that does not have an
<I>initializer</I>. ...

</BLOCKQUOTE>

<P>Furthermore, explicit instantiations with
a <I>nested-name-specifier</I> do not seem to be declarative.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 13.9.3 [<A href="https://wg21.link/temp.explicit#4">temp.explicit</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

If the <INS><I>declaration</I> in an</INS> explicit instantiation
is <INS>an <I>elaborated-type-specifier</I>, it shall be of the
form</INS>
<PRE class="ins">
<I>class-key</I> <I>nested-name-specifier</I><SUB>opt</SUB> template<SUB>opt</SUB> <I>simple-template-id</I>
</PRE>
<INS>and the explicit instantiation is</INS> for a class
<INS>template</INS> <DEL>or member class, the
<I>elaborated-type-specifier</I> in the declaration shall include
a <I>simple-template-id</I></DEL>; otherwise, the declaration shall be
a <I>simple-declaration</I> whose <I>init-declarator-list</I>
comprises a single <I>init-declarator</I> that does not have an
<I>initializer</I>. ...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 7.5.5.3 [<A href="https://wg21.link/expr.prim.id.qual#2">expr.prim.id.qual</A>] paragraph 2 as follows:</P>

<BLOCKQUOTE>

A <I>nested-name-specifier</I> is declarative if it is part of
<UL>
<LI>a <I>class-head-name</I> <INS>(11.1 [<A href="https://wg21.link/class.pre">class.pre</A>])</INS>,</LI>
<LI>an <I>enum-head-name</I> <INS>(9.8.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>])</INS>,</LI>
<LI>a <I>qualified-id</I> that is the <I>id-expression</I> of
a <I>declarator-id</I> <INS>(9.3.1 [<A href="https://wg21.link/dcl.decl.general">dcl.decl.general</A>])</INS>,
<DEL>or</DEL>
</LI>
<LI class="ins">an <I>elaborated-type-specifier</I> of an explicit
instantiation (13.9.3 [<A href="https://wg21.link/temp.explicit">temp.explicit</A>]), or</LI>
<LI>a declarative <I>nested-name-specifier</I>.</LI>
</UL>

</BLOCKQUOTE>
</LI>
</OL>

<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>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>16 August 2005<BR>


<P>Paragraph 17 of 13.9.4 [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>] 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 13.9.4 [<A href="https://wg21.link/temp.expl.spec#17">temp.expl.spec</A>] 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 <DEL>that is explicitly specialized</DEL>
<INS>specialization</INS>. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Change 13.9.4 [<A href="https://wg21.link/temp.expl.spec#18">temp.expl.spec</A>] 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, <DEL>except that the declaration shall not explicitly
specialize a class member template if its enclosing class templates
are not explicitly specialized as well</DEL> <INS>that is, the
<I>template-id</I> naming the template may be composed of template
parameter names rather than <I>template-argument</I>s</INS>. <DEL>In</DEL>
<INS>For each unspecialized template in</INS> such <INS>an</INS> 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 <DEL>explicit
specialization</DEL> 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. <INS>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.</INS> [<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 arguments 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 13.9.4 [<A href="https://wg21.link/temp.expl.spec#17">temp.expl.spec</A>] 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
<DEL>that is explicitly specialized</DEL>
<INS>specialization</INS>. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Change 13.9.4 [<A href="https://wg21.link/temp.expl.spec#18">temp.expl.spec</A>] 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, <DEL>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.</DEL> <INS>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.</INS>
[<I>Example:</I>...

</BLOCKQUOTE>

</OL>

<BR><BR><HR>
<A NAME="1993"></A><H4>1993.
  
Use of <TT>template&lt;&gt;</TT> defining member of explicit specialization
</H4>
<B>Section: </B>13.9.4&#160; [<A href="https://wg21.link/temp.expl.spec">temp.expl.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

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




<P>
<A HREF="cwg_defects.html#531">Issue 531</A> surveyed existing practice at
the time and determined that the most common syntax for defining a member
of an explicit specialization used the <TT>template&lt;&gt;</TT>
prefix.  This approach, however, does not seem consistent, since such
a definition is not itself an explicit specialization.</P>



<BR><BR><HR>
<A NAME="264"></A><H4>264.
  
Unusable template constructors and conversion functions
</H4>
<B>Section: </B>13.10.2&#160; [<A href="https://wg21.link/temp.arg.explicit">temp.arg.explicit</A>]
 &#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 13.10.2 [<A href="https://wg21.link/temp.arg.explicit">temp.arg.explicit</A>] 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="697"></A><H4>697.
  
Deduction rules apply to more than functions
</H4>
<B>Section: </B>13.10.3&#160; [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 &#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>13.10.3 [<A href="https://wg21.link/temp.deduct">temp.deduct</A>] 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 13.7.6.2 [<A href="https://wg21.link/temp.spec.partial.match#2">temp.spec.partial.match</A>] paragraph 2, argument
deduction is used to determine whether a given partial specialization
matches a given argument list.  However, there is nothing in
13.7.6.2 [<A href="https://wg21.link/temp.spec.partial.match">temp.spec.partial.match</A>] nor in 13.10.3 [<A href="https://wg21.link/temp.deduct">temp.deduct</A>] 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="1844"></A><H4>1844.
  
Defining &#8220;immediate context&#8221;
</H4>
<B>Section: </B>13.10.3&#160; [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-01-28
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>The handling of an example like</P>

<PRE>
  template&lt;typename T, std::size_t S = sizeof(T)&gt; struct X {};
  template&lt;typename T&gt; X&lt;T&gt; foo(T*);
  void foo(...);

  void test() { struct S *s; foo(s); }
</PRE>

<P>varies among implementations, presumably because the meaning of
&#8220;immediate context&#8221; in determining whether an error is
a substitution failure or a hard error is not clearly defined.</P>

<P><B>Notes from the February, 2016 meeting:</B></P>

<P>See also <A HREF="cwg_active.html#1554">issue 1554</A>; the resolution
of this issue should also deal with alias templates.</P>

<P><B>CWG 2024-06-28</B></P>

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

<BR><BR><HR>
<A NAME="2296"></A><H4>2296.
  
Are default argument instantiation failures in the &#8220;immediate context&#8221;?
</H4>
<B>Section: </B>13.10.3&#160; [<A href="https://wg21.link/temp.deduct">temp.deduct</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-06-25
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>


<P>Consider the following example (taken from issue 3 of paper
P0348R0):</P>

<PRE>
  template &lt;typename U&gt; void fun(U u = U());

  struct X {
    X(int) {}
  };

  template &lt;class T&gt; decltype(fun&lt;T&gt;()) g(int) { }

  template&lt;&gt; void g(long) { }

  int main() { g&lt;X&gt;(0); }
</PRE>

<P>When is the substitution into the return type done? The current
specification makes this example ill-formed because the failure
to instantiate the default argument in the <TT>decltype</TT> operand
is not in the immediate context of the substitution, although a plausible
argument for making this a SFINAE case can be made.</P>

<P><B>Notes from the June, 2016 meeting:</B></P>

<P>CWG decided to refer this question to EWG for their consideration.</P>

<P><B>EWG 2022-11-11</B></P>

<P>This is tracked in github issue
<A HREF="https://github.com/cplusplus/papers/issues/1377">cplusplus/papers#1377</A>.

See also paper P2285 (Are default function arguments in the immediate context?), tracked by github issue
<A HREF="https://github.com/cplusplus/papers/issues/976">cplusplus/papers#976</A>.</P>

<P><B>CWG 2024-06-28</B></P>

<P>See also issues <A HREF="cwg_active.html#1554">1554</A> and
<A HREF="cwg_active.html#1844">1844</A> for other cases of missing clarity for
"immediate context".</P>

<BR><BR><HR>
<A NAME="2498"></A><H4>2498.
  
Partial specialization failure and the immediate context
</H4>
<B>Section: </B>13.10.3.1&#160; [<A href="https://wg21.link/temp.deduct.general">temp.deduct.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2021-06-15<BR>


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

<PRE>
  template&lt;typename T, typename U&gt; struct S {};
  template&lt;typename T&gt; struct S&lt;T, T&gt; {};
  template&lt;typename T, typename U&gt; struct S&lt;T*, U*&gt; {};
  template&lt;typename... Ts&gt; using V = void;
  template&lt;typename T, typename U = void&gt; struct X {};
  template&lt;typename T&gt; struct X&lt;T, V&lt;typename S&lt;T, T&gt;::type&gt;&gt;;
  X&lt;int*&gt; xpi;
</PRE>

<P>Determining whether the partial specialization
of <TT>X</TT> matches <TT>X&lt;int*&gt;</TT> requires
determining whether one of the partial specializations
of <TT>S</TT> matches <TT>S&lt;int*,int*&gt;</TT>. The
partial specializations of <TT>S</TT> are ambiguous for this
case. The question is whether that ambiguity should be
considered in the &#8220;immediate context&#8221; of the
type (SFINAE) or whether it should result in a hard error.
There is implementation divergence on the handling of this
example.</P>

<P><B>Notes from the November, 2021 teleconference:</B></P>

<P>A similar example can be constructed involving overload
resolution instead of partial specialization:</P>

<PRE>
  template&lt;typename T, typename U&gt; struct S {};
  template&lt;typename T&gt; struct S&lt;T, T&gt; {};
  template&lt;typename T, typename U&gt; struct S&lt;T*, U*&gt; {};

  template&lt;class T&gt;
  bool f(T, typename S&lt;T, T&gt;::type = 0);
  bool f(...);

  int x;
  bool b = f(&amp;x);  //<SPAN CLASS="cmnt"> hard error with gcc, ok with clang</SPAN>
</PRE>

<BR><BR><HR>
<A NAME="2769"></A><H4>2769.
  
Substitution into template parameters and default template arguments should be interleaved
</H4>
<B>Section: </B>13.10.3.1&#160; [<A href="https://wg21.link/temp.deduct.general">temp.deduct.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-14<BR>




<P>Subclause 13.10.3.1 [<A href="https://wg21.link/temp.deduct.general#5">temp.deduct.general</A>] paragraph 5 specifies:</P>

<BLOCKQUOTE>

If a template argument has not been deduced and its corresponding
template parameter has a default argument, the template argument is
determined by substituting the template arguments determined for
preceding template parameters into the default argument. ... 
When all template arguments have been deduced or obtained from default
template arguments, all uses of template parameters in the template
parameter list of the template are replaced with the corresponding
deduced or default argument values.

</BLOCKQUOTE>

<P>This description is confused.  We need to have already substituted
into the template parameter declaration in order to finish forming a
template argument, and we need to finish forming a template argument
before we can substitute it into a later default template argument.
Consider:</P>

<PRE>
  struct X { constexpr operator int() { return 0; } };
  template&lt;const int*&gt; struct Y {};
  extern int arr[];
  template&lt;typename T, T K = X(), const int *p = &amp;arr[K], Y&lt;p&gt; y = {}&gt; struct A {};
  A&lt;int&gt; a;
</PRE>

<P>Here, we need to substitute <TT>T = int</TT> into the type
of <TT>K</TT>, then convert the default template argument <TT>X()</TT>
to <TT>int</TT>, then substitute the converted value of <TT>p</TT>
into the type of <TT>y</TT>.  The substitution into template
parameters and into default template arguments is necessarily
interleaved.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 13.10.3.1 [<A href="https://wg21.link/temp.deduct.general#5">temp.deduct.general</A>] paragraph 5 as follows:</P>

<BLOCKQUOTE>

The resulting substituted and adjusted function type is used as the
type of the function template for template argument deduction.
<INS>For each template parameter in turn:</INS>

<UL>
<LI class="ins">If a template argument has not been deduced and the
template parameter is a parameter pack, the template argument is an
empty pack.</LI>

<LI>
<INS>Otherwise,</INS> <DEL>If</DEL> <INS>if</INS> a template argument has
not been deduced <DEL>and its corresponding template parameter has a
default argument</DEL>, the template argument is determined by
substituting the template arguments determined for preceding template
parameters into the default argument. If <INS>the template parameter
does not have a default template argument, or if</INS> the
substitution results in an invalid type, as described above, type
deduction fails. [ Example: ... ]
</LI>

<LI>
<DEL>When all template arguments have been deduced or obtained from
default template arguments, all uses of template parameters in the
template parameter list of the template are replaced with the
corresponding deduced or default argument values.</DEL> <INS>The
substituted template parameter is determined by substituting the
template arguments determined for preceding template parameters into
the template parameter.</INS> If the substitution results in an
invalid type, as described above, type deduction fails.</LI>

<LI class="ins">
The template argument is matched against the substituted template
parameter (13.4.1 [<A href="https://wg21.link/temp.arg.general">temp.arg.general</A>]). If the template argument does not
match the substituted template parameter, type deduction fails. [
Note: Matching a template argument to a non-type template parameter
may perform a conversion. The converted value is used for later
substitutions. -- end note ]
</LI>

</UL>

If the function template has associated constraints
(13.5.3 [<A href="https://wg21.link/temp.constr.decl">temp.constr.decl</A>]), those constraints are checked for
satisfaction (13.5.2 [<A href="https://wg21.link/temp.constr.constr">temp.constr.constr</A>]).  ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2770"></A><H4>2770.
  
Trailing <I>requires-clause</I> can refer to function parameters before they are substituted into
</H4>
<B>Section: </B>13.10.3.1&#160; [<A href="https://wg21.link/temp.deduct.general">temp.deduct.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2023-07-14<BR>




<P>After the application of <A HREF="cwg_defects.html#2369">issue 2369</A>,
satisfaction for a trailing <I>requires-clause</I> is checked prior to
substitution into the function type.  Subclause
13.10.3.1 [<A href="https://wg21.link/temp.deduct.general#5">temp.deduct.general</A>] paragraph 5 specifies:</P>

<BLOCKQUOTE>

If the function template has associated constraints
(13.5.3 [<A href="https://wg21.link/temp.constr.decl">temp.constr.decl</A>]), those constraints are checked for
satisfaction (13.5.2 [<A href="https://wg21.link/temp.constr.constr">temp.constr.constr</A>]). ...  If type deduction has
not yet failed, then all uses of template parameters in the function
type are replaced with the corresponding deduced or default argument
values.

</BLOCKQUOTE>

<P>However, the associated constraints can refer to parameters, thus
substitution into the parameter types must have been already done at
the time of checking.  Consider:</P>

<PRE>
  template&lt;typename T&gt; void f(T t) requires (sizeof(t) == 5) {}
</PRE>

<P><U>Suggested resolution:</U></P>

<P>Function parameters should be instantiated when they are needed by
a satisfaction check of an atomic constraint or (recursively) by
another function parameter.</P>

<BR><BR><HR>
<A NAME="503"></A><H4>503.
  
Cv-qualified function types in template argument deduction
</H4>
<B>Section: </B>13.10.3.2&#160; [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]
 &#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, 13.10.3.2 [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>] 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>

<P>(See also <A HREF="cwg_active.html#1584">issue 1584</A>.)</P>
<BR><BR><HR>
<A NAME="1939"></A><H4>1939.
  
Argument conversions to nondeduced parameter types revisited
</H4>
<B>Section: </B>13.10.3.2&#160; [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-06-11<BR>


<P>The intent of the resolution of <A HREF="cwg_defects.html#1184">issue 1184</A> appears not to have been completely realized.  In
particular, the phrase, &#8220;contains
no <I>template-parameter</I>s that participate in template
argument deduction&#8221; in both the note in
13.10.3.2 [<A href="https://wg21.link/temp.deduct.call#4">temp.deduct.call</A>] paragraph 4 and the normative
wording in 13.10.2 [<A href="https://wg21.link/temp.arg.explicit#6">temp.arg.explicit</A>] paragraph 6 is potentially
misleading and probably should say something like,
&#8220;contains no <I>template-parameter</I>s outside non-deduced
contexts.&#8221; Also, the normative wording should be moved to
13.10.3.2 [<A href="https://wg21.link/temp.deduct.call#4">temp.deduct.call</A>] paragraph 4, since it applies when
there are no explicitly-specified template arguments.  For
example,</P>

<PRE>
  template&lt;typename T&gt;
  void f(T, typename identity&lt;T&gt;::type*);
</PRE>

<P>Presumably the second parameter should allow pointer conversions,
even though it does contain a <I>template-parameter</I> that
participates in deduction (via the first function parameter).</P>

<P><B>Additional note, October, 2015:</B></P>



<P>See also <A HREF="cwg_defects.html#1391">issue 1391</A>.</P>

<BR><BR><HR>
<A NAME="2978"></A><H4>2978.
  
Deduction involving reference to similar types
</H4>
<B>Section: </B>13.10.3.2&#160; [<A href="https://wg21.link/temp.deduct.call">temp.deduct.call</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Brian Bi
 &#160;&#160;&#160;

 <B>Date: </B>2024-12-11<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/651">#651</A>.)
</P>

<P>Consider:</P>

<PRE>
  #include &lt;cstddef&gt;

  template &lt;std::size_t N&gt;
  void f(const int* const (&amp;)[N]);

  int main() {
    int* a[3];
    f(a);
  }
</PRE>

<P>There is implementation divergence.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 13.10.3.2 [<A href="https://wg21.link/temp.deduct.call#4.1">temp.deduct.call</A>] bullet 4.1 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>If the original P is a reference type, the deduced A (i.e., the
type referred to by the reference) can be <DEL>more cv-qualified
than</DEL> <INS>a type similar to the transformed A that is
reference-compatible with</INS> the transformed A.</LI>
<LI>...</LI>
</UL>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1221"></A><H4>1221.
  
Partial ordering and reference collapsing
</H4>
<B>Section: </B>13.10.3.5&#160; [<A href="https://wg21.link/temp.deduct.partial">temp.deduct.partial</A>]
 &#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="2998"></A><H4>2998.
  
Missing deduction consistency check for partial ordering
</H4>
<B>Section: </B>13.10.3.5&#160; [<A href="https://wg21.link/temp.deduct.partial">temp.deduct.partial</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2025-03-02<BR>




<P>Consider <A HREF="cwg_active.html#2160">issue 2160</A>, first part:</P>

<PRE>
   template &lt;typename T&gt; void foo(T, T); //<SPAN CLASS="cmnt"> (1)</SPAN>
   template &lt;typename T, typename U&gt; void foo(T, U); //<SPAN CLASS="cmnt"> (2)</SPAN>
</PRE>

<P>Partial ordering is describing as pairwise (but otherwise
independent) P/A matching, missing a check that the deduced values for
the various Ps must be consistent per 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#2">temp.deduct.type</A>] paragraph 2.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 13.10.3.5 [<A href="https://wg21.link/temp.deduct.partial#8">temp.deduct.partial</A>] paragraph 8 as follows:</P>

<BLOCKQUOTE>

Using the <INS>set of pairs formed from the corresponding</INS>
resulting types P and A, the deduction is then done as described in
13.10.3.6 [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]. If P is a function parameter pack, the
type A of each remaining parameter type of the argument template is
compared with the type P of the <I>declarator-id</I> of the function
parameter pack. Each comparison deduces template arguments for
subsequent positions in the template parameter packs expanded by the
function parameter pack. Similarly, if A was transformed from a
function parameter pack, it is compared with each remaining parameter
type of the parameter template. If deduction succeeds for a given
type, the type from the argument template is considered to be at least
as specialized as the type from the parameter template.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1763"></A><H4>1763.
  
Length mismatch in template type deduction
</H4>
<B>Section: </B>13.10.3.6&#160; [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2013-09-23<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3903.html#CA4">N3690 comment
  CA&#160;4<BR></A>

<P>It is not clear how an example like the following is to be handled:</P>

<PRE>
  template &lt;typename U&gt;
  struct A {
    template &lt;typename V&gt; operator A&lt;V&gt;();
  };

  template &lt;typename T&gt;
  void foo(A&lt;void (T)&gt;);

  void foo();

  int main() {
    A&lt;void (int, char)&gt; a;
    foo&lt;int&gt;(a);
    foo(a); //<SPAN CLASS="cmnt"> deduces </SPAN>T<SPAN CLASS="cmnt"> to be </SPAN>int
  }
</PRE>

<P>In sub13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#10">temp.deduct.type</A>] paragraph 10, deduction from
a function type considers P/A pairs from the parameter-type-list only where
the "P" function type has a parameter.  Deduction is not specified to fail
if there are additional parameters in the corresponding "A" function
type.</P>

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

<P>CWG agreed that this example should not be accepted.  The existing
rules seem to cover this case (deduction is not specified to
&#8220;succeed,&#8221; so it's a reasonable conclusion that it fails),
but it might be helpful to be clearer.</P>

<BR><BR><HR>
<A NAME="2900"></A><H4>2900.
  
Deduction of non-type template arguments with placeholder types
</H4>
<B>Section: </B>13.10.3.6&#160; [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2024-06-05<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/546">#546</A>.)</P>

<P>The deduction rule for non-type template parameters in
13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#20">temp.deduct.type</A>] paragraph 20seems lacking:</P>

<BLOCKQUOTE>

If P has a form that contains &lt;i&gt;, and if the type of i differs
from the type of the corresponding template parameter of the template
named by the enclosing <I>simple-template-id</I>, deduction fails. If
P has a form that contains [i], and if the type of i is not an
integral type, deduction fails. [ Footnote: ... ] ...

</BLOCKQUOTE>

<P>This wording does not address the situation when the declared type
of <TT>i</TT> is a placeholder type, or when the type of the
corresponding template parameter of the template named by the
enclosing <I>simple-template-id</I> is a placeholder type.</P>

<P><U>Suggested resolution:</U></P>

<P>Change in 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#20">temp.deduct.type</A>] paragraph 20 as follows:</P>

<BLOCKQUOTE>

If P has a form that contains &lt;i&gt;,
<DEL>and if the type of i differs from the type</DEL>
<INS>deduction fails unless the type of <TT>i</TT> is the same as that</INS>
of the corresponding template parameter <INS><TT>p</TT> in the
specialization (from A)</INS> of the template named by the
enclosing <I>simple-template-id</I><DEL>, deduction fails</DEL> <INS>; if
the declared type of <TT>i</TT> contains a placeholder type, the
corresponding template argument for the purposes of placeholder type
deduction (9.2.9.7.2 [<A href="https://wg21.link/dcl.type.auto.deduct">dcl.type.auto.deduct</A>]) is an <I>id-expression</I>
for <TT>p</TT></INS>.  If P has a form that contains [i], and if the
type of i is not an integral type, deduction fails. [ Footnote: ... ]
...  [ Example 13:
<PRE>
  template&lt;int i&gt; class A { /* ... */ };
  template&lt;short s&gt; void f(A&lt;s&gt;);
  void k1() {
    A&lt;1&gt; a;
    f(a);      //<SPAN CLASS="cmnt"> error: deduction fails for conversion from int to short</SPAN>
    f&lt;1&gt;(a);   //<SPAN CLASS="cmnt"> OK</SPAN>
  }
  template&lt;const short cs&gt; class B { };
  template&lt;short s&gt; void g(B&lt;s&gt;);
  void k2() {
    B&lt;1&gt; b;
    g(b);  //<SPAN CLASS="cmnt"> OK, cv-qualifiers are ignored on template parameter types</SPAN>
  }
<P class="ins">
  template&lt;auto&gt; struct C;
  template&lt;long long x&gt; void f(C&lt;x&gt; *);
  void g(C&lt;0LL&gt; *ap) {
    f(ap);     //<SPAN CLASS="cmnt"> OK, deduces </SPAN>long long<SPAN CLASS="cmnt"> value from </SPAN>0LL
  }

  template&lt;int&gt; struct D;
  template&lt;auto x&gt; void f(D&lt;x&gt; *);
  void g(D&lt;0LL&gt; *ap) {
    f(ap);   //<SPAN CLASS="cmnt"> OK, deduces </SPAN>x<SPAN CLASS="cmnt"> as an </SPAN>int<SPAN CLASS="cmnt"> value</SPAN>
  }

  template&lt;int &amp;&gt; struct E;
  template&lt;auto x&gt; void f(E&lt;x&gt; *);
  int v;
  void g(E&lt;v&gt; *bp) {
    f(bp);    //<SPAN CLASS="cmnt"> error: type </SPAN>int<SPAN CLASS="cmnt"> of </SPAN>x<SPAN CLASS="cmnt"> does not match the </SPAN>int &amp;<SPAN CLASS="cmnt"> type of the template parameter in the </SPAN>E&lt;v&gt;<SPAN CLASS="cmnt"> specialization of </SPAN>E
  }

  template&lt;const int &amp;&gt; struct F;
  template&lt;decltype(auto) x&gt; void f(F&lt;x&gt; *);
  int i;
  void g(F&lt;i&gt; *ap) {
    f(ap);   //<SPAN CLASS="cmnt"> OK, deduces </SPAN>x<SPAN CLASS="cmnt"> as a non-type template parameter of type </SPAN>const int &amp;
  }

  template &lt;decltype(auto)&gt; struct G;
  template &lt;auto x&gt; long *f(G&lt;x&gt; *);   //<SPAN CLASS="cmnt"> #1</SPAN>
  template &lt;decltype(auto) x&gt; short *f(G&lt;x&gt; *); //<SPAN CLASS="cmnt"> #2</SPAN>

  const int j = 0;
  short *g(G&lt;(j)&gt; *ap) {
    return f(ap);     //<SPAN CLASS="cmnt"> OK, only #2 matches</SPAN>
  }

  long *g(G&lt;j&gt; *ap) {
    return f(ap);     //<SPAN CLASS="cmnt"> OK, #1 is more specialized</SPAN>
  }
</P>
</PRE>
-- end example]
</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2974"></A><H4>2974.
  
Non-deduced context for <I>qualified-id</I> naming a template
</H4>
<B>Section: </B>13.10.3.6&#160; [<A href="https://wg21.link/temp.deduct.type">temp.deduct.type</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2024-12-27<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/660">#660</A>.)
</P>

<P>Subclause 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#5.1">temp.deduct.type</A>] bullet 5.1 specifies as
a non-deduced context:</P>

<BLOCKQUOTE>

<UL>
<LI>The <I>nested-name-specifier</I> of a type that was specified
using a <I>qualified-id</I>.</LI>

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

</BLOCKQUOTE>

<P>This does not cover templates named using a <I>qualified-id</I>:</P>

<PRE>
  template &lt;template &lt;typename&gt; class&gt;
  struct B;

  struct C {
    template &lt;typename&gt;
    struct Nested;
  };

  template &lt;typename T&gt;
  void f(T *, B&lt;T::template Nested&gt; *);

  void g(C *cp) {
    f(cp, 0);           //<SPAN CLASS="cmnt"> should be OK</SPAN>
  }
</PRE>

<P><U>Suggested resolution:</U></P>

<P>Change in 13.10.3.6 [<A href="https://wg21.link/temp.deduct.type#5.1">temp.deduct.type</A>] bullet 5.1 as follows:</P>

<BLOCKQUOTE>

<UL>
<LI>The <I>nested-name-specifier</I> of a type <INS>or template</INS>
that was specified using a <I>qualified-id</I>.</LI>

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

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="2417"></A><H4>2417.
  
Explicit instantiation and exception specifications
</H4>
<B>Section: </B>14.5&#160; [<A href="https://wg21.link/except.spec">except.spec</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

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


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

<PRE>
  template&lt;class T&gt;struct Y {
    typedef typename T::value_type blah;  //<SPAN CLASS="cmnt"> #1</SPAN>
    void swap(Y&lt;T&gt; &amp;);
  };
  template&lt;class T&gt;
  void swap(Y&lt;T&gt;&amp; Left, Y&lt;T&gt;&amp; Right) noexcept(noexcept(Left.swap(Right))) { }

  template &lt;class T&gt; struct Z {
    void swap(Z&lt;T&gt; &amp;);
  };
  template&lt;class T&gt;
  void swap(Z&lt;T&gt;&amp; Left, Z&lt;T&gt;&amp; Right) noexcept(noexcept(Left.swap(Right))) { }

  Z&lt;int&gt; x00, y00;
  constexpr bool b00 = noexcept(x00.swap(y00));
  template void swap&lt;int&gt;(Z&lt;int&gt;&amp;, Z&lt;int&gt;&amp;) noexcept(b00);  //<SPAN CLASS="cmnt"> #2</SPAN>
</PRE>

<P>The question here is whether the explicit instantiation of</P>

<PRE>
  swap&lt;int&gt;(Z&lt;int&gt;&amp;, Z&lt;int&gt;&amp;)
</PRE>

<P>at #2 instantiates the exception specification of</P>

<PRE>
  swap&lt;int&gt;(Y&lt;int&gt;&amp;, Y&lt;int&gt;&amp;)
</PRE>

<P>which would instantiate <TT>Y&lt;int&gt;</TT>, resulting
in an error on the declaration of</P>

<PRE>
  typedef typename T::value_type blah;
</PRE>

<P>at #1.</P>

<P>According to 13.9.2 [<A href="https://wg21.link/temp.inst#14">temp.inst</A>] paragraph 14,</P>

<BLOCKQUOTE>

The <I>noexcept-specifier</I> of a function template
specialization is not instantiated along with the function
declaration; it is instantiated when needed
(14.5 [<A href="https://wg21.link/except.spec">except.spec</A>]).

</BLOCKQUOTE>

<P>According to 14.5 [<A href="https://wg21.link/except.spec#13.3">except.spec</A>] bullet 13.3, one
of the reasons an exception specification is needed is:</P>

<BLOCKQUOTE>

the exception specification is compared to that of another
declaration (e.g., an explicit specialization or an
overriding virtual function);

</BLOCKQUOTE>

<P>Such a comparison is presumably needed when determining
which function template the explicit instantiation is
referring to, making the program ill-formed. However, there is
implementation variance on this point.</P>

<P><B>CWG 2022-11-10</B></P>

<P>There are related problems in this area; CWG is seeking input to
form a holistic view.</P>

<BR><BR><HR>
<A NAME="2002"></A><H4>2002.
  
White space within preprocessing directives
</H4>
<B>Section: </B>15.1&#160; [<A href="https://wg21.link/cpp.pre">cpp.pre</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2014-09-10
  &#160;&#160;&#160;
  <B>Liaison: </B>WG14<BR>




<P>According to 15.1 [<A href="https://wg21.link/cpp.pre">cpp.pre</A>] paragraph 5,</P>

<BLOCKQUOTE>

The only white-space characters that shall appear between
preprocessing tokens within a preprocessing directive (from
just after the introducing <TT>#</TT> preprocessing token through
just before the terminating new-line character) are space
and horizontal-tab (including spaces that have replaced
comments or possibly other white-space characters in
translation phase 3).

</BLOCKQUOTE>

<P>The effect of this restriction is unclear, however, since
translation phase 3 is permitted to transform all white space
characters and comments into spaces.  The relationship between
these two rules should be clarified.</P>

<BR><BR><HR>
<A NAME="925"></A><H4>925.
  
Type of character literals in preprocessor expressions
</H4>
<B>Section: </B>15.2&#160; [<A href="https://wg21.link/cpp.cond">cpp.cond</A>]
 &#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 15.2 [<A href="https://wg21.link/cpp.cond#12">cpp.cond</A>] paragraph 12,</P>

<BLOCKQUOTE>

The resulting tokens comprise the controlling constant expression
which is evaluated according to the rules of 7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]
using arithmetic that has at least the ranges specified in
17.3 [<A href="https://wg21.link/support.limits">support.limits</A>], 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 [<A href="https://wg21.link/stdinth">stdinth</A>]).
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 7.3.7 [<A href="https://wg21.link/conv.prom#1">conv.prom</A>] 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>, 15.2 [<A href="https://wg21.link/cpp.cond#12">cpp.cond</A>] paragraph 12 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="1436"></A><H4>1436.
  
Interaction of constant expression changes with preprocessor expressions
</H4>
<B>Section: </B>15.2&#160; [<A href="https://wg21.link/cpp.cond">cpp.cond</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-01-02<BR>




<P>It appears that some of the recent changes to the description of
constant expressions have allowed constructs into preprocessor
expressions that do not belong there.  Some changes are required to
restrict the current capabilities of constant expressions to what
is intended to be allowed in preprocessor expressions.</P>

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

<OL>
<LI><P>Change 15.2 [<A href="https://wg21.link/cpp.cond#8">cpp.cond</A>] paragraph 8 as follows:</P></LI>

<BLOCKQUOTE>

Each preprocessing token that remains (in the list of preprocessing
tokens that will become the controlling expression) after all macro
replacements have occurred shall be in the lexical form of a token
(5.10 [<A href="https://wg21.link/lex.token">lex.token</A>]). <INS>Any such token that is a literal
(5.13.1 [<A href="https://wg21.link/lex.literal.kinds">lex.literal.kinds</A>]) shall be an <I>integer-literal</I>, a
<I>character-literal</I>, or a <I>boolean-literal</I>.</INS>

</BLOCKQUOTE>

<LI><P>Change 15.2 [<A href="https://wg21.link/cpp.cond#12">cpp.cond</A>] paragraph 12 as follows:</P></LI>

<BLOCKQUOTE>

...using arithmetic that has at least the ranges specified in
17.3 [<A href="https://wg21.link/support.limits">support.limits</A>]. <INS>The only operators permitted in the
controlling constant expression are <TT>?:</TT>, <TT>||</TT>,
<TT>&amp;&amp;</TT>, <TT>|</TT>, <TT>^</TT>, <TT>&amp;</TT>,
<TT>==</TT>, <TT>!=</TT>, <TT>&lt;</TT>, <TT>&lt;=</TT>,
<TT>&gt;</TT>, <TT>&gt;=</TT>, <TT>&lt;&lt;</TT>, <TT>&gt;&gt;</TT>,
<TT>-</TT>, <TT>+</TT>, <TT>*</TT>, <TT>/</TT>, <TT>%</TT>,
<TT>!</TT>, and <TT>~</TT>.</INS> For the purposes of this token
conversion...

</BLOCKQUOTE>

</OL>

<P><B>Additional note (March, 2022):</B></P>

<P>The proposed resolution shown above allows
<I>lambda-expression</I>s, which is undesirable.</P>

<P><B>CWG 2022-11-11</B></P>

<P>A possible approach, in addition to the proposed resolution above,
is to prohibit the <TT>[</TT> and <TT>{</TT> <I>pp-token</I>s in the
controlling expression of a conditional inclusion. C++ also permits
using the alternative tokens, e.g. <TT>not</TT>, which might need
clarification in the wording.</P>

<P><B>Additional notes (May, 2025)</B></P>

<P>See also <A HREF="cwg_active.html#3017">issue 3017</A> for comma operators
in the controlling expression of a conditional inclusion.</P>

<P><B>Additional notes (August, 2025)</B></P>

<P>See also submission
<A HREF="https://github.com/cplusplus/CWG/issues/735">#735</A>
for the <TT>&lt;=&gt;</TT> operator.</P>

<BR><BR><HR>
<A NAME="2190"></A><H4>2190.
  
Insufficient specification of <TT>__has_include</TT>
</H4>
<B>Section: </B>15.2&#160; [<A href="https://wg21.link/cpp.cond">cpp.cond</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2015-10-24<BR>




<P>The following example ought to be well-formed,
but the standard is insufficiently clear:</P>

<PRE>
  #define X &lt;ciso646&gt; )

  #if __has_include( X &amp;&amp; ( defined(X) )
  #endif
</PRE>

<P>Also, there is insufficient prohibition for the formation of
<TT>__has_include</TT> by token pasting when performing macro
replacement for the controlling expression of a conditional
inclusion.</P>

<BR><BR><HR>
<A NAME="2575"></A><H4>2575.
  
Undefined behavior when macro-replacing "defined" operator
</H4>
<B>Section: </B>15.2&#160; [<A href="https://wg21.link/cpp.cond">cpp.cond</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2019-10-23
  &#160;&#160;&#160;
  <B>Liaison: </B>SG12<BR>


<P>(From National Body comment US 130 on the C++20 DIS.)</P>

<P>Subclause 15.2 [<A href="https://wg21.link/cpp.cond#10">cpp.cond</A>] paragraph 10 specifies:</P>

<BLOCKQUOTE>

If the token <TT>defined</TT> is generated as a result of this
replacement process or use of the <TT>defined</TT> unary operator does
not match one of the two specified forms prior to macro replacement,
the behavior is undefined.

</BLOCKQUOTE>

<P>Undefined behavior during lexing is not acceptable. The behavior
ought to be well-defined, ill-formed, or conditionally-supported.</P>

<P><B>Additional notes (January, 2023):</B></P>

<P>Forwarded to SG12 with
<A HREF="https://github.com/cplusplus/papers/issues/1407">paper issue 1407</A>,
by decision of the CWG and SG12 chairs.
</P>

<BR><BR><HR>
<A NAME="3017"></A><H4>3017.
  
Commas in controlling expression of conditional inclusion
</H4>
<B>Section: </B>15.2&#160; [<A href="https://wg21.link/cpp.cond">cpp.cond</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Shafik Yaghmour
 &#160;&#160;&#160;

 <B>Date: </B>2025-03-24<BR>




<P>Consider:</P>

<PRE>
  #if 1 ? 1, 0: 3
  #error
  #endif
</PRE>

<P>Is this a well-formed translation unit?</P>

<P>According to 15.2 [<A href="https://wg21.link/cpp.cond#10">cpp.cond</A>] paragraph 10, C23 6.10.2
paragraph 3 and C23 6.6, the controlling expression is required to be
a syntactic <I>constant-expression</I> (7.7 [<A href="https://wg21.link/expr.const">expr.const</A>]).
(Concerns about C++ expressions vs. C expressions are handled via
<A HREF="cwg_active.html#1436">issue 1436</A>.)</P>

<P>However, implementations uniformly reject the example (gcc and
clang only in pedantic mode), because a comma operator appears in the
controlling expression.  There is no apparent normative basis for the
rejection.</P>

<P>Do all implementations have the same bug, or do both C and C++
share the same specification hole?</P>

<P><B>Additional notes (March, 2025)</B></P>

<P>Forwarded to SG22 via
<A HREF="https://github.com/cplusplus/papers/issues/2294">paper issue #2294</A>,
by decision of the CWG chair.</P>

<P><B>Additional notes (May, 2025)</B></P>

C23 specifies in its subclause 6.6 paragraph 3:

<BLOCKQUOTE>

Constant expressions shall not contain assignment, increment,
decrement, function-call, or comma operators, except when they are
contained within a subexpression that is not evaluated.

</BLOCKQUOTE>

<P>Thus, the behavior of C implementations for the example is actually
conforming.  The remaining C++ concerns are handled by
<A HREF="cwg_active.html#1436">issue 1436</A>.</P>
						
<BR><BR><HR>
<A NAME="2576"></A><H4>2576.
  
Undefined behavior with macro-expanded <TT>#include</TT> directives
</H4>
<B>Section: </B>15.3&#160; [<A href="https://wg21.link/cpp.include">cpp.include</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2019-10-23
  &#160;&#160;&#160;
  <B>Liaison: </B>SG12<BR>


<P>(From National Body comment US 131 on the C++20 DIS.)</P>

<P>Subclause 15.3 [<A href="https://wg21.link/cpp.include#4">cpp.include</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

If the directive resulting after all replacements does not match one
of the two previous forms, the behavior is undefined.

</BLOCKQUOTE>

<P>Undefined behavior during lexing is not acceptable. This ought to
be ill-formed.</P>

<P><B>Additional notes (January, 2023):</B></P>

<P>Forwarded to SG12 with
<A HREF="https://github.com/cplusplus/papers/issues/1408">paper issue 1408</A>,
by decision of the CWG and SG12 chairs.
</P>

<BR><BR><HR>
<A NAME="2947"></A><H4>2947.
  
Limiting macro expansion in <I>pp-module</I>
</H4>
<B>Section: </B>15.5&#160; [<A href="https://wg21.link/cpp.module">cpp.module</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2024-10-29<BR>




<P>Consider:</P>

<PRE>
  #define DOT_BAR .bar
  export module foo DOT_BAR;
</PRE>

<P>The current rules appear to make this valid, referring to
module <TT>foo.bar</TT> in phase 7.  This ought to be ill-formed to
align with the goal of keeping module directives parsable by simple
tools.</P>

<P><U>Possible resolution:</U></P>

<OL>
<LI>
<P>Change in 15.5 [<A href="https://wg21.link/cpp.module#1">cpp.module</A>] paragraph 1 as follows:</P>

<PRE>
  <I>pp-module</I>:
      export<SUB>opt</SUB> module <I>pp-tokens</I><SUB>opt</SUB> <DEL>;</DEL> <I>new-line</I>
</PRE>
</LI>

<LI>
<P>Delete 15.5 [<A href="https://wg21.link/cpp.module#3">cpp.module</A>] paragraph 3 as follows:</P>

<BLOCKQUOTE class="del">

Any preprocessing tokens after the module preprocessing token in the
module directive are processed just as in normal text.  [<I>Note
1:</I> Each identifier currently defined as a macro name is replaced
by its replacement list of preprocessing tokens.  &#8212;<I>end
note</I>]

</BLOCKQUOTE>
</LI>

<LI>
<P>Change in 15.5 [<A href="https://wg21.link/cpp.module#4">cpp.module</A>] paragraph 4 as follows:</P>

<BLOCKQUOTE>

The module and export (if it exists) preprocessing tokens are replaced
by the <I>module-keyword</I> and <I>export-keyword</I> preprocessing
tokens respectively.  [<I>Note:</I> This makes the line no longer a
directive so it is not removed at the end of phase 4. &#8212;<I>end
note</I>]

<INS>
After this replacement, the preprocessing tokens that constituted the
directive are a <I>text-line</I> and are processed as normal text.

[Note: No macro expansion is possible for the <I>pp-module-name</I> and
<I>pp-module-partition</I>. -- end note]

Processing the remainder of the input shall produce a <TT>;</TT>
or <TT>[</TT> preprocessing token following the <I>pp-module-name</I> and
optional <I>pp-module-partition</I>.
</INS>

</BLOCKQUOTE>

</LI>

<LI>
<P>Add 15.5 [<A href="https://wg21.link/cpp.module#5">cpp.module</A>] paragraph 5 with examples:</P>

<BLOCKQUOTE class="ins">
[ Example:
<PRE>
  #define DOT_BAR .bar
  export module foo DOT_BAR;   //<SPAN CLASS="cmnt"> error: expansion of </SPAN>DOT_BAR;<SPAN CLASS="cmnt"> does not begin with </SPAN>;<SPAN CLASS="cmnt"> or </SPAN>[
</PRE>
<P>-- end example ]</P>
<P>[ Example:</P>
<PRE>
  #define MOD_ATTR [[vendor::shiny_module]]
  export module M MOD_ATTR ;        // <SPAN CLASS="cmnt">OK</SPAN>
</PRE>
<P>-- end example ]</P>
<P>[ Example:</P>
<PRE>
  export module a
  .b;                         //<SPAN CLASS="cmnt"> error: preprocessing token after pp-module-name is not </SPAN>;<SPAN CLASS="cmnt"> or </SPAN>[
</PRE>
<P>-- end example ]</P>
<P>[ Example:</P>
<PRE>
  export module M [[
  attr1,
  attr2 ]] ;                 // <SPAN CLASS="cmnt">OK</SPAN>
</PRE>
<P>-- end example ]</P>
<P>[ Example:</P>
<PRE>
  export module M
  [[ attr1,
  attr2 ]] ;                 // <SPAN CLASS="cmnt">OK</SPAN>
</PRE>
<P>-- end example ]</P>
<P>[ Example:</P>
<PRE>
  export module M; int
  n;                         // <SPAN CLASS="cmnt">OK</SPAN>
</PRE>
<P>-- end example ]</P>
</BLOCKQUOTE>
</LI>
</OL>

<BR><BR><HR>
<A NAME="1718"></A><H4>1718.
  
Macro invocation spanning end-of-file
</H4>
<B>Section: </B>15.7&#160; [<A href="https://wg21.link/cpp.replace">cpp.replace</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-23
  &#160;&#160;&#160;
  <B>Liaison: </B>WG14<BR>


<P>Although it seems to be common implementation practice to reject
a macro invocation that begins in a header file and whose closing
right parenthesis appears in the file that included it, there does
not seem to be a prohibition of this case in the specification of
function-style macros.  Should this be accepted?</P>

<P><B>Notes from the February, 2014 meeting:</B></P>

<P>CWG agreed that macro invocations spanning file boundaries should be
prohibited.  Resolution of this issue should be coordinated with WG14.</P>

<BR><BR><HR>
<A NAME="2577"></A><H4>2577.
  
Undefined behavior for preprocessing directives in macro arguments
</H4>
<B>Section: </B>15.7.1&#160; [<A href="https://wg21.link/cpp.replace.general">cpp.replace.general</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2019-10-23
  &#160;&#160;&#160;
  <B>Liaison: </B>SG12<BR>


<P>(From National Body comment US 141 on the C++20 DIS.)</P>

<P>Subclause 15.7.1 [<A href="https://wg21.link/cpp.replace.general#13">cpp.replace.general</A>] paragraph 13 specifies:</P>

<BLOCKQUOTE>

If there are sequences of preprocessing tokens within the list of
arguments that would otherwise act as preprocessing directives, [
Footnote: ...] the behavior is undefined.

</BLOCKQUOTE>

<P>Undefined behavior during lexing is not acceptable. The behavior
ought to be ill-formed or conditionally-supported.  Some
implementation support an <TT>#if</TT> section, others reject
that.</P>

<P><B>Additional notes (January, 2023):</B></P>

<P>Forwarded to SG12 with
<A HREF="https://github.com/cplusplus/papers/issues/1413">paper issue 1413</A>,
by decision of the CWG and SG12 chairs.
</P>

<BR><BR><HR>
<A NAME="3053"></A><H4>3053.
  
Allowing <TT>#undef likely</TT>
</H4>
<B>Section: </B>15.7.1&#160; [<A href="https://wg21.link/cpp.replace.general">cpp.replace.general</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jakub Jelinek
 &#160;&#160;&#160;

 <B>Date: </B>2025-07-31<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/734">#734</A>.)</P>

<P>P2843 moved a prohibition to <TT>#define</TT> keywords to the core
language; it is now appearing in 15.7.1 [<A href="https://wg21.link/cpp.replace.general#9">cpp.replace.general</A>] paragraph 9:</P>

<BLOCKQUOTE>

A translation unit shall not #define or #undef names lexically
identical to keywords, to the identifiers listed in Table 4, or to
the <I>attribute-token</I>s described in 9.13 [<A href="https://wg21.link/dcl.attr">dcl.attr</A>],
except that the names likely and unlikely may be defined as
function-like macros.

</BLOCKQUOTE>

<P>This allows</P>

<PRE>
  #define likely(x) x
  #define unlikely(a, b) a + b
</PRE>

<P>but prohibits</P>

<PRE>
  #undef likely
  #undef unlikely
</PRE>

<P>even though guidelines for good macro hygiene suggest
to <TT>#undef</TT> a macro past its region of use.</P>

<P><U>Possible resolution:</U></P>

<P>Change in 15.7.1 [<A href="https://wg21.link/cpp.replace.general#9">cpp.replace.general</A>] paragraph 9 as follows:</P>

<BLOCKQUOTE>

A translation unit shall not #define or #undef names lexically
identical to keywords, to the identifiers listed in Table 4, or to
the <I>attribute-token</I>s described in 9.13 [<A href="https://wg21.link/dcl.attr">dcl.attr</A>],
except that the names likely and unlikely may be defined as
function-like macros <INS>and may be undefined</INS>.

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1625"></A><H4>1625.
  
Adding spaces between tokens in stringizing
</H4>
<B>Section: </B>15.7.3&#160; [<A href="https://wg21.link/cpp.stringize">cpp.stringize</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Chandler Carruth
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-18
  &#160;&#160;&#160;
  <B>Liaison: </B>WG14<BR>




<P>Given the following input,</P>

<PRE>
  #define F(A, B, C) A ## x.B ## y.C ## z
  #define STRINGIFY(x) #x
  #define EXPAND_AND_STRINGIFY(x) STRINGIFY(x)
  char v[] = EXPAND_AND_STRINGIFY(F(a, b, c))
</PRE>

<P>there is implementation variance in the value of <TT>v</TT>: some
produce the string <TT>"ax.by.cz"</TT> and others produce the string
<TT>"ax. by. cz"</TT>.  Although 15.7.3 [<A href="https://wg21.link/cpp.stringize#2">cpp.stringize</A>] paragraph 2 is
explicit in its treatment of leading and trailing white space, it is not
clear whether there is latitude for inserting spaces between tokens, as
some implementations do, since the description otherwise is written solely
in terms of preprocessing tokens.  There may be cases in which such spaces
would be needed to preserve the original tokenization, but it is not clear
whether the result of stringization needs to produce something that would
lex to the same tokens.</P>

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

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

<P>Because the preprocessor specification is primarily copied directly
from the C Standard, this issue has been referred to the C liaison for
consultation with WG14.</P>

<BR><BR><HR>
<A NAME="1709"></A><H4>1709.
  
Stringizing raw string literals containing newline
</H4>
<B>Section: </B>15.7.3&#160; [<A href="https://wg21.link/cpp.stringize">cpp.stringize</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-01<BR>


<P>Stringizing a raw string literal containing a newline produces an
invalid (unterminated) string literal and hence results in undefined
behavior.  It should be specified that a newline in a string literal is
transformed to the two characters <TT>'\' 'n'</TT> in the resulting string
literal.</P>

<P>A slightly related case involves stringizing a bare backslash
character: because backslashes are only escaped within a string or
character literal, a stringized bare backslash becomes <TT>"\"</TT>,
which is invalid and hence results in undefined behavior.</P>

<BR><BR><HR>
<A NAME="2578"></A><H4>2578.
  
Undefined behavior when creating an invalid string literal via stringizing
</H4>
<B>Section: </B>15.7.3&#160; [<A href="https://wg21.link/cpp.stringize">cpp.stringize</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2019-10-23
  &#160;&#160;&#160;
  <B>Liaison: </B>SG12<BR>


<P>(From National Body comment US 142 on the C++20 DIS.)</P>

<P>Subclause 15.7.3 [<A href="https://wg21.link/cpp.stringize#2">cpp.stringize</A>] paragraph 2 specifies:</P>

<BLOCKQUOTE>

If the replacement that results is not a valid character string
literal, the behavior is undefined.

</BLOCKQUOTE>

<P>Undefined behavior during lexing is not acceptable. This ought to
be ill-formed.</P>

<P><B>Additional notes (January, 2023):</B></P>

<P>Forwarded to SG12 with
<A HREF="https://github.com/cplusplus/papers/issues/1409">paper issue 1409</A>,
by decision of the CWG and SG12 chairs.
</P>

<BR><BR><HR>
<A NAME="2522"></A><H4>2522.
  
Removing placemarker tokens and retention of whitespace
</H4>
<B>Section: </B>15.7.4&#160; [<A href="https://wg21.link/cpp.concat">cpp.concat</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2018-04-08
  &#160;&#160;&#160;
  <B>Liaison: </B>WG14<BR>




<P>It appears that the replacement of a function-like macro
following further rescanning and replacement may begin or
end with whitespace when the leftmost or rightmost tokens
were placemarker tokens. GCC and MSVC preserve the
whitespace in both the starting and ending positions.  Clang
and ICC preserve only the trailing whitespace. For
example:</P>

<PRE>
  #define F( X ) X##X/**/&gt;
  #define G( X ) !/**/X##X
  #define F0( X ) F(X)
  #define G0( X ) G(X)
  #define STR2( X ) #X
  #define STR( X ) STR2(X)
  #define Q
  static_assert(STR(&gt;F0(Q))[1] == '\u0020', STR(&gt;F0(Q)));
    //<SPAN CLASS="cmnt"> ^ Works with GCC and MSVC; fails with Clang and ICC.</SPAN>
  static_assert(STR(G0(Q)=)[1] == '\u0020', STR(G0(Q)=));
</PRE>

<P>This appears to be an issue in C as well; see ISO C 6.10.3.</P>

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

<BR><BR><HR>
<A NAME="2579"></A><H4>2579.
  
Undefined behavior when token pasting does not create a preprocessing token
</H4>
<B>Section: </B>15.7.4&#160; [<A href="https://wg21.link/cpp.concat">cpp.concat</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2019-10-23
  &#160;&#160;&#160;
  <B>Liaison: </B>SG12<BR>


<P>(From National Body comment US 143 on the C++20 DIS.)</P>

<P>Subclause 15.7.4 [<A href="https://wg21.link/cpp.concat#3">cpp.concat</A>] paragraph 3 specifies:</P>

<BLOCKQUOTE>

If the result begins with a sequence matching the syntax
of <I>universal-character-name</I>, the behavior is undefined.
[<I>Note</I>: ... --<I>end note</I>]
If the result is not a valid preprocessing token, the behavior is
undefined.

</BLOCKQUOTE>

<P>Undefined behavior during lexing is not acceptable. The behavior
ought to be well-defined, ill-formed, or conditionally-supported.</P>

<P><B>Additional notes (January, 2023):</B></P>

<P>Forwarded to SG12 with
<A HREF="https://github.com/cplusplus/papers/issues/1410">paper issue 1410</A>,
by decision of the CWG and SG12 chairs.
</P>

<P><B>Additional notes (November, 2023):</B></P>

<P>The first case of undefined behavior was addressed by paper P2621R2
(Undefined behavior in the lexer), adopted in June, 2023.  The
relevant part of 15.7.4 [<A href="https://wg21.link/cpp.concat#3">cpp.concat</A>] paragraph 3 now reads:</P>

<BLOCKQUOTE>

... [<I>Note 1:</I> Concatenation can form
a <I>universal-character-name</I>
(5.3.1 [<A href="https://wg21.link/lex.charset">lex.charset</A>]). &#8212;<I>end note</I>] If the result is
not a valid preprocessing token, the behavior is undefined. ...

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="268"></A><H4>268.
  
Macro name suppression in rescanned replacement text
</H4>
<B>Section: </B>15.7.5&#160; [<A href="https://wg21.link/cpp.rescan">cpp.rescan</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Bjarne Stroustrup
 &#160;&#160;&#160;

 <B>Date: </B>18 Jan 2001
  &#160;&#160;&#160;
  <B>Liaison: </B>WG14<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
15.7.5 [<A href="https://wg21.link/cpp.rescan#2">cpp.rescan</A>] 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>

<P><B>Additional notes (June, 2022):</B></P>

<P>It is unclear whether the phrasing "following the macro's
replacement list" in the suggested resolution covers this case:</P>

<PRE>
  #define f(x) b
  #define b(x) x(1)

  f(1)(f) //<SPAN CLASS="cmnt"> the result is </SPAN>1
</PRE>

<BR><BR><HR>
<A NAME="2580"></A><H4>2580.
  
Undefined behavior with <TT>#line</TT>
</H4>
<B>Section: </B>15.8&#160; [<A href="https://wg21.link/cpp.line">cpp.line</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2019-10-23
  &#160;&#160;&#160;
  <B>Liaison: </B>SG12<BR>


<P>(From National Body comments US 144 and US 145 on the C++20 DIS.)</P>

<P>Subclause 15.8 [<A href="https://wg21.link/cpp.line#3">cpp.line</A>] paragraph 3 specifies:</P>

<BLOCKQUOTE>

If the digit sequence specifies zero or a number greater than
2147483647, the behavior is undefined.

</BLOCKQUOTE>

<P>Subclause 15.8 [<A href="https://wg21.link/cpp.line#5">cpp.line</A>] paragraph 5 specifies:</P>

<BLOCKQUOTE>

If the directive resulting after all replacements does not match one
of the two previous forms, the behavior is undefined; otherwise, the
result is processed as appropriate.

</BLOCKQUOTE>

<P>Undefined behavior during lexing is not acceptable. This ought to
be ill-formed.</P>

<P><B>Additional notes (January, 2023):</B></P>

<P>Forwarded to SG12 with
<A HREF="https://github.com/cplusplus/papers/issues/1411">paper issue 1411</A>,
by decision of the CWG and SG12 chairs.
</P>

<BR><BR><HR>
<A NAME="2693"></A><H4>2693.
  
Escape sequences for the <I>string-literal</I> of <TT>#line</TT>
</H4>
<B>Section: </B>15.8&#160; [<A href="https://wg21.link/cpp.line">cpp.line</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-02-07
  &#160;&#160;&#160;
  <B>Liaison: </B>WG14<BR>


<P>The grammar for <TT>#line</TT> is inconsistent between 15.8 [<A href="https://wg21.link/cpp.line#4">cpp.line</A>] paragraph 4:</P>

<BLOCKQUOTE>

<PRE>
# line <I>digit-sequence</I> " <I>s-char-sequence</I><SUB>opt</SUB> " <I>new-line</I>
</PRE>

</BLOCKQUOTE>

<P>and 15.8 [<A href="https://wg21.link/cpp.line#1">cpp.line</A>] paragraph 1:</P>

<BLOCKQUOTE>

The <I>string-literal</I> of a <TT>#line</TT> directive, if present, shall be a
character string literal.

</BLOCKQUOTE>

<P>The characters comprising the <I>string-literal</I> are not
necessarily interpreted for e.g. escape sequences
or <I>universal-character-name</I>s, so the use
of <I>string-literal</I> here is questionable.  This directive names a
source file, thus it might be better to use <I>header-name</I>
(5.6 [<A href="https://wg21.link/lex.header">lex.header</A>]) instead.</P>

<BR><BR><HR>
<A NAME="1889"></A><H4>1889.
  
Unclear effect of <TT>#pragma</TT> on conformance
</H4>
<B>Section: </B>15.10&#160; [<A href="https://wg21.link/cpp.pragma">cpp.pragma</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

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




<P>According to 15.10 [<A href="https://wg21.link/cpp.pragma#1">cpp.pragma</A>] paragraph 1, the effect of
a <TT>#pragma</TT> is to cause</P>

<BLOCKQUOTE>

the implementation to behave in an implementation-defined manner. The
behavior might cause translation to fail or cause the translator or the
resulting program to behave in a non-conforming manner.

</BLOCKQUOTE>

<P>It should be clarified that the extent of the non-conformance is
limited to the implementation-defined behavior.</P>

<BR><BR><HR>
<A NAME="2581"></A><H4>2581.
  
Undefined behavior for predefined macros
</H4>
<B>Section: </B>15.12&#160; [<A href="https://wg21.link/cpp.predefined">cpp.predefined</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2019-10-23
  &#160;&#160;&#160;
  <B>Liaison: </B>SG12<BR>


<P>(From National Body comments US 148 and US 149 on the C++20 DIS.)</P>

<P>Subclause 15.12 [<A href="https://wg21.link/cpp.predefined#4">cpp.predefined</A>] paragraph 4 specifies:</P>

<BLOCKQUOTE>

If any of the pre-defined macro names in this subclause, or the
identifier <TT>defined</TT>, is the subject of a <TT>#define</TT> or
a <TT>#undef</TT> preprocessing directive, the behavior is undefined.

</BLOCKQUOTE>

<P>Undefined behavior during lexing is not acceptable. This ought to
be ill-formed.</P>

<P><B>Additional notes (January, 2023):</B></P>

<P>Forwarded to SG12 with
<A HREF="https://github.com/cplusplus/papers/issues/1412">paper issue 1412</A>,
by decision of the CWG and SG12 chairs.
</P>

<BR><BR><HR>
<A NAME="897"></A><H4>897.
  
<TT>_Pragma</TT> and extended <I>string-literal</I>s
</H4>
<B>Section: </B>15.13&#160; [<A href="https://wg21.link/cpp.pragma.op">cpp.pragma.op</A>]
 &#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.
15.13 [<A href="https://wg21.link/cpp.pragma.op">cpp.pragma.op</A>] 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>



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

<P>If raw string literals are supported, the question of how to handle
line splicing is relevant.  The wording says that &#8220;the characters
are processed through translation phase 3,&#8221; which is a bit
ambiguous as to whether that includes phases 1 and 2 or not.  It would
be better to be explicit and say that the processing of phase 3 or of
phases 1 through 3 is applied.</P>

<P>See also the near-duplicate <A HREF="cwg_active.html#2694">issue 2694</A>.</P>

<BR><BR><HR>
<A NAME="2694"></A><H4>2694.
  
<I>string-literal</I>s of the <TT>_Pragma</TT> operator
</H4>
<B>Section: </B>15.13&#160; [<A href="https://wg21.link/cpp.pragma.op">cpp.pragma.op</A>]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2023-02-07
  &#160;&#160;&#160;
  <B>Liaison: </B>WG14<BR>


<P>Subclause 15.13 [<A href="https://wg21.link/cpp.pragma.op#1">cpp.pragma.op</A>] paragraph 1 specifies:</P>

<BLOCKQUOTE>

A unary operator expression of the form:
<PRE>
      _Pragma ( <I>string-literal</I> )
</PRE>
is processed as follows: The <I>string-literal</I> is destringized by
deleting the <TT>L</TT> prefix, if present, deleting the leading and
trailing double-quotes, replacing each escape sequence <TT>\"</TT> by
a double-quote, and replacing each escape sequence <TT>\\</TT> by a
single backslash. The resulting sequence of characters is processed
through translation phase 3 to produce preprocessing tokens that are
executed as if they were the <I>pp-token</I>s in a pragma directive.
The original four preprocessing tokens in the unary operator
expression are removed.

</BLOCKQUOTE>

<P>In contrast, C23 section 6.10.6 specifies:</P>

<BLOCKQUOTE>

A unary operator expression of the form:
<PRE>
    _Pragma ( <I>string-literal</I> )
</PRE>
is processed as follows: The string literal is destringized by deleting
any encoding prefix, ...

</BLOCKQUOTE>

<P>While in C, <I>any</I> encoding prefix is deleted, C++ only deletes
the L prefix and does not consider UTF-8, UTF-16, and UTF-32 string
literals.  This was probably an oversight when C++ obtained UTF-x
string literals.</P>

<P>However, a <I>string-literal</I> entails lexing of escape sequences
and <I>universal-character-name</I>s, which seems not useful given
that the string literal is de-stringized immediately afterwards.  It
might be more appropriate to employ a simpler lexical structure such
as a <I>q-char-sequence</I> as used in a <I>header-name</I>
instead. See also <A HREF="cwg_active.html#2693">issue 2693</A>.</P>

<P>See also <A HREF="cwg_active.html#897">issue 897</A>, which is also
concerned with raw string literals and line splicing.</P>

<BR><BR><HR>
<A NAME="2784"></A><H4>2784.
  
Unclear definition of <I>member-designator</I> for <TT>offsetof</TT>
</H4>
<B>Section: </B>17.2.4&#160; [<A href="https://wg21.link/support.types.layout">support.types.layout</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Corentin Jabot
 &#160;&#160;&#160;

 <B>Date: </B>2023-08-21
  &#160;&#160;&#160;
  <B>Liaison: </B>EWG<BR>




<P>Consider:</P>

<PRE>
  struct S {
    int a;
  };
  int x = offsetof(S, S::a)
</PRE>

<P>Is this valid? MSVC and gcc appear to support <I>qualified-id</I>s
in the <I>member-designator</I> of <TT>offsetof</TT>; clang does not.
Once that question is clarified, the rules about value-dependence may
need to be amended, because a <I>qualified-id</I> might introduce
type-dependence.</P>

<P>Specific questions:</P>
<UL>
<LI>Is a <I>qualified-id</I> allowed to appear in
a <I>member-designator</I>?</LI>
<LI>Is a <I>template-id</I> allowed to appear in
a <I>member-designator</I>?</LI>
<LI>Is an <TT>offsetof</TT> expression a core constant expression
(7.7 [<A href="https://wg21.link/expr.const">expr.const</A>])?</LI>
</UL>

<P><B>2023-08-23</B></P>

<P>Forwarded to EWG with paper issue
<A HREF="https://github.com/cplusplus/papers/issues/1616">#1616</A>,
by decision of the CWG chair.</P>

<P><B>EWG 2023-11-07</B></P>

<P>EWG is soliciting a paper to thoroughly explore the design space.</P>

<BR><BR><HR>
<A NAME="2361"></A><H4>2361.
  
Unclear description of <TT>longjmp</TT> undefined behavior
</H4>
<B>Section: </B>17.14.3&#160; [<A href="https://wg21.link/csetjmp.syn">csetjmp.syn</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Zhihao Yuan
 &#160;&#160;&#160;

 <B>Date: </B>2017-10-20<BR>


<P>According to 17.14.3 [<A href="https://wg21.link/csetjmp.syn#2">csetjmp.syn</A>] paragraph 2,</P>

<BLOCKQUOTE>

A <TT>setjmp</TT>/<TT>longjmp</TT> call pair has undefined behavior if
replacing the <TT>setjmp</TT> and <TT>longjmp</TT> by <TT>catch</TT>
and <TT>throw</TT> would invoke any non-trivial destructors for any
automatic objects.

</BLOCKQUOTE>

<P>The intent is clear, that transferring control from point A to point
B via <TT>longjmp</TT> has undefined behavior if throwing an exception
at point A and catching it at point B would invoke non-trivial destructors.
The wording could be more precise.</P>

<P>See also
the <A HREF="https://github.com/cplusplus/draft/issues/1778">corresponding
editorial issue</A> for additional discussion.</P>

<P><B>Notes from the October, 2018 teleconference:</B></P>

<P>There are a number of unanswered questions in the current
wording, including the impact on the current exception
(whether it still exists) after a <TT>longjmp</TT> out of a
handler, the impact on the initialization of locks if jumping
from the initialization of a local static data member,
etc. One thought was to restrict use of <TT>longjmp</TT> to
&#8220;plain C functions&#8221;. Another was to say if the
program would have different behavior via the use of
exceptions the behavior is undefined. There was no consensus
on how to proceed.</P>

<P><B>Additional note, January, 2022:</B></P>

<P>See also library issues
<A HREF="https://cplusplus.github.io/LWG/issue1265">1265</A> and
<A HREF="https://cplusplus.github.io/LWG/issue3652">3652</A>.</P>

<BR><BR><HR>
<A NAME="1944"></A><H4>1944.
  
New C incompatibilities
</H4>
<B>Section: </B>Clause Annex C&#160; [<A href="https://wg21.link/diff">diff</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2014-06-18<BR>


<P>Some new features of C++ not only introduce incompatibilities
with previous versions of C++ but also with C; however, the
organization of Annex Clause Annex C [<A href="https://wg21.link/diff">diff</A>] makes it difficult
to specify that a given feature is incompatible with both languages,
and the practice has been only to document the C++ incompatibilities.
Some means of specifying both sets of incompatibilities should be
found, hopefully without excessive duplication between the C and C++
sections.</P>

<BR><BR><HR>
<A NAME="1279"></A><H4>1279.
  
Additional differences between C++ 2003 and C++ 2011
</H4>
<B>Section: </B>C.6&#160; [<A href="https://wg21.link/diff.cpp03">diff.cpp03</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-27<BR>




<P>A number of differences between C++03 and C++11 were omitted from
C.6 [<A href="https://wg21.link/diff.cpp03">diff.cpp03</A>]:</P>

<UL>
<LI><P>New keywords.  Although these are said in C.6.2 [<A href="https://wg21.link/diff.cpp03.lex">diff.cpp03.lex</A>] only to invalidate C++03 code, they can also change
the meaning, e.g., <TT>thread_local x(y)</TT>, which would declare
a variable <TT>thread_local</TT> initialized with <TT>y</TT> in
C++03 and a thread-local variable <TT>y</TT> in C++11.</P></LI>

<LI><P>New deduction rules.</P></LI>

<LI><P>Removal of the deprecated string literal conversion.</P></LI>

<LI><P>When a <TT>friend</TT> function defined in a class template
is actually defined (i.e., with each instantiation or only when
odr-used).</P></LI>

<LI><P>Removal of access declarations.</P></LI>

<LI><P>Use of the injected-class-name of a class template as a
template <I>template-argument</I>.</P></LI>

</UL>

<P><B>Additional note (January, 2012):</B></P>

<P>In addition to the items previously mentioned, access declarations
were removed from C++11 but are not mentioned in C.6 [<A href="https://wg21.link/diff.cpp03">diff.cpp03</A>].</P>

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

<P>Add the following as a new section in C.6 [<A href="https://wg21.link/diff.cpp03">diff.cpp03</A>]:</P>

<BLOCKQUOTE>

<P><TABLE width="100%">
<TR>
<TD><B>C.2.5 11.8 [<A href="https://wg21.link/class.access">class.access</A>]: member access control</B></TD>
<TD align="right"><B>pdiff.cpp03.class.access</B></TD>

</TR>

</TABLE></P>

<P>
<B>Change:</B> Remove access declarations.</P>

<P>
<B>Rationale:</B> Removal of feature deprecated since C++ 1998.</P>

<P>
<B>Effect on original feature:</B> Valid C++ 2003 code that uses
access declarations is ill-formed in this International Standard.
Instead, <I>using-declaration</I>s (9.10 [<A href="https://wg21.link/namespace.udecl">namespace.udecl</A>]) can
be used.</P>

</BLOCKQUOTE>

<BR><BR><HR>
<A NAME="1248"></A><H4>1248.
  
Updating Annex C to C99 and C23
</H4>
<B>Section: </B>C.7&#160; [<A href="https://wg21.link/diff.iso">diff.iso</A>]
 &#160;&#160;&#160;

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

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

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




<P>The description of incompatibilities with C in Annex
C.7 [<A href="https://wg21.link/diff.iso">diff.iso</A>] is based on C89, but there are a number of
new features in C99 and C23 that should be covered.</P>



<P><B>Additional note (August, 2024)</B></P>

<P>The issue title and description were amended to cover C23 as well.</P>

<BR><BR><HR>
<A NAME="3008"></A><H4>3008.
  
Missing Annex C entry for <TT>void</TT> object declarations
</H4>
<B>Section: </B>C.7.6&#160; [<A href="https://wg21.link/diff.dcl">diff.dcl</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jiang An
 &#160;&#160;&#160;

 <B>Date: </B>2025-03-13<BR>


<P>(From submission
<A HREF="https://github.com/cplusplus/CWG/issues/682">#682</A>.)</P>

<P>C allows</P>

<PRE>
  extern void x;
</PRE>

<P>C++ does not, as clarified by <A HREF="cwg_defects.html#2475">issue 2475</A>
in 9.1 [<A href="https://wg21.link/dcl.pre#8">dcl.pre</A>] paragraph 8.</P>

<P>This deviation warrants an entry in Annex C.</P>

<P><U>Possible resolution:</U></P>

<P>Add a new paragraph to C.7.6 [<A href="https://wg21.link/diff.dcl">diff.dcl</A>] as follows:</P>

<BLOCKQUOTE class="ins">

<P>
Affected subclause: 9.1 [<A href="https://wg21.link/dcl.pre">dcl.pre</A>]<BR>
Change: In C++, no declaration of a variable can have <TT>void</TT> type.
In C, this is allowed, unless the declaration is a definition.<BR>
[Example:
<PRE>
  extern void x;   //<SPAN CLASS="cmnt"> valid C, invalid in C++</SPAN>
</PRE>
-- end example]<BR>
Rationale: Stricter type checking in C++.<BR>
Effect on original feature: Deletion of semantically well-defined feature.<BR>
Difficulty of converting: Syntactic transformation.<BR>
How widely used: Seldom.<BR>
</P>

</BLOCKQUOTE>

<BR><BR><BR><BR>
</BODY>
</HTML>
