This document contains the C++ core language issues that have been categorized as Defect Reports by the Committee (PL22.16 + WG21) and other accepted issues, that is, issues with status "DR," "accepted," "DRWP," "WP," "CD1," "CD2," "CD3," "CD4," "CD5," "CD6," "TC1," "C++11," "C++14," "C++17," "C++20," and "C++20," along with their proposed resolutions. Issues with DR, accepted, DRWP, and WP status are NOT part of the International Standard for C++. They are provided for informational purposes only, as an indication of the intent of the Committee. They should not be considered definitive until or unless they appear in an approved Technical Corrigendum or revised International Standard for C++.

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:

• Active Issues List, which contains explanatory material for the entire document group and a list of the issues that have not yet been acted upon by the Committee.
• Closed Issues List, 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.
• Table of Contents, which contains a summary listing of all issues in numerical order.
• Index by Section, which contains a summary listing of all issues arranged in the order of the sections of the Standard with which they deal most directly.
• Index by Status, which contains a summary listing of all issues grouped by status.

For more information, including a description of the meaning of the issue status codes and instructions on reporting new issues, please see the Active Issues List.

Section references in this document reflect the section numbering of document WG21 N4944.

Issues with "DR" Status

2520. Template signature and default template arguments

[Accepted as a DR at the February, 2023 meeting.]

According to 3.53 [defns.signature.templ], the signature of a function template includes:

name, parameter-type-list, enclosing namespace, return type, template-head, and trailing requires-clause (if any)

The mention of the template-head is a change from previous versions of the Standard, which referred to the “template parameter list”, in order to include the requires-clause in the signature. However, template-head is a syntactic nonterminal and thus includes everything in that production, including default template arguments. It seems undesirable to make the default arguments part of the template signature.

CWG 2022-11-11

CWG agrees with the suggested direction.

Proposed resolution (approved by CWG 2023-02-09):

1. Change in 3.52 [defns.signature.friend] as follows:

   signature
   <function template>
   name, parameter-type-list, enclosing namespace, return type, signature of the template-head, and trailing requires-clause (if any)

2. Change in 3.53 [defns.signature.templ] as follows:

   signature
   <friend function template with constraint involving enclosing template parameters>
   name, parameter-type-list, return type, enclosing class, signature of the template-head, and trailing requires-clause (if any)

3. Change in 3.56 [defns.signature.member] as follows:

   signature
   <class member function template>
   name, parameter-type-list, class of which the function is a member, cv-qualifiers (if any), ref-qualifier (if any), return type (if any), signature of the template-head, and trailing requires-clause (if any)

4. Add a new section in Clause 3 [intro.defs] as follows:

   signature
   <template-head>
   template parameter list, excluding template parameter names and default arguments, and requires-clause (if any)

2518. Conformance requirements and #error/#warning

[Accepted as a DR at the February, 2023 meeting.]

According to 4.1.1 [intro.compliance.general] bullet 2.2,

a conforming implementation shall issue at least one diagnostic message

for an ill-formed program that is not “no diagnostic required.” The relationship between this diagnostic message and the ones required by the #error and #warning preprocessor directives is not clear. For example, is an implementation required to emit multiple diagnostics if multiple #error directives are encountered, even though conformance requires only one? Could an implementation count the diagnostic emitted by #warning as satisfying the requirement for an ill-formed program?

See also issue 745.

Suggested resolution [SUPERSEDED]:

Add a new paragraph after 4.1.1 [intro.compliance.general] paragraph 2 as follows:

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. Such requirements have the following meaning:

• If a program contains no violations of the rules in Clause Clause 5 [lex] through Clause Clause 33 [thread] and Annex D, a conforming implementation shall, within its resource limits as described in Annex B, accept and correctly execute [ Footnote: ... ] that program.
• If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
• 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.

[Note: ... — end note]

Furthermore, a conforming implementation

• shall not accept a translation unit containing a #error preprocessing directive (15.8 [cpp.error]) unless it is part of a group skipped by conditional inclusion (15.2 [cpp.cond]) and
• shall issue at least one diagnostic message for each #warning or #error preprocessing directive not following a #error preprocessing directive, ignoring #warning and #error preprocessing directives appearing in groups skipped by conditional inclusion.

For classes and class templates, ...

Notes from the November, 2022 meeting

EWG review solicited via cplusplus/papers#1366.

EWG 2023-02-06

EWG agreed with the suggested resolution, but resolved to amend it to treat static_assert similarly.

Proposed resolution (February, 2023) [SUPERSEDED]:

1. Change and add a new paragraph after 4.1.1 [intro.compliance.general] paragraph 2 as follows:

   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. Such requirements have the following meaning:

   • If a program contains no violations of the rules in Clause Clause 5 [lex] through Clause Clause 33 [thread] and Annex D, a conforming implementation shall, within its resource limits as described in Annex B, accept and correctly execute [ Footnote: ... ] that program.
   • 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.
   • Otherwise, if If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
   • 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. [Note: During template argument deduction and substitution, certain constructs that in other contexts require a diagnostic are treated differently; see [temp.deduct] — end note]

   Furthermore, a conforming implementation

   • shall not accept a preprocessing translation unit containing a #error preprocessing directive (15.8 [cpp.error]),
   • shall issue at least one diagnostic message for each #warning or #error preprocessing directive not following a #error preprocessing directive in a preprocessing translation unit, and
   • shall not accept a translation unit with a failed static_assert-declaration (9.1 [dcl.pre]) outside an uninstantiated template.

   For classes and class templates, ...

2. Change in 5.1 [lex.separate] paragraph 1 as follows:

   The text of the program is kept in units called source files in this document. A source file together with all the headers (16.4.2.3 [headers]) and source files included (15.3 [cpp.include]) via the preprocessing directive #include, less any source lines skipped by any of the conditional inclusion (15.2 [cpp.cond]) preprocessing directives, is called a preprocessing translation unit.

3. Change in 5.2 [lex.phases] paragraph 7 as follows:

   ... The resulting tokens constitute a translation unit and are syntactically and semantically analyzed and translated as a translation unit.

4. Change in 9.1 [dcl.pre] paragraph 10 as follows:

   In a static_assert-declaration, the constant-expression is contextually converted to bool and the converted expression shall be a constant expression (7.7 [expr.const]). If the value of the expression when so converted is true, the declaration has no effect. Otherwise, the static_assert-declaration has failed, the program is ill-formed, and the resulting diagnostic message (4.1 [intro.compliance]) should include the text of the string-literal, if one is supplied.

CWG 2023-02-10

CWG decided to fold P2593R1 (static_assert(false)) into the proposed resolution.

Proposed resolution (approved by CWG 2023-02-10):

1. Change and add a new paragraph after 4.1.1 [intro.compliance.general] paragraph 2 as follows:

   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. Such requirements have the following meaning:

   • If a program contains no violations of the rules in Clause Clause 5 [lex] through Clause Clause 33 [thread] and Annex D, a conforming implementation shall, within its resource limits as described in Annex B, accept and correctly execute [ Footnote: ... ] that program.
   • 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.
   • Otherwise, if If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
   • 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. [Note: During template argument deduction and substitution, certain constructs that in other contexts require a diagnostic are treated differently; see [temp.deduct] — end note]

   Furthermore, a conforming implementation

   • shall not accept a preprocessing translation unit containing a #error preprocessing directive (15.8 [cpp.error]),
   • shall issue at least one diagnostic message for each #warning or #error preprocessing directive not following a #error preprocessing directive in a preprocessing translation unit, and
   • shall not accept a translation unit with a static_assert-declaration that fails (9.1 [dcl.pre]).

   For classes and class templates, ...

2. Change in 5.1 [lex.separate] paragraph 1 as follows:

   The text of the program is kept in units called source files in this document. A source file together with all the headers (16.4.2.3 [headers]) and source files included (15.3 [cpp.include]) via the preprocessing directive #include, less any source lines skipped by any of the conditional inclusion (15.2 [cpp.cond]) preprocessing directives, is called a preprocessing translation unit.

3. Change in 5.2 [lex.phases] paragraph 7 as follows:

   ... The resulting tokens constitute a translation unit and are syntactically and semantically analyzed and translated as a translation unit.

4. Change in 9.1 [dcl.pre] paragraph 10 as follows:

   In a static_assert-declaration, the constant-expression is contextually converted to bool and the converted expression shall be a constant expression (7.7 [expr.const]). If the value of the expression when so converted is true or the expression is evaluated in the context of a template definition, the declaration has no effect. Otherwise, the static_assert-declaration fails, the program is ill-formed, and the resulting diagnostic message (4.1 [intro.compliance]) should include the text of the string-literal, if one is supplied. [ Example:

     static_assert(sizeof(int) == sizeof(void*), "wrong pointer size");
     static_assert(sizeof(int[2]));   // OK, narrowing allowed
   
     template <class T>
     void f(T t) {
       if constexpr (sizeof(T) == sizeof(int)) {
         use(t);
       } else {
         static_assert(false, "must be int-sized");
       }
     }
     
     void g(char c) {
       f(0); // OK
       f(c); // error: must be int-sized
     }
     
   

   -- end example ]

5. Change in 13.8 [temp.res] paragraph 6 as follows:

   ... The program is ill-formed, no diagnostic required, if:

   • no valid specialization, ignoring static_assert-declarations that fail, can be generated for a template or a substatement of a constexpr if statement (8.5.2 [stmt.if]) within a template and the template is not instantiated, or
   • ...

2530. Multiple definitions of enumerators

[Accepted as a DR at the February, 2023 meeting.]

Issue 2494 specified a list of definable items and required that no translation unit contain more than one definition of any of those items. However, the list omits enumeration constants, implicitly allowing an example like:

  enum E { e, e };

According to 6.1 [basic.pre] paragraph 3, an enumerator is an entity. According to 6.2 [basic.def] paragraph 2,

Each entity declared by a declaration is also defined by that declaration unless: ...

and enumerators are not on the list of excluded cases, so an enumerator-definition is a definition. Furthermore, 6.6 [basic.link] paragraph 8 says,

Two declarations of entities declare the same entity if, considering declarations of unnamed types to introduce their names for linkage purposes, if any (9.2.4 [dcl.typedef], 9.7.1 [dcl.enum]), they correspond (6.4.1 [basic.scope.scope]), have the same target scope that is not a function or template parameter scope, and either

• they appear in the same translation unit, or

• ...

In the example above, both enumerators thus define the same entity, so the one-definition rule is responsible for excluding the duplicate definitions but does not do so.

Suggested resolution [SUPERSEDED]:

Each of the following is termed a definable item:

• ...
• an enumeration type (9.7.1 [dcl.enum]),
• an enumerator,
• a function (9.3.4.6 [dcl.fct]),
• ...

Proposed resolution (approved by CWG 2022-12-02):

Change in 9.7.1 [dcl.enum] paragraph 2 as follows:

... The identifiers in an enumerator-list are declared as constants, and can appear wherever constants are required. The same identifier shall not appear as the name of multiple enumerators in an enumerator-list. An enumerator-definition with = gives the associated enumerator the value indicated by the constant-expression. If the first enumerator has no initializer, the value of the corresponding constant is zero. An enumerator-definition without an initializer gives the enumerator the value obtained by increasing the value of the previous enumerator by one.

2678. std::source_location::current is unimplementable

[Accepted as a DR at the February, 2023 meeting.]

Consider:

  #include <source_location>

  inline char *f() {
    static char array[std::source_location::current().line()];
    return array;
  }

The sequence of tokens comprising the definition of f can appear in multiple translation units, on different lines. The one-definition rule is not violated. Thus, there is a single function f in the program with a unique static local object array, but that object would have a different type in each translation unit. It is unclear how to implement this, absent the conservative approach of always returning a value-initialized object from std::source_location::current, which would defeat its purpose.

Possible approaches to resolve this issue might include:

• Do not mark the source_location accessors constexpr; they are not deterministic.
• Prohibit calls to source_location accessors during constant evaluation unless the current() call happened in a context that can only appear once in a program.
• Do not mark the current function constexpr / consteval.
• Change the ODR to prohibit calling the current function in an inline function or in a function template.

2023-01-08

Forwarded to LWG / LEWG via cplusplus/papers#1416, by decision of the CWG chair.

EWG 2023-02-07

EWG approves of the approach for CWG2678 of changing the ODR to make use of source_location in a way that causes an inline function/function template/etc to 'be different' be an ODR violation.

Proposed resolution (approved by CWG 2023-02-08):

Add a new bullet after 6.3 [basic.def.odr] bullet 14.8 as follows:

• In each such definition, const objects with static or thread storage duration shall be constant-initialized if the object is constant-initialized in any such definition.
• In each such definition, corresponding manifestly constant-evaluated expressions that are not value-dependent shall have the same value (7.7 [expr.const], 13.8.3.4 [temp.dep.constexpr]).
• In each such definition, the overloaded operators referred to, the implicit calls to conversion functions, constructors, operator new functions and operator delete functions, shall refer to the same function.

2516. Locus of enum-specifier or opaque-enum-declaration

[Accepted as a DR at the February, 2023 meeting.]

According to 6.4.2 [basic.scope.pdecl] paragraph 3,

The locus of an enum-specifier or opaque-enum-declaration is immediately after the identifier (if any) in it (9.7.1 [dcl.enum]).

Equivalent wording has been present for a very long time; see, for instance, issue 1482. However, most or all implementations reject the example from that issue:

   template<typename T> struct S { typedef char I; };
   enum E: S<E>::I { e };   // Implementations say E is undeclared in S<E>

In addition to recognizing current implementation practice, it would be practically useful if the locus were specified instead as after the enum-head or complete opaque-enum-declaration, as it would allow use of SFINAE in std::is_scoped_enum to distinguish between scoped and unscoped enumerations rather than requiring special compiler support.

CWG 2022-11-11

Move the locus to immediately after the enum-head.

Proposed resolution (approved by CWG 2023-02-06):

The locus of an enum-specifier or opaque-enum-declaration is immediately after the identifier (if any) in it its enum-head; the locus of an opaque-enum-declaration is immediately after it (9.7.1 [dcl.enum]).

2642. Inconsistent use of T and C

[Accepted as a DR at the February, 2023 meeting.]

T and C are used inconsistently throughout these paragraphs.

Proposed resolution [SUPERSEDED]:

1. Change in 6.5.2 [class.member.lookup] paragraph 1 as follows:

   A search in a scope X for a name N from a program point P is a single search in X for N from P unless X is the scope of a class or class template T C, in which case the following steps define the result of the search.

2. Change in 6.5.2 [class.member.lookup] paragraph 4 as follows:

   [Note 2: If T C is incomplete, only base classes whose base-specifier appears before P are considered. If T C is an instantiated class, its base classes are not dependent. —end note]

3. Change in 6.5.2 [class.member.lookup] paragraph 6 as follows:

   The result of the search is the declaration set of S(N, T C). If it is an invalid set, the program is ill-formed. If it differs from the result of a search in T C for N in a complete-class context (11.4 [class.mem]) of T C, the program is ill-formed, no diagnostic required.

4. Change in 6.5.2 [class.member.lookup] paragraph 7 as follows:

   If N is a non-dependent conversion-function-id, conversion function templates that are members of T C are considered. For each such template F, the lookup set S(t, T C) is constructed, considering a function template declaration to have the name t only if it corresponds to a declaration of F (6.4.1 [basic.scope.scope]).

5. Change in 6.5.2 [class.member.lookup] paragraph 8 as follows:

   [Note 4: A static member, a nested type or an enumerator defined in a base class T B can unambiguously be found even if an object has more than one base class subobject of type T B. Two base class subobjects share the non-static member subobjects of their common virtual base classes. —end note]

CWG 2022-12-02

The resolution proposed above is incorrect: T is the parameter for the overall search and C is the parameter for the S(N,C) construction. Highlight that fact in paragraph 2.

Proposed resolution (approved by CWG 2023-01-06):

1. Change in 6.5.2 [class.member.lookup] paragraph 1 as follows:

   A search in a scope X for a name N M from a program point P is a single search in X for N M from P unless X is the scope of a class or class template T, in which case the following steps define the result of the search. [Note 1: The result differs only if N M is a conversion-function-id or if the single search would find nothing. —end note]

2. Change in 6.5.2 [class.member.lookup] paragraph 2 as follows:

   The lookup set for a name N in a class or class template C, called S(N, C), consists of two component sets: the declaration set, a set of members named N ; and the subobject set, a set of subobjects where declarations of these members were found (possibly via using-declarations). In the declaration set, type declarations (including injected-class-names) are replaced by the types they designate. S(N, C) is calculated as follows:

3. Change in 6.5.2 [class.member.lookup] paragraph 4 as follows:

   ... [Note 2: If T C is incomplete, only base classes whose base-specifier appears before P are considered. If T C is an instantiated class, its base classes are not dependent. —end note]

4. Change in 6.5.2 [class.member.lookup] paragraph 6 as follows:

   The result of the search is the declaration set of S(NM, T). If it is an invalid set, the program is ill-formed. If it differs from the result of a search in T for N M in a complete-class context (11.4 [class.mem]) of T , the program is ill-formed, no diagnostic required.

5. Change in 6.5.2 [class.member.lookup] paragraph 7 as follows:

   If N M is a non-dependent conversion-function-id, conversion function templates that are members of T are considered. For each such template F, the lookup set S(t, T) is constructed, considering a function template declaration to have the name t only if it corresponds to a declaration of F (6.4.1 [basic.scope.scope]). The members of the declaration set of each such lookup set, which shall not be an invalid set, are included in the result.

2489. Storage provided by array of char

[Accepted as a DR at the February, 2023 meeting.]

According to 6.7.2 [intro.object] paragraph 3,

If a complete object is created (7.6.2.8 [expr.new]) in storage associated with another object e of type “array of N unsigned char” or of type “array of N std::byte” (17.2.1 [cstddef.syn]), that array provides storage for the created object if...

However, note 4 in paragraph 13 indicates that a char array can also provide storage:

An operation that begins the lifetime of an array of char, unsigned char, or std::byte implicitly creates objects within the region of storage occupied by the array.

[Note 4: The array object provides storage for these objects. —end note]

The normative text and the note should be reconciled.

Proposed resolution (approved by CWG 2023-02-09):

Change in 6.7.2 [intro.object] paragraph 13 as follows:

An operation that begins the lifetime of an array of char, unsigned char, or std::byte implicitly creates objects within the region of storage occupied by the array.

2475. Object declarations of type cv void

[Accepted as a DR at the February, 2023 meeting.]

(From editorial issue 3953.)

Although an object cannot be defined with a type of cv void, there is nothing preventing a non-defining declaration of an object with that type. Should it be disallowed?

Notes from the December, 2020 teleconference:

Such declarations are permitted in C, so this question was referred to the C liaison for investigation.

CWG 2022-11-11

CWG resolved to making such declarations ill-formed.

Proposed resolution (approved by CWG 2022-12-02; amended 2023-02-06):

Change in 9.1 [dcl.pre] paragraph 7 as follows:

If the decl-specifier-seq contains the typedef specifier, the declaration is called a typedef declaration and each declarator-id is declared to be a typedef-name, synonymous with its associated type (9.2.4 [dcl.typedef]). [ Note 4: Such a declarator-id is an identifier (11.4.8.3 [class.conv.fct]). —end note] If the decl-specifier-seq contains no typedef specifier, Otherwise, if the type associated with a declarator-id is a function type (9.3.4.6 [dcl.fct]), the declaration is called a function declaration if the type associated with a declarator-id is a function type (9.3.4.6 [dcl.fct]) and . Otherwise, if the type associated with a declarator-id is an object or reference type, the declaration is an object declaration otherwise. Otherwise, the program is ill-formed.

[ Example:

int f(), x;            // OK, function declaration for f and object declaration for x
extern void g(),       // OK, function declaration for g
  y;                   // error: void is not an object type

-- end example ]

2528. Three-way comparison and the usual arithmetic conversions

[Accepted as a DR at the February, 2023 meeting.]

Consider an example like:

  void f(unsigned char i, unsigned ui) {
    i <=> ui;
  }

According to 7.6.8 [expr.spaceship] paragraph 4, the usual arithmetic conversions are applied to the operands. According to 7.4 [expr.arith.conv] bullet 1.5, the integral promotions are performed on both operands, resulting in i being converted from unsigned char to int. The operands are then of types int and unsigned int, so bullet 1.5.5 applies, further converting i to type unsigned int.

Unfortunately, that latter conversion, from int to unsigned int, is a narrowing conversion, which runs afoul of 7.6.8 [expr.spaceship] bullet 4.1, which prohibits narrowing conversions other than integral to floating in three-way comparisons.

Suggested resolution [SUPERSEDED]:

Change 7.4 [expr.arith.conv] bullet 1.5 as follows:

Otherwise, the integral promotions (7.3.7 [conv.prom]) shall be performed on both operands each operand shall be converted to a common type C. The integral promotion rules (7.3.7 [conv.prom] shall be used to determine a type T1 and type T2 for each operand.⁵⁰ Then the following rules shall be applied to the promoted operands determine C:

• If both operands have T1 and T2 are the same type, no further conversion is needed C shall be that type.

• Otherwise, if both operands have T1 and T2 are both signed integer types or both have are unsigned integer types, the operand with the type of lesser integer conversion rank shall be converted to the type of the operand C shall be the type with greater rank.

• Otherwise, if the operand that has the type U that is an unsigned integer type has rank greater than or equal to the rank of the other type of the other operand, the operand with signed integer type shall be converted to the type of the operand with unsigned integer type, C shall be U.

• Otherwise, if the type of the operand with S that is a signed integer type can represent all of the values of the other type of the operand with unsigned integer type, the operand with unsigned integer type shall be converted to the type of the operand with signed integer type, C shall be S.

• Otherwise, both operands shall be converted to C shall be the unsigned integer type corresponding to the type of the operand with signed integer type.

Proposed resolution (approved by CWG 2023-02-09):

Change in 7.4 [expr.arith.conv] bullet 1.3 as follows, adding sub-bullets:

Otherwise, the integral promotions (7.3.7 [conv.prom]) are performed on both operands each operand is converted to a common type C. The integral promotion rules (7.3.7 [conv.prom]) are used to determine a type T1 and type T2 for each operand. [ Footnote: ... ] Then the following rules are applied to the promoted operands determine C:

• If both operands have T1 and T2 are the same type, no further conversion is needed C is that type.
• Otherwise, if T1 and T2 are both operands have signed integer types or are both have unsigned integer types, the operand with the type of lesser integer conversion rank is converted to the type of the operand C is the type with greater rank.
• Otherwise, if the operand that has let U be the unsigned integer type and S be the signed integer type.
  • If U has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type is converted to the type of the operand with unsigned integer type S, C is U.
  • Otherwise, if the type of the operand with signed integer type S can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type is converted to the type of the operand with signed integer type U, C is S.
  • Otherwise, both operands are converted to C is the unsigned integer type corresponding to the type of the operand with signed integer type S.

2517. Useless restriction on use of parameter in constraint-expression

[Accepted as a DR at the February, 2023 meeting.]

According to 7.5.7.5 [expr.prim.req.nested] paragraph 2,

A local parameter shall only appear as an unevaluated operand (7.2.3 [expr.context]) within the constraint-expression. [Example 2:

  template<typename T> concept C = requires (T a) {
    requires sizeof(a) == 4; // OK
    requires a == 0; // error: evaluation of a constraint variable
  };

—end example]

However, a can't be used in a constant expression in any event, so the restriction is meaningless, except for ruling out an expression like true ? true : a, but there seems no reason to have a special rule for such a case.

Proposed resolution (approved by CWG 2023-01-06):

A local parameter shall only appear as an unevaluated operand (7.2.3 [expr.context]) within the constraint-expression. [Example 2:

  template<typename T> concept C = requires (T a) {
    requires sizeof(a) == 4; // OK
    requires a == 0; // error: evaluation of a constraint variable
  };

Additional notes (February, 2023)

After adopting paper P2280, it is no longer accurate that any use of requirement parameters makes an expression non-constant. However, the resolution as adopted makes the treatment of examples like the following uniform in requirements and other constant expression contexts:

  template<typename ArrayType> concept LargeArray =
    requires (ArrayType my_array) { requires my_array.size() > 5; }

2526. Relational comparison of void* pointers

[Accepted as a DR at the February, 2023 meeting.]

Prior to the adoption of paper N3624 (resolving issue 1512), comparison of void* pointers was explicitly unspecified. The current wording of 7.6.9 [expr.rel], however, describes only comparison of “pointers to objects” (paragraphs 4 and 5), but a pointer to void is not a pointer to an object, only an object pointer type (as opposed to a function pointer type). Formally, that means that comparing void* pointers is undefined behavior, which seems undesirable.

As a related note, there is implementation divergence over whether relational comparisons of void* pointers are accepted in constant expressions (when the void* values are converted from pointers that would otherwise be comparable in constant expressions).

CWG 2022-11-11

Paper N3624 erroneously removed support for void* and function pointer relational comparisons. That ought to be restored.

Proposed resolution (approved by CWG 2023-02-09):

Change in 7.6.9 [expr.rel] paragraph 5 as follows:

... Otherwise, the result of each of the operators is unspecified. [ Note: A relational operator applied to unequal function pointers or to unequal pointers to void yields an unspecified result. -- end note ]

2523. Undefined behavior via omitted destructor call in constant expressions

[Accepted as a DR at the February, 2023 meeting.]

According to 7.7 [expr.const] bullet 5.8, one criterion that disqualifies an expression from being a core constant expression is:

an operation that would have undefined behavior as specified in Clause 4 [intro] through Clause 15 [cpp]

One potential source of undefined behavior is the omission of a call to a destructor for a constructed object, as described in 6.7.3 [basic.life] paragraph 5:

A program may end the lifetime of an object of class type without invoking the destructor, by reusing or releasing the storage as described above. [Note 3: A delete-expression (7.6.2.9 [expr.delete]) invokes the destructor prior to releasing the storage. —end note] In this case, the destructor is not implicitly invoked and any program that depends on the side effects produced by the destructor has undefined behavior.

For example:

  #include <memory>

  constexpr int test_basic_life_p5() {
    class guard_t {
      int &ref_;
    public:
      explicit constexpr guard_t(int &i) : ref_{i} {}
      constexpr ~guard_t() { ref_ = 42; }
    };

    int result = 0;

    auto alloc = std::allocator<guard_t>{};
    auto pguard = alloc.allocate(1);
    std::construct_at(pguard, result);
    // std::destroy_at(pguard);
    alloc.deallocate(pguard, 1);

    return result;  // value depends on destructor execution
  }

  int main() {
    constexpr auto v = test_basic_life_p5();
    return v;
  }

It is not clear that it is reasonable to require implementations to diagnose this form of undefined behavior in constant expressions.

A somewhat related question is raised by the restrictions on the use of longjmp in 17.13.3 [csetjmp.syn] paragraph 2:

A setjmp/longjmp call pair has undefined behavior if replacing the setjmp and longjmp by catch and throw would invoke any non-trivial destructors for any objects with automatic storage duration.

Here the undefined behavior occurs for any non-trivial destructor that is skipped, not just one for which the program depends on its side effects, as in 6.7.3 [basic.life] paragraph 5. Perhaps these two specifications should be harmonized.

Additional notes (April, 2022):

The phrase "[a] program that depends on the side effects" may have these meanings:

• the program depends on the side effects if it would have undefined behavior if they don't happen (which they don't): this would mean the second half of the sentence has no normative effect and can be struck
• the program depends on the side effects if it would have different observable behavior if (in violation of the standard) the destructor were actually invoked by the implementation when the object's lifetime ended
• something else

The second option would need a fork in the evaluation of constant expressions to determine whether undefined behavior occurs.

Proposed resolution (approved by CWG 2022-11-11):

Change in 6.7.3 [basic.life] paragraph 5 as follows:

A program may end the lifetime of an object of class type without invoking the destructor, by reusing or releasing the storage as described above. [Note 3: A delete-expression (7.6.2.9 [expr.delete]) invokes the destructor prior to releasing the storage. —end note] In this case, the destructor is not implicitly invoked and any program that depends on the side effects produced by the destructor has undefined behavior. [Note: The correct behavior of a program often depends on the destructor being invoked for each object of class type. -- end note]

2529. Constant destruction of constexpr references

[Accepted as a DR at the February, 2023 meeting.]

According to 9.2.6 [dcl.constexpr] paragraph 10, a constexpr variable must have constant destruction. However, 7.7 [expr.const] paragraph 7 only defines constant destruction for objects, not for references. Presumably constexpr references should also be able to have constant destruction, and any temporary object to which such a reference is bound should also be required to have constant destruction.

Proposed resolution (approved by CWG 2022-12-02):

Change in 9.2.6 [dcl.constexpr] paragraph 7 as follows:

A constexpr specifier used in an object declaration declares the object as const. Such an object shall have literal type and shall be initialized. In any constexpr variable declaration, the full-expression of the initialization shall be a constant expression (7.7 [expr.const]). A constexpr variable that is an object, as well as any temporary to which a constexpr reference is bound, shall have constant destruction. [ Example: ... ]

2558. Uninitialized subobjects as a result of an immediate invocation

[Accepted as a DR at the February, 2023 meeting.]

Consider:

  struct A {
    int n;
    consteval A() {}
  };
  constexpr A a; // implementations reject

Paper P1331R2 (Permitting trivial default initialization in constexpr contexts) dropped the restriction that immediate invocations cannot yield results with some subobjects left uninitialized. It is unclear whether that change was intentional or accidental.

Furthermore, indeterminate values of pointer type are currently not permitted as the result of a constant expression per 7.7 [expr.const] bullet 12.2; indeterminate values of scalar types are permitted only due to the absence of a restriction.

This issue is closely related to issue 2536.

2022-12-03

Forwarded to EWG with cplusplus/papers#1380.

EWG 2023-01-19

Uninitialized non-variant direct subobjects should not be allowed to appear in the result of a constant expression. There was no consensus in support of the statements "Union types shall be initialized such that they have an active member in the result of a constant expression" and "EWG confirms that padding bits and data belonging to non-active variant members are permitted to have indeterminate values in the static initialization of objects".

Proposed resolution (approved by CWG 2023-01-27):

Change in 7.7 [expr.const] paragraph 12 as follows:

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:

• 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,
• if the value is an object of scalar type, it does not have indeterminate value (6.7.4 [basic.indet]),
• ...
• if the value is an object of class or array type, each subobject satisfies these constraints for the value.

2658. Trivial copying of unions in core constant expressions

[Accepted as a DR at the February, 2023 meeting.]

Consider:

  struct A { char c; int x; };
  union U { A a; };
  constexpr int f() {
    U u;
    u.a.c = 1;
    u.a.x = 2;
    U v = u; // indeterminate padding bytes read!
    return u.a.x;
  }
  extern constexpr int x = f();

Subclause 7.7 [expr.const] bullet 5.11 added by P1331R2 prohibits lvalue-to-rvalue conversion of objects having indeterminate value during evaluation of a core constant expression. Trivial copy constructors of unions copy the object representation (not just the active member). The new prohibition causes cases where bytes not involved in the value presentation of the active member and having indeterminate values would prevent a union from being copied by a trivial copy constructor (for example, the padding bytes in the above case).

Note: The source of a union copy is never a prvalue within the evaluation of a trivial copy constructor because the reference parameter is bound to a glvalue.

Proposed resolution (January, 2023):

Add a new paragraph after 7.7 [expr.const] paragraph 6 as follows:

... to an object whose lifetime began within the evaluation of E.

For the purposes of determining whether E is a core constant expression, lvalue-to-rvalue conversion of an object of indeterminate value during the evaluation of a call to a trivial copy/move constructor or copy/move assignment operator of a union does not disqualify E from being a core constant expression unless the active member of the source union object contains a subobject of indeterminate value.

Proposed resolution (approved by CWG 2023-02-07):

Add a new paragraph after 7.7 [expr.const] paragraph 6 as follows:

... to an object whose lifetime began within the evaluation of E.

For the purposes of determining whether E is a core constant expression, the evaluation of a call to a trivial copy/move constructor or copy/move assignment operator of a union is considered to copy/move the active member of the union, if any. [ Note: The copy/move of the active member is trivial. -- end note ]

2602. consteval defaulted functions

[Accepted as a DR at the February, 2023 meeting.]

It is not clear whether a defaulted consteval function is still an immediate function even if it is not a valid constexpr function. For example:

  template <typename Ty>
  struct A {
    Ty n;
    consteval A() {}
  };

  template <typename Ty>
  struct B {
    Ty n;
    consteval B() = default;
  };

  A<int> a;
  B<int> b;

The declarations of a and b should both fail due to an uninitialized member n in each of A and B. The = default; should not make a difference. However, there is implementation divergence. We should be able to lean on 7.7 [expr.const] bullet 5.5 to handle this when the immediate invocation is required.

Possible resolution:

Change in 9.2.6 [dcl.constexpr] paragraph 7 as follows:

If the instantiated template specialization of a constexpr templated function template or member function of a class template would fail to satisfy the requirements for a constexpr function, that specialization is still a constexpr function, even though a call to such a function cannot appear in a constant expression. Similarly, if the instantiated template specialization of a consteval templated function would fail to satisfy the requirements for a consteval function, that specialization is still an immediate function, even though an immediate invocation would be ill-formed. If no specialization of the template would satisfy the requirements for a constexpr or consteval function when considered as a non-template function, the template is ill-formed, no diagnostic required.

Proposed resolution (August, 2022) [SUPERSEDED]:

Change in 9.2.6 [dcl.constexpr] paragraph 4 as follows:

If the instantiated template specialization of a constexpr templated function template or member function of a class template would fail to satisfy the requirements for a constexpr function, that specialization is still a constexpr function, even though a call to such a function cannot appear in a constant expression. Similarly, if the instantiated template specialization of a consteval templated function would fail to satisfy the requirements for a consteval function, that specialization is still an immediate function, even though an immediate invocation would be ill-formed.

Additional notes (November, 2022)

The proposed wording is possibly not addressing the point of the issue; the issue has been retracted from the WG21 plenary straw polls for further consideration in CWG.

Proposed resolution (approved by CWG 2023-01-27):

1. Change in 9.2.6 [dcl.constexpr] paragraph 3 as follows:

   The definition of a constexpr function shall satisfy the following requirements: A function is constexpr-suitable if:

   • it shall is not be a coroutine (9.5.4 [dcl.fct.def.coroutine]); , and
   • if the function is a constructor or destructor, its class shall does not have any virtual base classes.

   Except for instantiated constexpr functions, non-templated constexpr functions shall be constexpr-suitable.

2. Delete 9.2.6 [dcl.constexpr] paragraph 4:

   If the instantiated template specialization of a constexpr function template or member function of a class template would fail to satisfy the requirements for a constexpr function, that specialization is still a constexpr function, even though a call to such a function cannot appear in a constant expression.

3. Change in 7.5.5.2 [expr.prim.lambda.closure] paragraph 5 as follows:

   ... The function call operator or any given operator template specialization is a constexpr function if either the corresponding lambda-expression's parameter-declaration-clause is followed by constexpr or consteval, or it satisfies the requirements for a constexpr function is constexpr-suitable (9.2.6 [dcl.constexpr]). ...

4. Change in 7.7 [expr.const] bullet 5.5 as follows:

   • an invocation of an instantiated constexpr function that fails to satisfy the requirements for a constexpr function is not constexpr-suitable;

5. Change in 9.5.2 [dcl.fct.def.default] paragraph 3 as follows:

   A function explicitly defaulted on its first declaration is implicitly inline (9.2.8 [dcl.inline]), and is implicitly constexpr (9.2.6 [dcl.constexpr]) if it satisfies the requirements for a constexpr function is constexpr-suitable.

6. Change in 11.4.7 [class.dtor] paragraph 9 as follows:

   A defaulted destructor is a constexpr destructor if it satisfies the requirements for a constexpr function is constexpr-suitable (9.2.6 [dcl.constexpr]).

2543. constinit and optimized dynamic initialization

[Accepted as a DR at the February, 2023 meeting.]

Subclause 9.2.7 [dcl.constinit] paragraph 2 states:

If a variable declared with the constinit specifier has dynamic initialization (6.9.3.3 [basic.start.dynamic]), the program is ill-formed. [ Note: The constinit specifier ensures that the variable is initialized during static initialization (6.9.3.2 [basic.start.static]). —end note]

Subclause 6.9.3.2 [basic.start.static] paragraph 3 gives permission for an implementation to perform static initialization in lieu of dynamic initialization:

An implementation is permitted to perform the initialization of a variable with static or thread storage duration as a static initialization even if such initialization is not required to be done statically, provided that ...

constinit will assuredly not give a diagnostic for variables that are constant initialized (7.7 [expr.const] paragraph 2), because those are required to be statically initialized and thus will never be dynamically initialized. Conversely, constinit is guaranteed to give a diagnostic for variables that cannot be statically initialized, for example those with an initializer whose value depends on runtime conditions.

Between those boundaries, it is unclear whether constinit ought to give a diagnostic for variables whose initializer does not satisfy the constraints of constant-initialized, yet the implementation takes advantage of the permission to turn dynamic initialization into static initialization. For example,

  float f;
  constinit int * pi = (int*) &f;    // reinterpret_cast, not constant-initialized

The current wording seems to imply that constinit accurately reflects whether dynamic initialization was turned into static initialization by the implementation. However, that is impossible to implement, because such decisions are often made by the optimizer, which runs later than the compiler front-end interpreting the program text containing constinit.

There is value in permitting constinit not to diagnose some of the dynamic initializations that are turned into static initializations.

There is also value in having portable semantics of constinit.

See also issue 2536.

Notes from the November, 2022 meeting

CWG seeks the advice of EWG how to proceed with this issue, via cplusplus/papers#1379.

EWG 2023-01-19

EWG resolved to desire portable, guaranteed semantics for constinit. That means, constinit should produce a diagnostic if de-jure dynamic initialization is turned into de-facto static initialization as permitted by 6.9.3.2 [basic.start.static] paragraph 3.

Proposed resolution (approved by CWG 2023-02-06):

Change in 9.2.7 [dcl.constinit] paragraph 2 as follows:

If a variable declared with the constinit specifier has dynamic initialization (6.9.3.3 [basic.start.dynamic]), the program is ill-formed, even if the implementation would perform that initialization as a static initialization (6.9.3.2 [basic.start.static]). [Note 1: The constinit specifier ensures that the variable is initialized during static initialization (6.9.3.2 [basic.start.static]). —end note]

2483. Language linkage of static member functions

[Accepted as a DR at the February, 2023 meeting.]

According to 9.11 [dcl.link] paragraph 5,

A C language linkage is ignored in determining the language linkage of class members, friend functions with a trailing requires-clause, and the function type of class member functions.

It doesn't make sense that static member functions should behave like non-static member functions in this regard:

   extern "C" {
     struct A {
       static void f();
       constexpr static void (*p)()=f; // error: must point to a function whose type has C language linkage
     };
   }

Suggested resolution:

Change 9.11 [dcl.link] paragraph 5 as follows:

A C language linkage is ignored in determining the language linkage of class members, friend functions with a trailing requires-clause, and the function type of non-static class member functions.

Notes from the August, 2021 teleconference:

There was some question as to whether a linkage specification should affect the language linkage of any function declarators within class scope. The question was also raised as to whether some non-typedef syntax should be available for affecting language linkage, which would be a question for EWG.

Proposed resolution (approved by CWG 2022-11-10):

Change 9.11 [dcl.link] paragraph 5 as follows:

A C language linkage is ignored in determining the language linkage of class members, friend functions with a trailing requires-clause, and the function type of non-static class member functions.

2695. Semantic ignorability of attributes

[Accepted as a DR at the February, 2023 meeting.]

EWG resolved to reflect the understanding of semantic ignorability of attributes in a note.

Proposed resolution (approved by CWG 2023-02-09):

Add to 9.12.1 [dcl.attr.grammar] paragraph 6 as follows:

[Note 4: A program is ill-formed if it contains an attribute specified in 9.12 [dcl.attr] that violates the rules specifying to which entity or statement the attribute can apply or the syntax rules for the attribute's attribute-argument-clause, if any. —end note] [Note: The attributes specified in 9.12 [dcl.attr] 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 [intro.abstract]) 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. -- end note ]

2690. Semantics of defaulted move assignment operator for unions

[Accepted as a DR at the February, 2023 meeting.]

Subclause 11.4.6 [class.copy.assign] paragraph 13 does not specify the semantics of a defaulted move assignment operator:

The implicitly-defined copy assignment operator for a union X copies the object representation (6.8.1 [basic.types.general]) of X. ...

In contrast, the corresponding rule for move constructors is present in 11.4.5.3 [class.copy.ctor] paragraph 15:

The implicitly-defined copy/move constructor for a union X copies the object representation (6.8.1 [basic.types.general]) of X. ...

Proposed resolution (approved by CWG 2023-01-27):

Change in 11.4.6 [class.copy.assign] paragraph 13 as follows:

The implicitly-defined copy/move assignment operator for a union X copies the object representation (6.8.1 [basic.types.general]) of X. ...

2662. Example for member access control vs. overload resolution

[Accepted as a DR at the February, 2023 meeting.]

Issue 600 was resolved by P1787R6, but no example was added.

Proposed resolution (approved by CWG 2023-01-06):

Change in 11.8.1 [class.access.general] paragraph 4 as follows:

... When a using-declarator is named, access control is applied to it, not to the declarations that replace it. For an overload set, access control is applied only to the function selected by overload resolution.

[ Example:

  struct S {
    void f(int);
  private:
    void f(double);
  };

  void g(S* sp) {
    sp->f(2);    // OK, access control applied after overload resolution
  }

-- end example ]

2539. Three-way comparison requiring strong ordering for floating-point types

[Accepted as a DR at the February, 2023 meeting.]

Consider:

  struct MyType {
    int i;
    double d;
    std::strong_ordering operator<=> (const MyType& c) const = default;
  };

The defaulted three-way comparison operator is defined only if it is used, per 11.10.1 [class.compare.default] paragraph 1:

A comparison operator function for class C that is defaulted on its first declaration and is not defined as deleted is implicitly defined when it is odr-used or needed for constant evaluation.

The current rules make an odr-use of the three-way comparison operator ill-formed, but it would be preferable if it were deleted instead. In particular, 11.10.3 [class.spaceship] bullet 2.2 specifies

If the synthesized three-way comparison of type R between any objects x_i and x_i is not defined, the operator function is defined as deleted.

This refers to bullets 1.2 and 1.3 of 11.10.3 [class.spaceship] paragraph 1:

The synthesized three-way comparison of type R (17.11.2 [cmp.categories]) of glvalues a and b of the same type is defined as follows:

• If a <=> b is usable (11.10.1 [class.compare.default]), static_cast<R>(a <=> b).
• Otherwise, if overload resolution for a <=> b is performed and finds at least one viable candidate, the synthesized three-way comparison is not defined.
• Otherwise, if R is not a comparison category type, or either the expression a == b or the expression a < b is not usable, the synthesized three-way comparison is not defined.
• Otherwise, ...

However, a <=> b is actually usable, because 11.10.1 [class.compare.default] paragraph 3 defines:

A binary operator expression a @ b is usable if either

• a or b is of class or enumeration type and overload resolution (12.2 [over.match]) as applied to a @ b results in a usable candidate, or
• neither a nor b is of class or enumeration type and a @ b is a valid expression.

Proposed resolution (approved by CWG 2022-11-11) [SUPERSEDED]:

The synthesized three-way comparison of type R (17.11.2 [cmp.categories]) of glvalues a and b of the same type is defined as follows:

• If a <=> b is usable (11.10.1 [class.compare.default]) and
  • if overload resolution for a direct-initialization of an object or reference of type R from a <=> b results in a usable candidate, static_cast<R>(a <=> b),
  • otherwise, the synthesized three-way comparison is not defined.
• Otherwise, if overload resolution for a <=> b is performed and finds at least one viable candidate, the synthesized three-way comparison is not defined.
• Otherwise, if R is not a comparison category type, or either the expression a == b or the expression a < b is not usable, the synthesized three-way comparison is not defined.
• Otherwise, ...

CWG 2023-02-06

A simplification of the wording is sought.

Proposed resolution (approved by CWG 2023-02-07):

The synthesized three-way comparison of type R (17.11.2 [cmp.categories]) of glvalues a and b of the same type is defined as follows:

• If a <=> b is usable (11.10.1 [class.compare.default]) and can be explicitly converted to R using static_cast, static_cast<R>(a <=> b).
• Otherwise, if overload resolution for a <=> b is performed and finds at least one viable candidate, the synthesized three-way comparison is not defined.
• Otherwise, if R is not a comparison category type, or either the expression a == b or the expression a < b is not usable, the synthesized three-way comparison is not defined.
• Otherwise, ...

2673. User-declared spaceship vs. built-in operators

[Accepted as a DR at the February, 2023 meeting.]

Consider:

  #include <compare>

  enum class E : int {
    Lo = 0,
    Hi = 1
  };

  constexpr auto operator<=>(E lhs, E rhs) -> std::strong_ordering {
    return (int)rhs <=> (int)lhs;
  }

  // everybody agrees this is true
  static_assert((E::Lo <=> E::Hi) == std::strong_ordering::greater);

  // gcc rejects this, msvc and clang accept
  static_assert(E::Lo > E::Hi);  // #1

The intent here is for the user-provided operator<=> to suppress the built-in operator<=> for E. And gcc, clang, and msvc all agree that this does happen when the comparison expression explicitly uses a <=> b.

But when the comparison expression is a @ b for one of the relational operators, gcc disagrees, conforming to 12.2.2.3 [over.match.oper] bullet 3.3:

For all other operators, the built-in candidates include all of the candidate operator functions defined in 12.5 [over.built] that, compared to the given operator, ... do not have the same parameter-type-list as any non-member candidate that is not a function template specialization.

The issue is that, for #1, the user-provided operator<=> is not a non-member candidate, but a rewritten candidate. A similar situation arises for a user-declared operator==, which will be called for e1 == e2, but not for e1 != e2. Again, clang and MSVC disagree.

Proposed resolution (January, 2023) [SUPERSEDED]:

Change 12.2.2.3 [over.match.oper] bullet 3.3.4 as follows:

• ...
• do not have the same parameter-type-list as any non-member or rewritten candidate that is not a function template specialization.

Proposed resolution (approved by CWG 2023-02-10):

Change 12.2.2.3 [over.match.oper] bullet 3.3.4 as follows:

• ...
• 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.

2664. Deduction failure in CTAD for alias templates

[Accepted as a DR at the February, 2023 meeting.]

Subclause 12.2.2.9 [over.match.class.deduct] paragraph 3 has an exception only for deduction failure for non-deduced contexts when deducing the return type from the defining-type-id, but not for other cases where deduction fails according to 13.10.3.6 [temp.deduct.type] paragraph 2. For example,

  template <class S1, class S2> struct C {
    C(...);
  };

  template<class T1> C(T1) -> C<T1, T1>;
  template<class T1, class T2> C(T1, T2) -> C<T1 *, T2>;

  template<class V1, class V2> using A = C<V1, V2>;

  C c1{""};
  A a1{""};

  C c2{"", 1};
  A a2{"", 1};

resulting in A having neither of these deduction guides. There is implementation divergence in the handling of this example.

Suggested resolution:

We could say that cases where P involves a template parameter and A is not of the same form (under 13.10.3.6 [temp.deduct.type] paragraph 8) are non-deduced contexts for the purpose of these deductions. That should be enough to make it clear what happens for a2, where we'd deduce T2 = V2, and not deduce anything for T1, but wouldn't fix a1 due to the inconsistent deductions for T1; maybe this is what MSVC is doing. We could further fix a1 by allowing inconsistent deductions and treating them as if no value was deduced. Another option might be to do independent deductions for each template argument of the simple-template-id, and then try to merge the results for template arguments where deduction was successful; that'd be clearer that deduction can't fail, but would deduce less.

CWG 2023-02-08

In the example, A is the most trivial alias template imaginable; having this cause issues depending on the details of C is concerning.

Proposed resolution (approved by CWG 2023-02-09):

Change in 12.2.2.9 [over.match.class.deduct] paragraph 3 as follows:

... For each function or function template f in the guides of the template named by the simple-template-id of the defining-type-id, the template arguments of the return type of f are deduced from the defining-type-id of A according to the process in 13.10.3.6 [temp.deduct.type] with the exception that deduction does not fail if not all template arguments are deduced. If deduction fails for another reason, proceed with an empty set of deduced template arguments Let g denote the result of substituting these deductions into f. ...

2681. Deducing member array type from string literal

[Accepted as a DR at the February, 2023 meeting.]

Consider:

  template<typename T, std::size_t N>
  struct A {
    T array[N];
  };

  A a = { "meow" };

The current wording says in 12.2.2.9 [over.match.class.deduct] bullet 1.8:

• if ei is of array type and xi is a braced-init-list or string-literal, Ti is an rvalue reference to the declared type of ei, and
• ...

This will fail overload resolution, because a string literal (which is an lvalue) does not match a parameter of type T (&&)[N].

Proposed resolution (approved by CWG 2023-02-07):

1. Change in 12.2.2.9 [over.match.class.deduct] paragraph 1.8 as follows:

   • if e_i is of array type and x_i is a braced-init-list or string-literal, T_i is an rvalue reference to the declared type of e_i, and
   • if e_i is of array type and x_i is a string-literal, T_i is an lvalue reference to the const-qualified declared type of e_i, and
   • ...

2. Append to the example in 12.2.2.9 [over.match.class.deduct] paragraph 2 as follows:

     G g(true, 'a', 1); // OK, deduces G<char, bool>
   

     template<class T, std::size_t N>
     struct H {
       T array[N];
     };
     template<class T, std::size_t N>
     struct I {
       volatile T array[N];
     };
     template<std::size_t N>
     struct J {
       unsigned char array[N];
     };
   
     H h = { "abc" };  // OK, deduces H<char, 4> (not T = const char)
     I i = { "def" };  // OK, deduces I<char, 4>
     J j = { "ghi" };  // error: cannot bind reference to array of unsigned char to array of char in deduction
   

2685. Aggregate CTAD, string, and brace elision

[Accepted as a DR at the February, 2023 meeting.]

Consider:

  template <class T>
  struct A {
    T ar[4];
  };
  A a = { "foo" }; 

Subclause 12.2.2.9 [over.match.class.deduct] bullet 1.5 specifies:

For each xi, let ei be the corresponding aggregate element of C or of one of its (possibly recursive) subaggregates that would be initialized by xi (9.4.2 [dcl.init.aggr]) if

• brace elision is not considered for any aggregate element that has a dependent non-array type or an array type with a value-dependent bound, and
• ...

The normative rule does not properly consider arrays with dependent element type, initialized by a string literal. MSVC accepts, gcc and clang reject the example.

Suggested resolution [SUPERSEDED]:

Change in 12.2.2.9 [over.match.class.deduct] bullet 1.5 as follows:

For each xi, let ei be the corresponding aggregate element of C or of one of its (possibly recursive) subaggregates that would be initialized by xi (9.4.2 [dcl.init.aggr]) if

• brace elision is not considered for any aggregate element that has
  • a dependent non-array type or ,
  • an array type with a value-dependent bound, or
  • a string literal as the corresponding initializer and that has an array type whose element type is a (possibly cv-qualified) template parameter or is a dependent type specified with a qualified-id whose nested-name-specifier is dependent or with a decltype-specifier; and
• ...

Proposed resolution (approved by CWG 2023-02-09):

Change in 12.2.2.9 [over.match.class.deduct] bullet 1.5 as follows:

For each xi, let ei be the corresponding aggregate element of C or of one of its (possibly recursive) subaggregates that would be initialized by xi (9.4.2 [dcl.init.aggr]) if

• brace elision is not considered for any aggregate element that has
  • a dependent non-array type or ,
  • an array type with a value-dependent bound, or
  • an array type with a dependent array element type and x_i is a string literal; and
• ...

2521. User-defined literals and reserved identifiers

[Accepted as a DR at the February, 2023 meeting.]

The example in 12.6 [over.literal] paragraph 8 has the following lines:

  double operator""_Bq(long double);  // OK: does not use the reserved identifier _Bq (5.10)
  double operator"" _Bq(long double); // ill-formed, no diagnostic required:
                                      // uses the reserved identifier _Bq (5.10)

The referenced rule in 5.10 [lex.name] is in bullet 3.1:

Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.

The distinction being drawn in the user-defined literal example apparently relies on the grammar for literal-operator-id at the beginning of 12.6 [over.literal]:

literal-operator-id:
operator string-literal identifier
operator user-defined-string-literal

The second production does not mention the syntactic non-terminal identifier, so the literal-operator-id operator""_Bq presumably does not run afoul of the restriction in 5.10 [lex.name]. However, the grammar for user-defined-string-literal in 5.13.8 [lex.ext] is:

user-defined-string-literal:
string-literal ud-suffix

ud-suffix:
identifier

There doesn't seem to be a rule that exempts the identifier that is the ud-suffix of a user-defined-string-literal from the restriction in 5.10 [lex.name]. Either the example is incorrect or there needs to be a refinement of the rule in 5.10 [lex.name].

CWG 2022-11-11

CWG feels that the ostensible significance of whitespace in this context is unfortunate. In addition, since the normative rule is not consistent with the example, CWG solicits EWG input on the handling of this issue via cplusplus/papers#1367.

EWG 2023-02-06

EWG had consensus on "The form of User Defined Literals that permits a space between the quotes and the name of the literal should be deprecated, and eventually removed. Additionally, the UDL name should be excluded from the restriction in 5.10 [lex.name] in the non-deprecated form (sans space)."

Proposed resolution (February, 2023) [SUPERSEDED]:

1. Change in 5.10 [lex.name] paragraph 3 as follows:

   In addition, some identifiers appearing as a token or pp-token are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required.

2. Change in 12.6 [over.literal] paragraph 1 as follows:

   The string-literal or user-defined-string-literal in a literal-operator-id shall have no encoding-prefix and shall contain no characters other than the implicit terminating '\0'. The ud-suffix of the user-defined-string-literal or the identifier in a literal-operator-id is called a literal suffix identifier. The first form of literal-operator-id is deprecated. Some literal suffix identifiers are reserved for future standardization; see 16.4.5.3.6 [usrlit.suffix]. A declaration whose literal-operator-id uses such a literal suffix identifier is ill-formed, no diagnostic required.

3. Change in 12.6 [over.literal] paragraph 8 as follows:

     void operator "" _km(long double);         // OK
     string operator "" _i18n(const char*, std::size_t); // OK, deprecated
     template <char...> double operator "" _\u03C0();  // OK, UCN for lowercase pi
     float operator ""_e(const char*);          // OK
     float operator ""E(const char*);          // ill-formed, no diagnostic required:
   			    // reserved literal suffix ([usrlit.suffix], [lex.ext])
     double operator""_Bq(long double);         // OK, does not use the reserved identifier _Bq ([lex.name])
     double operator"" _Bq(long double);         // ill-formed, no diagnostic required:
   			    // uses the reserved identifier _Bq ([lex.name])
     float operator " " B(const char*);         // error: non-empty string-literal
     string operator "" 5X(const char*, std::size_t);  // error: invalid literal suffix identifier
     double operator "" _miles(double);         // error: invalid parameter-declaration-clause
     template <char...> int operator "" _j(const char*); // error: invalid parameter-declaration-clause
     extern "C" void operator "" _m(long double);    // error: C language linkage
   

4. Add a new subclause after D.8 [depr.impldec]:

   D.9 Literal operator function declarations using an identifier [depr.lit]

   A literal-operator-id (12.6 [over.literal]) of the form

       operator string-literal identifier
   

   is deprecated.

CWG 2023-02-07

Some implementers are concerned about the lack of space for implementation extensions. The suggestion is to reserve literal suffix identifiers starting with two underscores for the implementation in 16.4.5.3.6 [usrlit.suffix]. EWG is invited to comment on that direction.

EWG / LEWG 2023-02-07

EWG and LEWG resolved to amend the proposed resolution for CWG2521 to reserve literal suffix identifiers with double underscores anywhere for implementation use.

Proposed resolution (approved by CWG 2023-02-09):

1. Change in 5.10 [lex.name] paragraph 3 as follows:

   In addition, some identifiers appearing as a token or pp-token are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required.

2. In 5.13.8 [lex.ext], modify all occurrences as follows:

   operator "" X
   

3. Change in 5.13.8 [lex.ext] paragraph 7 as follows:

   long double operator "" _w(long double);
   std::string operator "" _w(const char16_t*, std::size_t);
   unsigned operator "" _w(const char*);
   int main() {
     1.2_w;      // calls operator "" _w(1.2L)
     u"one"_w;   // calls operator "" _w(u"one", 3)
     12_w;       // calls operator "" _w("12")
     "two"_w;    // error: no applicable literal operator
   }
   

4. Change in 12.6 [over.literal] paragraph 1 as follows:

   The string-literal or user-defined-string-literal in a literal-operator-id shall have no encoding-prefix and shall contain no characters other than the implicit terminating '\0'. The ud-suffix of the user-defined-string-literal or the identifier in a literal-operator-id is called a literal suffix identifier. The first form of literal-operator-id is deprecated. Some literal suffix identifiers are reserved for future standardization; see 16.4.5.3.6 [usrlit.suffix]. A declaration whose literal-operator-id uses such a literal suffix identifier is ill-formed, no diagnostic required.

5. Change in 12.6 [over.literal] paragraph 8 as follows:

     void operator "" _km(long double);         // OK
     string operator "" _i18n(const char*, std::size_t); // OK, deprecated
     template <char...> double operator "" _\u03C0();  // OK, UCN for lowercase pi
     float operator ""_e(const char*);          // OK
     float operator ""E(const char*);          // ill-formed, no diagnostic required:
   			    // reserved literal suffix ([usrlit.suffix], [lex.ext])
     double operator""_Bq(long double);         // OK, does not use the reserved identifier _Bq ([lex.name])
     double operator"" _Bq(long double);         // ill-formed, no diagnostic required:
   			    // uses the reserved identifier _Bq ([lex.name])
     float operator " " B(const char*);         // error: non-empty string-literal
     string operator "" 5X(const char*, std::size_t);  // error: invalid literal suffix identifier
     double operator "" _miles(double);         // error: invalid parameter-declaration-clause
     template <char...> int operator "" _j(const char*); // error: invalid parameter-declaration-clause
     extern "C" void operator "" _m(long double);    // error: C language linkage
   

6. Change in 16.4.5.3.6 [usrlit.suffix] as follows:

   Literal suffix identifiers (12.6 [over.literal]) that do not start with an underscore are reserved for future standardization. Literal suffix identifiers that contain a double underscore __ are reserved for use by C++ implementations.

7. Add a new subclause after D.8 [depr.impldec]:

   D.9 Literal operator function declarations using an identifier [depr.lit]

   A literal-operator-id (12.6 [over.literal]) of the form

       operator string-literal identifier
   

   is deprecated.

2682. Templated function vs. function template

[Accepted as a DR at the February, 2023 meeting.]

In 13.1 [temp.pre] paragraph 8, the phrase "templated entity" is defined. The derived term "templated function" is never actually defined, but is intended to apply to function templates as well as non-template members of class templates. Similarly, the phrases "templated variable" and "templated class" should be properly defined.

Proposed resolution (approved by CWG 2023-01-27):

1. Change in 9.2.9.6.1 [dcl.spec.auto.general] paragraph 12 as follows:

   Return type deduction for a templated entity that is a function or function template with a placeholder in its declared type occurs when the definition is instantiated even if the function body contains a return statement with a non-type-dependent operand.

2. Change in 13.1 [temp.pre] paragraph 8 as follows:

   [Note 6: A local class, a local or block variable, or a friend function defined in a templated entity is a templated entity. —end note]
   A templated function is a function template or a function that is templated. A templated class is a class template or a class that is templated. A templated variable is a variable template or a variable that is templated.

2072. Default argument instantiation for member functions of templates

[Accepted as a DR at the February, 2023 meeting.]

Default argument instantiation is described in 13.9.2 [temp.inst] paragraph 12, and although instantiation of default arguments for member functions of class templates is mentioned elsewhere a number of times, this paragraph only describes default argument instantiation for function templates.

Proposed resolution (approved by CWG 2023-02-06):

Change in 13.9.2 [temp.inst] paragraph 12 as follows:

If a templated function template f 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 f used at that point, except that the scope in which a closure type is declared (7.5.5.2 [expr.prim.lambda.closure]) --- and therefore its associated namespaces --- 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 f.

2478. Properties of explicit specializations of implicitly-instantiated class templates

[Accepted as a DR at the February, 2023 meeting.]

According to 13.9.4 [temp.expl.spec] paragraph 16,

A member or a member template of a class template may be explicitly specialized for a given implicit instantiation of the class template, even if the member or member template is defined in the class template definition. An explicit specialization of a member or member template is specified using the syntax for explicit specialization.

The relationship between this construct and paragraph 14 is not clear:

Whether an explicit specialization of a function or variable template is inline, constexpr, or an immediate function is determined by the explicit specialization and is independent of those properties of the template.

(See also 9.2.6 [dcl.constexpr] paragraph 1, note 1.) Is this intended to apply to explicit specializations of members of implicitly-instantiated class templates? For example:

  template<typename T> struct S {
    int f();
    constexpr int g();
  };
  template<> constexpr int S<int>::f() {  // OK, constexpr?
    return 0;
  }
  template<> int S<int>::g() {            // OK, not constexpr?
    return 0;
  }

There is implementation divergence on the treatment of this example. This divergence may relate to interpretation of the requirement in 9.2.6 [dcl.constexpr] paragraph 1,

If any declaration of a function or function template has a constexpr or consteval specifier, then all its declarations shall contain the same specifier.

Is an explicit specialization of a member of an implicitly-instantiated class template a declaration of that member? A similar question also applies to the constinit specifier as specified in 9.2.7 [dcl.constinit] paragraph 1:

If the specifier is applied to any declaration of a variable, it shall be applied to the initializing declaration.

(Note that constinit is not mentioned in 13.9.4 [temp.expl.spec] paragraph 14.) For example:

  template<typename T> struct S {
    static constinit T x;
  };
  template<> int S<int>::x = 10;    // constinit required?
  extern char c;
  template<> short S<char>::x = c;  // error, c not constant?

(Possibly relevant is the fact that default arguments are prohibited in explicit specializations of member functions of implicitly-instantiated class templates, per 13.9.4 [temp.expl.spec] bullet 21.3.)

CWG 2022-11-10

A specialization of a member of a class template redeclares the member of the primary template and thus the redeclaration rules apply. In passing, it was noticed that the rule governing explicit specializations in general omitted treatment of constinit, which was considered an oversight.

Proposed resolution (approved 2023-02-09):

Change in 13.9.4 [temp.expl.spec] paragraph 13 as follows:

Whether an explicit specialization of a function or variable template is inline, constexpr, constinit, or consteval an immediate function is determined by the explicit specialization and is independent of those properties of the template.

2667. Named module imports do not import macros

[Accepted as a DR at the February, 2023 meeting.]

It should be clarified via an example or a note that named module imports do not make macros available.

Proposed resolution (approved by CWG 2023-01-06):

1. Change in 10.3 [module.import] paragraph 7 as follows:

   ... These rules can in turn lead to the importation of yet more translation units. [ Note: Such indirect importation does not make macros available, because a translation unit is a sequence of tokens in translation phase 7 (5.2 [lex.phases]). Macros can be made available by directly importing header units as described in 15.5 [cpp.import]. -- end note ]

2. Add to the example in 15.5 [cpp.import] paragraph 8 as follows:

     import "a.h";  // point of definition of #1, #2, and #3, point of undefinition of #1 in "e.h"
     import "d.h";  // point of definition of #4 and #5 in "e.h"
     int a = Y;     // OK, active macro definitions #2 and #4 are valid redefinitions
     int c = Z;     // error: active macro definitions #3 and #5 are not valid redefinitions of Z
   

   Module unit f:

   export module f;
   export import "a.h";
   
   int a = Y;    // OK
   

   Translation unit #1:

   import f;
   int x = Y;   // error: Y is neither a defined macro nor a declared name
   

   -- end example ]

Issues with "accepted" Status

2691. hexadecimal-escape-sequence is too greedy

[Accepted at the February, 2023 meeting.]

The lexer grammar production hexadecimal-escape-sequence matches text of the form \x{20}ab due to its recursive definition.

Proposed resolution (approved by CWG 2023-01-27):

Change in 5.13.3 [lex.ccon] as follows:

hexadecimal-escape-sequence :
     \x hexadecimal-digit simple-hexadecimal-digit-sequence
     hexadecimal-escape-sequence hexadecimal-digit
     \x{ simple-hexadecimal-digit-sequence }

2674. Prohibit explicit object parameters for constructors

[Accepted at the February, 2023 meeting.]

Constructors are not intended to have explicit object parameters, but the standard is missing a corresponding prohibition.

Proposed resolution (approved by CWG 2023-01-06):

Add a new paragraph after 11.4.5.1 [class.ctor.general] paragraph 7 as follows:

A constructor shall not be a coroutine.

A constructor shall not have an explicit object parameter (9.3.4.6 [dcl.fct]).

2692. Static and explicit object member functions with the same parameter-type-lists

[Accepted at the February, 2023 meeting as part of paper P2797R0.]

(Split off from issue 2687.)

Consider:

  struct A {
    static void f(A);
    void f(this A);

    void g();
  };

  void A::g() {
    (&A::f)(A()); // #1
    (&A::f)();    // #2
  }

It is obvious that #2 is ill-formed, but what about #1? One possible answer is to make such declarations conflict.

Suggested resolution:

1. Change in 6.4.1 [basic.scope.scope] paragraph 3, adding bullets, a follows:

   Two function templates have corresponding signatures if

   • their template-parameter-lists have the same length,
   • their corresponding template-parameters are equivalent,
   • they have equivalent
     • parameter-type-lists or non-object-parameter-type-lists and
     • return types (if any), and,
   • if both are non-static members, they have corresponding object parameters.

2. Change in 6.4.1 [basic.scope.scope] bullet 4.3.1 as follows:

   • both declare functions with the same parameter-type-list or non-object-parameter-type-list [Footnote: ...], equivalent (13.7.7.2 [temp.over.link]) trailing requires-clauses (if any, except as specified in 13.7.5 [temp.friend]), and, if both are non-static members, they have corresponding object parameters, or

CWG 2023-01-27

Forward to EWG to determine whether such member declarations are considered sufficiently confusing to outweigh concerns of language orthogonality; see plusplus/papers#1455.

2659. Missing feature-test macro for lifetime extension in range-for loop

[Accepted at the February, 2023 meeting.]

Paper P2718R0 (Wording for P2644R1 Fix for Range-based for Loop), adopted at the November, 2022 meeting, omitted a consideration of a feature-test macro, although one is desirable.

Proposed resolution (approved by CWG 2023-01-06):

Change in 15.11 [cpp.predefined] table 23 as follows:

  __cpp_range_based_for 201603L 202211L

Issues with "DRWP" Status

2641. Redundant specification of value category of literals

[Accepted as a DR at the November, 2022 meeting.]

Subclause 7.5.1 [expr.prim.literal] paragraph 1 specifies:

... A string-literal is an lvalue designating a corresponding string literal object (5.13.5 [lex.string]), a user-defined-literal has the same value category as the corresponding operator call expression described in 5.13.8 [lex.ext], and any other literal is a prvalue.

Yet, there is redundant specification in 5.13.2 [lex.icon] paragraph 3:

The type of an integer-literal is the first type in the list in Table 9 corresponding to its optional integer-suffix in which its value can be represented. An integer-literal is a prvalue.

And in 5.13.6 [lex.bool] paragraph 1:

The Boolean literals are the keywords false and true. Such literals are prvalues and have type bool.

And in 5.13.7 [lex.nullptr] paragraph 1:

The pointer literal is the keyword nullptr. It is a prvalue of type std::nullptr_t.

Proposed resolution (approved by CWG 2022-11-10):

1. Change in 5.13.1 [lex.literal.kinds] paragraph 1 as follows:

   There are several kinds of literals. [ Footnote: ... ]

   literal:
       integer-literal
       character-literal
       floating-point-literal
       string-literal
       boolean-literal
       pointer-literal
       user-defined-literal
   

   [ Note: When appearing as an expression, a literal has a type and a value category (7.5.1 [expr.prim.literal]). -- end note ]

2. Change in 5.13.2 [lex.icon] paragraph 3 as follows:

   The type of an integer-literal is the first type in the list in Table 9 corresponding to its optional integer-suffix in which its value can be represented. An integer-literal is a prvalue.

3. Change in 5.13.6 [lex.bool] paragraph 1 as follows:

   The Boolean literals are the keywords false and true. Such literals are prvalues and have type bool.

4. Change in 5.13.7 [lex.nullptr] paragraph 1 as follows:

   The pointer literal is the keyword nullptr. It is a prvalue of has type std::nullptr_t.

2242. ODR violation with constant initialization possibly omitted

[Accepted as a DR at the November, 2022 meeting.]

Consider the following example:

  // tu1.cpp
  extern const int a = 1;
  inline auto f() {
    static const int b = a;
    struct A { auto operator()() { return &b; } } a;
    return a;
  }

  // tu2.cpp
  extern const int a;
  inline auto f() {
    static const int b = a;
    struct A { auto operator()() { return &b; } } a;
    return a;
  }
  int main() {
    return *decltype(f())()();
  }

Here, b may or may not have constant initialization. This example should be an ODR violation.

(Split off from issue 2123.)

Proposed resolution (approved by CWG 2022-11-11):

Insert after 6.3 [basic.def.odr] bullet 14.7 as follows:

• ...
• In each such definition, corresponding entities shall have the same language linkage.
• In each such definition, const objects with static or thread storage duration shall be constant-initialized if the object is constant-initialized in any such definition.
• ...

2625. Deletion of pointer to out-of-lifetime object

[Accepted as a DR at the November, 2022 meeting.]

Consider:

struct S {};

int main() {
  S* p = new S;
  p->~S();
  delete p;
}

This code appears to be allowed per 6.7.3 [basic.life] bullet 6.1:

The program has undefined behavior if:

• the object will be or was of a class type with a non-trivial destructor and the pointer is used as the operand of a delete-expression,
• ...

However, this calls the (trivial) destructor on *p twice. Invoking a non-static member function of an out-of-lifetime object is generally undefined behavior per 6.7.3 [basic.life] bullet 6.2 and 6.7.3 [basic.life] bullet 7.2. The rules ought to be consistent.

Proposed resolution (approved by CWG 2022-10-07):

Change in 6.7.3 [basic.life] bullet 6.1 as follows:

The program has undefined behavior if:

• the object will be or was of a class type with a non-trivial destructor and the pointer is used as the operand of a delete-expression,
• ...

900. Lifetime of temporaries in range-based for

[Accepted at the November, 2022 meeting as part of paper P2718R0.]

Temporaries created in the expression of the range-based for statement are not given special treatment, so they only persist to the end of the expression. This can lead to undefined behavior as __range and the iterators are used in the expansion of the statement. Such temporaries should have their lifetimes extended until the end of the statement.

Rationale (October, 2009):

In the expansion, expression is used to initialize a reference. If expression is a temporary, its lifetime is thus extended to that of the reference, which is the entire for statement.

Additional notes, February, 2017:

Posting from Daniel Frey to the std-discussion group:

Some people have tried

  namespace detail {
    template< class C > struct reverse_range {
      explicit reverse_range (C& _c) : c(_c) {}
      auto begin () { using std::rbegin; return rbegin(c); }
      auto end () { using std::rend; return rend(c); }
     private:
      C& c;
    };
  }


  template< class C > auto reverse (C& c) {
    return detail::reverse_range<C>{c};
  }

In an attempt to allow:

  // some function
  std::vector<int> foo();

  // correct usage
  auto v = foo();
  for( auto i : reverse(v) ) { std::cout << i << std::endl; }

  // problematic usage
  for( auto i : reverse(foo()) ) { std::cout << i << std::endl; }

The problem is that the temporary returned by foo() is destructed before the loop starts executing. [This issue] was supposed to be about that, but considers only the top-level temporary.

It might be reasonable to make the range-based for treat the for-range-initializer like a function argument: all temporaries of the expression should be destructed after the execution of the loop. This also removes the only place where binding a reference to a temporary extends its lifetime implicitly, unseen by the user.

Notes from the February, 2017 meeting:

CWG was inclined to accept the suggested change but felt that EWG involvement was necessary prior to such a decision.

2598. Unions should not require a non-static data member of literal type

[Accepted as a DR at the November, 2022 meeting.]

According to 6.8.1 [basic.types.general] paragraph 10, a type is a literal type only if it satisfies the following:

A type is a literal type if it is:

• ...
• a possibly cv-qualified class type (Clause 11 [class]) that has all of the following properties:
  • it has a constexpr destructor (9.2.6 [dcl.constexpr]),
  • it is either a closure type (7.5.5.2 [expr.prim.lambda.closure]), an aggregate type (9.4.2 [dcl.init.aggr]), or has at least one constexpr constructor or constructor template (possibly inherited (9.9 [namespace.udecl]) from a base class) that is not a copy or move constructor,
  • if it is a union, at least one of its non-static data members is of non-volatile literal type, and
  • if it is not a union, all of its non-static data members and base classes are of non-volatile literal types.

[Note 4: A literal type is one for which it might be possible to create an object within a constant expression. ... —end note]

However, the normative rule disagrees with the note. Consider:

  struct A { A(); };
  union U {
    A a;
    constexpr U() {}
    constexpr ~U() {}
  };

It is certainly possible to create an object of type U in a constant expression, even though U is not a literal type.

In the suggested resolution, the aggregate type rule is intended to capture the fact that it is not possible for aggregate initialization of a non-empty union to leave no active member (and similarly for each anonymous union member in a non-union union-like class).

Suggested resolution [SUPERSEDED]:

Change in 6.8.1 [basic.types.general] paragraph 10 as follows:

A type is a literal type if it is:

• ...
• a possibly cv-qualified class type (Clause 11 [class]) that has all of the following properties:
  • it has a constexpr destructor (9.2.6 [dcl.constexpr]),
  • it is either
    • is a closure type (7.5.5.2 [expr.prim.lambda.closure]),
    • is an aggregate type (9.4.2 [dcl.init.aggr]) for which that type (if it is a union) or each of its anonymous union members (otherwise) either has at least one variant member of non-volatile literal type or has no variant members, or
    • has at least one constexpr constructor or constructor template (possibly inherited (9.9 [namespace.udecl]) from a base class) that is not a copy or move constructor, and
  • if it is a union, at least one of its non-static data members is of non-volatile literal type, and
  • if it is not a union, all of its non-static non-variant data members and base classes are of non-volatile literal types.

Proposed resolution (CWG telecon 2022-08-12) [SUPERSEDED]:

Change in 6.8.1 [basic.types.general] paragraph 10 as follows:

A type is a literal type if it is:

• ...
• a possibly cv-qualified class type (Clause 11 [class]) that has all of the following properties:
  • it has a constexpr destructor (9.2.6 [dcl.constexpr]),
  • all of its non-static non-variant data members and base classes are of non-volatile literal types, and
  • it is either
    • is a closure type (7.5.5.2 [expr.prim.lambda.closure]),
    • is an aggregate type (9.4.2 [dcl.init.aggr]) for which that type (if it is a union) or each of its anonymous union members (otherwise) either has at least one variant member of non-volatile literal type or has no variant members, or
    • has at least one constexpr constructor or constructor template (possibly inherited (9.9 [namespace.udecl]) from a base class) that is not a copy or move constructor, .
  • if it is a union, at least one of its non-static data members is of non-volatile literal type, and
  • if it is not a union, all of its non-static data members and base classes are of non-volatile literal types.

Proposed resolution (approved by CWG 2022-11-09):

Change 6.8.1 [basic.types.general] paragraph 10 as follows:

A type is a literal type if it is:

• ...

• a possibly cv-qualified class type (Clause 11 [class]) that has all of the following properties:

• it has a constexpr destructor (9.2.6 [dcl.constexpr]),

• all of its non-static non-variant data members and base classes are of non-volatile literal types, and

• it is either

• is a closure type (7.5.5.2 [expr.prim.lambda.closure]),

• an aggregate type (9.4.2 [dcl.init.aggr]),

• is an aggregate union type that has either no variant members or at least one variant member of non-volatile literal type,

• is a non-union aggregate type for which each of its anonymous union members satisfies the above requirements for an aggregate union type, or

• has at least one constexpr constructor or constructor template (possibly inherited (9.9 [namespace.udecl]) from a base class) that is not a copy or move constructor,.

• if it is a union, at least one of its non-static data members is of non-volatile literal type, and

• if it is not a union, all of its non-static data members and base classes are of non-volatile literal types.

2643. Completing a pointer to array of unknown bound

[Accepted as a DR at the November, 2022 meeting.]

Subclause 6.8.1 [basic.types.general] paragraph 6 specifies:

... The type of a pointer to array of unknown bound, or of a type defined by a typedef declaration to be an array of unknown bound, cannot be completed.

This is misleading; such a type is already complete.

Proposed resolution:

Change in 6.8.1 [basic.types.general] paragraph 6 as follows:

... [ Note: 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 , or of a type defined named by a typedef declaration to be an array of unknown bound, permanently refers to an incomplete type. In either case, the array type cannot be completed. -- end note ]

2644. Incorrect comment in example

[Accepted as a DR at the November, 2022 meeting.]

The comment in the example in 7.5.5.3 [expr.prim.lambda.capture] paragraph 6 refers to "local variable", but should refer to init-capture instead.

Possible resolution:

Change in 7.5.5.3 [expr.prim.lambda.capture] paragraph 6 as follows:

  auto z = [a = 42](int a) { return 1; };   // error: parameter and conceptual local variable have the same name

2599. What does initializing a parameter include?

[Accepted as a DR at the November, 2022 meeting.]

Subclause 7.6.1.3 [expr.call] paragraph 8 specifies:

The postfix-expression is sequenced before each expression in the expression-list 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. [Note 8: All side effects of argument evaluations are sequenced before the function is entered (see 6.9.1 [intro.execution]). —end note]

Consider:

  f(std::unique_ptr<int>(new int),std::unique_ptr<int>(new int));

It is not clear from the phrasing whether the evaluation of each new int is part of the "initialization of [its] parameter" or whether only the initialization of f's parameters from the completed std::unique_ptr<int> objects is included. The note does not help, since it can be read as distinguishing argument evaluations from initialization.

Suggested resolution [SUPERSEDED]:

Insert before 9.4.1 [dcl.init.general] paragraph 18 as follows:

An initializer-clause followed by an ellipsis is a pack expansion (13.7.4 [temp.variadic]).

Initialization includes the evaluation of all subexpressions of each initializer-clause of the initializer (possibly nested within braced-init-lists).

If the initializer is a parenthesized expression-list, the expressions are evaluated in the order specified for function calls (7.6.1.3 [expr.call]).

Proposed resolution (approved by CWG 2022-08-26):

Insert before 9.4.1 [dcl.init.general] paragraph 18 as follows:

An initializer-clause followed by an ellipsis is a pack expansion (13.7.4 [temp.variadic]).

Initialization includes the evaluation of all subexpressions of each initializer-clause of the initializer (possibly nested within braced-init-lists) and the creation of any temporary objects for function arguments or return values (6.7.7 [class.temporary]).

If the initializer is a parenthesized expression-list, the expressions are evaluated in the order specified for function calls (7.6.1.3 [expr.call]).

2645. Unused term "default argument promotions"

[Accepted as a DR at the November, 2022 meeting.]

The phrase "default argument promotions" is apparently unused.

Possible resolution [SUPERSEDED]:

1. Change in 7.6.1.3 [expr.call] paragraph 12 as follows:

   ...If the argument has integral or enumeration type that is subject to the integral promotions (7.3.7 [conv.prom]), or a floating-point type that is subject to the floating-point promotion (7.3.8 [conv.fpprom]), the value of the argument is converted to the promoted type before the call. These promotions are referred to as the default argument promotions.

2. Change in 17.13.2 [cstdarg.syn] as follows:

   See also: ISO C 7.16.1.1 7.16.1

CWG 2022-11-10

The phrase is useful and needed to override C's deviating definition, as applicable to va_arg.

Proposed resolution (approved by CWG and LWG 2022-11-11):

Change in 17.13.2 [cstdarg.syn] as follows:

The contents of the header <cstdarg> are the same as the C standard library header <stdarg.h>, with the following changes: In lieu of the default argument promotions specified in ISO C 6.5.2.2, the definition in 7.6.1.3 [expr.call] applies. The restrictions that ISO C places on the second parameter to the va_start macro in header <stdarg.h> are different in this document. ...

2614. Unspecified results for class member access

[Accepted as a DR at the November, 2022 meeting.]

Subclause 7.6.1.5 [expr.ref] paragraph 6 specifies:

If E2 is declared to have type “reference to T”, then E1.E2 is an lvalue; the type of E1.E2 is T. Otherwise, ...

This does not specifiy which object or functiom the resulting lvalue designates. A similar problem exists with member enumerators:

If E2 is a member enumerator and the type of E2 is T, the expression E1.E2 is a prvalue. The type of E1.E2 is T.

Proposed resolution (approved by CWG 2022-09-23):

1. Split and change in 7.6.1.5 [expr.ref] paragraph 6 as follows:

   If E2 is declared to have type “reference to T”, then E1.E2 is an lvalue; the of type of E1.E2 is T. If E2 is a static data member, E1.E2 designates the object or function to which the reference is bound, otherwise E1.E2 designates the object or function to which the corresponding reference member of E1 is bound.

   Otherwise, ...

2. Change in 7.6.1.5 [expr.ref] bullet 6.5 as follows:

   If E2 is a member enumerator and the type of E2 is T, the expression E1.E2 is a prvalue. The of type of E1.E2 is T whose value is the value of the enumerator.

2626. Rephrase ones' complement using base-2 representation

[Accepted as a DR at the November, 2022 meeting.]

Subclause 7.6.2.2 [expr.unary.op] paragraph 10 specifies:

The operand of ~ shall have integral or unscoped enumeration type; the result is the ones' complement of its operand. Integral promotions are performed. The type of the result is the type of the promoted operand. There is an ambiguity in the grammar...

This should be phrased in terms of the base-2 representation similar to bitwise-AND, instead of alluding to some bit representation by using the term "ones' complement".

Proposed resolution (approved by CWG 2022-10-07):

Subclause 7.6.2.2 [expr.unary.op] paragraph 10 specifies:

The operand of ~ shall have integral or unscoped enumeration type; the result is the ones' complement of its operand. Integral promotions are performed. The type of the result is the type of the promoted operand. Given the coefficients x_i of the base-2 representation (6.8.2 [basic.fundamental]) of the promoted operand x, the coefficient r_i of the base-2 representation of the result r is 1 if x_i is 0, and 0 otherwise. There is an ambiguity in the grammar...

2624. Array delete expression with no array cookie

[Accepted as a DR at the November, 2022 meeting.]

Consider:

char *p = static_cast<char*>(operator new[](2));
p = new (p) char[2];  // #1
delete[] p;           // #2

Subclause 7.6.2.8 [expr.new] paragraph 16 specifies:

... When a new-expression calls an allocation function and that allocation has not been extended, the new-expression passes the amount of space requested to the allocation function as the first argument of type std::size_t. That argument shall be no less than the size of the object being created; it may be greater than the size of the object being created only if the object is an array and the allocation function is not a non-allocating form (17.6.3.4 [new.delete.placement]). ...

Subclause 7.6.2.9 [expr.delete] paragraph 2 specifies:

... In an array delete expression, the value of the operand of delete may be a null pointer value or a pointer value that resulted from a previous array new-expression. [ Footnote: ... ] If not, the behavior is undefined.

The non-allocating form of the new-expression at #1 is constrained not to place an array cookie at the start of the array. Yet, the array delete appears to be expected to divine that fact.

Proposed resolution (approved by CWG 2022-10-07):

Change in 7.6.2.9 [expr.delete] paragraph 2 as follows:

... In an array delete expression, the value of the operand of delete may be a null pointer value or a pointer value that resulted from a previous array new-expression whose allocation function was not a non-allocating form (17.6.3.4 [new.delete.placement]). [ Footnote: ... ] If not, the behavior is undefined.

2654. Un-deprecation of compound volatile assignments

[Accepted as a DR at the November, 2022 meeting.]

Many functions of volatile were deprecated in C++20. In C++23, volatile compound operations were de-deprecated by P2327. The rationale for this de-deprecation is lacking.

Deprecation is not removal. P2327 in C++23 is stopping the change that we began with C++20, mere moments ago if counting by adoption time. It primarily argued that it's an inconvenient change, and that some of the audience would just not cooperate with WG21's indicated direction, so WG21 should compromise the technical consistency of the Standard so they could continue to not cooperate.

The paper did not bring new information on the technical merits of the case, and net the result of applying it was a technically dissonant Standard specification --- a strictly worse specification than C++20. Bitwise compound operations are not special for any technical reason, they are only special because making them special shields some from deprecation diagnostics.

EWG 2022-11-07

Contrary to the direction desired in the NB comment, EWG resolved to un-deprecate all volatile compound assignments.

Proposed resolution (approved by CWG 2022-11-08):

Change in 7.6.19 [expr.ass] paragraph 6 as follows:

The behavior of an expression of the form E1 op= E2 is equivalent to E1 = E1 op E2 except that E1 is evaluated only once. [ Note: The object designated by E1 is accessed twice. -- end note ] Such expressions are deprecated if E1 has volatile-qualified type and op is not one of the bitwise operators |, &, ^; see D.5.

Change in D.5 [depr.volatile.type] paragraph 2 as follows:

  brachiosaur += neck;                // deprecatedOK
  brachiosaur = brachiosaur + neck;   // OK
  brachiosaur |= neck;                // OK, bitwise compound expression

2392. new-expression size check and constant evaluation

[Accepted as a DR at the November, 2022 meeting.]

According to 7.6.2.8 [expr.new] paragraph 8, if the expression in a noptr-new-declarator is a core constant expression, the program is ill-formed if the expression is erroneous, e.g., negative. However, consider the following example:

  template<class T = void> constexpr int f() { T t; return 1; }
  using _ = decltype(new int[f()]);

f() is a core constant expression, so it must be evaluated to determine its value. However, because the expression appears in an unevaluated operand, it is not “potentially constant evaluated” and thus f is not “needed for constant evaluation”, so the template is not instantiated (13.9.2 [temp.inst] paragraph 7). There is implementation divergence on the handling of this example.

CWG telecon 2022-09-09:

The example should be well-formed, because f is not instantiated.

A similar situation arises for narrowing conversions, except that in the latter case, determining the value at compile-time empowers to allow additional cases, whereas the new-expression case uses a compile-time value to prohibit additional cases.

Proposed resolution (approved by CWG 2022-09-23):

Change in 7.6.2.8 [expr.new] paragraph 8 as follows:

If the expression is erroneous after converting to std::size_t:

• if the expression is a potentially-evaluated core constant expression, the program is ill-formed;
• otherwise, an allocation function is not called; instead...

2440. Allocation in core constant expressions

[Accepted as a DR at the November, 2022 meeting.]

7.7 [expr.const] paragraph 5 attempts to describe allowable allocation/deallocation calls in terms of what could be called “core constant subexpressions,” but the actual definition of a core constant expression in paragraph 4 is in terms of evaluation.

Suggested resolution [SUPERSEDED]:

Replace the entirety of 7.7 [expr.const] paragraph 6 with the following:

For the purposes of determining whether an expression E is a core constant expression, the evaluation of a call to the body of a member function of std::allocator<T> as defined in 20.2.10.2 [allocator.members], where T is a literal type, does not disqualify E from being a core constant expression, even if the actual evaluation of such a call would otherwise fail the requirements for a core constant expression is ignored. Similarly, the evaluation of a call to the body of std::destroy_at, std::ranges::destroy_at, std::construct_at, or std::ranges::construct_at (27.11.8 [specialized.construct]) does not disqualify E from being a core constant expression unless the first argument, of type T*, does not point to storage allocated with std::allocator<T> or to an object whose lifetime began within the evaluation of E, or the evaluation of is considered to include only the underlying constructor call disqualifies E from being a core constant expression (for the functions construct_at) or destructor (for the functions destroy_at) call if the first argument (of type T*) points to storage allocated with std::allocator<T>.

CWG telecon 2022-10-21:

The references to destroy_at were removed in an unrelated update to the Working Draft. Also, restore the reference to local objects whose lifetime began within E.

Proposed resolution (approved by CWG 2022-11-10):

Change in 7.7 [expr.const] paragraph 6 as follows:

For the purposes of determining whether an expression E is a core constant expression, the evaluation of a call to the body of a member function of std::allocator<T> as defined in 20.2.10.2 [allocator.members], where T is a literal type, does not disqualify E from being a core constant expression, even if the actual evaluation of such a call would otherwise fail the requirements for a core constant expression is ignored. Similarly, the evaluation of a call to the body of std::construct_at or std::ranges::construct_at (27.11.8 [specialized.construct]) does not disqualify E from being a core constant expression unless the first argument, of type T*, does not point to storage allocated with std::allocator<T> or to an object whose lifetime began within the evaluation of E, or the evaluation of is considered to include only the underlying constructor call disqualifies E from being a core constant expression call if the first argument (of type T*) points to storage allocated with std::allocator<T> or to an object whose lifetime began within the evaluation of E.

2631. Immediate function evaluations in default arguments

[Accepted as a DR at the November, 2022 meeting.]

Consider:

consteval int const_div(int a, int b) { return a / b; }
int func(int x = const_div(10, 0));

According to 7.7 [expr.const] paragraph 14:

An expression or conversion is an immediate invocation if it is a potentially-evaluated explicit or implicit invocation of an immediate function and is not in an immediate function context. An immediate invocation shall be a constant expression.

Subclause 9.3.4.7 [dcl.fct.default] paragraph 5 specifies:

The default argument has the same semantic constraints as the initializer in a declaration of a variable of the parameter type, using the copy-initialization semantics (9.4 [dcl.init]). The names in the default argument are looked up, and the semantic constraints are checked, at the point where the default argument appears. Name lookup and checking of semantic constraints for default arguments of templated functions are performed as described in 13.9.2 [temp.inst].

Checking the semantic constraints of the default argument appears to include a check whether the immediate invocation of const_div is actually a constant expression, even though the default argument's value might never actually be used for any function call in the program.

However, instantiation of a consteval function template to be able to perform the constant evaluation is not permitted per 13.9.2 [temp.inst] paragraph 11:

... The use of a template specialization in a default argument shall not cause the template to be implicitly instantiated except that a class template may be instantiated where its complete type is needed to determine the correctness of the default argument. The use of a default argument in a function call causes specializations in the default argument to be implicitly instantiated.

Example 2:

constexpr int g();
consteval int f() {
  return g();
}

int k(int x = f()) {  // error: constexpr evaluation of undefined function g
  return x;
}

constexpr int g() {
  return 42;
}

int main() {
  return k();
}

Example 3:

#include <source_location>
#include <iostream>

consteval int const_div(int a, int b) {
  return a / b;
}

#line 5
void foo(int x = const_div(1000, std::source_location::current().line() - 15)) {
  std::cout << x << "\n";
}

// Should the definition of `bar` produce errors? (division by zero during constant
// evaluation for constraint checking)
#line 10
void bar(int x = const_div(1000, std::source_location::current().line() - 10)) {
  std::cout << x << "\n";
}

int main() {
  // Should this call produce errors? (division by zero during constant
  // evaluation of the default argument)
  #line 15
  foo();
  #line 20
  bar();
}

Note that source_location::current() is specified to take its value from the location where it is evaluated, if it appears in a default argument (17.8.2.2 [support.srcloc.cons] paragraph 2):

Remarks: Any call to current that appears as a default member initializer (11.4 [class.mem]), or as a subexpression thereof, should correspond to the location of the constructor definition or aggregate initialization that uses the default member initializer. Any call to current that appears as a default argument (9.3.4.7 [dcl.fct.default]), or as a subexpression thereof, should correspond to the location of the invocation of the function that uses the default argument (7.6.1.3 [expr.call]).

Proposed resolution (September, 2022) [SUPERSEDED]:

1. Split 9.3.4.7 [dcl.fct.default] paragraph 5 and change as follows:

   The default argument has the same semantic constraints as the initializer in a declaration of a variable of the parameter type, using the copy-initialization semantics (9.4 [dcl.init]).

   A default argument context is

   • the initializer-clause in a parameter-declaration, including any conversions to the parameter type,
   • a subexpression of one of the above that is not a subexpression of a nested unevaluated operand.

   The names in the default argument are looked up, and the semantic constraints are checked, at the point where the default argument appears, except that an immediate invocation (7.7 [expr.const]) in a default argument context is neither evaluated nor checked for whether it is a constant expression at that point. Name lookup and checking of semantic constraints for default arguments of templated functions are performed as described in 13.9.2 [temp.inst].

2. Change in 13.9.2 [temp.inst] paragraph 11 as follows:

   ... The use of a template specialization in a default argument shall not cause the template to be implicitly instantiated except that a class template or a function template with a deduced return type may be instantiated where its complete type is needed to determine the correctness of the default argument. The use of a default argument in a function call causes specializations in the default argument to be implicitly instantiated.

Approved by EWG telecon 2022-09-29.

Amendment to also cover default member initializers (October, 2022) [SUPERSEDED]:

1. Split 9.3.4.7 [dcl.fct.default] paragraph 5 and change as follows:

   The default argument has the same semantic constraints as the initializer in a declaration of a variable of the parameter type, using the copy-initialization semantics (9.4 [dcl.init]).

   A default argument context of an initializer is

   • the initializer, including any conversions to the target type, or
   • a subexpression thereof that is not a subexpression of a nested unevaluated operand.

   The names in the default argument are looked up, and the semantic constraints are checked, at the point where the default argument appears, except that an immediate invocation (7.7 [expr.const]) in a default argument context of the initializer-clause in a parameter-declaration is neither evaluated nor checked for whether it is a constant expression at that point. Name lookup and checking of semantic constraints for default arguments of templated functions are performed as described in 13.9.2 [temp.inst].

2. Change in 11.4.1 [class.mem.general] paragraph 11 as follows:

   A brace-or-equal-initializer for a non-static data member specifies a default member initializer for the member, and shall not directly or indirectly cause the implicit definition of a defaulted default constructor for the enclosing class or the exception specification of that constructor. An immediate invocation (7.7 [expr.const]) in a default argument context (9.3.4.7 [dcl.fct.default]) of a default member initializer is neither evaluated nor checked for whether it is a constant expression at the point where it appears.

3. Change in 13.9.2 [temp.inst] paragraph 11 as follows:

   ... The use of a template specialization in a default argument shall not cause the template to be implicitly instantiated except that a class template or a function template with a deduced return type may be instantiated where its complete type is needed to determine the correctness of the default argument. The use of a default argument in a function call causes specializations in the default argument to be implicitly instantiated.

CWG telecon 2022-10-07:

The new term should be defined in 6.9.1 [intro.execution] without reference to immediacy.

Possible resolution [SUPERSEDED]:

1. Change in 6.9.1 [intro.execution] paragraph 4 as follows:

   A subexpression of an expression E is an immediate subexpression of E or a subexpression of an immediate subexpression of E. [ Note: ... -- end note ]

   The potentially-evaluated subexpressions of an expression, conversion, or initializer E are

   • the constituent expressions of E and
   • the subexpressions thereof that are not subexpressions of a nested unevaluated operand (7.2.3 [expr.context]).

2. Change in 7.7 [expr.const] paragraph 16 as follows:

   An expression or conversion is potentially constant evaluated if it is:

   • ...
   • a potentially-evaluated subexpression (6.9.1 [intro.execution]) of one of the above that is not a subexpression of a nested unevaluated operand (7.2.3 [expr.context]).

3. Change in 9.3.4.7 [dcl.fct.default] paragraph 5 as follows:

   The default argument has the same semantic constraints as the initializer in a declaration of a variable of the parameter type, using the copy-initialization semantics (9.4 [dcl.init]). The names in the default argument are looked up, and the semantic constraints are checked, at the point where the default argument appears, except that an immediate invocation (7.7 [expr.const]) that is a potentially-evaluated subexpression (6.9.1 [intro.execution]) of the initializer-clause in a parameter-declaration is neither evaluated nor checked for whether it is a constant expression at that point. Name lookup and checking of semantic constraints for default arguments of templated functions are performed as described in 13.9.2 [temp.inst].

4. Add a paragraph before 9.4.1 [dcl.init.general] paragraph 17 as follows:

   An immediate invocation (7.7 [expr.const]) that is not evaluated where it appears (9.3.4.7 [dcl.fct.default], 11.4.1 [class.mem.general]) is evaluated and checked for whether it is a constant expression at the point where the enclosing initializer is used in a function call, a constructor definition, or an aggregate initialization.

   An initializer-clause followed by an ellipsis is a pack expansion (13.7.4 [temp.variadic]).

5. Change in 11.4.1 [class.mem.general] paragraph 11 as follows:

   A brace-or-equal-initializer for a non-static data member specifies a default member initializer for the member, and shall not directly or indirectly cause the implicit definition of a defaulted default constructor for the enclosing class or the exception specification of that constructor. An immediate invocation (7.7 [expr.const]) that is a potentially-evaluated subexpression (6.9.1 [intro.execution]) of a default member initializer is neither evaluated nor checked for whether it is a constant expression at the point where the subexpression appears.

6. Change in 13.9.2 [temp.inst] paragraph 11 as follows:

   ... The use of a template specialization in a default argument or default member initializer shall not cause the template to be implicitly instantiated except that a templated class template , a templated function with a deduced return type, or a variable template with a deduced type may be instantiated where its complete type is needed to determine the correctness of the default argument or default member initializer. The use of a default argument in a function call causes specializations in the default argument to be implicitly instantiated. Similarly, the use of a default member initializer in a constructor definition or an aggregate initialization causes specializations in the default member initializer to be instantiated.

CWG telecon 2022-10-21:

In the above wording, "constituent expression of a conversion" is not a defined term.

Possible resolution [SUPERSEDED]:

1. Change in 6.9.1 [intro.execution] paragraph 2 as follows:

   A constituent expression is defined as follows:

   • The constituent expression of an expression is that expression.
   • The constituent expression of a conversion is the corresponding implicit function call, if any, or the converted expression otherwise.
   • The constituent expressions of a braced-init-list or of a (possibly parenthesized) expression-list are the constituent expressions of the elements of the respective list.
   • The constituent expressions of a brace-or-equal-initializer of the form = initializer-clause are the constituent expressions of the initializer-clause.

2. Change in 6.9.1 [intro.execution] paragraph 4 as follows:

   A subexpression of an expression E is an immediate subexpression of E or a subexpression of an immediate subexpression of E. [ Note: ... -- end note ]

   The potentially-evaluated subexpressions of an expression, conversion, or initializer E are

   • the constituent expressions of E and
   • the subexpressions thereof that are not subexpressions of a nested unevaluated operand (7.2.3 [expr.context]).

3. Change in 7.7 [expr.const] paragraph 16 as follows:

   An expression or conversion is potentially constant evaluated if it is:

   • ...
   • a potentially-evaluated subexpression (6.9.1 [intro.execution]) of one of the above that is not a subexpression of a nested unevaluated operand (7.2.3 [expr.context]).

4. Change in 9.3.4.7 [dcl.fct.default] paragraph 5 as follows:

   The default argument has the same semantic constraints as the initializer in a declaration of a variable of the parameter type, using the copy-initialization semantics (9.4 [dcl.init]). The names in the default argument are looked up, and the semantic constraints are checked, at the point where the default argument appears, except that an immediate invocation (7.7 [expr.const]) that is a potentially-evaluated subexpression (6.9.1 [intro.execution]) of the initializer-clause in a parameter-declaration is neither evaluated nor checked for whether it is a constant expression at that point. Name lookup and checking of semantic constraints for default arguments of templated functions are performed as described in 13.9.2 [temp.inst].

5. Add a paragraph before 9.4.1 [dcl.init.general] paragraph 17 as follows:

   An immediate invocation (7.7 [expr.const]) that is not evaluated where it appears (9.3.4.7 [dcl.fct.default], 11.4.1 [class.mem.general]) is evaluated and checked for whether it is a constant expression at the point where the enclosing initializer is used in a function call, a constructor definition, or an aggregate initialization.

   An initializer-clause followed by an ellipsis is a pack expansion (13.7.4 [temp.variadic]).

6. Change in 11.4.1 [class.mem.general] paragraph 11 as follows:

   A brace-or-equal-initializer for a non-static data member specifies a default member initializer for the member, and shall not directly or indirectly cause the implicit definition of a defaulted default constructor for the enclosing class or the exception specification of that constructor. An immediate invocation (7.7 [expr.const]) that is a potentially-evaluated subexpression (6.9.1 [intro.execution]) of a default member initializer is neither evaluated nor checked for whether it is a constant expression at the point where the subexpression appears.

7. Change in 13.9.2 [temp.inst] paragraph 11 as follows:

   ... The use of a template specialization in a default argument or default member initializer shall not cause the template to be implicitly instantiated except that a templated class template , a templated function with a deduced return type, or a variable template with a deduced type may be instantiated where its complete type is needed to determine the correctness of the default argument or default member initializer. The use of a default argument in a function call causes specializations in the default argument to be implicitly instantiated. Similarly, the use of a default member initializer in a constructor definition or an aggregate initialization causes specializations in the default member initializer to be instantiated.

CWG 2022-11-07

Expand requirement to avoid template instantiations in default arguments by not giving a specific, closed list.

Proposed resolution (approved by CWG 2022-11-08):

1. Change in 6.9.1 [intro.execution] paragraph 2 as follows:

   A constituent expression is defined as follows:

   • The constituent expression of an expression is that expression.
   • The constituent expression of a conversion is the corresponding implicit function call, if any, or the converted expression otherwise.
   • The constituent expressions of a braced-init-list or of a (possibly parenthesized) expression-list are the constituent expressions of the elements of the respective list.
   • The constituent expressions of a brace-or-equal-initializer of the form = initializer-clause are the constituent expressions of the initializer-clause.

2. Change in 6.9.1 [intro.execution] paragraph 4 as follows:

   A subexpression of an expression E is an immediate subexpression of E or a subexpression of an immediate subexpression of E. [ Note: ... -- end note ]

   The potentially-evaluated subexpressions of an expression, conversion, or initializer E are

   • the constituent expressions of E and
   • the subexpressions thereof that are not subexpressions of a nested unevaluated operand (7.2.3 [expr.context]).

3. Change in 7.7 [expr.const] paragraph 16 as follows:

   An expression or conversion is potentially constant evaluated if it is:

   • ...
   • a potentially-evaluated subexpression (6.9.1 [intro.execution]) of one of the above that is not a subexpression of a nested unevaluated operand (7.2.3 [expr.context]).

4. Change in 9.3.4.7 [dcl.fct.default] paragraph 5 as follows:

   The default argument has the same semantic constraints as the initializer in a declaration of a variable of the parameter type, using the copy-initialization semantics (9.4 [dcl.init]). The names in the default argument are looked up, and the semantic constraints are checked, at the point where the default argument appears, except that an immediate invocation (7.7 [expr.const]) that is a potentially-evaluated subexpression (6.9.1 [intro.execution]) of the initializer-clause in a parameter-declaration is neither evaluated nor checked for whether it is a constant expression at that point. Name lookup and checking of semantic constraints for default arguments of templated functions are performed as described in 13.9.2 [temp.inst].

5. Add a paragraph before 9.4.1 [dcl.init.general] paragraph 17 as follows:

   An immediate invocation (7.7 [expr.const]) that is not evaluated where it appears (9.3.4.7 [dcl.fct.default], 11.4.1 [class.mem.general]) is evaluated and checked for whether it is a constant expression at the point where the enclosing initializer is used in a function call, a constructor definition, or an aggregate initialization.

   An initializer-clause followed by an ellipsis is a pack expansion (13.7.4 [temp.variadic]).

6. Change in 11.4.1 [class.mem.general] paragraph 11 as follows:

   A brace-or-equal-initializer for a non-static data member specifies a default member initializer for the member, and shall not directly or indirectly cause the implicit definition of a defaulted default constructor for the enclosing class or the exception specification of that constructor. An immediate invocation (7.7 [expr.const]) that is a potentially-evaluated subexpression (6.9.1 [intro.execution]) of a default member initializer is neither evaluated nor checked for whether it is a constant expression at the point where the subexpression appears.

7. Change in 13.9.2 [temp.inst] paragraph 11 as follows:

   ... The use of a template specialization in a default argument or default member initializer shall not cause the template to be implicitly instantiated except that a class template may be instantiated where its complete type is needed to determine the correctness of the default argument or default member initializer. The use of a default argument in a function call causes specializations in the default argument to be implicitly instantiated. Similarly, the use of a default member initializer in a constructor definition or an aggregate initialization causes specializations in the default member initializer to be instantiated.

2647. Fix for "needed for constant evaluation"

[Accepted as a DR at the November, 2022 meeting.]

The criteria for a variable to be needed for constant evaluation are inconsistent with those for it to be usable in constant expressions (/4).

Proposed resolution (approved by CWG 2022-11-08):

1. Change in 7.7 [expr.const] paragraph 3 as follows:

   A variable is potentially-constant if it is constexpr or it has reference or non-volatile const-qualified integral or enumeration type.

2. Change in 7.7 [expr.const] paragraph 16.7 as follows:

   A function or variable is needed for constant evaluation if it is:

   • a constexpr function that is named by an expression (6.3) that is potentially constant evaluated, or
   • a potentially-constant variable named by a potentially constant evaluated expression that is either a constexpr variable or is of non-volatile const-qualified integral type or of reference type.

2616. Imprecise restrictions on break and continue

[Accepted as a DR at the November, 2022 meeting.]

Consider:

for (int i = 0; i< 10; ++i){
  auto f = [](){
    break; // #1
  };
}

Subclause 8.7.2 [stmt.break] paragraph 1 specifies:

The break statement shall occur only in an iteration-statement or a switch statement and causes termination of the smallest enclosing iteration-statement or switch statement; control passes to the statement following the terminated statement, if any.

Does the break at #1 "occur" in the for loop?

Proposed resolution (approved by CWG 2022-08-26):

1. Append to 8.1 [stmt.pre] paragraph 3 as follows:

   ... A statement S1 is enclosed by a statement S2 if S2 encloses S1.

   The rules for conditions apply both...

2. Change in 8.2 [stmt.label] paragraph 2 as follows:

   Case labels and default labels shall occur only in switch statements A labeled-statement whose label is a case or default label shall be enclosed by (8.1 [stmt.pre]) a switch statement (8.5.3 [stmt.switch])..

3. Change in 8.7.2 [stmt.break] paragraph 1 as follows:

   The A break statement shall occur only in be enclosed by (8.1 [stmt.pre]) an iteration-statement (8.6 [stmt.iter]) or a switch statement and (8.5.3 [stmt.switch]). The break statement causes termination of the smallest such enclosing iteration-statement or switch statement; control passes to the statement following the terminated statement, if any.

4. Change in 8.7.3 [stmt.cont] paragraph 1 as follows:

   The A continue statement shall occur only in be enclosed by (8.1 [stmt.pre]) an iteration-statement (8.6 [stmt.iter]) and. The continue statement causes control to pass to the loop-continuation portion of the smallest such enclosing iteration-statement statement, that is, to the end of the loop. ...

2629. Variables of floating-point type as switch conditions

[Accepted as a DR at the November, 2022 meeting.]

Consider:

switch(float v = 0) {
  case 0: ;
}

Subclause 8.1 [stmt.pre] paragraph 5 specifies:

... The value of a condition that is an initialized declaration in a switch statement is the value of the declared variable if it has integral or enumeration type, or of that variable implicitly converted to integral or enumeration type otherwise. ...

That appears to permit variables of floating-point type, whose value can be converted to integral type. In contrast, expressions of floating-point type are prohibited by 8.5.3 [stmt.switch] paragraph 2:

The condition shall be of integral type, enumeration type, or class type. ...

Possible resolution [SUPERSEDED]:

Change in 8.1 [stmt.pre] paragraph 5 as follows:

... The value of a condition that is an initialized declaration in a switch statement is the value of the declared variable if it has integral or enumeration type, or of that variable implicitly converted to integral or enumeration type if it has class type; otherwise the program is ill-formed. ...

CWG telecon 2022-10-21:

Rewording is needed.

Proposed resolution (approved by CWG 2022-11-09):

1. Change in 8.1 [stmt.pre] paragraph 5 as follows:

   ... The value of a condition that is an initialized declaration in a switch statement is the value of the declared variable if it has integral or enumeration type, or of that variable implicitly converted to integral or enumeration type otherwise. ...

2. Change in 8.5.3 [stmt.switch] paragraph 2 as follows:

   The value of a condition that is an initialized declaration is the value of the declared variable, or the value of the expression otherwise. The value of the condition shall be of integral type, enumeration type, or class type. If of class type, the condition is contextually implicitly converted (7.3 [conv]) to an integral or enumeration type. If the (possibly converted) type is subject to integral promotions (7.3.7 [conv.prom]), the condition is converted to the promoted type. ...

2635. Constrained structured bindings

[Accepted as a DR at the November, 2022 meeting.]

Consider:

template<class T> concept C = true;
C auto [x, y] = std::pair{1, 2}; // ok?

Subclause 9.1 [dcl.pre] paragraph 6 specifies:

A simple-declaration with an identifier-list is called a structured binding declaration (9.6 [dcl.struct.bind]). If the decl-specifier-seq contains any decl-specifier other than static, thread_local, auto (9.2.9.6 [dcl.spec.auto]), or cv-qualifier s, the program is ill-formed.

Use of the word "contains" leads to an interpretation that any placeholder-type-specifier (9.2.9.6.1 [dcl.spec.auto.general]), possibly including a type-constraint, is valid here, since a placeholder-type-specifier is a decl-specifier and "contains" auto.

However, paper P1141R2 (Yet another approach for constrained declarations), applied in November 2018, expressly excludes structured bindings from constrained auto:

Structured bindings do deduce auto in some cases; however, the auto is deduced from the whole (and not from the individual components). It is somewhat doubtful that applying the constraint to the whole, as opposed to (for example) applying separately to each component, is the correct semantic. Therefore, we propose to defer enabling the application of constraints to structured bindings to separate papers.

Notwithstanding, clang, gcc, and MSVC accept the example.

Proposed resolution (approved by CWG 2022-10-21):

Change in 9.1 [dcl.pre] paragraph 6 specifies:

A simple-declaration with an identifier-list is called a structured binding declaration (9.6 [dcl.struct.bind]). If the decl-specifier-seq contains any decl-specifier other than static, thread_local, auto (9.2.9.6 [dcl.spec.auto]), or cv-qualifiers, the program is ill-formed. Each decl-specifier in the decl-specifier-seq shall be static, thread_local, auto (9.2.9.6 [dcl.spec.auto]), or a cv-qualifier. [ Example:

template<class T> concept C = true;
C auto [x, y] = std::pair{1, 2}; // error: constrained placeholder-type-specifier not permitted for structured bindings

-- end example ]

2410. Implicit calls of immediate functions

[Accepted as a DR at the November, 2022 meeting.]

The intent for immediate functions is that they can only be called at compile time. That rule is enforced by the wording of 7.5.4 [expr.prim.id] paragraph 3:

An id-expression that denotes an immediate function (9.2.6 [dcl.constexpr]) shall appear as a subexpression of an immediate invocation or in an immediate function context (7.7 [expr.const]).

However, this restriction does not apply to implicit function calls such as constructor and operator invocations. Presumably some additional wording is needed for such cases.

Additional note, July, 2019:

This issue would appear to be NAD because of the following wording from 7.7 [expr.const] paragraph 10:

An expression or conversion is an immediate invocation if it is an explicit or implicit invocation of an immediate function and is not in an immediate function context. An immediate invocation shall be a constant expression.

Proposed resolution (approved by CWG 2022-10-21):

Change in 7.7 [expr.const] paragraph 10 as follows:

An expression or conversion invocation is an immediate invocation if it is an explicit or implicit invocation of an immediate function and is not in an immediate function context. An immediate invocation shall be a constant expression.

2620. Nonsensical disambiguation rule

[Accepted as a DR at the November, 2022 meeting.]

Subclause 9.3.3 [dcl.ambig.res] paragraph 1 specifies:

The ambiguity arising from the similarity between a function-style cast and a declaration mentioned in 8.9 [stmt.ambig] can also occur in the context of a declaration. In that context, the choice is between a function declaration with a redundant set of parentheses around a parameter name and an object declaration with a function-style cast as the initializer. Just as for the ambiguities mentioned in 8.9 [stmt.ambig], the resolution is to consider any construct that could possibly be a declaration a declaration.

The specification correctly describes an ambiguity between a function declaration and an object declaration, but resolves the ambiguity to a "declaration", which does not offer any insight.

Proposed resolution (2022-09-09) [SUPERSEDED]:

Change in 9.3.3 [dcl.ambig.res] paragraph 1 as follows:

... Just as for the ambiguities mentioned in 8.9 [stmt.ambig], the The resolution is to consider any construct that could possibly be a function declaration a function declaration.

Proposed resolution (approved by CWG 2022-09-23):

Change in 9.3.3 [dcl.ambig.res] paragraph 1 as follows:

The ambiguity arising from the similarity between a function-style cast and a declaration mentioned in 8.9 [stmt.ambig] can also occur in the context of a declaration. In that context, the choice is between a function declaration with a redundant set of parentheses around a parameter name and an object declaration with a function-style cast as the initializer and a declaration involving a function declarator with a redundant set of parentheses around a parameter name. Just as for the ambiguities mentioned in 8.9 [stmt.ambig], the resolution is to consider any construct, such as the potential parameter declaration, that could possibly be a declaration to be a declaration.

2612. Incorrect comment in example

[Accepted as a DR at the November, 2022 meeting.]

Subclause 9.4.1 [dcl.init.general] bullet 16.6.1 says:

[Example 2: T x = T(T(T())); calls the T default constructor to initialize x. —end example]

This is incorrect; in some situations, the default constructor is not invoked (see 9.4.1 [dcl.init.general] paragraph 9).

Proposed resolution (approved by CWG 2022-08-26):

Change in 9.4.1 [dcl.init.general] bullet 16.6.1 as follows:

[Example 2: T x = T(T(T())); calls the T default constructor to initialize value-initializes x. —end example]

2610. Indirect private base classes in aggregates

[Accepted as a DR at the November, 2022 meeting.]

The wording appears to prohibit aggregates from having indirect private base classes. That does not match existing practice and is an unnecessary restriction. For example:

#include <type_traits>

struct B1 {};
struct B2 : private B1 {};
struct S : public B2 {};

void f() {
  static_assert(std::is_aggregate<S>::value);
}

Proposed resolution (approved by CWG 2022-08-26):

Change in 9.4.2 [dcl.init.aggr] paragraph 1 as follows:

An aggregate is an array or a class (Clause 11 [class]) with

• no user-declared or inherited constructors (11.4.5 [class.ctor]),
• no private or protected direct non-static data members (11.8 [class.access]),
• no private or protected direct base classes (11.8.3 [class.access.base]), and
• no virtual functions (11.7.3 [class.virtual]) or virtual base classes (11.7.2 [class.mi])., and
• no virtual, private, or protected base classes (11.7.2 [class.mi]).

2619. Kind of initialization for a designated-initializer-list

[Accepted as a DR at the November, 2022 meeting.]

Consider:

struct S {
  explicit S(int){}
};
struct A {
  S s;
};
struct B {
  union {
    S s;
  };
};
int main() {
  A a1 = {.s{0}};  // #1
  A a2{.s{0}};     // #2
  B b1 = {.s{0}};  // #3
  B b2{.s{0}};     // #4
}

Subclause 9.4.2 [dcl.init.aggr] bullet 4.2 specifies:

Otherwise, the element is copy-initialized from the corresponding initializer-clause or is initialized with the brace-or-equal-initializer of the corresponding designated-initializer-clause.

It is unclear what kind of initialization is performed for "is initialized". For example, one could imagine that the top-level kind of initialization is inherited. On the other hand, 9.4.1 [dcl.init.general] paragraph 14 specifies:

The initialization that occurs in the = form of a brace-or-equal-initializer or condition (8.5 [stmt.select]), as well as in argument passing, function return, throwing an exception (14.2 [except.throw]), handling an exception (14.4 [except.handle]), and aggregate member initialization (9.4.2 [dcl.init.aggr]), is called copy-initialization.

There is implementation divergence: gcc and icc reject the example; clang and MSVC accept.

Suggested resolution [SUPERSEDED]:

1. Change in 9.4.2 [dcl.init.aggr] bullet 4.1 as follows:

   If the element is an anonymous union member and the initializer list is a brace-enclosed designated-initializer-list, the element is initialized by the designated-initializer-list braced-init-list { D }, where D is the designated-initializer-clause naming a member of the anonymous union member.

2. Change in 9.4.2 [dcl.init.aggr] bullet 4.2 as follows:

   Otherwise, the element is copy-initialized from the corresponding initializer-clause or is initialized copy-initialized or direct-initialized with the brace-or-equal-initializer of the corresponding designated-initializer-clause, according to the form of the brace-or-equal-initializer (9.4.1 [dcl.init.general]). ...

CWG telecon 2022-09-09:

The examples #1 to #4 should all be valid, direct-initializing the s member.

Proposed resolution (approved by CWG 2022-09-23):

1. Change in 9.4.1 [dcl.init.general] paragraph 14 as follows:

   The initialization that occurs in the = form of a brace-or-equal-initializer or condition (8.5 [stmt.select]), as well as in argument passing, function return, throwing an exception (14.2 [except.throw]), handling an exception (14.4 [except.handle]), and aggregate member initialization other than by a designated-initializer-clause (9.4.2 [dcl.init.aggr]), is called copy-initialization.

2. Change in 9.4.2 [dcl.init.aggr] bullet 4.1 as follows:

   If the element is an anonymous union member and the initializer list is a brace-enclosed designated-initializer-list, the element is initialized by the designated-initializer-list braced-init-list { D }, where D is the designated-initializer-clause naming a member of the anonymous union member.

3. Change in 9.4.2 [dcl.init.aggr] bullet 4.2 as follows:

   Otherwise, the element is copy-initialized from the corresponding initializer-clause or is initialized with the brace-or-equal-initializer of the corresponding designated-initializer-clause. If that initializer is of the form assignment-expression or = assignment-expression and a narrowing conversion (9.4.5 [dcl.init.list]) is required to convert the expression, the program is ill-formed. [ Note: If the initialization is by designated-initializer-clause, its form determines whether copy-initialization or direct-initialization is performed.-- end note]

2627. Bit-fields and narrowing conversions

[Accepted as a DR at the November, 2022 meeting.]

Consider:

struct C {
  long long i : 8;
};

void f() {
  C x{1}, y{2};
  x.i <=> y.i; // error: narrowing conversion required (7.6.8 [expr.spaceship] bullet 4.1)
}

The rules for narrowing conversions in 9.4.5 [dcl.init.list] paragraph 7 consider only the source type, even though integral promotions can change the type of a bit-field to a smaller integer type without loss of value range according to 7.3.7 [conv.prom] paragraph 5:

A prvalue for an integral bit-field (11.4.10 [class.bit]) can be converted to a prvalue of type int if int can represent all the values of the bit-field; otherwise, it can be converted to unsigned int if unsigned int can represent all the values of the bit-field. If the bit-field is larger yet, no integral promotion applies to it. If the bit-field has enumeration type, it is treated as any other value of that type for promotion purposes.

There is implementation divergence in the handling of this example.

Proposed resolution (approved by CWG 2022-10-07):

Change in 9.4.5 [dcl.init.list] bullet 7.4 as follows:

A narrowing conversion is an implicit conversion

• ...
• from an integer type or unscoped enumeration type to an integer type that cannot represent all the values of the original type, except where
  • the source is a bit-field whose width w is less than that of its type (or, for an enumeration type, its underlying type) and the target type can represent all the values of a hypothetical extended integer type with width w and with the same signedness as the original type or
  • the source is a constant expression whose value after integral promotions will fit into the target type, or
• ...

2646. Defaulted special member functions

[Accepted as a DR at the November, 2022 meeting.]

The exposition in terms of F1 and F2 as well as T1 and T2 is confusing.

Possible resolution:

Change in 9.5.2 [dcl.fct.def.default] paragraph 2 as follows:

An explicitly defaulted special member function F1 with type T1 is allowed to differ from the corresponding special member function F2 with type T2 that would have been implicitly declared, as follows:

• T1 F1 and T2 F2 may have differing ref-qualifier s;
• if F2 has an implicit object parameter of type “reference to C”, F1 may be an explicit object member function whose explicit object parameter is of type “reference to C”, in which case T1 the type of F1 would differ from T2 the type of F2 in that T1 the type of F1 has an additional parameter;
• T1 F1 and T2 F2 may have differing exception specifications; and
• if F2 has a non-object parameter of type const C&, the corresponding non-object parameter of F1 may be of type C&.

If T1 the type of F1 differs from T2 the type of F2 in a way other than as allowed by the preceding rules, then:

• if F1 is an assignment operator, and the return type of T1 F1 differs from the return type of T2 F2 or F1 's non-object parameter type is not a reference, the program is ill-formed;
• otherwise, if F1 is explicitly defaulted on its first declaration, it is defined as deleted;
• otherwise, the program is ill-formed.

2451. promise.unhandled_exception() and final suspend point

[Accepted as a DR at the November, 2022 meeting.]

According to 9.5.4 [dcl.fct.def.coroutine] paragraph 14,

If the evaluation of the expression promise.unhandled_exception() exits via an exception, the coroutine is considered suspended at the final suspend point.

However, the “final suspend point” is defined as being “the await-expression containing the call to final_suspend” (bullet 5.2), and it is not desired to evaluate the final_suspend expression in this case.

Suggested resolution [SUPERSEDED]:

1. Change 9.5.4 [dcl.fct.def.coroutine] paragraph 5 as follows:

...where

• the await-expression containing the call to initial_suspend is the initial suspend point await expression, and

• the await-expression containing the call to final_suspend is the final suspend point await expression, and

• initial-await-resume-called is initially false and is set to true immediately before the evaluation of the await-resume expression (7.6.2.4 [expr.await]) of the initial suspend point await expression, and

• ...

• promise-constructor-arguments is determined as follows: overload resolution is performed on a promise constructor call created by assembling an argument list with lvalues p₁ ... p_n. If a viable constructor is found (12.2.3 [over.match.viable]), then promise-constructor-arguments is (p₁, ..., p_n), otherwise promise-constructor-arguments is empty. , and

• A coroutine is suspended at a final suspend point if it is suspended

  • at a final await expression or

  • due to an exception exiting from unhandled_exception()

2. Change bullet 3.2 of 7.6.2.4 [expr.await] as follows:

Evaluation of an await-expression involves the following auxiliary types, expressions, and objects:

• ...

• a is the cast-expression if the await-expression was implicitly produced by a yield-expression (7.6.17 [expr.yield]), an initial suspend point await expression, or a final suspend point await expression (9.5.4 [dcl.fct.def.coroutine]). Otherwise

• ...

3. If needed, change 9.5.4 [dcl.fct.def.coroutine] paragraph 14 as follows:

If the evaluation of the expression promise.unhandled_exception() exits via an exception, the coroutine is considered suspended at the final suspend point and the exception propagates to the caller or resumer.

Notes from the August, 2020 teleconference [SUPERSEDED]:

CWG expressed some concern about the lack of a precise definition of “suspend point”. Gor Nishanov suggests the following change, in 7.6.2.4 [expr.await] bullet 5.1:

• If the evaluation of await-suspend exits via an exception, the exception is caught, the coroutine is resumed, and the exception is immediately re-thrown (14.2 [except.throw]). Otherwise, control flow returns to the current coroutine caller or resumer (9.5.4 [dcl.fct.def.coroutine]) without exiting any scopes (8.7 [stmt.jump]). The point in the coroutine immediately prior to control returning to its caller or resumer is a coroutine suspend point.

Proposed resolution (approved by CWG 2022-11-10):

1. Change in 7.6.2.4 [expr.await] bullet 3.2 as follows:

   Evaluation of an await-expression involves the following auxiliary types, expressions, and objects:

   • ...

   • a is the cast-expression if the await-expression was implicitly produced by a yield-expression (7.6.17 [expr.yield]), an initial suspend point await expression, or a final suspend point await expression (9.5.4 [dcl.fct.def.coroutine]). Otherwise

   • ...

2. Change in 7.6.2.4 [expr.await] bullet 5.1 as follows:

   • If the evaluation of await-suspend exits via an exception, the exception is caught, the coroutine is resumed, and the exception is immediately re-thrown (14.2 [except.throw]). Otherwise, control flow returns to the current coroutine caller or resumer (9.5.4 [dcl.fct.def.coroutine]) without exiting any scopes (8.7 [stmt.jump]). The point in the coroutine immediately prior to control returning to its caller or resumer is a coroutine suspend point.

3. Change in 9.5.4 [dcl.fct.def.coroutine] paragraph 5 as follows:

   ...where

   • the await-expression containing the call to initial_suspend is the initial suspend point await expression, and

   • the await-expression containing the call to final_suspend is the final suspend point await expression, and

   • initial-await-resume-called is initially false and is set to true immediately before the evaluation of the await-resume expression (7.6.2.4 [expr.await]) of the initial suspend point await expression, and

   • ...

   • promise-constructor-arguments is determined as follows: overload resolution is performed on a promise constructor call created by assembling an argument list with lvalues p₁ ... p_n. If a viable constructor is found (12.2.3 [over.match.viable]), then promise-constructor-arguments is (p₁, ..., p_n), otherwise promise-constructor-arguments is empty. , and

   • a coroutine is suspended at the initial suspend point if it is suspended at the initial await expression, and

   • a coroutine is suspended at a final suspend point if it is suspended

     • at a final await expression or

     • due to an exception exiting from unhandled_exception()

4. Change 9.5.4 [dcl.fct.def.coroutine] paragraph 14 as follows:

   If the evaluation of the expression promise.unhandled_exception() exits via an exception, the coroutine is considered suspended at the final suspend point and the exception propagates to the caller or resumer.

2613. Incomplete definition of resumer

[Accepted as a DR at the November, 2022 meeting.]

Subclause 9.5.4 [dcl.fct.def.coroutine] paragraph 8 specifies:

A suspended coroutine can be resumed to continue execution by invoking a resumption member function (17.12.4.6 [coroutine.handle.resumption]) of a coroutine handle (17.12.4 [coroutine.handle]) that refers to the coroutine. The function that invoked a resumption member function is called the resumer.

However, non-functions can also resume a coroutine, for example:

Task task() {
  std::cout << "in task\n";
  int r = co_await Line();
  std::cout << "resumed\n";
  co_return r;
}
auto r = task();
auto c = (r.coro_.resume(), 0); // #1

Proposed resolution (approved by CWG 2022-08-26):

Change in 9.5.4 [dcl.fct.def.coroutine] paragraph 8 as follows:

A suspended coroutine can be resumed to continue execution by invoking a resumption member function (17.12.4.6 [coroutine.handle.resumption]) of a coroutine handle (17.12.4 [coroutine.handle]) that refers to the coroutine. The function evaluation that invoked a resumption member function is called the resumer.

2590. Underlying type should determine size and alignment requirements of an enum

[Accepted as a DR at the November, 2022 meeting.]

Subclause 9.7.1 [dcl.enum] specifies how the underlying type of an enumeration is determined, and, for enumerations whose underlying type is fixed, specifies that the enumeration has the same set of values as the underlying type. However, the specification does not relate the size and alignment requirements of the enumeration to those of the underlying type. Those ought to be the same.

Suggested resolution [SUPERSEDED]:

Add a new paragraph after 9.7.1 [dcl.enum] paragraph 8:

For an enumeration whose underlying type is fixed, ...

An enumeration has the same size, value representation, and alignment requirements (6.7.6 [basic.align]) as its underlying type. Furthermore, each value of an enumeration has the same representation as the same value of the underlying type.

Two enumeration types are layout-compatible enumerations if ...

Proposed resolution (approved by CWG 2022-08-26):

Add a new paragraph after 9.7.1 [dcl.enum] paragraph 8:

For an enumeration whose underlying type is fixed, ...

An enumeration has the same size, value representation, and alignment requirements (6.7.6 [basic.align]) as its underlying type. Furthermore, each value of an enumeration has the same representation as the corresponding value of the underlying type.

Two enumeration types are layout-compatible enumerations if ...

2621. Kind of lookup for using enum declarations

[Accepted as a DR at the November, 2022 meeting.]

Consider:

enum class E {
  a, b, c
};

using MyE = E;

int main() {
  using enum MyE;   // #1
}

Does the lookup for the elaborated-enum-specifier at #1 use type-only lookup per 6.5.6 [basic.lookup.elab]? There is implementation divergence; EDG, gcc, and MSVC accept, clang rejects.

Suggested resolution [SUPERSEDED]:

Change in 9.7.2 [enum.udecl] paragraph 1 as follows:

Lookup for the elaborated-enum-specifier is as specified in 6.5.6 [basic.lookup.elab]. The elaborated-enum-specifier shall not name a dependent type and the type shall have a reachable enum-specifier.

CWG telecon 2022-09-09:

The example at #1 is intended to be valid; even though the grammar suggests that an elaborated-type-specifier is used here, an ordinary (not a type-only) lookup is performed.

Proposed resolution (approved by CWG 2022-09-23) [SUPERSEDED]:

Change in 9.7.2 [enum.udecl] paragraph 1 as follows:

The terminal name of the elaborated-enum-specifier undergoes ordinary lookup (6.5.3 [basic.lookup.unqual], 6.5.5 [basic.lookup.qual]). The elaborated-enum-specifier shall not name a dependent type and the type shall have a reachable enum-specifier.

CWG 2022-11-07:

Use the wording approach presented in CA-054, with necessary adjunct fixes.

Proposed resolution (approved by CWG 2022-11-10):

Change the grammar before 9.2.9.4 [dcl.type.elab] paragraph 1 as follows, merging the grammar productions:

elaborated-type-specifier :
    class-key attribute-specifier-seqopt nested-name-specifieropt identifier
    class-key simple-template-id
    class-key nested-name-specifier templateopt simple-template-id
    elaborated-enum-specifier
    
elaborated-enum-specifier :
    enum nested-name-specifieropt identifier

Change the grammar before 9.7.2 [enum.udecl] paragraph 1 as follows:

using-enum-declaration:
    using elaborated-enum-specifier enum using-enum-declarator ;

using-enum-declarator:
    nested-name-specifieropt identifier
    nested-name-specifieropt simple-template-id

Change in 9.7.2 [enum.udecl] paragraph 1 as follows:

A using-enum-declarator names the set of declarations found by lookup (6.5.3 [basic.lookup.unqual], 6.5.5 [basic.lookup.qual]) for the using-enum-declarator. The elaborated-enum-specifier using-enum-declarator shall not name a dependent designate a non-dependent type and the type shall have with a reachable enum-specifier.

2538. Can standard attributes be syntactically ignored?

[Accepted as a DR at the November, 2022 meeting.]

Subclause 9.12.1 [dcl.attr.grammar] paragraph 6 specifies that an unrecognized attribute-token is ignored:

For an attribute-token (including an attribute-scoped-token) not specified in this document, the behavior is implementation-defined. Any attribute-token that is not recognized by the implementation is ignored.

The intent is that only non-standard unrecognized attribute-tokens can be ignored; in particular, an implementation is required to syntax-check all standard attributes, even if the implementation then chooses not to effect any semantics for that attribute.

The paper introducing attributes was N2761; the phrasing in question was introduced by P0283R2 attempting to implement the design change presented in P0283R1.

See also paper P2552 (On the ignorability of standard attributes).

Suggested resolution:

Change in 9.12.1 [dcl.attr.grammar] paragraph 6 as follows:

For an attribute-token (including an attribute-scoped-token) not specified in this document, the behavior is implementation-defined. Any ; any such attribute-token that is not recognized by the implementation is ignored.

EWG telecon 2022-05-26

See paper issue 1252.

There was consensus for the statement "It is EWG's intent that [dcl.attr]/6 ONLY permits an implementation to ignore a standard attribute's effect, but not appertainment and argument parsing." To be confirmed by electronic polling.

Proposed resolution (approved by CWG 2022-07-01) [SUPERSEDED]:

Change in 9.12.1 [dcl.attr.grammar] paragraph 6 as follows:

For an attribute-token (including an attribute-scoped-token) not specified in this document, the behavior is implementation-defined. Any ; any such attribute-token that is not recognized by the implementation is ignored. [ Note: A program is ill-formed if it contains an attribute specified in 9.12 [dcl.attr] that violates the rules to which entity or statement the attribute may apply or the syntax rules for the attribute's attribute-argument-clause, if any. -- end note ]

EWG 2022-06 electronic polling

No consensus. See vote.

EWG 2022-11-08

Approved the direction of the 2022-07-01 proposed resolution.

Proposed resolution (approved by CWG 2022-11-08):

Change in 9.12.1 [dcl.attr.grammar] paragraph 6 as follows:

For an attribute-token (including an attribute-scoped-token) not specified in this document, the behavior is implementation-defined. Any ; any such attribute-token that is not recognized by the implementation is ignored. [ Note: A program is ill-formed if it contains an attribute specified in 9.12 [dcl.attr] that violates the rules specifying to which entity or statement the attribute may apply or the syntax rules for the attribute's attribute-argument-clause, if any. -- end note ]

2443. Meaningless template exports

[Accepted as a DR at the November, 2022 meeting, as part of paper P2615R1 (Meaningful exports).]

According to 10.2 [module.interface] paragraph 1, export does not interfere with other definitions; paragraph 3 merely requires that it appear in a declaration that declares at least one name. 13.1 [temp.pre] paragraph 4 prevents using an export-declaration as the declaration of a template-declaration.

With some interpretation, these rules appear to allow various useless constructs like:

   template export void f();
   export template void f();
   export template<> void g(int);
   template<> export void g(int);
   export template<class T> struct trait<T*>;

Simply forbidding them in 10.2 [module.interface] paragraph 3 would also prohibit their appearance in export blocks:

   export {
     template<class> struct A;
     template<class T> struct A<T*>;
   }

It is already the case that the closely-related example

   export {
     template<class T> struct A {A(non_deducible<T>);};
     template<class U> A(U) -> A<find_param<U>>;
   }

is disallowed, although a fix is pending in EWG.

Suggested resolution: Forbid the direct use of the export keyword in these contexts but continue to allow them (and perhaps more) in export { }.

Notes from the February, 2021 teleconference:

CWG agreed with the suggested direction.

Notes from the 2022-05-20 CWG telecon:

CWG agreed with the wording suggested by Herring; forwarding to EWG for approval.

2605. Implicit-lifetime aggregates

[Accepted as a DR at the November, 2022 meeting.]

Subclause 11.2 [class.prop] paragraph 9 specifies:

A class S is an implicit-lifetime class if

• it is an aggregate or
• it has at least one trivial eligible constructor and a trivial, non-deleted destructor.

However, an aggregate may have a non-deleted non-trivial destructor:

  struct X {
    Y i;
    ~X();
  };

This class is an aggregate, but destroying X itself (ignoring the subobjects) does not satisfy "destroying an instance of the type runs no code"; see P0593R6 "Implicit creation of objects for low-level object manipulation" section 3.1.

Additional notes (September, 2022):

From a thread starting here: What if X had a deleted destructor (either explicitly or implicitly)?

CWG 2022-11-09:

A deleted destructor does not prevent an aggregate from being an implicit-lifetime class.

Proposed resolution (approved by CWG 2022-11-09):

Change in 11.2 [class.prop] paragraph 9 as follows:

A class S is an implicit-lifetime class if

• it is an aggregate whose destructor is not user-provided or
• it has at least one trivial eligible constructor and a trivial, non-deleted destructor.

2583. Common initial sequence should consider over-alignment

[Accepted as a DR at the November, 2022 meeting.]

Consider:

  struct A {
    int i;
    char c;
  };

  struct B {
    int i;
    alignas(8) char c;
  };

  union U { A a; B b; };

On a lot of platforms, A and B do not have the same layout, yet 11.4.1 [class.mem.general] paragraph 23 does not consider differences in alignment in the rules for "common initial sequence":

The common initial sequence of two standard-layout struct (11.2 [class.prop]) types is the longest sequence of non-static data members and bit-fields in declaration order, starting with the first such entity in each of the structs, such that corresponding entities have layout-compatible types (6.8 [basic.types]), either both entities are declared with the no_unique_address attribute (9.12.11 [dcl.attr.nouniqueaddr]) or neither is, and either both entities are bit-fields with the same width or neither is a bit-field.

In the following example,

  struct S0 {
    alignas(16) char x[128];
    int i;
  };
  struct alignas(16) S1 {
    char x[128];
    int i;
  };

S0 and S1 have the same alignment, yet per the suggested rules below, they will not be layout-compatible.

Suggested resolution [SUPERSEDED]:

Change in 11.4.1 [class.mem.general] paragraphs 23-25 as follows (also add bullets):

The common initial sequence of two standard-layout struct (11.2 [class.prop]) types is the longest sequence of non-static data members and bit-fields in declaration order, starting with the first such entity in each of the structs, such that

• corresponding entities have layout-compatible types (6.8 [basic.types]),
• either both entities have alignment-specifiers that specify equivalent alignment or neither entity has an alignment-specifier (9.12.2 [dcl.align]),
• either both entities are declared with the no_unique_address attribute (9.12.11 [dcl.attr.nouniqueaddr]) or neither is, and
• either both entities are bit-fields with the same width or neither is a bit-field.

[...]

Two standard-layout struct (11.2 [class.prop]) types are layout-compatible classes if their common initial sequence comprises all members and bit-fields of both classes (6.8 [basic.types]) and either both types are declared with alignment-specifiers that specify equivalent alignment or neither type has an alignment-specifier.

Two standard-layout unions are layout-compatible if they have the same number of non-static data members and corresponding non-static data members (in any order)

• have layout-compatible types (6.8.1 [basic.types.general]) and
• either both have alignment-specifiers that specify equivalent alignment or neither has an alignment-specifier.

Proposed resolution (approved by CWG telecon 2022-08-26):

Change in 11.4.1 [class.mem.general] paragraphs 23-25 as follows (also add bullets):

The common initial sequence of two standard-layout struct (11.2 [class.prop]) types is the longest sequence of non-static data members and bit-fields in declaration order, starting with the first such entity in each of the structs, such that

• corresponding entities have layout-compatible types (6.8 [basic.types]),
• corresponding entities have the same alignment requirements (6.7.6 [basic.align]),
• either both entities are declared with the no_unique_address attribute (9.12.11 [dcl.attr.nouniqueaddr]) or neither is, and
• either both entities are bit-fields with the same width or neither is a bit-field.

[...]

2630. Syntactic specification of class completeness

[Accepted as a DR at the November, 2022 meeting.]

Consider:

// translation unit 1
export module A;
export class X {};

// translation unit 2
import A;
X x; // is X complete at this point?

Subclause 11.4.1 [class.mem.general] paragraph 8 specifies:

A class is considered a completely-defined object type (6.8.1 [basic.types.general]) (or complete type) at the closing } of the class-specifier. ...

The syntactic (even lexical) reference to the closing } does not address the question when a different translation unit regards a class as complete. However, it seems this provision is entirely redundant given 6.3 [basic.def.odr] paragraph 13:

A definition of a class shall be reachable in every context in which the class is used in a way that requires the class type to be complete.

The standard never asks the question: "Is class X complete?"; it always specifies "X shall be complete" (otherwise the program is ill-formed).

Possible resolution [SUPERSEDED]:

Change in 11.4.1 [class.mem.general] paragraph 8 as follows:

A class is considered a completely-defined object type (6.8.1 [basic.types.general]) (or complete type) at the closing } of the class-specifier. The A class is regarded as complete within its complete-class contexts; otherwise it is regarded as incomplete within its own class member-specification.

CWG telecon 2022-10-21:

Explicitly refer to reachable definitions.

Proposed resolution (approved by CWG 2022-11-09):

Change in 11.4.1 [class.mem.general] paragraph 8 as follows:

A class is considered a completely-defined object type (6.8.1 [basic.types.general]) (or complete type) at the closing } of the class-specifier. The A class is regarded as complete where its definition is reachable and within its complete-class contexts; otherwise it is regarded as incomplete within its own class member-specification.

2649. Incorrect note about implicit conversion sequence

[Accepted as a DR at the November, 2022 meeting.]

Contrary to the note in the subject paragraph, overload resolution in selecting a surrogate call function can prefer a different conversion operator for the implicit conversion sequence because the conversion function from which the surrogate call function was derived is not the best viable function.

For example, noting that surrogate call functions are not generated from conversion function templates, the single surrogate call function derived from the (non-template) conversion function below is the sole candidate for the call; however, the specialization of the conversion function template is a better candidate f or the implicit conversion sequence during overload resolution:

  using ff = int (*)(int);
  constexpr int ffimpl0(int x) {
   return x;
  }
  constexpr int ffimpl1(int x) {
   return x + 1;
  }
  struct A {
   template <typename T> constexpr operator T() const { return ffimpl0; }
   constexpr operator ff() const volatile { return ffimpl1; }
  };
  char x[A()(42.f)];
  extern char x[43];

Proposed resolution (approved CWG 2022-11-08):

Change in 12.2.2.2.3 [over.call.object] paragraph 3 as follows:

[Note 1: When comparing the call against the function call operators, the implied object argument is compared against the object parameter of the function call operator. When comparing the call against a surrogate call function, the implied object argument is compared against the first parameter of the surrogate call function. The conversion function from which the surrogate call function was derived will be used in the conversion sequence for that parameter since it converts the implied object argument to the appropriate function pointer or reference required by that first parameter. —end note]

2648. Correspondence of surrogate call function and conversion function

[Accepted as a DR at the November, 2022 meeting.]

Post-Prague "editorial" change cplusplus/draft#3625 removed the normative text supporting the interpretation that surrogate call functions, when chosen, call the functions they were formed from.

Proposed resolution (approved by CWG 2022-11-08):

Change in 12.4.4 [over.call] paragraph 1 as follows:

If a surrogate call function for a conversion function named operator conversion-type-id is selected, let e be the result of invoking the corresponding conversion operator function on the postfix-expression; is invoked the expression is interpreted as

postfix-expression . operator conversion-type-id () e ( expression-listopt )

Otherwise, ...

2611. Missing parentheses in expansion of fold-expression could cause syntactic reinterpretation

[Accepted as a DR at the November, 2022 meeting.]

13.7.4 [temp.variadic] paragraph 10 expands a fold-expression (including its enclosing parentheses) to an unparenthesized expression. If interpreted literally, this could result in reassociation and misinterpretation of the expression. For example, given:

template<int ...N> int k = 2 * (... + N);

... k<1, 2, 3> is specified as expanding to int k<1, 2, 3> = 2 * 1 + (2 + 3); resulting in a value of 7 rather than the intended value of 12.

Further, there is implementation divergence for the following example:

#include <type_traits>
template<class ...TT>
void f(TT ...tt) {
  static_assert(std::is_same_v<decltype((tt, ...)), int&>);
}
template void f(int /*,int*/);

gcc and MSVC apply the general expression interpretation of decltype, whereas clang and icc apply the identifier special case.

Proposed resolution (approved by CWG 2022-08-26):

The instantiation of a fold-expression (7.5.6 [expr.prim.fold]) produces:

• ( ((E₁ op E₂ ) op . . . ) op E_N ) for a unary left fold,
• ( E₁ op (. . . op (E_N-1 op E_N )) ) for a unary right fold,
• ( (((E op E₁ ) op E₂ ) op . . . ) op E_N ) for a binary left fold, and
• ( E₁ op (. . . op (E_N-1 op (E_N op E))) ) for a binary right fold.

...

2603. Holistic functional equivalence for function templates

[Accepted as a DR at the November, 2022 meeting.]

In C++20, 13.7.7.2 [temp.over.link] paragraph 7 defined equivalence for function templates in terms of equivalence of several of its components; functional equivalence for them was similar in that it was defined recursively for their "return types and parameter lists", but differed with regard to constraints in that it required that they "accept and are satisfied by the same set of template argument lists". P1787R6 simplified the treatment by relying entirely on the "depends on whether two constructs are equivalent, and they are functionally equivalent but not equivalent" rule to make the correspondence check between the function templates ill-formed, no diagnostic required.

This created a situation where moving a constraint between a template-head and a requires-clause makes a function template truly different (because there is no reasonable way to read 6.4.1 [basic.scope.scope] bullet 4.3.2's "equivalent [...], template-heads, and trailing requires-clauses (if any)" as requiring a joint check for functional equivalence), even if overload resolution would never be able to distinguish them.

Suggested resolution [SUPERSEDED]:

Change in 13.7.7.2 [temp.over.link] paragraph 7 as follows:

If the validity or meaning of the program depends on whether two constructs are equivalent, and they are functionally equivalent but not equivalent, the program is ill-formed, no diagnostic required. Furthermore, if two function templates do not correspond, but accept and are satisfied by the same set of template argument lists, the program is ill-formed, no diagnostic required.

Suggested resolution (August, 2022) [SUPERSEDED]:

1. Append to 6.4.1 [basic.scope.scope] paragraph 3 as follows:

   • ...
   • the types of their object parameters are equivalent.
   Two function templates have corresponding signatures if their template-parameter-lists have the same length, corresponding template-parameters 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.

2. Change in 6.4.1 [basic.scope.scope] paragraph 4 as follows:

   • ...
   • • ...
     • both declare function templates with corresponding signatures and equivalent non-object-parameter-type-lists, return types (if any), template-heads, and trailing requires-clauses (if any), and, if both are non-static members, they have corresponding object parameters.

3. Change in 13.7.7.2 [temp.over.link] paragraph 7 as follows:

   If the validity or meaning of the program depends on whether two constructs are equivalent, and they are functionally equivalent but not equivalent, the program is ill-formed, no diagnostic required. Furthermore, if two function templates with corresponding signatures do not correspond, but accept and are satisfied by the same set of template argument lists, the program is ill-formed, no diagnostic required.

Proposed resolution (approved by CWG 2022-09-09):

1. Append to 6.4.1 [basic.scope.scope] paragraph 3 as follows:

   • ...
   • the types of their object parameters are equivalent.
   Two function templates have corresponding signatures if their template-parameter-lists have the same length, corresponding template-parameters 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.

2. Change in 6.4.1 [basic.scope.scope] paragraph 4 as follows:

   • ...
   • • ...
     • both declare function templates with corresponding signatures and equivalent non-object-parameter-type-lists, return types (if any), template-heads, and trailing requires-clauses (if any), and, if both are non-static members, they have corresponding object parameters.

3. Change in 13.7.7.2 [temp.over.link] paragraph 7 as follows:

   If the validity or meaning of the program depends on whether two constructs are equivalent, and they are functionally equivalent but not equivalent, the program is ill-formed, no diagnostic required. Furthermore, if two function templates that do not correspond

   • have the same name,
   • have corresponding signatures (6.4.1 [basic.scope.scope]),
   • would declare the same entity (6.6 [basic.link]) considering them to correspond, and
   • accept and are satisfied by the same set of template argument lists,

   the program is ill-formed, no diagnostic required.

2428. Deprecating a concept

[Accepted as a DR at the November, 2022 meeting.]

The grammar for a concept-definition does not include an attribute-specifier-seq_opt, making it impossible to deprecate an attribute. This seems like an oversight.

CWG telecon 2022-10-07:

Agreed.

Proposed resolution (approved by CWG 2022-10-21):

1. Change in 9.12.5 [dcl.attr.deprecated] paragraph 2 as follows:

   The attribute may be applied to the declaration of a class, a typedef-name, a variable, a non-static data member, a function, a namespace, an enumeration, an enumerator, a concept, or a template specialization.

2. Change in 13.7.9 [temp.concept] paragraph 1 as follows:

   A concept is a template that defines constraints on its template arguments.

   concept-definition:
       concept concept-name attribute-specifier-seqopt = constraint-expression ;
   
   concept-name:
       identifier
   

   A concept-definition declares a concept. Its identifier becomes a concept-name referring to that concept within its scope. The optional attribute-specifier-seq appertains to the concept.

2508. Restrictions on uses of template parameter names

[Accepted as a DR at the November, 2022 meeting.]

The status of an example like the following is unclear:

  template<typename T> T T(T) {}

According to 13.8.2 [temp.local] paragraph 6,

The name of a template-parameter shall not be bound to any following declaration contained by the scope to which the template-parameter belongs. [Example 5:

  ...
  template<class X> class X; // error: hidden by template-parameter

—end example]

The intent would appear to be that the function template could not have the same name as the template parameter. However, according to 6.4.9 [basic.scope.temp] paragraph 2,

Each template-declaration D introduces a template parameter scope that extends from the beginning of its template-parameter-list to the end of the template-declaration. Any declaration outside the template-parameter-list that would inhabit that scope instead inhabits the same scope as D.

This would indicate that the function template inhabits the namespace scope, not the template parameter scope, so the prohibition against use of the template parameter name would not apply.

To reject both the function and class template examples, 13.8.2 [temp.local] paragraph 6 could be changed to read:

The name of a template-parameter shall not be bound to any following declaration whose locus is contained by the scope to which the template-parameter belongs.

To accept both examples, the change could be:

The name of a template-parameter shall not be bound to any following declaration that inhabits a scope contained by the scope to which the template-parameter belongs.

Notes from the December, 2021 teleconference:

The consensus of CWG was to reject both examples, i.e., the first option.

Additional note (December, 2021):

It was observed that this issue is, strictly speaking, not a defect: the word “contains” is used in 6.4.1 [basic.scope.scope] paragraph 1 in its usual English sense to refer to the lexical nesting of scopes, so the template parameter scope of T “contains” the declaration of the function T. However, the use of the term “locus” would make the intent clearer.

Proposed resolution (December, 2021):

Change 13.8.2 [temp.local] paragraph 6 as follows:

The name of a template-parameter shall not be bound to any following declaration whose locus is contained by the scope to which the template-parameter belongs.

1396. Deferred instantiation and checking of non-static data member initializers

[Resolved by issue 2631, which was accepted as a DR at the November, 2022 meeting.]

Non-static data member initializers get the same late parsing as member functions and default arguments, but are they also instantiated as needed like them? And when is their validity checked?

Notes from the October, 2012 meeting:

CWG agreed that non-static data member initializers should be handled like default arguments.

Additional note (March, 2013):

Determining whether a defaulted constructor is constexpr or not requires parsing the class's non-static data member initializers; see also issue 1360.

CWG 2022-11-11

Resolved by issue 2631.

2604. Attributes for an explicit specialization

[Accepted as a DR at the November, 2022 meeting.]

It is unclear whether an explicit template specialization "inherits" the attributes written on the primary template, or whether the specialization has to repeat the attributes. For example:

  template <typename Ty>
  [[noreturn]] void func(Ty);

  template <>
  void func<int>(int) {
    // Warning about returning from a noreturn function or not?
  }

A similar question arises for attributes written on the parameters of the primary function template. For example:

  template <typename Ty>
  void func([[maybe_unused]] int i);

  template <>
  void func<int>(int i) {
   // i is not used, should it be warned on or not?
  }

There is implementation divergence for the example.

Suggested resolution [SUPERSEDED]:

Change in 13.9.4 [temp.expl.spec] paragraph 13 as follows:

Any attributes applying to any part of the declaration of an explicit specialization of a function or variable template, as well as Whether whether such an explicit specialization of a function or variable template is inline, constexpr, or an immediate function, is determined by the explicit specialization and is independent of those properties of the template. [ Note: Attributes that would affect the association of the declaration of an explicit specialization with the declaration of the primary template need to match. -- end note ]

Proposed resolution (approved by CWG 2022-11-09):

Change 13.9.4 [temp.expl.spec] paragraph 13 as follows:

Whether an explicit specialization of a function or variable template is inline, constexpr, or an immediate function is determined by the explicit specialization and is independent of those properties of the template. Similarly, attributes appearing in the declaration of a template have no effect on an explicit specialization of that template. [Example 7:

  template<class T> void f(T) { /* ... */ }
  template<class T> inline T g(T) { /* ... */ }

  template<> inline void f<>(int) { /* ... */ } // OK, inline
  template<> int g<>(int) { /* ... */ }         // OK, not inline

  template<typename> [[noreturn]] void h([[maybe_unused]] int i);
  template<> void h<int>(int i) {
    // Implementations are expected not to warn that the function returns but can
    // warn about the unused parameter.
  }

—end example]

2618. Substitution during deduction should exclude exception specifications

[Accepted as a DR at the November, 2022 meeting.]

Subclause 13.10.3.1 [temp.deduct.general] paragraph 7 specifies:

The substitution occurs in all types and expressions that are used in the function type and in template parameter declarations. The expressions include not only constant expressions such as those that appear in array bounds or as nontype template arguments but also general expressions (i.e., non-constant expressions) inside sizeof, decltype, and other contexts that allow non-constant expressions. The substitution proceeds in lexical order and stops when a condition that causes deduction to fail is encountered. If substitution into different declarations of the same function template would cause template instantiations to occur in a different order or not at all, the program is ill-formed; no diagnostic required.

[Note 4: The equivalent substitution in exception specifications is done only when the noexcept-specifier is instantiated, at which point a program is ill-formed if the substitution results in an invalid type or expression. —end note]

The note says that substitution into the noexcept-specifier occurs late, but the normative text does not support that, because the exception specification is part of the function type.

Subclause 13.10.3.1 [temp.deduct.general] paragraph 8 specifies:

Only invalid types and expressions in the immediate context of the function type, its template parameter types, and its explicit-specifier can result in a deduction failure.

However, paragraph 7 does not mention the explicit-specifier when describing the substitution.

Proposed resolution (approved by CWG 2022-09-09):

Change in 13.10.3.1 [temp.deduct.general] paragraph 7 as follows:

The deduction substitution loci are

• the function type outside of the noexcept-specifier,
• the explicit-specifier, and
• the template parameter declarations.

The substitution occurs in all types and expressions that are used in the function type and in template parameter declarations deduction substitution loci. ...

Change in 13.10.3.1 [temp.deduct.general] paragraph 8 as follows:

... Only invalid Invalid types and expressions can result in a deduction failure only in the immediate context of the function type, its template parameter types, and its explicit-specifier deduction substitution loci can result in a deduction failure.

2650. Incorrect example for ill-formed non-type template arguments

[Accepted as a DR at the November, 2022 meeting.]

The example intends to illustrate that a class type cannot be the type of a non-type template parameter (although the example is still ill-formed because "T()" is interpreted as a function type).

Proposed resolution (approved by CWG 2022-11-08):

Change in 13.10.3.1 [temp.deduct.general] bullet 11.8 as follows:

• ...
• Attempting to give an invalid type to a non-type template parameter. [Example 13:

    template <class T, T> struct S {};
    template <class T> int f(S<T, T()T{}>*);   // #1
    class X {
      int m;
    };
    int i0 = f<X>(0);   // #1 uses a value of non-structural type X as a non-type template argument
  

  -- end example ]
• ...

2651. Conversion function templates and "noexcept"

[Accepted as a DR at the November, 2022 meeting.]

The rule in 13.10.3.4 [temp.deduct.conv] bullet 5.2 seems to allow

template<class T,bool B>
using get=T(*)() noexcept(B);

struct A {
 template<class T>
 operator get<T,false>() const;
};

auto *p=A().operator get<int,true>();

Proposed resolution (approved by CWG 2022-11-09):

Change in 13.10.3.4 [temp.deduct.conv] paragraph 1 as follows:

... If the conversion-function-id is constructed during overload resolution ([over.match.funcs]), the following transformations rules in the remainder of this subclause apply.

Change in 13.10.3.4 [temp.deduct.conv] bullet 5.2 as follows:

However, certain attributes of A may be ignored:

• ...
• If the original A is a function pointer or pointer-to-member-function type with a potentially-throwing exception specification (14.5 [except.spec]), its noexcept the exception specification.
• ...

2601. Tracking of created and destroyed subobjects

[Accepted as a DR at the November, 2022 meeting.]

Subclause 14.3 [except.ctor] paragraph 3 specifies:

If the initialization or destruction of an object other than by delegating constructor is terminated by an exception, the destructor is invoked for each of the object's direct subobjects and, for a complete object, virtual base class subobjects, whose initialization has completed (9.4 [dcl.init]) and whose destructor has not yet begun execution, except that in the case of destruction, the variant members of a union-like class are not destroyed.

A traditional implementation has no way of knowing which subobjects are in the state that their initialization has completed but their destructor has not yet begun execution. For example, the program might call the destructor explicitly, and the implementation does not track whether that has happened. The intent here is that it only matters whether the implied destructor call generated implicitly as part of the class object's destructor has begun yet, but it does not say that, and the reference to variant members reinforces the interpretation that the set of subobjects that are destroyed is determined dynamically based on which objects are within their lifetimes. Also, combining construction and destruction rules here confuses the matter further -- in "whose initialization has completed and whose destructor has not yet begun" we care exclusively about the first part in constructors and exclusively about the second part in destructors.

The set of things that we actually want to destroy here is the things that were initialized by the initialization (constructor or aggregate initializer) itself, not the things that have been constructed and not destroyed by evaluations that the initialization happens to perform. For example:

  struct A {
    union { T x; U y; };
    A() { throw "does not destroy x"; }
    A(int) : x() { throw "does destroy x"; }
    A(float) : x() { x.~T(); throw "still destroys x, oops"; }
    A(double) : x() {
      x.~T();
      new(&y) U();
      throw "destroys x, does not destroy y";
    }
  };

and similarly for aggregate initialization:

  struct B {
    union { T x; U y; };
    int a;
  };
  B b = { .x = {}, .a = (b.x.~T(), new (&b.y) U(), throw "destroys x not y")};

Destruction is completely different: we just want to destroy all the things that the destructor was going to destroy anyway and hasn't already started destroying.

Suggested resolution [SUPERSEDED]:

Change in 14.3 [except.ctor] paragraph 3 as follows:

If the initialization or destruction of an object other than by delegating constructor is terminated by an exception, the destructor is invoked for each of the object's direct subobjects and, for a complete object, virtual base class subobjects that were directly initialized by the object's initialization and , whose initialization has completed (9.4 [dcl.init]) and whose destructor has not yet begun execution, except that in the case of destruction, the variant members of a union-like class are not destroyed. A subobject is directly initialized if its initialization is specified in 11.9.3 [class.base.init] for initialization by constructor, in 11.9.4 [class.inhctor.init] for initialization by inherited constructor, in 9.4.2 [dcl.init.aggr] for aggregate initialization, or in 9.4.1 [dcl.init.general] for default-initialization, value-initialization, or direct-initialization of an array. [Note: This includes virtual base class subobjects if the initialization is for a complete object, and can include variant members that were nominated explicitly by a mem-initializer or designated-initializer-clause or that have a default member initializer. -- end note]

If the destructor of an object is terminated by an exception, each destructor invocation that would be performed after executing the body of the destructor (11.4.7 [class.dtor]) and that has not yet begun execution is performed. [Note: This includes virtual base class subobjects if the destructor was invoked for a complete object. -- end note ]

Proposed resolution (CWG telecon 2022-08-12) [SUPERSEDED]:

Change in 14.3 [except.ctor] paragraph 3 as follows:

If the initialization or destruction of an object other than by delegating constructor is terminated by an exception, the destructor is invoked for each of the object's direct subobjects and, for a complete object, virtual base class subobjects that were known to be initialized by the object's initialization and , whose initialization has completed (9.4 [dcl.init]) and whose destructor has not yet begun execution, except that in the case of destruction, the variant members of a union-like class are not destroyed. A subobject is known to be initialized if its initialization is specified in 11.9.3 [class.base.init] for initialization by constructor, in 11.9.4 [class.inhctor.init] for initialization by inherited constructor, in 9.4.2 [dcl.init.aggr] for aggregate initialization, or in 9.4.1 [dcl.init.general] for default-initialization, value-initialization, or direct-initialization of an array. [Note: This includes virtual base class subobjects if the initialization is for a complete object, and can include variant members that were nominated explicitly by a mem-initializer or designated-initializer-clause or that have a default member initializer. -- end note]

If the destructor of an object is terminated by an exception, each destructor invocation that would be performed after executing the body of the destructor (11.4.7 [class.dtor]) and that has not yet begun execution is performed. [Note: This includes virtual base class subobjects if the destructor was invoked for a complete object. -- end note ]

Additional notes (August, 2022):

The proposed resolution above does not handle the situation where the initialization of a closure object is terminated by an exception during the evaluation of a lambda expression. It also does not handle 11.4.5.3 [class.copy.ctor] bullet 14.1 (array copies in defaulted constructors).

Proposed resolution (approved by CWG telecon 2022-09-09):

Change in 14.3 [except.ctor] paragraph 3 as follows:

If the initialization or destruction of an object other than by delegating constructor is terminated by an exception, the destructor is invoked for each of the object's direct subobjects and, for a complete object, virtual base class subobjects that were known to be initialized by the object's initialization and , whose initialization has completed (9.4 [dcl.init]) and whose destructor has not yet begun execution, except that in the case of destruction, the variant members of a union-like class are not destroyed. [Note: If such an object has a reference member that extends the lifetime of a temporary object, this ends the lifetime of the reference member, so the lifetime of the temporary object is effectively not extended. —end note] A subobject is known to be initialized if its initialization is specified

• in 11.9.3 [class.base.init] for initialization by constructor,
• in 11.4.5.3 [class.copy.ctor] for initialization by defaulted copy/move constructor,
• in 11.9.4 [class.inhctor.init] for initialization by inherited constructor,
• in 9.4.2 [dcl.init.aggr] for aggregate initialization,
• in 7.5.5.3 [expr.prim.lambda.capture] for the initialization of the closure object when evaluating a lambda-expression,
• in 9.4.1 [dcl.init.general] for default-initialization, value-initialization, or direct-initialization of an array.

[Note: This includes virtual base class subobjects if the initialization is for a complete object, and can include variant members that were nominated explicitly by a mem-initializer or designated-initializer-clause or that have a default member initializer. —end note]

If the destructor of an object is terminated by an exception, each destructor invocation that would be performed after executing the body of the destructor (11.4.7 [class.dtor]) and that has not yet begun execution is performed. [Note: This includes virtual base class subobjects if the destructor was invoked for a complete object. —end note]

The subobjects are destroyed in the reverse order of the completion of their construction. Such destruction is sequenced before entering a handler of the function-try-block of the constructor or destructor, if any.

2622. Compounding types from function and pointer-to-member types

[Accepted as a DR at the November, 2022 meeting.]

Clause Annex B [implimits] bullet 2.3 specifies:

• Pointer (9.3.4.2 [dcl.ptr]), array (9.3.4.5 [dcl.array]), and function (9.3.4.6 [dcl.fct]) declarators (in any combination) modifying a class, arithmetic, or incomplete type in a declaration [256].

This omits function types as the to-be-modified type, and ignores pointer-to-member declarators.

Proposed resolution (approved by CWG 2022-09-23):

Change in Clause Annex B [implimits] bullet 2.3 as follows:

• Pointer (9.3.4.2 [dcl.ptr]), pointer-to-member (9.3.4.4 [dcl.mptr]), array (9.3.4.5 [dcl.array]), and function (9.3.4.6 [dcl.fct]) declarators (in any combination) modifying a class, arithmetic, or incomplete type in a declaration [256].

2407. Missing entry in Annex C for defaulted comparison operators

[Accepted as a DR at the November, 2022 meeting.]

The changes from P1185R2 need an entry in Annex C, because they affect the interpretation of existing well-formed code. For example, given:

  struct A {
    operator int() const { return 10; }
  };

  bool operator==(A, int); // #1
  //built-in: bool operator==(int, int); // #2

  A a, b;

The expression 10 == a resolves to #2 in C++17 but now to #1. In addition, a == b is now ambiguous, because #1 has a user-defined conversion on the second argument, while the reversed order has it on the first argument. Similarly for operator!=.

Notes from the March, 2019 teleconference:

The ambiguity in 10 == a arises from the consideration of the reverse ordering of the operands.

CWG found this breakage surprising and asked for EWG's opinion before updating Annex C.

Proposed resolution (April, 2019) [SUPERSEDED]

Add the following as a new subclause in C.2 [diff.cpp17]:

C.5.6 Clause 12: Overloading

Affected subclause: 12.2.2.3 [over.match.oper]
Change: Overload resolution may change for equality operators 7.6.10 [expr.eq].
Rationale: Support calling operator== with reversed order of arguments.
Effect on original feature: Valid C++ 2017 code that uses equality operators with conversion functions may be ill-formed or have different semantics in this International Standard.

  struct A {
    operator int() const { return 10; }
  };

  bool operator==(A, int);               // #1
  // built-in: bool operator==(int, int);  // #2
  bool b = 10 == A();                   // uses #1 with reversed order of arguments; previously used #2

Proposed resolution:

Add the following as a new subclause in C.2 [diff.cpp17]:

C.5.6 Clause 12: Overloading

Affected subclause: 12.2.2.3 [over.match.oper]
Change: Overload resolution may change for equality operators 7.6.10 [expr.eq].
Rationale: Support calling operator== with reversed order of arguments.
Effect on original feature: Valid C++ 2017 code that uses equality operators with conversion functions may be ill-formed or have different semantics in this International Standard.

  struct A {
    operator int() const { return 10; }
  };

  bool operator==(A, int);               // #1
  // built-in: bool operator==(int, int);   // #2
  bool b = 10 == A();                   // uses #1 with reversed order of arguments; previously used #2

  struct B {
    bool operator==(const B&);          // member function with no cv-qualifier
  };
  B b1;
  bool eq = (b1 == b1);                   // ambiguous; previously well-formed

2636. Update Annex E based on Unicode 15.0 UAX #31

[Accepted as a DR at the November, 2022 meeting.]

Unicode 15.0 UAX #31 clarified that rule R3 was, in fact, intended to apply to programming languages. WG21's prior understanding was that programming languages are not in scope of that rule. The proposed resolution updates E.4 [uaxid.pattern] to the revised understanding. See paper P2653R1 (Update Annex E based on Unicode 15.0 UAX 31) for more details.

Proposed resolution (approved by CWG 2022-10-21):

Change in E.4 [uaxid.pattern] as follows:

UAX #31 describes how formal languages that use or interpret patterns of characters, such as regular expressions or number formats, may describe that syntax with Unicode properties such as computer languages should describe and implement their use of whitespace and syntactically significant characters during the processes of lexing and parsing.

C++ does not do this as part of the language, deferring to library components for such usage of patterns. This requirement does not apply to C++ claim conformance with this requirement.

Issues with "WP" Status

2639. new-lines after phase 1

[Accepted at the November, 2022 meeting.]

Translation phases 2 and 3 assume that lines are terminated by "new-line characters". However, the current specification of phase 1 does not guarantee that to be true. In particular, for a UTF-8 file the verbatim sequence of source file characters forms the input for phase 2, even on systems where the line terminator is a carriage return. The non-UTF-8 specification is also defective in that it speaks of "introducing" new-line characters, even for encodings like Latin-1 where new-lines might already be present and no "introduction" is needed or appropriate.

Proposed resolution [SUPERSEDED]:

Change in 5.2 [lex.phases] paragraph 1.1 as follows:

... If an input file is determined to be a UTF-8 file, then it shall be a well-formed UTF-8 code unit sequence and it is decoded to produce a sequence of UCS scalar values that constitutes the sequence of elements of the translation character set, representing each line-termination character or character sequence as a new-line character.

For any other kind of input file supported by the implementation, characters are mapped, in an implementation-defined manner, to a sequence of translation character set elements (5.3 [lex.charset]) (introducing new-line characters for representing end-of-line indicators as new-line characters).

Proposed resolution (approved by CWG 2022-11-08):

Change in 5.2 [lex.phases] paragraph 1.1 as follows:

... If an input file is determined to be a UTF-8 file, then it shall be a well-formed UTF-8 code unit sequence and it is decoded to produce a sequence of UCS scalar values that constitutes the sequence of elements of the translation character set. In the resulting sequence, each pair of characters in the input sequence consisting of U+000D CARRIAGE RETURN followed by U+000A LINE FEED, as well as each U+000D CARRIAGE RETURN not immediately followed by a U+000A LINE FEED, is replaced by a single new-line character.

For any other kind of input file supported by the implementation, characters are mapped, in an implementation-defined manner, to a sequence of translation character set elements (5.3 [lex.charset]) (introducing new-line characters for , representing end-of-line indicators as new-line characters ).

2640. Allow more characters in an n-char sequence

[Accepted at the November, 2022 meeting.]

The n-char grammar term is defined to match only the Latin uppercase, Latin digit, hyphen and space characters. This results in \N{ABC} matching named-universal-character while \N{abc} does not. This leads to programs like the following being unexpectedly well-formed because the \N{abc} sequence is lexed as the preprocessing token sequence , N, {, abc, }. The expansion of macro a then leads to the token sequence being passed as an argument to macro z where it is discarded.

  #define z(x) 0
  #define a z(
  int x = a\N{abc});

Changes to make the above program ill-formed would provide two benefits:

• Implementations could diagnose the \N{abc} sequence as an ill-formed named-universal-character regardless of where it appears in a program.
• The \N{...} syntax space would be reserved for expansion (e.g., for extensions or future support of UAX44-LM2 loose matching schemes).

Proposed resolution (approved by CWG 2022-11-07):

Change the grammar in 5.3 [lex.charset] paragraph 3 as follows:

n-char:
     A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
     0 1 2 3 4 5 6 7 8 9
     U+002d hyphen-minus
     U+0020 space
     any member of the translation character set except the U+007D RIGHT CURLY BRACKET or new-line character

2653. Can an explicit object parameter have a default argument?

[Accepted at the November, 2022 meeting.]

The syntax and semantics appear to allow:

  struct S { void f(this const S& = S{}); };

Proposed resolution (approved by CWG 2022-11-08):

Change in 9.3.4.6 [dcl.fct] paragraph 3 as follows:

parameter-declaration:
    attribute-specifier-seqopt thisopt decl-specifier-seq declarator
    attribute-specifier-seqopt thisopt decl-specifier-seq declarator = initializer-clause
    attribute-specifier-seqopt thisopt decl-specifier-seq abstract-declaratoropt
    attribute-specifier-seqopt thisopt decl-specifier-seq abstract-declaratoropt = initializer-clause

2615. Missing __has_cpp_attribute(assume)

[Accepted at the November, 2022 meeting.]

Paper P1774R8 (accepted in July, 2022) adds a new attribute assume, but neglects to update table 22 in 15.2 [cpp.cond].

Proposed resolution (accepted by CWG 2022-08-26):

In 15.2 [cpp.cond], add a row to table tab:cpp.cond.ha as follows:

Attribute	Value
assume	202207L

2652. Overbroad definition of __STDCPP_BFLOAT16_T__

[Accepted at the November, 2022 meeting.]

The wording for the predefined macro __STDCPP_BFLOAT16_T__ added by P1467 can be interpreted more broadly than was intended.

Proposed resolution (approved by CWG 2022-11-08):

Change in 15.11 [cpp.predefined] paragraph 1 as follows:

__STDCPP_BFLOAT16_T__

Defined as the integer literal 1 if and only if the implementation supports an extended floating-point type with the properties of the typedef-name std::bfloat16_t as described in 6.8.3 [basic.extended.fp].

Issues with "CD1" Status

663. Valid Cyrillic identifier characters

[Voted into the WP at the June, 2008 meeting.]

The C99 and C++ Standards disagree about the validity of two Cyrillic characters for use in identifiers. C++ (_N2691_.E [extendid]) says that 040d is valid in an identifier but that 040e is not; C99 (Annex D) says exactly the opposite. In fact, both characters should be accepted in identifiers; see the Unicode chart.

Proposed resolution (February, 2008):

The reference in paragraph 2 should be changed to ISO/IEC TR 10176:2003 and the table should be changed to conform to the one in that document (beginning on page 34).

122. template-ids as unqualified-ids

[Moved to DR at 10/01 meeting.]

_N4567_.5.1.1 [expr.prim.general] paragraph 11 reads,

A template-id shall be used as an unqualified-id only as specified in 13.9.3 [temp.explicit] , 13.9 [temp.spec] , and 13.7.6 [temp.spec.partial] .

What uses of template-ids as unqualified-ids is this supposed to prevent? And is the list of referenced sections correct/complete? For instance, what about 13.10.2 [temp.arg.explicit], "Explicit template argument specification?" Does its absence from the list in _N4567_.5.1.1 [expr.prim.general] paragraph 11 mean that "f<int>()" is ill-formed?

This is even more confusing when you recall that unqualified-ids are contained in qualified-ids:

qualified-id: ::_opt nested-name-specifier template_opt unqualified-id

Is the wording intending to say "used as an unqualified-id that is not part of a qualified-id?" Or something else?

Proposed resolution (10/00):

Remove the referenced sentence altogether.

125. Ambiguity in friend declaration syntax

[Voted into WP at March 2004 meeting.]

The example below is ambiguous.

    struct A{
      struct B{};
    };

    A::B C();

    namespace B{
      A C();
    }

    struct Test {
      friend A::B ::C();
    };

The ambiguity arises since both the simple-type-specifier (9.2.9.3 [dcl.type.simple] paragra 1) and an init-declararator (9.3 [dcl.decl] paragraph 1) contain an optional :: and an optional nested-name-specifier (_N4567_.5.1.1 [expr.prim.general] paragraph 1) . Therefore, two different ways to analyse this code are possible:

simple-type-specifier = A::B
init-declarator = ::C()
simple-declaration = friend A::B ::C();

simple-type-specifier = A
init-declarator = ::B::C()
simple-declaration = friend A ::B::C();

Suggested Resolution: In the definition of nested-name-specifier, add a sentence saying that a :: token immediately following a nested-name-specifier is always considered as part of the nested-name-specifier. Under this interpretation, the example is ill-formed, and should be corrected as either

    friend A (::B::C)();   //or
    friend A::B (::C)();

An alternate suggestion — changing 9.2 [dcl.spec] to say that

The longest sequence of tokens that could possibly be a type name is taken as the decl-specifier-seq of a declaration.

— is undesirable because it would make the example well-formed rather than requiring the user to disambiguate the declaration explicitly.

Proposed resolution (04/01):

(See below for problem with this, from 10/01 meeting.)

In _N4567_.5.1.1 [expr.prim.general] paragraph 7,

1. Before the grammar for qualified-id, start a new paragraph 7a with the text

   A qualified-id is an id-expression that contains the scope resolution operator ::.

2. Following the grammar fragment, insert the following:

   The longest sequence of tokens that could form a qualified-id constitutes a single qualified-id. [Example:

       // classes C, D; functions F, G, namespace N; non-class type T
       friend C ::D::F();   // ill-formed, means friend (C::D::F)();
       friend C (::D::F)(); // well-formed
       friend N::T ::G();   // ill-formed, means friend (N::T::G)();
       friend N::T (::G)(); // well-formed
   

   —end example]

3. Start a new paragraph 7b following the example.

(This resolution depends on that of issue 215.)

Notes from 10/01 meeting:

It was pointed out that the proposed resolution does not deal with cases like X::Y where X is a type but not a class type. The working group reaffirmed its decision that the disambiguation should be syntactic only, i.e., it should depend only on whether or not the name is a type.

At the Seattle meeting, I suggested that a solution might be to change the class-or-namespace-name in the nested-name-specifier rule to just be "identifier"; there was some resistance to this idea. FWIW, I've tried this in g++. I had to revise the idea so that only the second and subsequent names were open to being any identifier, but that seems to work just fine.

So, instead of

nested-name-specifier:
class-or-namespace-name :: nested-name-specifier_opt
class-or-namespace-name :: template nested-name-specifier

it would be

nested-name-specifier:
type-or-namespace-name :: (per issue 215)
nested-name-specifier identifier ::
nested-name-specifier template template-id ::

Or some equivalent but right-associative formulation, if people feel that's important, but it seems irrelevant to me.

Clark Nelson :

Personally, I prefer the left-associative rule. I think it makes it easier to understand. I was thinking about this production a lot at the meeting, considering also some issues related to 301. My formulation was getting kind of ugly, but with a left-associative rule, it gets a lot nicer.

Your proposal isn't complete, however, as it doesn't allow template arguments without an explicit template keyword. You probably want to add an alternative for:

nested-name-specifier type-or-namespace-name ::

There is admittedly overlap between this alternative and

nested-name-specifier identifier ::

but I think they're both necessary.

Notes from the 4/02 meeting:

The changes look good. Clark Nelson will merge the two proposals to produce a single proposed resolution.

Proposed resolution (April 2003):

nested-name-specifier is currently defined in _N4567_.5.1.1 [expr.prim.general] paragraph 7 as:

nested-name-specifier:
class-or-namespace-name :: nested-name-specifier_opt
class-or-namespace-name :: template nested-name-specifier
class-or-namespace-name:
class-name
namespace-name

The proposed definition is instead:

nested-name-specifier:
type-name ::
namespace-name ::
nested-name-specifier identifier ::
nested-name-specifier template_opt template-id ::

Issue 215 is addressed by using type-name instead of class-name in the first alternative. Issue 125 (this issue) is addressed by using identifier instead of anything more specific in the third alternative. Using left association instead of right association helps eliminate the need for class-or-namespace-name (or type-or-namespace-name, as suggested for issue 215).

It should be noted that this formulation also rules out the possibility of A::template B::, i.e. using the template keyword without any template arguments. I think this is according to the purpose of the template keyword, and that the former rule allowed such a construct only because of the difficulty of formulation of a right-associative rule that would disallow it. But I wanted to be sure to point out this implication.

Notes from April 2003 meeting:

See also issue 96.

The proposed change resolves only part of issue 215.

466. cv-qualifiers on pseudo-destructor type

[Voted into WP at April, 2006 meeting.]

_N4778_.7.6.1.4 [expr.pseudo] paragraph 2 says both:

The type designated by the pseudo-destructor-name shall be the same as the object type.

The cv-unqualified versions of the object type and of the type designated by the pseudo-destructor-name shall be the same type.

See also issues 305 and 399.

Proposed resolution (October, 2005):

Change _N4778_.7.6.1.4 [expr.pseudo] paragraph 2 as follows:

The left-hand side of the dot operator shall be of scalar type. The left-hand side of the arrow operator shall be of pointer to scalar type. This scalar type is the object type. The type designated by the pseudo-destructor-name shall be the same as the object type. The cv-unqualified versions of the object type and of the type designated by the pseudo-destructor-name shall be the same type. Furthermore, the two type-names in a pseudo-destructor-name of the form

::_opt nested-name-specifier_opt type-name ::~ type-name

shall designate the same scalar type. The cv-unqualified versions of the object type and of the type designated by the pseudo-destructor-name shall be the same type.

141. Non-member function templates in member access expressions

[Voted into the WP at the June, 2008 meeting.]

_N4868_.6.5.6 [basic.lookup.classref] paragraph 1 says,

In a class member access expression (7.6.1.5 [expr.ref] ), if the . or -> token is immediately followed by an identifier followed by a <, the identifier must be looked up to determine whether the < is the beginning of a template argument list (13.3 [temp.names] ) or a less-than operator. The identifier is first looked up in the class of the object expression. If the identifier is not found, it is then looked up in the context of the entire postfix-expression and shall name a class or function template.

There do not seem to be any circumstances in which use of a non-member template function would be well-formed as the id-expression of a class member access expression.

Proposed Resolution (November, 2006):

Change _N4868_.6.5.6 [basic.lookup.classref] paragraph 1 as follows:

In a class member access expression (7.6.1.5 [expr.ref]), if the . or -> token is immediately followed by an identifier followed by a <, the identifier must be looked up to determine whether the < is the beginning of a template argument list (13.3 [temp.names]) or a less-than operator. The identifier is first looked up in the class of the object expression. If the identifier is not found, it is then looked up in the context of the entire postfix-expression and shall name a class or function template...

305. Name lookup in destructor call

[Voted into WP at the October, 2006 meeting.]

I believe this program is invalid:

    struct A {
    };

    struct C {
      struct A {};
      void f ();
    };

    void C::f () {
      ::A *a;
      a->~A ();
    }

The EDG front end does not issue an error about this program, though.

Am I reading the standardese incorrectly?

John Spicer: I think you are reading it correctly. I think I've been hoping that this would get changed. Unlike other dual lookup contexts, this is one in which the compiler already knows the right answer (the type must match that of the left hand of the -> operator). So I think that if either of the types found matches the one required, it should be sufficient. You can't say a->~::A(), which means you are forced to say a->::A::~A(), which disables the virtual mechanism. So you would have to do something like create a local typedef for the desired type.

See also issues 244, 399, and 466.

Proposed resolution (April, 2006):

1. Remove the indicated text from _N4868_.6.5.6 [basic.lookup.classref] paragraph 2:

   If the id-expression in a class member access (7.6.1.5 [expr.ref]) is an unqualified-id, and the type of the object expression is of a class type C (or of pointer to a class type C), the unqualified-id is looked up in the scope of class C...

2. Change _N4868_.6.5.6 [basic.lookup.classref] paragraph 3 as indicated:

   If the unqualified-id is ~type-name, the type-name is looked up in the context of the entire postfix-expression. and If the type T of the object expression is of a class type C (or of pointer to a class type C), the type-name is also looked up in the context of the entire postfix-expression and in the scope of class C. The type-name shall refer to a class-name. If type-name is found in both contexts, the name shall refer to the same class type. If the type of the object expression is of scalar type, the type-name is looked up in the scope of the complete postfix-expression. At least one of the lookups shall find a name that refers to (possibly cv-qualified) T. [Example:

   
       struct A { };
   
       struct B {
         struct A { };
         void f(::A* a);
       };
   
       void B::f(::A* a) {
         a->~A();  // OK, lookup in *a finds the injected-class-name
       }
   

   —end example]

[Note: this change also resolves issue 414.]

381. Incorrect example of base class member lookup

[Voted into WP at October 2004 meeting.]

The example in _N4868_.6.5.6 [basic.lookup.classref] paragraph 4 is wrong (see 11.8.3 [class.access.base] paragraph 5; the cast to the naming class can't be done) and needs to be corrected. This was noted when the final version of the algorithm for issue 39 was checked against it.

Proposed Resolution (October 2003):

Remove the entire note at the end of _N4868_.6.5.6 [basic.lookup.classref] paragraph 4, including the entire example.

414. Multiple types found on destructor lookup

[Voted into WP at the October, 2006 meeting.]

By _N4868_.6.5.6 [basic.lookup.classref] paragraph 3, the following is ill-formed because the two lookups of the destructor name (in the scope of the class of the object and in the surrounding context) find different Xs:

  struct X {};
  int main() {
    X x;
    struct X {};
    x.~X();  // Error?
  }

This is silly, because the compiler knows what the type has to be, and one of the things found matches that. The lookup should require only that one of the lookups finds the required class type.

Proposed resolution (April, 2005):

This issue is resolved by the resolution of issue 305.

452. Wording nit on description of this

[Voted into WP at July, 2007 meeting.]

_N4868_.11.4.3.2 [class.this] paragraph 1, which specifies the meaning of the keyword 'this', seems to limit its usage to the *body* of non-static member functions. However 'this' is also usable in ctor-initializers which, according to the grammar in 9.5 [dcl.fct.def] par. 1, are not part of the body.

Proposed resolution: Changing the first part of _N4868_.11.4.3.2 [class.this] par. 1 to:

In the body of a nonstatic (9.3) member function or in a ctor-initializer (12.6.2), the keyword this is a non-lvalue expression whose value is the address of the object for which the function is called.

NOTE: I'm talking of constructors as functions that are "called"; there have been discussions on c.l.c++.m as to whether constructors are "functions" and to whether this terminology is correct or not; I think it is both intuitive and in agreement with the standard wording.

Steve Adamczyk: See also issue 397, which is defining a new syntax term for the body of a function including the ctor-initializers.

Notes from the March 2004 meeting:

This will be resolved when issue 397 is resolved.

Proposed resolution (October, 2005):

1. Change 9.5 [dcl.fct.def] paragraph 1 as indicated:

Function definitions have the form

function-definition:
decl-specifier-seq_opt declarator ctor-initializer_opt function-body
decl-specifier-seq_opt declarator function-try-block
function-body:
ctor-initializer_opt compound-statement
function-try-block

An informal reference to the body of a function should be interpreted as a reference to the nonterminal function-body.

2. Change the definition of function-try-block in Clause 14 [except] paragraph 1:

function-try-block:
try ctor-initializer_opt function-body compound-statement handler-seq

3. Change 6.4.7 [basic.scope.class] paragraph 1, point 1, as indicated:

The potential scope of a name declared in a class consists not only of the declarative region following the name's point of declaration, but also of all function bodies, bodies and default arguments, and constructor ctor-initializers in that class (including such things in nested classes).

4. Change 6.4.7 [basic.scope.class] paragraph 1, point 5, as indicated:

The potential scope of a declaration that extends to or past the end of a class definition also extends to the regions defined by its member definitions, even if the members are defined lexically outside the class (this includes static data member definitions, nested class definitions, member function definitions (including the member function body and, for constructor functions (11.4.5 [class.ctor]), the ctor-initializer (11.9.3 [class.base.init])) and any portion of the declarator part of such definitions which follows the identifier, including a parameter-declaration-clause and any default arguments (9.3.4.7 [dcl.fct.default]). [Example:...

5. Change footnote 32 in 6.5.3 [basic.lookup.unqual] paragraph 8 as indicated:

That is, an unqualified name that occurs, for instance, in a type or default argument expression in the parameter-declaration-clause, parameter-declaration-clause or in the function body, or in an expression of a mem-initializer in a constructor definition.

6. Change _N4567_.5.1.1 [expr.prim.general] paragraph 3 as indicated:

...The keyword this shall be used only inside a non-static class member function body (11.4.2 [class.mfct]) or in a constructor mem-initializer (11.9.3 [class.base.init])...

7. Change 11.4 [class.mem] paragraph 2 as indicated:

...Within the class member-specification, the class is regarded as complete within function bodies, default arguments, and exception-specifications, and constructor ctor-initializers (including such things in nested classes)...

8. Change 11.4 [class.mem] paragraph 9 as indicated:

Each occurrence in an expression of the name of a non-static data member or non-static member function of a class shall be expressed as a class member access (7.6.1.5 [expr.ref]), except when it appears in the formation of a pointer to member (7.6.2.2 [expr.unary.op]), or or when it appears in the body of a non-static member function of its class or of a class derived from its class (11.4.3 [class.mfct.non.static]), or when it appears in a mem-initializer for a constructor for its class or for a class derived from its class (11.9.3 [class.base.init]).

9. Change the note in 11.4.2 [class.mfct] paragraph 5 as indicated:

[Note: a name used in a member function definition (that is, in the parameter-declaration-clause including the default arguments (9.3.4.7 [dcl.fct.default]), or or in the member function body, or, for a constructor function (11.4.5 [class.ctor]), in a mem-initializer expression (11.9.3 [class.base.init])) is looked up as described in 6.5 [basic.lookup]. —end note]

10. Change 11.4.3 [class.mfct.non.static] paragraph 1 as indicated:

...A non-static member function may also be called directly using the function call syntax (7.6.1.3 [expr.call], 12.2.2.2 [over.match.call]) from within the body of a member function of its class or of a class derived from its class.

• from within the body of a member function of its class or of a class derived from its class, or
• from a mem-initializer (11.9.3 [class.base.init]) for a constructor for its class or for a class derived from its class.

11. Change 11.4.3 [class.mfct.non.static] paragraph 3 as indicated:

When an id-expression (_N4567_.5.1.1 [expr.prim.general]) that is not part of a class member access syntax (7.6.1.5 [expr.ref]) and not used to form a pointer to member (7.6.2.2 [expr.unary.op]) is used in the body of a non-static member function of class X or used in the mem-initializer for a constructor of class X, if name lookup (6.5.3 [basic.lookup.unqual]) resolves the name in the id-expression to a non-static non-type member of class X or of a base class of X, the id-expression is transformed into a class member access expression (7.6.1.5 [expr.ref]) using (*this) (_N4868_.11.4.3.2 [class.this]) as the postfix-expression to the left of the . operator...

12. Change 11.4.5 [class.ctor] paragraph 7 as indicated:

...The implicitly-defined default constructor performs the set of initializations of the class that would be performed by a user-written default constructor for that class with an empty mem-initializer-list no ctor-initializer (11.9.3 [class.base.init]) and an empty function body compound-statement...

13. Change 11.9.3 [class.base.init] paragraph 4 as indicated:

...After the call to a constructor for class X has completed, if a member of X is neither specified in the constructor's mem-initializers, nor default-initialized, nor value-initialized, nor given a value during execution of the compound-statement of the body of the constructor, the member has indeterminate value.

14. Change the last bullet of 11.9.3 [class.base.init] paragraph 5 as indicated:

• Finally, the body compound-statement of the constructor body is executed.

15. Change Clause 14 [except] paragraph 4 as indicated:

A function-try-block associates a handler-seq with the ctor-initializer, if present, and the function-body compound-statement. An exception thrown during the execution of the initializer expressions in the ctor-initializer or during the execution of the function-body compound-statement transfers control to a handler in a function-try-block in the same way as an exception thrown during the execution of a try-block transfers control to other handlers. [Example:

    int f(int);
    class C {
        int i;
        double d;
    public:
        C(int, double);
    };

    C::C(int ii, double id)
    try
        : i(f(ii)), d(id)
    {
        // constructor function body statements
    }
    catch (...)
    {
        // handles exceptions thrown from the ctor-initializer
        // and from the constructor function body statements
    }

—end example]

16. Change 14.3 [except.ctor] paragraph 2 as indicated:

When an exception is thrown, control is transferred to the nearest handler with a matching type (14.4 [except.handle]); “nearest” means the handler for which the compound-statement, compound-statement or ctor-initializer, or function-body following the try keyword was most recently entered by the thread of control and not yet exited.

387. Errors in example in 14.6.5

[Voted into WP at March 2004 meeting.]

The example in _N4868_.13.8.6 [temp.inject] paragraph 2 is incorrect:

  template<typename T> class number {
      number(int);
      //...
      friend number gcd(number& x, number& y) { /* ... */ }
      //...
  };

  void g()
  {
      number<double> a(3), b(4);
      //...
      a = gcd(a,b);   // finds gcd because number<double> is an
                      // associated class, making gcd visible
                      // in its namespace (global scope)
      b = gcd(3,4);   // ill-formed; gcd is not visible
  }

Regardless of the last statement ("b = gcd(3,4);"), the above code is ill-formed:

a) number's constructor is private;

b) the definition of (non-void) friend 'gcd' function does not contain a return statement.

Proposed resolution (April 2003):

Replace the example in _N4868_.13.8.6 [temp.inject] paragraph 2

  template<typename T> class number {
          number(int);
          //...
          friend number gcd(number& x, number& y) { /* ... */ }
          //...
  };

  void g()
  {
          number<double> a(3), b(4);
          //...
          a = gcd(a,b);           //  finds  gcd  because  number<double>  is an
                                  //  associated class, making  gcd  visible
                                  //  in its namespace (global scope)
          b = gcd(3,4);           //  ill-formed;  gcd  is not visible
  }

  template<typename T> class number {
     public:
          number(int);
          //...
          friend number gcd(number x, number y) { return 0; }
     private:
          //...
  };

  void g()
  {
          number<double> a(3), b(4);
          //...
          a = gcd(a,b);           //  finds  gcd  because  number<double>  is an
                                  //  associated class, making  gcd  visible
                                  //  in its namespace (global scope)
          b = gcd(3,4);           //  ill-formed;  gcd  is not visible
  }

Drafting note: Added "return" to the friend function, removed references in gcd arguments, added access specifiers.

357. Definition of signature should include name

[Voted into WP at April, 2007 meeting.]

Section Clause 3 [intro.defs], definition of "signature" omits the function name as part of the signature. Since the name participates in overload resolution, shouldn't it be included in the definition? I didn't find a definition of signature in the ARM, but I might have missed it.

Fergus Henderson: I think so. In particular, _N4140_.17.6.4.3.2 [global.names] reserves certain "function signatures" for use by the implementation, which would be wrong unless the signature includes the name.

-2- Each global function signature declared with external linkage in a header is reserved to the implementation to designate that function signature with external linkage.

-5- Each function signature from the Standard C library declared with external linkage is reserved to the implementation for use as a function signature with both extern "C" and extern "C++" linkage, or as a name of namespace scope in the global namespace.

Other uses of the term "function signature" in the description of the standard library also seem to assume that it includes the name.

James Widman:

Names don't participate in overload resolution; name lookup is separate from overload resolution. However, the word “signature” is not used in Clause 12 [over]. It is used in linkage and declaration matching (e.g., 13.7.7.2 [temp.over.link]). This suggests that the name and scope of the function should be part of its signature.

Proposed resolution (October, 2006):

1. Replace Clause 3 [intro.defs] “signature” with the following:

the name and the parameter-type-list (9.3.4.6 [dcl.fct]) of a function, as well as the class or namespace of which it is a member. If a function or function template is a class member its signature additionally includes the cv-qualifiers (if any) on the function or function template itself. The signature of a function template additionally includes its return type and its template parameter list. The signature of a function template specialization includes the signature of the template of which it is a specialization and its template arguments (whether explicitly specified or deduced). [Note: Signatures are used as a basis for name-mangling and linking. —end note]

2. Delete paragraph 3 and replace the first sentence of 13.7.7.2 [temp.over.link] as follows:

The signature of a function template specialization consists of the signature of the function template and of the actual template arguments (whether explicitly specified or deduced).

The signature of a function template consists of its function signature, its return type and its template parameter list is defined in Clause 3 [intro.defs]. The names of the template parameters are significant...

(See also issue 537.)

537. Definition of “signature”

[Voted into WP at April, 2007 meeting.]

The standard defines “signature” in two places: Clause 3 [intro.defs] and 13.7.7.2 [temp.over.link] paragraphs 3-4. The former seems to be meant as a formal definition (I think it's the only place covering the nontemplate case), yet it lacks some bits mentioned in the latter (specifically, the notion of a “signature of a function template,” which is part of every signature of the associated function template specializations).

Also, I think the Clause 3 [intro.defs] words “the information about a function that participates in overload resolution” isn't quite right either. Perhaps, “the information about a function that distinguishes it in a set of overloaded functions?”

Eric Gufford:

In Clause 3 [intro.defs] the definition states that “Function signatures do not include return type, because that does not participate in overload resolution,” while 13.7.7.2 [temp.over.link] paragraph 4 states “The signature of a function template consists of its function signature, its return type and its template parameter list.” This seems inconsistent and potentially confusing. It also seems to imply that two identical function templates with different return types are distinct signatures, which is in direct violation of 12.2 [over.match]. 13.7.7.2 [temp.over.link] paragraph 4 should be amended to include verbiage relating to overload resolution.

Either return types are included in function signatures, or they're not, across the board. IMHO, they should be included as they are an integral part of the function declaration/definition irrespective of overloads. Then verbiage should be added about overload resolution to distinguish between signatures and overload rules. This would help clarify things, as it is commonly understood that overload resolution is based on function signature.

In short, the term “function signature” should be made consistent, and removed from its (implicit, explicit or otherwise) linkage to overload resolution as it is commonly understood.

James Widman:

The problem is that (a) if you say the return type is part of the signature of a non-template function, then you have overloading but not overload resolution on return types (i.e., what we have now with function templates). I don't think anyone wants to make the language uglier in that way. And (b) if you say that the return type is not part of the signature of a function template, you will break code. Given those alternatives, it's probably best to maintain the status quo (which the implementors appear to have rendered faithfully).

Proposed resolution (September, 2006):

This issue is resolved by the resolution of issue 357.

362. Order of initialization in instantiation units

[Voted into WP at March 2004 meeting.]

Should this program do what its author obviously expects? As far as I can tell, the standard says that the point of instantiation for Fib<n-1>::Value is the same as the point of instantiation as the enclosing specialization, i.e., Fib<n>::Value. What in the standard actually says that these things get initialized in the right order?

  template<int n>
  struct Fib { static int Value; };

  template <>
  int Fib<0>::Value = 0;

  template <>
  int Fib<1>::Value = 1;

  template<int n>
  int Fib<n>::Value = Fib<n-1>::Value + Fib<n-2>::Value;

  int f ()
  {
    return Fib<40>::Value;
  }

John Spicer: My opinion is that the standard does not specify the behavior of this program. I thought there was a core issue related to this, but I could not find it. The issue that I recall proposed tightening up the static initialization rules to make more cases well defined.

Your comment about point of instantiation is correct, but I don't think that really matters. What matters is the order of execution of the initialization code at execution time. Instantiations don't really live in "translation units" according to the standard. They live in "instantiation units", and the handling of instantiation units in initialization is unspecified (which should probably be another core issue). See 5.2 [lex.phases] paragraph 8.

Notes from October 2002 meeting:

We discussed this and agreed that we really do mean the the order is unspecified. John Spicer will propose wording on handling of instantiation units in initialization.

Proposed resolution (April 2003):

TC1 contains the following text in 6.9.3.2 [basic.start.static] paragraph 1:

Objects with static storage duration defined in namespace scope in the same translation unit and dynamically initialized shall be initialized in the order in which their definition appears in the translation unit.

This was revised by issue 270 to read:

Dynamic initialization of an object is either ordered or unordered. Explicit specializations and definitions of class template static data members have ordered initialization. Other class template static data member instances have unordered initialization. Other objects defined in namespace scope have ordered initialization. Objects defined within a single translation unit and with ordered initialization shall be initialized in the order of their definitions in the translation unit. The order of initialization is unspecified for objects with unordered initialization and for objects defined in different translation units.

This addresses this issue but while reviewing this issue some additional changes were suggested for the above wording:

Dynamic initialization of an object is either ordered or unordered. Definitions of explicitly specialized Explicit specializations and definitions of class template static data members have ordered initialization. Other class template static data members (i.e., implicitly or explicitly instantiated specializations) instances have unordered initialization. Other objects defined in namespace scope have ordered initialization. Objects defined within a single translation unit and with ordered initialization shall be initialized in the order of their definitions in the translation unit. The order of initialization is unspecified for objects with unordered initialization and for objects defined in different translation units.

558. Excluded characters in universal character names

[Moved to DR at October 2007 meeting.]

C99 and C++ differ in their approach to universal character names (UCNs).

Issue 248 already covers the differences in UCNs allowed for identifiers, but a more fundamental issue is that of UCNs that correspond to codes reserved by ISO 10676 for surrogate pair forms.

Specifically, C99 does not allow UCNs whose short names are in the range 0xD800 to 0xDFFF. I think C++ should have the same constraint. If someone really wants to place such a code in a character or string literal, they should use a hexadecimal escape sequence instead, for example:

    wchar_t  w1 = L'\xD900'; // Okay.
    wchar_t  w2 = L'\uD900'; // Error, not a valid character.

(Compare 6.4.3 paragraph 2 in ISO/IEC 9899/1999 with 5.3 [lex.charset] paragraph 2 in the C++ standard.)

Proposed resolution (October, 2007):

This issue is resolved by the adoption of paper J16/07-0030 = WG21 N2170.

505. Conditionally-supported behavior for unknown character escapes

[Voted into WP at the October, 2006 meeting.]

The current wording of 5.13.3 [lex.ccon] paragraph 3 states,

If the character following a backslash is not one of those specified, the behavior is undefined.

Paper J16/04-0167=WG21 N1727 suggests that such character escapes be ill-formed. In discussions at the Lillehammer meeting, however, the CWG felt that the newly-approved category of conditionally-supported behavior would be more appropriate.

Proposed resolution (April, 2006):

Change the next-to-last sentence of 5.13.3 [lex.ccon] paragraph 3 from:

If the character following a backslash is not one of those specified, the behavior is undefined.

to:

Escape sequences in which the character following the backslash is not listed in Table 6 are conditionally-supported, with implementation-defined semantics.

309. Linkage of entities whose names are not simply identifiers, in introduction

[Voted into the WP at the June, 2008 meeting.]

6.1 [basic.pre] paragraph 10, while not incorrect, does not allow for linkage of operators and conversion functions. It says:

An identifier used in more than one translation unit can potentially refer to the same entity in these translation units depending on the linkage (6.6 [basic.link]) of the identifier specified in each translation unit.

Proposed Resolution (November, 2006):

This issue is resolved by the proposed resolution of issue 485.

485. What is a “name”?

[Voted into the WP at the June, 2008 meeting.]

6.1 [basic.pre] paragraph 4 says:

A name is a use of an identifier (5.10 [lex.name]) that denotes an entity or label (8.7.6 [stmt.goto], 8.2 [stmt.label]).

Just three paragraphs later, it says

Two names are the same if

• they are identifiers composed of the same character sequence; or
• they are the names of overloaded operator functions formed with the same operator; or
• they are the names of user-defined conversion functions formed with the same type.

The last two bullets contradict the definition of name in paragraph 4 because they are not identifiers.

This definition affects other parts of the Standard, as well. For example, in 6.5.4 [basic.lookup.argdep] paragraph 1,

When an unqualified name is used as the postfix-expression in a function call (7.6.1.3 [expr.call]), other namespaces not considered during the usual unqualified lookup (6.5.3 [basic.lookup.unqual]) may be searched, and in those namespaces, namespace-scope friend function declarations (11.8.4 [class.friend]) not otherwise visible may be found.

With the current definition of name, argument-dependent lookup apparently does not apply to function-notation calls to overloaded operators.

Another related question is whether a template-id is a name or not and thus would trigger an argument-dependent lookup. Personally, I have always viewed a template-id as a name, just like operator+.

Proposed Resolution (November, 2006):

1. Change 6.1 [basic.pre] paragraphs 3-8 as follows:

   3. An entity is a value, object, subobject, base class subobject, array element, variable, reference, function, instance of a function, enumerator, type, class member, template, template specialization, namespace, or parameter pack.

   4. A name is a use of an identifier identifier (5.10 [lex.name]), operator-function-id (12.4 [over.oper]), conversion-function-id (11.4.8.3 [class.conv.fct]), or template-id (13.3 [temp.names]) that denotes an entity or label (8.7.6 [stmt.goto], 8.2 [stmt.label]). A variable is introduced by the declaration of an object. The variable's name denotes the object.

   5. Every name that denotes an entity is introduced by a declaration. Every name that denotes a label is introduced either by a goto statement (8.7.6 [stmt.goto]) or a labeled-statement (8.2 [stmt.label]).

   1. A variable is introduced by the declaration of an object. The variable's name denotes the object.

   6. Some names denote types, classes, enumerations, or templates. In general, it is necessary to determine whether or not a name denotes one of these entities before parsing the program that contains it. The process that determines this is called name lookup (6.5 [basic.lookup]).

   7. Two names are the same if

      • they are identifiers identifiers composed of the same character sequence; or

      • they are the names of overloaded operator functions operator-function-ids formed with the same operator; or

      • they are the names of user-defined conversion functions conversion-function-ids formed with the same type., or

      • they are template-ids that refer to the same class or function (13.6 [temp.type]).

   8. An identifier A name used in more than one translation unit can potentially refer to the same entity in these translation units depending on the linkage (6.6 [basic.link]) of the identifier name specified in each translation unit.

2. Change 6.4.7 [basic.scope.class] paragraph 1 item 5 as follows:

   The potential scope of a declaration that extends to or past the end of a class definition also extends to the regions defined by its member definitions, even if the members are defined lexically outside the class (this includes static data member definitions, nested class definitions, member function definitions (including the member function body and any portion of the declarator part of such definitions which follows the identifier declarator-id, including a parameter-declaration-clause and any default arguments (9.3.4.7 [dcl.fct.default]).

   [Drafting note: This last change is not really mandated by the issue, but it's another case of “identifier” confusion.]

(This proposed resolution also resolves issue 309.)

261. When is a deallocation function "used?"

[Moved to DR at October 2002 meeting.]

6.3 [basic.def.odr] paragraph 2 says that a deallocation function is "used" by a new-expression or delete-expression appearing in a potentially-evaluated expression. 6.3 [basic.def.odr] paragraph 3 requires only that "used" functions be defined.

This wording runs afoul of the typical implementation technique for polymorphic delete-expressions in which the deallocation function is invoked from the virtual destructor of the most-derived class. The problem is that the destructor must be defined, because it's virtual, and if it contains an implicit reference to the deallocation function, the deallocation function must also be defined, even if there are no relevant new-expressions or delete-expressions in the program.

For example:

        struct B { virtual ~B() { } };

        struct D: B {
            void operator delete(void*);
            ~D() { }
        };

Is it required that D::operator delete(void*) be defined, even if no B or D objects are ever created or deleted?

Suggested resolution: Add the words "or if it is found by the lookup at the point of definition of a virtual destructor (11.4.7 [class.dtor])" to the specification in 6.3 [basic.def.odr] paragraph 2.

Notes from 04/01 meeting:

The consensus was in favor of requiring that any declared non-placement operator delete member function be defined if the destructor for the class is defined (whether virtual or not), and similarly for a non-placement operator new if a constructor is defined.

Proposed resolution (10/01):

In 6.3 [basic.def.odr] paragraph 2, add the indicated text:

An allocation or deallocation function for a class is used by a new expression appearing in a potentially-evaluated expression as specified in 7.6.2.8 [expr.new] and 11.4.11 [class.free]. A deallocation function for a class is used by a delete expression appearing in a potentially-evaluated expression as specified in 7.6.2.9 [expr.delete] and 11.4.11 [class.free]. A non-placement allocation or deallocation function for a class is used by the definition of a constructor of that class. A non-placement deallocation function for a class is 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 [class.dtor]). [Footnote: An implementation is not required to call allocation and deallocation functions from constructors or destructors; however, this is a permissible implementation technique.]

289. Incomplete list of contexts requiring a complete type

[Moved to DR at October 2002 meeting.]

6.3 [basic.def.odr] paragraph 4 has a note listing the contexts that require a class type to be complete. It does not list use as a base class as being one of those contexts.

Proposed resolution (10/01):

In 6.3 [basic.def.odr] paragraph 4 add a new bullet at the end of the note as the next-to-last bullet:

• a class with a base class of type T is defined (11.7 [class.derived]), or

433. Do elaborated type specifiers in templates inject into enclosing namespace scope?

[Voted into WP at March 2004 meeting.]

Consider the following translation unit:

  template<class T> struct S {
    void f(union U*);  // (1)
  };
  template<class T> void S<T>::f(union U*) {}  // (2)
  U *p;  // (3)

Does (1) introduce U as a visible name in the surrounding namespace scope?

If not, then (2) could presumably be an error since the "union U" in that definition does not find the same type as the declaration (1).

If yes, then (3) is OK too. However, we have gone through much trouble to allow template implementations that do not pre-parse the template definitions, but requiring (1) to be visible would change that.

A slightly different case is the following:

  template<typename> void f() { union U *p; }
  U *q;  // Should this be valid?

Notes from October 2003 meeting:

There was consensus that example 1 should be allowed. (Compilers already parse declarations in templates; even MSVC++ 6.0 accepts this case.) The vote was 7-2.

Example 2, on the other hand, is wrong; the union name goes into a block scope anyway.

Proposed resolution:

In 6.4.2 [basic.scope.pdecl] change the second bullet of paragraph 5 as follows:

for an elaborated-type-specifier of the form

   class-key identifier

if the elaborated-type-specifier is used in the decl-specifier-seq or parameter-declaration-clause of a function defined in namespace scope, the identifier is declared as a class-name in the namespace that contains the declaration; otherwise, except as a friend declaration, the identifier is declared in the smallest non-class, non-function-prototype scope that contains the declaration. [Note: These rules also apply within templates.] [Note: ...]

432. Is injected class name visible in base class specifier list?

[Voted into WP at March 2004 meeting.]

Consider the following example (inspired by a question from comp.lang.c++.moderated):

  template<typename> struct B {};
  template<typename T> struct D: B<D> {};

Most (all?) compilers reject this code because D is handled as a template name rather than as the injected class name.

Clause 11 [class]/2 says that the injected class name is "inserted into the scope of the class."

6.4.7 [basic.scope.class]/1 seems to be the text intended to describe what "scope of a class" means, but it assumes that every name in that scope was introduced using a "declarator". For an implicit declaration such as the injected-class name it is not clear what that means.

So my questions:

1. Should the injected class name be available in the base class specifiers?

   John Spicer: I do not believe the injected class name should be available in the base specifier. I think the semantics of injected class names should be as if a magic declaration were inserted after the opening "{" of the class definition. The injected class name is a member of the class and members don't exist at the point where the base specifiers are scanned.

2. Do you agree the wording should be clarified whatever the answer to the first question?

   John Spicer: I believe the 6.4.7 [basic.scope.class] wording should be updated to reflect the fact that not all names come from declarators.

Notes from October 2003 meeting:

We agree with John Spicer's suggested answers above.

Proposed Resolution (October 2003):

The answer to question 1 above is No and no change is required.

For question 1, change 6.4.7 [basic.scope.class] paragraph 1 rule 1 to:

1) The potential scope of a name declared in a class consists not only of the declarative region following the name's point of declaration declarator, but also of all function bodies, default arguments, and constructor ctor-initializers in that class (including such things in nested classes). The point of declaration of an injected-class-name (Clause 11 [class]) is immediately following the opening brace of the class definition.

(Note that this change overlaps a change in issue 417.)

Also change 6.4.2 [basic.scope.pdecl] by adding a new paragraph 8 for the injected-class-name case:

The point of declaration for an injected-class-name (Clause 11 [class]) is immediately following the opening brace of the class definition.

Alternatively this paragraph could be added after paragraph 5 and before the two note paragraphs (i.e. it would become paragraph 5a).

39. Conflicting ambiguity rules

[Voted into WP at April 2005 meeting.]

The ambiguity text in 6.5.2 [class.member.lookup] may not say what we intended. It makes the following example ill-formed:

    struct A {
        int x(int);
    };
    struct B: A {
        using A::x;
        float x(float);
    };

    int f(B* b) {
        b->x(3);  // ambiguous
    }

... Each of these declarations that was introduced by a using-declaration is considered to be from each sub-object of C that is of the type containing the declaration designated by the using-declaration. If the resulting set of declarations are not all from sub-objects of the same type, or the set has a nonstatic member and includes members from distinct sub-objects, there is an ambiguity and the program is ill-formed.

Proposed Resolution (10/00):

1. Replace the two cited sentences from 6.5.2 [class.member.lookup] paragraph 2 with the following:

   The resulting set of declarations shall all be from sub-objects of the same type, or there shall be a set of declarations from sub-objects of a single type that contains using-declarations for the declarations found in all other sub-object types. Furthermore, for nonstatic members, the resulting set of declarations shall all be from a single sub-object, or there shall be a set of declarations from a single sub-object that contains using-declarations for the declarations found in all other sub-objects. Otherwise, there is an ambiguity and the program is ill-formed.

2. Replace the examples in 6.5.2 [class.member.lookup] paragraph 3 with the following:

       struct A {
           int x(int);
           static int y(int);
       };
       struct V {
           int z(int);
       };
       struct B: A, virtual V {
           using A::x;
           float x(float);
           using A::y;
           static float y(float);
           using V::z;
           float z(float);
       };
       struct C: B, A, virtual V {
       };
   
       void f(C* c) {
           c->x(3);    // ambiguous -- more than one sub-object A
           c->y(3);    // not ambiguous
           c->z(3);    // not ambiguous
       }
   

Notes from 04/01 meeting:

The following example should be accepted but is rejected by the wording above:

    struct A { static void f(); };

    struct B1: virtual A {
        using A::f;
    };

    struct B2: virtual A {
        using A::f;
    };

    struct C: B1, B2 { };

    void g() {
        C::f();        // OK, calls A::f()
    }

Notes from 10/01 meeting (Jason Merrill):

The example in the issues list:

    struct A {
        int x(int);
    };
    struct B: A {
        using A::x;
        float x(float);
    };

    int f(B* b) {
        b->x(3);  // ambiguous
    }

... Each of these declarations that was introduced by a using-declaration is considered to be from each sub-object of C that is of the type containing the declaration designated by the using-declaration. If the resulting set of declarations are not all from sub-objects of the same type, or the set has a nonstatic member and includes members from distinct sub-objects, there is an ambiguity and the program is ill-formed.

The first proposed solution:

The resulting set of declarations shall all be from sub-objects of the same type, or there shall be a set of declarations from sub-objects of a single type that contains using-declarations for the declarations found in all other sub-object types. Furthermore, for nonstatic members, the resulting set of declarations shall all be from a single sub-object, or there shall be a set of declarations from a single sub-object that contains using-declarations for the declarations found in all other sub-objects. Otherwise, there is an ambiguity and the program is ill-formed.

    struct A { static void f(); };

    struct B1: virtual A {
        using A::f;
    };

    struct B2: virtual A {
        using A::f;
    };

    struct C: B1, B2 { };

    void g() {
        C::f();        // OK, calls A::f()
    }

The solution is to separate the notions of lookup and definition context. I have taken an algorithmic approach to describing the strategy.

Incidentally, the earlier proposal allows one base to have a superset of the declarations in another base; that was an extension, and my proposal does not do that. One algorithmic benefit of this limitation is to simplify the case of a virtual base being hidden along one arm and not another ("domination"); if we allowed supersets, we would need to remember which subobjects had which declarations, while under the following resolution we need only keep two lists, of subobjects and declarations.

Proposed resolution (October 2002):

Replace 6.5.2 [class.member.lookup] paragraph 2 with:

The following steps define the result of name lookup for a member name f in a class scope C.

The lookup set for f in C, called S(f,C), consists of two component sets: the declaration set, a set of members named f; and the subobject set, a set of subobjects where declarations of these members (possibly including using-declarations) were found. In the declaration set, using-declarations are replaced by the members they designate, and type declarations (including injected-class-names) are replaced by the types they designate. S(f,C) is calculated as follows.

If C contains a declaration of the name f, the declaration set contains every declaration of f in C (excluding bases), the subobject set contains C itself, and calculation is complete.

Otherwise, S(f,C) is initially empty. If C has base classes, calculate the lookup set for f in each direct base class subjobject B_i, and merge each such lookup set S(f,B_i) in turn into S(f,C).

The following steps define the result of merging lookup set S(f,B_i) into the intermediate S(f,C):

• If each of the subobject members of S(f,B_i) is a base class subobject of at least one of the subobject members of S(f,C), S(f,C) is unchanged and the merge is complete. Conversely, if each of the subobject members of S(f,C) is a base class subobject of at least one of the subobject members of S(f,B_i), the new S(f,C) is a copy of S(f,B_i).
• Otherwise, if the declaration sets of S(f,B_i) and S(f,C) differ, the merge is ambiguous: the new S(f,C) is a lookup set with an invalid declaration set and the union of the subobject sets. In subsequent merges, an invalid declaration set is considered different from any other.
• Otherwise, consider each declaration d in the set, where d is a member of class A. If d is a nonstatic member, compare the A base class subobjects of the subobject members of S(f,B_i) and S(f,C). If they do not match, the merge is ambiguous, as in the previous step. [Note: It is not necessary to remember which A subobject each member comes from, since using-declarations don't disambiguate. ]
• Otherwise, the new S(f,C) is a lookup set with the shared set of declarations and the union of the subobject sets.

The result of name lookup for f in C is the declaration set of S(f,C). If it is an invalid set, the program is ill-formed.

[Example:

    struct A { int x; };                    // S(x,A) = {{ A::x }, { A }}
    struct B { float x; };                  // S(x,B) = {{ B::x }, { B }}
    struct C: public A, public B { };       // S(x,C) = { invalid, { A in C, B in C }}
    struct D: public virtual C { };         // S(x,D) = S(x,C)
    struct E: public virtual C { char x; }; // S(x,E) = {{ E::x }, { E }}
    struct F: public D, public E { };       // S(x,F) = S(x,E)

    int main() {
      F f;
      f.x = 0;   // OK, lookup finds { E::x }
    }

S(x,F) is unambiguous because the A and B base subobjects of D are also base subobjects of E, so S(x,D) is discarded in the first merge step. --end example]

Turn 6.5.2 [class.member.lookup] paragraphs 5 and 6 into notes.

Notes from October 2003 meeting:

Mike Miller raised some new issues in N1543, and we adjusted the proposed resolution as indicated in that paper.

Further information from Mike Miller (January 2004):

Unfortunately, I've become aware of a minor glitch in the proposed resolution for issue 39 in N1543, so I'd like to suggest a change that we can discuss in Sydney.

A brief review and background of the problem: the major change we agreed on in Kona was to remove detection of multiple-subobject ambiguity from class lookup (6.5.2 [class.member.lookup]) and instead handle it as part of the class member access expression. It was pointed out in Kona that 11.8.3 [class.access.base]/5 has this effect:

If a class member access operator, including an implicit "this->," is used to access a nonstatic data member or nonstatic member function, the reference is ill-formed if the left operand (considered as a pointer in the "." operator case) cannot be implicitly converted to a pointer to the naming class of the right operand.

After the meeting, however, I realized that this requirement is not sufficient to handle all the cases. Consider, for instance,

    struct B {
        int i;
    };

    struct I1: B { };
    struct I2: B { };

    struct D: I1, I2 {
        void f() {
            i = 0;    // not ill-formed per 11.2p5
        }
    };

Here, both the object expression ("this") and the naming class are "D", so the reference to "i" satisfies the requirement in 11.8.3 [class.access.base]/5, even though it involves a multiple-subobject ambiguity.

In order to address this problem, I proposed in N1543 to add a paragraph following 7.6.1.5 [expr.ref]/4:

If E2 is a non-static data member or a non-static member function, the program is ill-formed if the class of E1 cannot be unambiguously converted (10.2) to the class of which E2 is directly a member.

That's not quite right. It does diagnose the case above as written; however, it breaks the case where qualification is used to circumvent the ambiguity:

    struct D2: I1, I2 {
        void f() {
            I2::i = 0;    // ill-formed per proposal
        }
    };

In my proposed wording, the class of "this" can't be converted to "B" (the qualifier is ignored), so the access is ill-formed. Oops.

I think the following is a correct formulation, so the proposed resolution we discuss in Sydney should contain the following paragraph instead of the one in N1543:

If E2 is a nonstatic data member or a non-static member function, the program is ill-formed if the naming class (11.2) of E2 cannot be unambiguously converted (10.2) to the class of which E2 is directly a member.

This reformulation also has the advantage of pointing readers to 11.8.3 [class.access.base], where the the convertibility requirement from the class of E1 to the naming class is located and which might otherwise be overlooked.

Notes from the March 2004 meeting:

We discussed this further and agreed with these latest recommendations. Mike Miller has produced a paper N1626 that gives just the final collected set of changes.

(This resolution also resolves isssue 306.)

306. Ambiguity by class name injection

[Voted into WP at April 2005 meeting.]

Is the following well-formed?

    struct A {
        struct B { };
    };
    struct C : public A, public A::B {
        B *p;
    };

What if a struct is found along one path and a typedef to that struct is found along another path? That should probably be valid, but does the standard say so?

This is resolved by issue 39

February 2004: Moved back to "Review" status because issue 39 was moved back to "Review".

139. Error in friend lookup example

[Moved to DR at 10/01 meeting.]

The example in 6.5.3 [basic.lookup.unqual] paragraph 3 is incorrect:

    typedef int f;
    struct A {
        friend void f(A &);
        operator int();
        void g(A a) {
            f(a);
        }
    };

One possible repair of the example would be to make f a class with a constructor taking either A or int as its parameter.

(See also issues 95, 136, 138, 143, 165, and 166.)

Proposed resolution (04/01):

1. Change the example in 6.5.3 [basic.lookup.unqual] paragraph 3 to read:

       typedef int f;
       namespace N {
           struct A {
               friend int f(A &);
               operator int();
               void g(A a) {
                   int i = f(a);
                         // f is the typedef, not the friend function:
                         // equivalent to int(a)
               }
           };
       }
   

2. Delete the sentence immediately following the example:

   The expression f(a) is a cast-expression equivalent to int(a).

514. Is the initializer for a namespace member in the scope of the namespace?

[Voted into WP at the October, 2006 meeting.]

Is the following code well-formed?

    namespace N {
      int i;
      extern int j;
    }
    int N::j = i;

The question here is whether the lookup for i in the initializer of N::j finds the declaration in namespace N or not. Implementations differ on this question.

If N::j were a static data member of a class, the answer would be clear: both 6.5.3 [basic.lookup.unqual] paragraph 12 and 9.4 [dcl.init] paragraph 11 say that the initializer “is in the scope of the member's class.” There is no such provision for namespace members defined outside the namespace, however.

The reasoning given in 6.5.3 [basic.lookup.unqual] may be instructive:

A name used in the definition of a static data member of class X (11.4.9.3 [class.static.data]) (after the qualified-id of the static member) is looked up as if the name was used in a member function of X.

It is certainly the case that a name used in a function that is a member of a namespace is looked up in that namespace (6.5.3 [basic.lookup.unqual] paragraph 6), regardless of whether the definition is inside or outside that namespace. Initializers for namespace members should probably be looked up the same way.

Proposed resolution (April, 2006):

Add a new paragraph following 6.5.3 [basic.lookup.unqual] paragraph 12:

If a variable member of a namespace is defined outside of the scope of its namespace then any name used in the definition of the variable member (after the declarator-id) is looked up as if the definition of the variable member occurred in its namespace. [Example:

    namespace N {
      int i = 4;
      extern int j;
    }

    int i = 2;

    int N::j = i;	// N::j == 4

—end example]

143. Friends and Koenig lookup

[Moved to DR at 4/02 meeting.]

Paragraphs 1 and 2 of 6.5.4 [basic.lookup.argdep] say, in part,

When an unqualified name is used as the postfix-expression in a function call (7.6.1.3 [expr.call] )... namespace-scope friend function declarations (11.8.4 [class.friend] ) not otherwise visible may be found... the set of declarations found by the lookup of the function name [includes] the set of declarations found in the... classes associated with the argument types.

Consider the following example:

    namespace A {
	class S;
    };
    namespace B {
	void f(A::S);
    };
    namespace A {
	class S {
	    int i;
	    friend void B::f(S);
	};
    }
    void g() {
	A::S s;
	f(s); // should find B::f(A::S)
    }

Another interpretation is that, instead of finding the friend declarations in associated classes, one only looks for namespace-scope functions, visible or invisible, in the namespaces of which the the associated classes are members; the only use of the friend declarations in the associated classes is to validate whether an invisible function declaration came from an associated class or not and thus whether it should be included in the overload set or not. By this interpretation, the call f(s) in the example will fail, because B::f(A::S) is not a member of namespace A and thus is not found by the lookup.

Notes from 10/99 meeting: The second interpretation is correct. The wording should be revised to make clear that Koenig lookup works by finding "invisible" declarations in namespace scope and not by finding friend declarations in associated classes.

Proposed resolution (04/01): The "associated classes" are handled adequately under this interpretation by 6.5.4 [basic.lookup.argdep] paragraph 3, which describes the lookup in the associated namespaces as including the friend declarations from the associated classes. Other mentions of the associated classes should be removed or qualified to avoid the impression that there is a lookup in those classes:

1. In 6.5.4 [basic.lookup.argdep], change

   When an unqualified name is used as the postfix-expression in a function call (7.6.1.3 [expr.call]), other namespaces not considered during the usual unqualified lookup (6.5.3 [basic.lookup.unqual]) may be searched, and namespace-scope friend function declarations (11.8.4 [class.friend]) not otherwise visible may be found.

   to

   When an unqualified name is used as the postfix-expression in a function call (7.6.1.3 [expr.call]), other namespaces not considered during the usual unqualified lookup (6.5.3 [basic.lookup.unqual]) may be searched, and in those namespaces, namespace-scope friend function declarations (11.8.4 [class.friend]) not otherwise visible may be found.

2. In 6.5.4 [basic.lookup.argdep] paragraph 2, delete the words and classes in the following two sentences:

   If the ordinary unqualified lookup of the name finds the declaration of a class member function, the associated namespaces and classes are not considered. Otherwise the set of declarations found by the lookup of the function name is the union of the set of declarations found using ordinary unqualified lookup and the set of declarations found in the namespaces and classes associated with the argument types.

(See also issues 95, 136, 138, 139, 165, 166, and 218.)

218. Specification of Koenig lookup

[Voted into WP at April, 2007 meeting.]

The original intent of the Committee when Koenig lookup was added to the language was apparently something like the following:

1. The name in the function call expression is looked up like any other unqualified name.
2. If the ordinary unqualified lookup finds nothing or finds the declaration of a (non-member) function, function template, or overload set, argument-dependent lookup is done and any functions found in associated namespaces are added to the result of the ordinary lookup.

This approach is not reflected in the current wording of the Standard. Instead, the following appears to be the status quo:

1. Lookup of an unqualified name used as the postfix-expression in the function call syntax always performs Koenig lookup (6.5.3 [basic.lookup.unqual] paragraph 3).
2. Unless ordinary lookup finds a class member function, the result of Koenig lookup always includes the declarations found in associated namespaces (6.5.4 [basic.lookup.argdep] paragraph 2), regardless of whether ordinary lookup finds a declaration and, if so, what kind of entity is found.
3. The declarations from associated namespaces are not limited to functions and template functions by anything in 6.5.4 [basic.lookup.argdep]. However, if Koenig lookup results in more than one declaration and at least one of the declarations is a non-function, the program is ill-formed (9.8.4 [namespace.udir], paragraph 4; although this restriction is in the description of the using-directive, the wording applies to any lookup that spans namespaces).

John Spicer: Argument-dependent lookup was created to solve the problem of looking up function names within templates where you don't know which namespace to use because it may depend on the template argument types (and was then expanded to permit use in nontemplates). The original intent only concerned functions. The safest and simplest change is to simply clarify the existing wording to that effect.

Bill Gibbons: I see no reason why non-function declarations should not be found. It would take a special rule to exclude "function objects", as well as pointers to functions, from consideration. There is no such rule in the standard and I see no need for one.

There is also a problem with the wording in 6.5.4 [basic.lookup.argdep] paragraph 2:

If the ordinary unqualified lookup of the name finds the declaration of a class member function, the associated namespaces and classes are not considered.

This implies that if the ordinary lookup of the name finds the declaration of a data member which is a pointer to function or function object, argument-dependent lookup is still done.

My guess is that this is a mistake based on the incorrect assumption that finding any member other than a member function would be an error. I would just change "class member function" to "class member" in the quoted sentence.

Mike Miller: In light of the issue of "short-circuiting" Koenig lookup when normal lookup finds a non-function, perhaps it should be written as "...finds the declaration of a class member, an object, or a reference, the associated namespaces..."?

Andy Koenig: I think I have to weigh in on the side of extending argument-dependent lookup to include function objects and pointers to functions. I am particularly concerned about [function objects], because I think that programmers should be able to replace functions by function objects without changing the behavior of their programs in fundamental ways.

Bjarne Stroustrup: I don't think we could seriously argue from first principles that [argument-dependent lookup should find only function declarations]. In general, C++ name lookup is designed to be independent of type: First we find the name(s), then, we consider its(their) meaning. 6.5 [basic.lookup] states "The name lookup rules apply uniformly to all names ..." That is an important principle.

Thus, I consider text that speaks of "function call" instead of plain "call" or "application of ()" in the context of koenig lookup an accident of history. I find it hard to understand how 7.6.1.3 [expr.call] doesn't either disallow all occurrences of x(y) where x is a class object (that's clearly not intended) or requires koenig lookup for x independently of its type (by reference from 6.5 [basic.lookup]). I suspect that a clarification of 7.6.1.3 [expr.call] to mention function objects is in order. If the left-hand operand of () is a name, it should be looked up using koenig lookup.

John Spicer: This approach causes otherwise well-formed programs to be ill-formed, and it does so by making names visible that might be completely unknown to the author of the program. Using-directives already do this, but argument-dependent lookup is different. You only get names from using-directives if you actually use using-directives. You get names from argument-dependent lookup whether you want them or not.

This basically breaks an important reason for having namespaces. You are not supposed to need any knowledge of the names used by a namespace.

But this example breaks if argument-dependent lookup finds non-functions and if the translation unit includes the <list> header somewhere.

    namespace my_ns {
        struct A {};
        void list(std::ostream&, A&);

        void f() {
            my_ns::A a;
            list(cout, a);
        }
    }

This really makes namespaces of questionable value if you still need to avoid using the same name as an entity in another namespace to avoid problems like this.

Erwin Unruh: Before we really decide on this topic, we should have more analysis on the impact on programs. I would also like to see a paper on the possibility to overload functions with function surrogates (no, I won't write one). Since such an extension is bound to wait until the next official update, we should not preclude any outcome of the discussion.

I would like to have a change right now, which leaves open several outcomes later. I would like to say that:

Koenig lookup will find non-functions as well. If it finds a variable, the program is ill-formed. If the primary lookup finds a variable, Koenig lookup is done. If the result contains both functions and variables, the program is ill-formed. [Note: A future standard will assign semantics to such a program.]

I myself are not comfortable with this as a long-time result, but it prepares the ground for any of the following long term solutions:

• Do overloading on mixed function/variable sets.
• Ignore variables on Koenig lookup.
• Don't do Koenig lookup if the primary lookup finds a variable.
• Find variables on Koenig lookup and give an error if there is a variable/function mix.

The note is there to prevent compiler vendors to put their own extensions in here.

(See also issues 113 and 143.)

Notes from 04/00 meeting:

Although many agreed that there were valid concerns motivating a desire for Koenig lookup to find non-function declarations, there was also concern that supporting this capability would be more dangerous than helpful in the absence of overload resolution for mixed function and non-function declarations.

A straw poll of the group revealed 8 in favor of Koenig lookup finding functions and function templates only, while 3 supported the broader result.

Notes from the 10/01 meeting:

There was unanimous agreement on one less controversial point: if the normal lookup of the identifier finds a non-function, argument-dependent lookup should not be done.

On the larger issue, the primary point of consensus is that making this change is an extension, and therefore it should wait until the point at which we are considering extensions (which could be very soon). There was also consensus on the fact that the standard as it stands is not clear: some introductory text suggests that argument-dependent lookup finds only functions, but the more detailed text that describes the lookup does not have any such restriction.

It was also noted that some existing implementations (e.g., g++) do find some non-functions in some cases.

The issue at this point is whether we should (1) make a small change to make the standard clear (presumably in the direction of not finding the non-functions in the lookup), and revisit the issue later as an extension, or (2) leave the standard alone for now and make any changes only as part of considering the extension. A straw vote favored option (1) by a strong majority.

Additional Notes (September, 2006):

Recent discussion of this issue has emphasized the following points:

1. The concept of finding function pointers and function objects as part of argument-dependent lookup is not currently under active discussion in the Evolution Working Group.

2. The major area of concern with argument-dependent lookup is finding functions in unintended namespaces. There are current proposals to deal with this concern either by changing the definition of “associated namespace” so that fewer namespaces are considered or to provide a mechanism for enabling or disabling ADL altogether. Although this concern is conceptually distinct from the question of whether ADL finds function pointers and function objects, it is related in the sense that the current rules are perceived as finding too many functions (because of searching too many namespaces), and allowing function pointers and function objects would also increase the number of entities found by ADL.

3. Any expansion of ADL to include function pointers and function objects must necessarily update the overloading rules to specify how they interact with functions and function templates in the overload set. Current implementation experience (g++) is not helpful in making this decision because, although it performs a uniform lookup and finds non-function entities, it diagnoses an error in overload resolution if non-function entities are in the overload set.

4. There is a possible problem if types are found by ADL: it is not clear that overloading between callable entities (functions, function templates, function pointers, and function objects) and types (where the postfix syntax means a cast or construction of a temporary) is reasonable or useful.

James Widman:

There is a larger debate here about whether ADL should find object names; the proposed wording below is only intended to answer the request for wording to clarify the status quo (option 1 above) and not to suggest the outcome of the larger debate.

Proposed Resolution (October, 2006):

1. Replace the normative text in 6.5.4 [basic.lookup.argdep] paragraph 3 with the following (leaving the text of the note and example unchanged):

   Let X be the lookup set produced by unqualified lookup (6.5.3 [basic.lookup.unqual]) and let Y be the lookup set produced by argument dependent lookup (defined as follows). If X contains

   • a declaration of a class member, or
   • a block-scope function declaration that is not a using-declaration, or
   • a declaration that is neither a function nor a function template

   then Y is empty. Otherwise Y is the set of declarations found in the namespaces associated with the argument types as described below. The set of declarations found by the lookup of the name is the union of X and Y.

2. Change 6.5.3 [basic.lookup.unqual] paragraph 4 as indicated:

   When considering an associated namespace, the lookup is the same as the lookup performed when the associated namespace is used as a qualifier (6.5.5.3 [namespace.qual]) except that:

   • Any using-directives in the associated namespace are ignored.
   • Any namespace-scope friend functions or friend function templates declared in associated classes are visible within their respective namespaces even if they are not visible during an ordinary lookup (11.8.4 [class.friend]).
   • All names except those of (possibly overloaded) functions and function templates are ignored.

403. Reference to a type as a template-id

[Voted into WP at March 2004 meeting.]

Spun off from issue 384.

6.5.4 [basic.lookup.argdep] says:

If T is a template-id, its associated namespaces and classes are the namespace in which the template is defined; for member templates, the member template's class; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which any template template arguments are defined; and the classes in which any member templates used as template template arguments are defined. [Note: non-type template arguments do not contribute to the set of associated namespaces. ]

Proposed Resolution (October 2003):

In 6.5.4 [basic.lookup.argdep], paragraph 2, bullet 8, replace

If T is a template-id ...

If T is a class template specialization ...

557. Does argument-dependent lookup cause template instantiation?

[Voted into WP at the October, 2006 meeting.]

One might assume from 13.9.2 [temp.inst] paragraph 1 that argument-dependent lookup would require instantiation of any class template specializations used in argument types:

Unless a class template specialization has been explicitly instantiated (13.9.3 [temp.explicit]) or explicitly specialized (13.9.4 [temp.expl.spec]), the class template specialization is implicitly instantiated when the specialization is referenced in a context that requires a completely-defined object type or when the completeness of the class type affects the semantics of the program.

A complete class type is required to determine the associated classes and namespaces for the argument type (to determine the class's bases) and to determine the friend functions declared by the class, so the completeness of the class type certainly “affects the semantics of the program.”

This conclusion is reinforced by the second bullet of 6.5.4 [basic.lookup.argdep] paragraph 2:

• If T is a class type (including unions), its associated classes are: the class itself; the class of which it is a member, if any; and its direct and indirect base classes. Its associated namespaces are the namespaces in which its associated classes are defined.

A class template specialization is a class type, so the second bullet would appear to apply, requiring the specialization to be instantiated in order to determine its base classes.

However, bullet 8 of that paragraph deals explicitly with class template specializations:

• If T is a class template specialization its associated namespaces and classes are the namespace in which the template is defined; for member templates, the member template's class; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which any template template arguments are defined; and the classes in which any member templates used as template template arguments are defined.

Note that the class template specialization itself is not listed as an associated class, unlike other class types, and there is no mention of base classes. If bullet 8 were intended as a supplement to the treatment of class types in bullet 2, one would expect phrasing along the lines of, “In addition to the associated namespaces and classes for all class types...” or some such; instead, bullet 8 reads like a self-contained and complete specification.

If argument-dependent lookup does not cause implicit instantiation, however, examples like the following fail:

    template <typename T> class C {
        friend void f(C<T>*) { }
    };
    void g(C<int>* p) {
        f(p);    // found by ADL??
    }

Implementations differ in whether this example works or not.

Proposed resolution (April, 2006):

1. Change bullet 2 of 6.5.4 [basic.lookup.argdep] paragraph 2 as indicated:

   • If T is a class type (including unions), its associated classes are: the class itself; the class of which it is a member, if any; and its direct and indirect base classes. Its associated namespaces are the namespaces in of which its associated classes are defined members. Furthermore, if T is a class template specialization, its associated namespaces and classes also include: the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces of which any template template arguments are members; and the classes of which any member templates used as template template arguments are members. [Note: Non-type template arguments do not contribute to the set of associated namespaces. —end note]

2. Delete bullet 8 of 6.5.4 [basic.lookup.argdep] paragraph 2:

   • If T is a class template specialization its associated namespaces and classes are the namespace in which the template is defined; for member templates, the member template's class; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which any template template arguments are defined; and the classes in which any member templates used as template template arguments are defined. [Note: non-type template arguments do not contribute to the set of associated namespaces. —end note]

298. T::x when T is cv-qualified

[Voted into WP at April 2003 meeting.]

Can a typedef T to a cv-qualified class type be used in a qualified name T::x?

    struct A { static int i; };
    typedef const A CA;
    int main () {
      CA::i = 0;  // Okay?
    }

Suggested answer: Yes. All the compilers I tried accept the test case.

Proposed resolution (10/01):

In 6.5.5.2 [class.qual] paragraph 1 add the indicated text:

If the nested-name-specifier of a qualified-id nominates a class, the name specified after the nested-name-specifier is looked up in the scope of the class (6.5.2 [class.member.lookup]), except for the cases listed below. The name shall represent one or more members of that class or of one of its base classes (11.7 [class.derived]). If the class-or-namespace-name of the nested-name-specifier names a cv-qualified class type, it nominates the underlying class (the cv-qualifiers are ignored).

Notes from 4/02 meeting:

There is a problem in that class-or-namespace-name does not include typedef names for cv-qualified class types. See 9.2.4 [dcl.typedef] paragraph 4:

Argument and text removed from proposed resolution (October 2002):

9.2.4 [dcl.typedef] paragraph 5:

Here's a good question: in this example, should X be used as a name-for-linkage-purposes (FLP name)?

  typedef class { } const X;

Because a type-qualifier is parsed as a decl-specifier, it isn't possible to declare cv-qualified and cv-unqualified typedefs for a type in a single declaration. Also, of course, there's no way to declare a typedef for the cv-unqualified version of a type for which only a cv-qualified version has a name. So, in the above example, if X isn't used as the FLP name, then there can be no FLP name. Also note that a FLP name usually represents a parameter type, where top-level cv-qualifiers are usually irrelevant anyway.

Data points: for the above example, Microsoft uses X as the FLP name; GNU and EDG do not.

My recommendation: for consistency with the direction we're going on this issue, for simplicity of description (e.g., "the first class-name declared by the declaration"), and for (very slightly) increased utility, I think Microsoft has this right.

If the typedef declaration defines an unnamed class type (or enum type), the first typedef-name declared by the declaration to be have that class type (or enum type) or a cv-qualified version thereof is used to denote the class type (or enum type) for linkage purposes only (6.6 [basic.link]). [Example: ...

Proposed resolution (October 2002):

6.5.6 [basic.lookup.elab] paragraphs 2 and 3:

This sentence is deleted twice:

... If this name lookup finds a typedef-name, the elaborated-type-specifier is ill-formed. ...

Note that the above changes are included in N1376 as part of the resolution of issue 245.

_N4567_.5.1.1 [expr.prim.general] paragraph 7:

This is only a note, and it is at least incomplete (and quite possibly inaccurate), despite (or because of) its complexity. I propose to delete it.

... [Note: a typedef-name that names a class is a class-name (11.3 [class.name]). Except as the identifier in the declarator for a constructor or destructor definition outside of a class member-specification (11.4.5 [class.ctor], 11.4.7 [class.dtor]), a typedef-name that names a class may be used in a qualified-id to refer to a constructor or destructor. ]

9.2.4 [dcl.typedef] paragraph 4:

My first choice would have been to make this the primary statement about the equivalence of typedef-name and class-name, since the equivalence comes about as a result of a typedef declaration. Unfortunately, references to class-name point to 11.3 [class.name], so it would seem that the primary statement should be there instead. To avoid the possiblity of conflicts in the future, I propose to make this a note.

[Note: A typedef-name that names a class type, or a cv-qualified version thereof, is also a class-name (11.3 [class.name]). If a typedef-name is used following the class-key in an elaborated-type-specifier (9.2.9.4 [dcl.type.elab]), or in the class-head of a class declaration (Clause 11 [class]), or is used as the identifier in the declarator for a constructor or destructor declaration (11.4.5 [class.ctor], 11.4.7 [class.dtor]), to identify the subject of an elaborated-type-specifier (9.2.9.4 [dcl.type.elab]), class declaration (Clause 11 [class]), constructor declaration (11.4.5 [class.ctor]), or destructor declaration (11.4.7 [class.dtor]), the program is ill-formed. ] [Example: ...

9.2.9.4 [dcl.type.elab] paragraph 2:

This is the only remaining (normative) statement that a typedef-name can't be used in an elaborated-type-specifier. The reference to template type-parameter is deleted by the resolution of issue 283.

... If the identifier resolves to a typedef-name or a template type-parameter, the elaborated-type-specifier is ill-formed. [Note: ...

9.3 [dcl.decl] grammar rule declarator-id:

When I looked carefully into the statement of the rule prohibiting a typedef-name in a constructor declaration, it appeared to me that this grammar rule (inadvertently?) allows something that's always forbidden semantically.

declarator-id:
id-expression
::_opt nested-name-specifier_opt type-name class-name

11.3 [class.name] paragraph 5:

Unlike the prohibitions against appearing in an elaborated-type-specifier or constructor or destructor declarator, each of which was expressed more than once, the prohibition against a typedef-name appearing in a class-head was previously stated only in 9.2.4 [dcl.typedef]. It seems to me that that prohibition belongs here instead. Also, it seems to me important to clarify that a typedef-name that is a class-name is still a typedef-name. Otherwise, the various prohibitions can be argued around easily, if perversely ("But that isn't a typedef-name, it's a class-name; it says so right there in 11.3 [class.name].")

A typedef-name (9.2.4 [dcl.typedef]) that names a class type or a cv-qualified version thereof is also a class-name, but shall not be used in an elaborated-type-specifier; see also 9.2.4 [dcl.typedef]. as the identifier in a class-head.

11.4.5 [class.ctor] paragraph 3:

The new nonterminal references are needed to really nail down what we're talking about here. Otherwise, I'm just eliminating redundancy. (A typedef-name that doesn't name a class type is no more valid here than one that does.)

A typedef-name that names a class is a class-name (9.2.4 [dcl.typedef]); however, a A typedef-name that names a class shall not be used as the identifier class-name in the declarator declarator-id for a constructor declaration.

11.4.7 [class.dtor] paragraph 1:

The same comments apply here as to 11.4.5 [class.ctor].

... A typedef-name that names a class is a class-name (7.1.3); however, a A typedef-name that names a class shall not be used as the identifier class-name following the ~ in the declarator for a destructor declaration.

318. struct A::A should not name the constructor of A

[Voted into WP at April 2003 meeting.]

A use of an injected-class-name in an elaborated-type-specifier should not name the constructor of the class, but rather the class itself, because in that context we know that we're looking for a type. See issue 147.

Proposed Resolution (revised October 2002):

This clarifies the changes made in the TC for issue 147.

In 6.5.5.2 [class.qual] paragraph 1a replace:

If the nested-name-specifier nominates a class C, and the name specified after the nested-name-specifier, when looked up in C, is the injected class name of C (Clause 11 [class]), the name is instead considered to name the constructor of class C.

with

In a lookup in which the constructor is an acceptable lookup result, if the nested-name-specifier nominates a class C and the name specified after the nested-name-specifier, when looked up in C, is the injected class name of C (Clause 11 [class]), the name is instead considered to name the constructor of class C. [Note: For example, the constructor is not an acceptable lookup result in an elaborated type specifier so the constructor would not be used in place of the injected class name.]

Note that issue 263 updates a part of the same paragraph.

Append to the example:

  struct A::A a2;  // object of type A

400. Using-declarations and the "struct hack"

[Voted into WP at March 2004 meeting.]

Consider this code:

  struct A { int i; struct i {}; };
  struct B { int i; struct i {}; };
  struct D : public A, public B { using A::i; void f (); };
  void D::f () { struct i x; }

I can't find anything in the standard that says definitively what this means. 9.9 [namespace.udecl] says that a using-declaration shall name "a member of a base class" -- but here we have two members, the data member A::i and the class A::i.

Personally, I'd find it more attractive if this code did not work. I'd like "using A::i" to mean "lookup A::i in the usual way and bind B::i to that", which would mean that while "i = 3" would be valid in D::f, "struct i x" would not be. However, if there were no A::i data member, then "A::i" would find the struct and the code in D::f would be valid.

John Spicer: I agree with you, but unfortunately the standard committee did not.

I remembered that this was discussed by the committee and that a resolution was adopted that was different than what I hoped for, but I had a hard time finding definitive wording in the standard.

I went back though my records and found the paper that proposed a resolution and the associated committee motion that adopted the proposed resolution The paper is N0905, and "option 1" from that paper was adopted at the Stockholm meeting in July of 1996. The resolution is that "using A::i" brings in everything named i from A.

6.5.5.3 [namespace.qual] paragraph 2 was modified to implement this resolution, but interestingly that only covers the namespace case and not the class case. I think the class case was overlooked when the wording was drafted. A core issue should be opened to make sure the class case is handled properly.

Notes from April 2003 meeting:

This is related to issue 11. 9.9 [namespace.udecl] paragraph 10 has an example for namespaces.

Proposed resolution (October 2003):

Add a bullet to the end of 6.5.5.2 [class.qual] paragraph 1:

• the lookup for a name specified in a using-declaration (9.9 [namespace.udecl]) also finds class or enumeration names hidden within the same scope (_N4868_.6.4.10 [basic.scope.hiding]).

Change the beginning of 9.9 [namespace.udecl] paragraph 4 from

A using-declaration used as a member-declaration shall refer to a member of a base class of the class being defined, shall refer to a member of an anonymous union that is a member of a base class of the class being defined, or shall refer to an enumerator for an enumeration type that is a member of a base class of the class being defined.

to

In a using-declaration used as a member-declaration, the nested-name-specifier shall name a base class of the class being defined. Such a using-declaration introduces the set of declarations found by member name lookup (6.5.2 [class.member.lookup], 6.5.5.2 [class.qual]).

245. Name lookup in elaborated-type-specifiers

[Voted into WP at April 2003 meeting.]

I have some concerns with the description of name lookup for elaborated type specifiers in 6.5.6 [basic.lookup.elab]:

1. Paragraph 2 has some parodoxical statements concerning looking up names that are simple identifers:

   If the elaborated-type-specifier refers to an enum-name and this lookup does not find a previously declared enum-name, the elaborated-type-specifier is ill-formed. If the elaborated-type-specifier refers to an [sic] class-name and this lookup does not find a previously declared class-name... the elaborated-type-specifier is a declaration that introduces the class-name as described in 6.4.2 [basic.scope.pdecl]."

   It is not clear how an elaborated-type-specifier can refer to an enum-name or class-name given that the lookup does not find such a name and that class-name and enum-name are not part of the syntax of an elaborated-type-specifier.

2. The second sentence quoted above seems to suggest that the name found will not be used if it is not a class name. typedef-name names are ill-formed due to the sentence preceding the quote. If lookup finds, for instance, an enum-name then a new declaration will be created. This differs from C, and from the enum case, and can have surprising effects:

       struct S {
          enum E {
              one = 1
          };
          class E* p;     // declares a global class E?
       };
   

   Was this really the intent? If this is the case then some more work is needed on 6.5.6 [basic.lookup.elab]. Note that the section does not make finding a type template formal ill-formed, as is done in 9.2.9.4 [dcl.type.elab]. I don't see anything that makes a type template formal name a class-name. So the example in 9.2.9.4 [dcl.type.elab] of friend class T; where T is a template type formal would no longer be ill-formed with this interpretation because it would declare a new class T.

(See also issue 254.)

Notes from the 4/02 meeting:

This will be consolidated with the changes for issue 254. See also issue 298.

Proposed resolution (October 2002):

As given in N1376=02-0034. Note that the inserts and strikeouts in that document do not display correctly in all browsers; <del> --> <strike> and <ins> --> <b>, and the similar changes for the closing delimiters, seem to do the trick.

254. Definitional problems with elaborated-type-specifiers

[Voted into WP at April 2003 meeting.]

1. The text in 6.5.6 [basic.lookup.elab] paragraph 2 twice refers to the possibility that an elaborated-type-specifier might have the form

           class-key identifier ;
   

   However, the grammar for elaborated-type-specifier does not include a semicolon.

2. In both 6.5.6 [basic.lookup.elab] and 9.2.9.4 [dcl.type.elab], the text asserts that an elaborated-type-specifier that refers to a typedef-name is ill-formed. However, it is permissible for the form of elaborated-type-specifier that begins with typename to refer to a typedef-name.

   This problem is the result of adding the typename form to the elaborated-type-name grammar without changing the verbiage correspondingly. It could be fixed either by updating the verbiage or by moving the typename syntax into its own production and referring to both nonterminals when needed.

(See also issue 180. If this issue is resolved in favor of a separate nonterminal in the grammar for the typename forms, the wording in that issue's resolution must be changed accordingly.)

Notes from 04/01 meeting:

The consensus was in favor of moving the typename forms out of the elaborated-type-specifier grammar.

Notes from the 4/02 meeting:

This will be consolidated with the changes for issue 245.

Proposed resolution (October 2002):

As given in N1376=02-0034.

216. Linkage of nameless class-scope enumeration types

[Moved to DR at 10/01 meeting.]

A name having namespace scope has external linkage if it is the name of

• [...]
• a named enumeration (9.7.1 [dcl.enum]), or an unnamed enumeration defined in a typedef declaration in which the enumeration has the typedef name for linkage purposes (9.2.4 [dcl.typedef])

    typedef enum { e1 } *PE;
    void f(PE) {}  // Cannot declare a function (with linkage) using a
		   // type with no linkage.

However, the same prohibition was not made for class scope types. Indeed, 6.6 [basic.link] paragraph 5 says:

In addition, a member function, static data member, class or enumeration of class scope has external linkage if the name of the class has external linkage.

That allows for:

    struct S {
       typedef enum { e1 } *MPE;
       void mf(MPE) {}
    };

My guess is that this is an unintentional consequence of 6.6 [basic.link] paragraph 5, but I would like confirmation on that.

Proposed resolution:

Change text in 6.6 [basic.link] paragraph 5 from:

In addition, a member function, static data member, class or enumeration of class scope has external linkage if the name of the class has external linkage.

In addition, a member function, a static data member, a named class or enumeration of class scope, or an unnamed class or enumeration defined in a class-scope typedef declaration such that the class or enumeration has the typedef name for linkage purposes (9.2.4 [dcl.typedef]), has external linkage if the name of the class has external linkage.

319. Use of names without linkage in declaring entities with linkage

[Voted into WP at October 2004 meeting.]

According to 6.6 [basic.link] paragraph 8, "A name with no linkage ... shall not be used to declare an entity with linkage." This would appear to rule out code such as:

  typedef struct {
    int i;
  } *PT;
  extern "C" void f(PT);

  static enum { a } e;

See issue 132, which dealt with a closely related issue.

Andrei Iltchenko submitted the same issue via comp.std.c++ on 17 Dec 2001:

Paragraph 8 of Section 6.6 [basic.link] contains the following sentences: "A name with no linkage shall not be used to declare an entity with linkage. If a declaration uses a typedef name, it is the linkage of the type name to which the typedef refers that is considered."

The problem with this wording is that it doesn't cover cases where the type to which a typedef-name refers has no name. As a result it's not clear whether, for example, the following program is well-formed:

#include <vector>

int  main()
{
   enum  {   sz = 6u   };
   typedef int  (* aptr_type)[sz];
   typedef struct  data  {
      int   i,  j;
   }  * elem_type;
   std::vector<aptr_type>   vec1;
   std::vector<elem_type>   vec2;
}

Suggested resolution:

My feeling is that the rules for whether or not a typedef-name used in a declaration shall be treated as having or not having linkage ought to be modelled after those for dependent types, which are explained in 13.8.3.2 [temp.dep.type].

Add the following text at the end of Paragraph 8 of Section 6.6 [basic.link] and replace the following example:

In case of the type referred to by a typedef declaration not having a name, the newly declared typedef-name has linkage if and only if its referred type comprises no names of no linkage excluding local names that are eligible for appearance in an integral constant-expression (7.7 [expr.const]). [Note: if the referred type contains a typedef-name that does not denote an unnamed class, the linkage of that name is established by the recursive application of this rule for the purposes of using typedef names in declarations.] [Example:

  void f()
  {
     struct A { int x; };        // no linkage
     extern A a;                 // ill-formed
     typedef A Bl
     extern B b;                 // ill-formed

     enum  {   sz = 6u   };
     typedef int  (* C)[sz];     // C has linkage because sz can
                                 // appear in a constant expression
  }

--end example.]

Additional issue (13 Jan 2002, from Andrei Iltchenko):

Paragraph 2 of Section 13.4.2 [temp.arg.type] is inaccurate and unnecessarily prohibits a few important cases; it says "A local type, a type with no linkage, an unnamed type or a type compounded from any of these types shall not be used as a template-argument for a template-parameter." The inaccuracy stems from the fact that it is not a type but its name that can have a linkage.

For example based on the current wording of 13.4.2 [temp.arg.type], the following example is ill-formed.

  #include <vector>
  struct  data  {
    int   i,  j;
  };
  int  main()
  {
    enum  {   sz = 6u   };
    std::vector<int(*)[sz]>   vec1; // The types 'int(*)[sz]' and 'data*'
    std::vector<data*>        vec2; // have no names and are thus illegal
                                    // as template type arguments.
  }

Suggested resolution:

Replace the whole second paragraph of Section 13.4.2 [temp.arg.type] with the following wording:

A type whose name does not have a linkage or a type compounded from any such type shall not be used as a template-argument for a template-parameter. In case of a type T used as a template type argument not having a name, T constitutes a valid template type argument if and only if the name of an invented typedef declaration referring to T would have linkage; see 3.5. [Example:

  template <class T> class X { /* ... */ };
  void f()
  {
    struct S { /* ... */ };
    enum  {   sz = 6u   };

    X<S> x3;                     // error: a type name with no linkage
                                 // used as template-argument
    X<S*> x4;                    // error: pointer to a type name with
                                 // no linkage used as template-argument
    X<int(*)[sz]> x5;            // OK: since the name of typedef int
                                 // (*pname)[sz] would have linkage
  }

--end example] [Note: a template type argument may be an incomplete type (6.8 [basic.types]).]

Proposed resolution:

This is resolved by the changes for issue 389. The present issue was moved back to Review status in February 2004 because 389 was moved back to Review.

389. Unnamed types in entities with linkage

[Voted into WP at October 2004 meeting.]

6.6 [basic.link] paragraph 8 says (among other things):

A name with no linkage (notably, the name of a class or enumeration declared in a local scope (6.4.3 [basic.scope.block])) shall not be used to declare an entity with linkage. If a declaration uses a typedef name, it is the linkage of the type name to which the typedef refers that is considered.

I would expect this to catch situations such as the following:

  // File 1:
  typedef struct {} *UP;
  void f(UP) {}

  // File 2:
  typedef struct {} *UP; // Or: typedef struct {} U, *UP;
  void f(UP);

The problem here is that most implementations must generate the same mangled name for "f" in two translation units. The quote from the standard above isn't quite clear, unfortunately: There is no type name to which the typedef refers.

A related situation is the following:

  enum { no, yes } answer;

Finally, these problems are much less relevant when declaring names with internal linkage. For example, I would expect there to be few problems with:

  typedef struct {} *UP;
  static void g(UP);

I recently tried to interpret 6.6 [basic.link] paragraph 8 with the assumption that types with no names have no linkage. Surprisingly, this resulted in many diagnostics on variable declarations (mostly like "answer" above).

I'm pretty sure the standard needs clarifying words in this matter, but which way should it go?

See also issue 319.

Notes from April 2003 meeting:

There was agreement that this check is not needed for variables and functions with extern "C" linkage, and a change there is desirable to allow use of legacy C headers. The check is also not needed for entities with internal linkage, but there was no strong sentiment for changing that case.

We also considered relaxing this requirement for extern "C++" variables but decided that we did not want to change that case.

We noted that if extern "C" functions are allowed an additional check is needed when such functions are used as arguments in calls of function templates. Deduction will put the type of the extern "C" function into the type of the template instance, i.e., there would be a need to mangle the name of an unnamed type. To plug that hole we need an additional requirement on the template created in such a case.

Proposed resolution (April 2003, revised slightly October 2003 and March 2004):

In 6.6 [basic.link] paragraph 8, change

A name with no linkage (notably, the name of a class or enumeration declared in a local scope (6.4.3 [basic.scope.block])) shall not be used to declare an entity with linkage. If a declaration uses a typedef name, it is the linkage of the type name to which the typedef refers that is considered.

to

A type is said to have linkage if and only if

• it is a class or enumeration type that is named (or has a name for linkage purposes (9.2.4 [dcl.typedef])) and the name has linkage; or
• it is a specialization of a class template (Clause 13 [temp]) [Footnote: a class template always has external linkage, and the requirements of 13.4.2 [temp.arg.type] and 13.4.3 [temp.arg.nontype] ensure that the template arguments will also have appropriate linkage]; or
• it is a fundamental type (6.8.2 [basic.fundamental]); or
• it is a compound type (6.8.4 [basic.compound]) other than a class or enumeration, compounded exclusively from types that have linkage; or
• it is a cv-qualified (6.8.5 [basic.type.qualifier]) version of a type that has linkage.

A type without linkage shall not be used as the type of a variable or function with linkage, unless the variable or function has extern "C" linkage (9.11 [dcl.link]). [Note: in other words, a type without linkage contains a class or enumeration that cannot be named outside of its translation unit. An entity with external linkage declared using such a type could not correspond to any other entity in another translation unit of the program and is thus not permitted. Also note that classes with linkage may contain members whose types do not have linkage, and that typedef names are ignored in the determination of whether a type has linkage.]

Change 13.4.2 [temp.arg.type] paragraph 2 from (note: this is the wording as updated by issue 62)

The following types shall not be used as a template-argument for a template type-parameter:

• a type whose name has no linkage
• an unnamed class or enumeration type that has no name for linkage purposes (9.2.4 [dcl.typedef])
• a cv-qualified version of one of the types in this list
• a type created by application of declarator operators to one of the types in this list
• a function type that uses one of the types in this list

to

A type without linkage (6.6 [basic.link]) shall not be used as a template-argument for a template type-parameter.

Once this issue is ready, issue 319 should be moved back to ready as well.

474. Block-scope extern declarations in namespace members

[Voted into WP at October 2005 meeting.]

Consider the following bit of code:

    namespace N {
      struct S {
        void f();
      };
    }
    using namespace N;
    void S::f() {
      extern void g();  // ::g or N::g?
    }

In 6.6 [basic.link] paragraph 7 the Standard says (among other things),

When a block scope declaration of an entity with linkage is not found to refer to some other declaration, then that entity is a member of the innermost enclosing namespace.

The question then is whether N is an “enclosing namespace” for the local declaration of g()?

Proposed resolution (October 2004):

Add the following text as a new paragraph at the end of 9.8.2 [namespace.def]:

The enclosing namespaces of a declaration are those namespaces in which the declaration lexically appears, except for a redeclaration of a namespace member outside its original namespace (e.g., a definition as specified in _N4868_.9.8.2.3 [namespace.memdef]). Such a redeclaration has the same enclosing namespaces as the original declaration. [Example:

  namespace Q {
    namespace V {
      void f(); // enclosing namespaces are the global namespace, Q, and Q::V
      class C { void m(); };
    }
    void V::f() { // enclosing namespaces are the global namespace, Q, and Q::V
      extern void h(); // ... so this declares Q::V::h
    }
    void V::C::m() { // enclosing namespaces are the global namespace, Q, and Q::V
    }
  }

—end example]