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

Issues with "DR" Status

2970. Races with volatile sig_atomic_t bit-fields

(From submission #654.)

Subclause 6.9.2.2 [intro.races] paragraph 22 specifies:

Two accesses to the same object of type volatile std::sig_atomic_t do not result in a data race if both occur in the same thread, even if one or more occurs in a signal handler. ...

This provision applies to bit-fields as well, because bit-fields are objects (6.8.1 [basic.types.general] paragraph 4). However, in practice bit-fields are not updated atomically and are subject to tearing.

Proposed resolution (2025-01-20, approved by CWG 2025-02-14):

Change in 6.9.2.2 [intro.races] paragraph 22 as follows:

Two accesses to the same non-bit-field object of type volatile std::sig_atomic_t do not result in a data race if both occur in the same thread, even if one or more occurs in a signal handler. ...

2549. Implicitly moving the operand of a throw-expression in unevaluated contexts

Consider:

  void f() {
    X x;
    // Is x an lvalue or an xvalue here?
    void g(int n = (decltype((throw x, 0))()));  // status quo: x is move-eligible here
  }

  void f() {
    X x;
    struct A {
      void g() {
        try {
          struct Y {
            // Is x an lvalue or an xvalue here?
            void h(int n = (decltype((throw x, 0))()));
          };
        } catch (...) { }
      }
    };
  }

11.9.6 [class.copy.elision] paragraph 3 specifies:

An implicitly movable entity is a variable of automatic storage duration that is either a non-volatile object or an rvalue reference to a non-volatile object type. In the following copy-initialization contexts, a move operation is first considered before attempting a copy operation:

• ...
• if the operand of a throw-expression (7.6.18 [expr.throw]) is a (possibly parenthesized) id-expression that names an implicitly movable entity that belongs to a scope that does not contain the compound-statement of the innermost try-block or function-try-block (if any) whose compound-statement or ctor-initializer contains the throw-expression,

Thus, in the first example above, x is treated as an xvalue, but it is treated as an lvalue in the second example. This outcome is surprising.

(P2266R2 (Simpler implicit move) moved this wording, introduced by P1825R0 (Merged wording for P0527R1 and P1155R3), from 11.9.6 [class.copy.elision] to 7.5.5.2 [expr.prim.id.unqual].)

Proposed resolution [SUPERSEDED]:

Change in 7.5.5.2 [expr.prim.id.unqual] paragraph 4:

An implicitly movable entity is a variable of with automatic storage duration that is either a non-volatile object or an rvalue reference to a non-volatile object type. In the following contexts, an An id-expression is move-eligible: if

• it names an implicitly movable entity declared in the body or parameter-declaration-clause of the innermost enclosing function or lambda-expression and
• If the id-expression (possibly parenthesized) id-expression is the operand of
  • a return or co_return statement, and names an implicitly movable entity declared in the body or parameter-declaration-clause of the innermost enclosing function or lambda-expression or
  • if the id-expression (possibly parenthesized) is the operand of a potentially-evaluated throw-expression, and names an implicitly movable entity that belongs to a scope that does not contain the compound-statement of the innermost lambda-expression, try-block, or function-try-block (if any) whose compound-statement or ctor-initializer encloses the throw-expression where no try-block or function-try-block intervenes between the declaration of the entity and the innermost enclosing scope of the throw-expression.

Additional notes (December, 2024)

Treating potentially-evaluated expressions differently (as opposed to unevaluated ones) is surprising.

Proposed resolution (approved by CWG 2025-02-14):

Change in 7.5.5.2 [expr.prim.id.unqual] paragraph 4:

An implicitly movable entity is a variable of with automatic storage duration that is either a non-volatile object or an rvalue reference to a non-volatile object type. In the following contexts, an An id-expression is move-eligible: if

• it names an implicitly movable entity,
• Ifit is the id-expression (possibly parenthesized) is the operand of a return or co_return statement, and names an implicitly movable entity declared in the body or parameter-declaration-clause of the innermost enclosing function or lambda-expression or if the id-expression (possibly parenthesized) is the operand of a throw-expression, and names an implicitly movable entity that belongs to a scope that does not contain the compound-statement of the innermost lambda-expression, try-block, or function-try-block (if any) whose compound-statement or ctor-initializer encloses the throw-expression
• each intervening scope between the declaration of the entity and the innermost enclosing scope of the id-expression is a block scope and, for a throw-expression, is not the block scope of a try-block or function-try-block.

2943. Discarding a void return value

(From submission #628.)

A warning is currently, but ought not to be, encouraged for a call to a [[nodiscard]] function with a void return type. Such a situation may arise for dependent return types. For example:

  [[nodiscard]] void f();
  template<class T> [[nodiscard]] T g();

  void h() {
    f();                // suggested change: warning no longer recommended
    (void)f();          // warning not recommended
    g<int>();           // warning recommended
    g<void>();          // suggested change: warning no longer recommended
    (void)g<void>();    // warning not recommended
  }

Proposed resolution (2025-01-21, approved by CWG 2025-02-14):

Change in 9.13.9 [dcl.attr.nodiscard] paragraph 4 as follows:

Recommended practice: Appearance of a nodiscard call as a potentially-evaluated discarded-value expression (7.2 [expr.prop]) of non-void type is discouraged unless explicitly cast to void. Implementations should issue a warning in such cases. The value of a has-attribute-expression for the nodiscard attribute should be 0 unless the implementation can issue such warnings.

2990. Exporting redeclarations of namespaces

Issue 2921 fixed the following issue with namespaces:

  export module M;
  namespace N { // external linkage, attached to global module, not exported
    void f();
  }
  namespace N { // error: exported namespace, redeclares non-exported namespace
    export void g();
  }

This is considered a CWG consistency / wording fix. However, the change for that issue also allowed:

  module;
  #include "header"
  export module wrap;

  export using ::feature;               // already allowed previously
  export extern "C++" void feature();   // newly allowed by CWG2921

The CWG chair had neglected to run this new feature past EWG prior to plenary-approving issue 2921 in Wroclaw. Subsequent discussion on the EWG reflector surfaced concerns about missing syntactic differentiation between an intended export-by-redeclaration and an accidental declaration of a different entity because of a slight signature mismatch.

This issues seeks to limit the change to namespaces only; any additional feature in this area should be presented to EWG via a paper.

Proposed resolution (approved by CWG 2025-02-14):

Change in 10.2 [module.interface] paragraph 6 as follows:

A redeclaration of an entity X is implicitly exported if X was introduced by an exported declaration; otherwise it shall not be exported if it is attached to a named module unless it is a namespace. [ Example:

  export module M;
  struct S { int n; };
  typedef S S;
  export typedef S S;     // OK, does not redeclare an entity
  export struct S;        // error: exported declaration follows non-exported declaration
  namespace N {           // external linkage, attached to global module, not exported
    void f();
  }
  namespace N {           // OK, exported namespace redeclaring non-exported namespace
    export void g();
  }

-- end example ]

2703. Three-way comparison requiring strong ordering for floating-point types, take 2

The resolution accepted for issue 2539 does not actually address the example in the issue, because overload resolution is never performed for expressions involving only built-in types.

Proposed resolution (2025-01-13, approved by CWG 2025-02-14):

Change in 11.10.3 [class.spaceship] paragraph 1 as follows:

The synthesized three-way comparison of type R (17.12.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 a <=> b is usable or overload resolution for a <=> b is performed and finds at least one viable candidate, the synthesized three-way comparison is not defined.
• Otherwise, ...

Issues with "accepted" Status

Issues with "DRWP" Status

2924. Undefined behavior during constant evaluation

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

(From editorial issue #7042 and submission #595.)

Subclause 3.65 [defns.undefined] states:

[Note 1 to entry: ... Evaluation of a constant expression (7.7 [expr.const]) never exhibits behavior explicitly specified as undefined in Clause 4 [intro] through Clause 15 [cpp]. —end note]

However, 7.7 [expr.const] bullet 5.8 excludes [[noreturn]] and [[assume]]; see also 7.7 [expr.const] paragraph 6.

Suggested resolution [SUPERSEDED]:

Change in 3.65 [defns.undefined] as follows:

[Note 1 to entry: ... Evaluation of a constant expression (7.7 [expr.const]) never exhibits behavior explicitly specified as undefined in Clause 4 [intro] through Clause 15 [cpp], excluding 9.13 [dcl.attr]. —end note]

CWG 2024-09-13

Admitting unbounded core-language undefined behavior in constant expressions is to be avoided. The quoted note is correct; the semantics of [[noreturn]] and [[assume]] need to be clarified.

Possible resolution [SUPERSEDED]:

1. Change in 9.13.3 [dcl.attr.assume] paragraph 1 as follows:

   ... The expression is not evaluated. If the converted expression would evaluate to true at the point where the assumption appears or if the assumption is evaluated in a context that is manifestly constant-evaluated, the assumption has no effect. Otherwise, the behavior is undefined.

2. Change in 9.13.10 [dcl.attr.noreturn] paragraph 2 as follows:

   If a function f is called where f was previously declared with the noreturn attribute, the function call is evaluated in a context that is not manifestly constant-evaluated (7.7 [expr.const]), and f eventually returns, the behavior is undefined.

CWG 2024-09-27

The suggested resolution is circular with the rules in 7.7 [expr.const] paragraph 6.

Possible resolution [SUPERSEDED]:

1. Change in 9.13.3 [dcl.attr.assume] paragraph 1 as follows:

   ... The expression is not evaluated. If the converted expression would evaluate to true at the point where the assumption appears, the assumption has no effect. Otherwise, outside of an evaluation to determine whether an expression is a core constant expression (7.7 [expr.const]), the behavior is undefined.

2. Change in 9.13.10 [dcl.attr.noreturn] paragraph 2 as follows:

   If a function f is called where f was previously declared with the noreturn attribute, the function call is evaluated outside of an evaluation to determine whether an expression is a core constant expression (7.7 [expr.const]), and f eventually returns, the behavior is undefined.

CWG 2024-10-11

Implementations have two options: Either a violation of an attribute causes an expressions not to be a constant expression, leading to runtime undefined behavior, or the attribute has no effect during constant evaluation.

Possible resolution [SUPERSEDED]:

1. Change in 7.7 [expr.const] paragraph 6:

   It is implementation-defined whether E is a core constant expression in the situations specified in 9.13.3 [dcl.attr.assume] and 9.13.10 [dcl.attr.noreturn].

   It is unspecified whether E is a core constant expression if E satisfies the constraints of a core constant expression, but evaluation of E would evaluate

   • an operation that has undefined behavior as specified in Clause 16 [library] through Clause 33 [exec], or
   • an invocation of the va_start macro (17.14.2 [cstdarg.syn]),.
   • a call to a function that was previously declared with the noreturn attribute (9.13.10 [dcl.attr.noreturn]) and that call returns to its caller, or
   • a statement with an assumption (9.13.3 [dcl.attr.assume]) whose converted conditional-expression, if evaluated where the assumption appears, would not disqualify E from being a core constant expression and would not evaluate to true. [Note 5: E is not disqualified from being a core constant expression if the hypothetical evaluation of the converted conditional-expression would disqualify E from being a core constant expression. —end note]

2. Change in 9.13.3 [dcl.attr.assume] paragraph 1 as follows:

   ... The expression is not evaluated.

   • If the converted expression would evaluate to true at the point where the assumption appears, the assumption has no effect.
   • Otherwise, if the statement with the assumption would be evaluated as part of an evaluation of an expression E that satisfies the constraints of a core constant expression (7.7 [expr.const]):
     • If the converted expression, evaluated at the point where the assumption appears, would disqualify E from being a core constant expression, the assumption is ignored.
     • Otherwise, it is implementation-defined whether E is a core constant expression; if E is evaluated as a core constant expression, the assumption has no effect.
   • Otherwise, the behavior is undefined.

3. Change in 9.13.10 [dcl.attr.noreturn] paragraph 2 as follows:

   If a function f is called where f was previously declared with the noreturn attribute and f eventually returns:

   • If the function call would be part of an evaluation of an expression E that satisfies the constraints of a core constant expression (7.7 [expr.const]), it is implementation-defined whether E is a core constant expression; if E is evaluated as a core constant expression, the attribute has no effect.
   • Otherwise, the behavior is undefined.

CWG 2024-10-25

CWG prefers an approach suggested by Richard Smith that defines a new term "runtime undefined behavior".

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

1. Add to Clause 3 [intro.defs]:

   constant evaluation [defns.const.eval]

   evaluation that is performed as part of evaluating an expression as a core constant expression (7.7 [expr.const])

   runtime-undefined behavior [defns.undefined.runtime]

   behavior that is undefined except when it occurs during constant evaluation

   [Note 1 to entry: During constant evaluation,

   • it is implementation-defined whether runtime-undefined behavior results in the expression being deemed non-constant (as specified in 7.7 [expr.const]) and
   • runtime-undefined behavior has no other effect.]

2. Change in 7.7 [expr.const] bullet 5.8 as follows:

   • an operation that would have undefined or erroneous behavior as specified in Clause 4 [intro] through Clause 15 [cpp], excluding 9.13.3 [dcl.attr.assume] and 9.13.10 [dcl.attr.noreturn];

3. Add a paragraph after 7.7 [expr.const] paragraph 5 as follows:

   It is implementation-defined whether E is a core constant expression if E satisfies the constraints of a core constant expression, but evaluation of E has runtime-undefined behavior.

4. Change in 7.7 [expr.const] paragraph 6:

   It is unspecified whether E is a core constant expression if E satisfies the constraints of a core constant expression, but evaluation of E would evaluate

   • an operation that has undefined behavior as specified in Clause 16 [library] through Clause 33 [exec], or
   • an invocation of the va_start macro (17.14.2 [cstdarg.syn]),.
   • a call to a function that was previously declared with the noreturn attribute (9.13.10 [dcl.attr.noreturn]) and that call returns to its caller, or
   • a statement with an assumption (9.13.3 [dcl.attr.assume]) whose converted conditional-expression, if evaluated where the assumption appears, would not disqualify E from being a core constant expression and would not evaluate to true. [Note 5: E is not disqualified from being a core constant expression if the hypothetical evaluation of the converted conditional-expression would disqualify E from being a core constant expression. —end note]

5. Change in 9.13.3 [dcl.attr.assume] paragraph 1 as follows:

   ... If the converted expression would evaluate to true at the point where the assumption appears, the assumption has no effect. Otherwise, the behavior is undefined evaluation of the assumption has runtime-undefined behavior.

6. Change in 9.13.10 [dcl.attr.noreturn] paragraph 2 as follows:

   If a function f is called invoked where f was previously declared with the noreturn attribute and f that invocation eventually returns, the behavior is runtime-undefined.

2700. #error disallows existing implementation practice

[Accepted as a DR at the March, 2024 meeting.]

The resolution for issue 2518 disallows existing implementation practice, as detailed below:

• The requirement to issue a diagnostic message for each appearance of #warning conflicts with existing implementations having a diagnostic limit. Furthermore, an implementation with an on-the-fly incremental preprocessor is no longer allowed to abort the compilation when an error deemed fatal happens (e.g. a #include file that does not exist).
• The wording does not allow for implementation-specific mechanisms for creating a preprocessing translation unit, such as vendor-specific forms of #if-like directives and #pragma once.

Suggested resolution [SUPERSEDED]:

1. Change in 4.1.1 [intro.compliance.general] paragraph 2 as follows:

   Furthermore, a conforming implementation

   • shall not accept a preprocessing translation unit containing a #error preprocessing directive (15.9 [cpp.error]), and
   • 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]).

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 or by the implementation-defined behavior of any conditionally-supported-directives (15.1 [cpp.pre]), is called a preprocessing translation unit.

CWG 2023-03-03

Permit that #warning can be ignored if another diagnostic is produced.

Proposed resolution (approved by CWG 2024-01-19):

1. Change in 4.1.1 [intro.compliance.general] bullet 2.3 as follows:

   • ...
   • Otherwise, if a program contains
     • a violation of any diagnosable rule or,
     • a preprocessing translation unit with a #warning preprocessing directive (15.9 [cpp.error]), 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.

2. Change in 4.1.1 [intro.compliance.general] paragraph 2 as follows:

   Furthermore, a conforming implementation shall not accept

   • a preprocessing translation unit containing a #error preprocessing directive (15.9 [cpp.error]), or
   • 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]).

3. 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, as modified by the implementation-defined behavior of any conditionally-supported-directives (15.1 [cpp.pre]) and pragmas (15.10 [cpp.pragma]), if any, is called a preprocessing translation unit.

4. Change in 15.9 [cpp.error] as follows:

   A preprocessing directive of either of the following forms the form

   # error pp-tokensopt new-line
   

   renders the program ill-formed. A preprocessing directive of the form

   # warning pp-tokensopt new-line
   

   causes requires the implementation to produce a at least one diagnostic message for the preprocessing translation unit (4.1.1 [intro.compliance.general]) that.

   Recommended practice: Any diagnostic message caused by either of these directives should include the specified sequence of preprocessing tokens; the #error directive renders the program ill-formed.

1698. Files ending in \

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

The description of how to handle file not ending in a newline in 5.2 [lex.phases] paragraph 1, phase 2, is:

2. Each instance of a backslash character (\) immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines. Only the last backslash on any physical source line shall be eligible for being part of such a splice. If, as a result, a character sequence that matches the syntax of a universal-character-name is produced, the behavior is undefined. A source file that is not empty and that does not end in a new-line character, or that ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, shall be processed as if an additional new-line character were appended to the file.

This is not clear regarding what happens if the last character in the file is a backslash. In such a case, presumably the result of adding the newline should not be a line splice but rather a backslash preprocessing-token (that will be diagnosed as an invalid token in phase 7), but that should be spelled out.

CWG 2023-07-14

Addressed by the resolution for issue 2747.

2573. Undefined behavior when splicing results in a universal-character-name

[ Resolved by paper P2621R2 (Undefined behavior in the lexer), adopted in June, 2023. ]

(From National Body comments US 024 and US 025 on the C++20 DIS.)

Subclause 5.2 [lex.phases] bullet 1.2 specifies:

Except for splices reverted in a raw string literal, if a splice results in a character sequence that matches the syntax of a universal-character-name, the behavior is undefined.

Undefined behavior during lexing is not acceptable. The behavior ought to be well-defined, ill-formed, or conditionally-supported.

Additional notes (January, 2023):

Forwarded to SG12 with paper issue 1405, by decision of the CWG and SG12 chairs.

2747. Cannot depend on an already-deleted splice

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

(From editorial issue 4903.)

Subclause 5.2 [lex.phases] paragraph 2 specifies:

... Each sequence of a backslash character (\) immediately followed by zero or more whitespace characters other than new-line followed by a new-line character is deleted, splicing physical source lines to form logical source lines. ... A source file that is not empty and that does not end in a new-line character, or that ends in a splice, shall be processed as if an additional new-line character were appended to the file.

This is confusing, because the first sentence deletes all splices, and then the last sentence checks for a splice that has already been deleted.

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

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

... Each sequence of a backslash character (\) immediately followed by zero or more whitespace characters other than new-line followed by a new-line character is deleted, splicing physical source lines to form logical source lines. ... A source file that is not empty and that (after splicing) does not end in a new-line character, or that ends in a splice, shall be processed as if an additional new-line character were appended to the file.

CWG 2023-07-14

CWG noted that a lone backslash at the end of a file remains (in the status quo and with the proposed change) and turns into an ill-formed preprocessing-token. The wording as amended seems sufficiently clear to consider issue 1698 resolved.

2937. Grammar for preprocessing-file has no normative effect

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

(From submission #615.)

Subclause 15.1 [cpp.pre] defines the grammar production preprocessing-file, but nothing in the standard specifies that a translation unit is ill-formed if it fails to match that grammar. Similarly, translation-unit has no effect.

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

1. Change in 5.2 [lex.phases] bullet 1.4 as follows:

   • ...
   • The source file is analyzed as a preprocessing-file (15.1 [cpp.pre]). Preprocessing directives are executed, macro invocations are expanded, and _Pragma unary operator expressions are executed. A #include preprocessing directive causes the named header or source file to be processed from phase 1 through phase 4, recursively. All preprocessing directives are then deleted.
   • ...

2. Change in 5.2 [lex.phases] bullet 1.7 as follows:

   Whitespace characters separating tokens are no longer significant. Each preprocessing token is converted into a token (5.10 [lex.token]). The resulting tokens constitute a translation unit and are syntactically and semantically analyzed as a translation-unit (6.6 [basic.link]) and translated.

2574. Undefined behavior when lexing unmatched quotes

[ Resolved by paper P2621R2 (Undefined behavior in the lexer), adopted in June, 2023. ]

(From National Body comment US 027 on the C++20 DIS.)

Subclause 5.5 [lex.pptoken] paragraph 2 specifies:

If a U+0027 apostrophe or a U+0022 quotation mark character matches the last category, the behavior is undefined.

Undefined behavior during lexing is not acceptable. This ought to be ill-formed.

Additional notes (January, 2023):

Forwarded to SG12 with paper issue 1406, by decision of the CWG and SG12 chairs.

2818. Use of predefined reserved identifiers

[Accepted as a DR at the June, 2024 meeting.]

Subclause 5.11 [lex.name] paragraph 3 specifies:

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

• 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.
• Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

That implies that uses of standard-specified predefined macros (15.12 [cpp.predefined]) or feature-test macros (17.3.2 [version.syn]) make the program ill-formed. This does not appear to be the intent.

Proposed resolution (approved by CWG 2024-01-19) [SUPERSEDED]:

Change in 5.11 [lex.name] paragraph 3 and add bullets as follows:

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

• 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, except for
  • the macros specified in 15.12 [cpp.predefined],
  • the function-local predefined variable (9.6.1 [dcl.fct.def.general]), and
  • the macros and identifiers declared in the standard library as specified in Clause 17 [support] through Clause 32 [thread], and Clause Annex D [depr]. [ Note: This affects macros in 17.3.2 [version.syn], 31.13.1 [cstdio.syn], and D.11 [depr.c.macros] as well as identifiers in 17.2.2 [cstdlib.syn]. -- end note ]
• Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

CWG 2024-03-20

The exceptions should not be specified using a specific list, which might become stale in the future.

Proposed resolution (approved by CWG 2024-03-20):

Change in 5.11 [lex.name] paragraph 3 and add bullets as follows:

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

• Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter, other than those specified in this document (for example, __cplusplus (15.12 [cpp.predefined])), is reserved to the implementation for any use.
• Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

2698. Using extended integer types with z suffix

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

Subclause 5.13.2 [lex.icon] paragraph 4 specifies:

If an integer-literal cannot be represented by any type in its list and an extended integer type (6.8.2 [basic.fundamental]) can represent its value, it may have that extended integer type. If all of the types in the list for the integer-literal are signed, the extended integer type shall be signed. If all of the types in the list for the integer-literal are unsigned, the extended integer type shall be unsigned. If the list contains both signed and unsigned types, the extended integer type may be signed or unsigned. A program is ill-formed if one of its translation units contains an integer-literal that cannot be represented by any of the allowed types.

This implies that an integer-literal with a z suffix can be of extended integer type, if the literal is larger than what is representable in std::size_t.

According to the author of the paper P0330R8 (Literal Suffix for (signed) size_t) introducing the feature, this is unintentional; z should only yield std::size_t and its corresponding signed integer type.

See also the corresponding WG14 paper N2998 Literal Suffixes for size_t.

Proposed resolution (reviewed by CWG 2023-03-03, approved by CWG 2023-05-12):

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

If Except for integer-literals containing a size-suffix, if the value of an integer-literal cannot be represented by any type in its list and an extended integer type (6.8.2 [basic.fundamental]) can represent its value, it may have that extended integer type. If all of the types in the list for the integer-literal are signed, the extended integer type shall be is signed. If all of the types in the list for the integer-literal are unsigned, the extended integer type shall be is unsigned. If the list contains both signed and unsigned types, the extended integer type may be signed or unsigned. A program is ill-formed if one of its translation units contains If an integer-literal that cannot be represented by any of the allowed types, the program is ill-formed. [ Note: An integer-literal with a z or Z suffix is ill-formed if it cannot be represented by std::size_t. -- end note ]

Additional notes (February, 2023)

Alerted the chair of SG22 (C/C++ Liaison).

Forwarded to EWG at the request of the EWG chair via cplusplus/papers#1467.

EWG 2023-05-11

The "z" suffixes mean std::size_t (or its corresponding signed type) only. The proposed resolution is accepted by EWG.

2870. Combining absent encoding-prefixes

[Accepted as a DR at the June, 2024 meeting.]

(From submission #511.)

Subclause 5.13.5 [lex.string] paragraph 7 does not properly handle the case where both encoding-prefixes are absent:

The common encoding-prefix for a sequence of adjacent string-literals is determined pairwise as follows: If two string-literals have the same encoding-prefix , the common encoding-prefix is that encoding-prefix . If one string-literal has no encoding-prefix , the common encoding-prefix is that of the other string-literal. Any other combinations are ill-formed.

Possible resolution [SUPERSEDED]:

Change in 5.13.5 [lex.string] paragraph 7 as follows:

The common encoding-prefix for a sequence of adjacent string-literals is determined pairwise as follows: If two string-literals have the same encoding-prefix, the common encoding-prefix is that encoding-prefix. If one string-literal has no encoding-prefix, the common encoding-prefix is that of the other string-literal or is absent if the other string-literal has no encoding-prefix. Otherwise, both string-literals shall have the same encoding-prefix, and the common encoding-prefix is that encoding-prefix. Any other combinations are ill-formed.

CWG 2024-05-03

CWG preferred a holistic instead of a pairwise approach.

Proposed resolution (approved by CWG 2024-05-17):

Change in 5.13.5 [lex.string] paragraph 7 as follows:

The common encoding-prefix for a sequence of adjacent string-literals is determined pairwise as follows: If two string-literals have the same encoding-prefix , the common encoding-prefix is that encoding-prefix . If one string-literal has no encoding-prefix , the common encoding-prefix is that of the other string-literal. Any other combinations are ill-formed.

The string-literals in any sequence of adjacent string-literals shall have at most one unique encoding-prefix among them. The common encoding-prefix of the sequence is that encoding-prefix, if any.

2745. Dependent odr-use in generic lambdas

[Accepted as a DR at the March, 2024 meeting.]

Default template arguments of generic lambdas can refer to local variables. It is unclear whether the potential odr-use is checked when parsing the template definition or when instantiating the template.

There is wide implementation divergence.

Proposed resolution (approved by CWG 2024-03-20):

Insert a new paragraph before 6.3 [basic.def.odr] paragraph 11:

[ Example:

  void g() {
    constexpr int x = 1;
    auto lambda = [] <typename T, int = ((T)x, 0)> {};  // OK
    lambda.operator()<int, 1>();         // OK, does not consider x at all
    lambda.operator()<int>();            // OK, does not odr-use x
    lambda.operator()<const int&>();     // error: odr-uses x from a context where x is not odr-usable
  }

  void h() {
    constexpr int x = 1;
    auto lambda = [] <typename T> { (T)x; };  // OK
    lambda.operator()<int>();            // OK, does not odr-use x
    lambda.operator()<void>();           // OK, does not odr-use x
    lambda.operator()<const int&>();     // error: odr-uses x from a context where x is not odr-usable
  }

-- end example ]

Every program shall contain at least one definition of every function or variable ...

2883. Definition of "odr-usable" ignores lambda scopes

[Accepted as a DR at the June, 2024 meeting.]

(From submission #523.)

Consider:

  void f() {
    int x;
    [&] {
      return x;       // #1
    };
  }

The odr-use of x is ill-formed, because x is not odr-usable in that scope, because there is a lambda scope (6.4.5 [basic.scope.lambda]) between #1 and the definition of x.

A more involved example exhibits implementation divergence:

  struct A {
    A() = default;
    A(const A &) = delete;
    constexpr operator int() { return 42; }
  };
  void f() {
    constexpr A a;
    [=]<typename T, int = a> {};   // OK, not odr-usable from a default template argument, and not odr-used
  }

Proposed resolution (approved by CWG 2024-05-31):

Change in 6.3 [basic.def.odr] paragraph 10 as follows:

A local entity (6.1 [basic.pre]) is odr-usable in a scope (6.4.1 [basic.scope.scope]) if:

• either the local entity is not *this, or an enclosing class or non-lambda function parameter scope exists and, if the innermost such scope is a function parameter scope, it corresponds to a non-static member function, and
• for each intervening scope (6.4.1 [basic.scope.scope]) between the point at which the entity is introduced and the scope (where *this is considered to be introduced within the innermost enclosing class or non-lambda function definition scope), either:
  • the intervening scope is a block scope, or
  • the intervening scope is the function parameter scope of a lambda-expression, or
  • the intervening scope is the lambda scope of a lambda-expression that has a simple-capture naming the entity or has a capture-default, and the block scope of the lambda-expression is also an intervening scope.

If a local entity is odr-used in a scope in which it is not odr-usable, the program is ill-formed.

2910. Effect of requirement-parameter-lists on odr-usability

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

(From submission #561.)

Consider:

  bool f() {
    constexpr int z = 42;
    return requires {
      sizeof(int [*&z]);
    } && requires (int x) {
      sizeof(int [*&z]);
    };
  }

The second requires-expression introduces a function parameter scope according to 6.4.4 [basic.scope.param]. This affects odr-usability as specified in 6.3 [basic.def.odr] paragraph 10, but the two requires-expression in the example ought to actually behave the same.

Proposed resolution (approved by CWG 2024-11-19):

Change in 6.3 [basic.def.odr] bullet 10.2.2 as follows:

A local entity (6.1 [basic.pre]) is odr-usable in a scope (6.4.1 [basic.scope.scope]) if:

• ...
• for each intervening scope (6.4.1 [basic.scope.scope]) between the point at which the entity is introduced and the scope (where *this is considered to be introduced within the innermost enclosing class or non-lambda function definition scope), either:
  • the intervening scope is a block scope, or
  • the intervening scope is the function parameter scope of a lambda-expression or requires-expression, or
  • the intervening scope is the lambda scope of a lambda-expression that has a simple-capture naming the entity or has a capture-default, and the block scope of the lambda-expression is also an intervening scope.

2764. Use of placeholders affecting name mangling

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

Paper P2169R4 (A nice placeholder with no name), as approved by WG21 in Varna, added a placeholder facility. The intent was that the use of placeholders is sufficiently limited such that they never need to be mangled. Quote from 6.4.1 [basic.scope.scope] paragraph 5 as modified by the paper:

A declaration is name-independent if its name is _ and it declares a variable with automatic storage duration, a structured binding not inhabiting a namespace scope, the variable introduced by an init-capture, or a non-static data member.

The following example does not seem to follow that intent:

  struct A { A(); };
  inline void f() {
    static union { A _{}; };
    static union { A _{}; };
  }
  void g() { return f(); }

The preceding example needs handling similar to the following example, which is unrelated to the placeholder feature:

  struct A { A(); };
  inline void f() {
    { static union { A a{}; }; }
    { static union { A a{}; }; }
  }
  void g() { return f(); }

A similar problem may arise for static or thread_local structured bindings at block scope.

Finally, another example involving placeholders in anonymous unions:

  static union { int _ = 42; };
  int &ref = _;
  int foo() { return 13; }
  static union { int _ = foo(); };
  int main() { return ref; }

Possible resolution (reviewed by CWG 2023-08-25) [SUPERSEDED]:

Change in 6.4.1 [basic.scope.scope] paragraph 5 and add bullets as follows:

A class is name-dependent if it is an anonymous union declared at namespace scope or with a storage-class-specifier (11.5.2 [class.union.anon]). A declaration is name-independent if its name is _ and it declares

• a variable with automatic storage duration,
• a structured binding with no storage-class-specifier and not inhabiting a namespace scope,
• the variable introduced by an init-capture, or
• a non-static data member of other than a name-dependent class.

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

Change in 6.4.1 [basic.scope.scope] paragraph 5 and add bullets as follows:

A declaration is name-independent if its name is _ and it declares

• a variable with automatic storage duration,
• a structured binding with no storage-class-specifier and not inhabiting a namespace scope,
• the variable introduced by an init-capture, or
• a non-static data member of other than an anonymous union.

2793. Block-scope declaration conflicting with parameter name

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

Consider:

  void f(int i) { extern int i; } 

According to 6.4.3 [basic.scope.block] paragraph 2, the target scope of the declaration is relevant (which would be the global scope), but not the scope in which the name is bound. That seems wrong. For comparison, template parameter names use the latter rule (13.8.2 [temp.local] paragraph 6).

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

If a declaration that is not a name-independent declaration and whose target scope is that binds a name in the block scope S of a

• compound-statement of a lambda-expression, function-body, or function-try-block,
• substatement of a selection or iteration statement that is not itself a selection or iteration statement, or
• handler of a function-try-block

potentially conflicts with a declaration whose target scope is the parent scope of S, the program is ill-formed.

2857. Argument-dependent lookup with incomplete class types

[Accepted as a DR at the March, 2024 meeting.]

Subclause 6.5.4 [basic.lookup.argdep] bullet 3.2 specifies:

• ...
• If T is a class type (including unions), its associated entities are: the class itself; the class of which it is a member, if any; and its direct and indirect base classes. ...
• ...

It is unclear what happens if T is incomplete, for example because it was instantiated from a template whose definition was not (yet) available.

Proposed resolution (approved by CWG 2024-03-01)

Change in 6.5.4 [basic.lookup.argdep] bullet 3.2 as follows:

• ...
• If T is a class type (including unions), its associated entities are: the class itself; the class of which it is a member, if any; and, if it is a complete type, its direct and indirect base classes. ...
• ...

2872. Linkage and unclear "can be referred to"

[Accepted as a DR at the June, 2024 meeting.]

It is unclear what "can be referred to" means in 6.6 [basic.link] paragraph 2. Paragraph 8 provides precise definitions for "same entity".

Possible resolution [SUPERSEDED]:

1. Replace in 6.6 [basic.link] paragraph 2 as follows:

   A name is said to have linkage when it can denote the same object, reference, function, type, template, namespace or value as a name introduced by a declaration in another scope:

   • When a name has external linkage, the entity it denotes can be referred to by names from scopes of other translation units or from other scopes of the same translation unit.
   • When a name has module linkage, the entity it denotes can be referred to by names from other scopes of the same module unit (10.1 [module.unit]) or from scopes of other module units of that same module.
   • When a name has internal linkage, the entity it denotes can be referred to by names from other scopes in the same translation unit.
   • When a name has no linkage, the entity it denotes cannot be referred to by names from other scopes.

   A name can have external linkage, module linkage, internal linkage, or no linkage, as determined by the rules below. [ Note: The linkage of a name determines when corresponding declarations (6.4.1 [basic.scope.scope]) that introduce that name can declare the same entity. ---end note]

2. Change in 11.6 [class.local] paragraph 3 as follows:

   If class X is a local class, a nested class Y may be declared in class X and later defined in the definition of class X or be later defined in the same scope as the definition of class X. A class nested within a local class is a local class. A member of a local class X shall be declared only in the definition of X or the nearest enclosing block scope of X.

CWG 2024-05-03

CWG opined to split off the second change (see issue 2890) and clarify the note.

Proposed resolution (approved by CWG 2024-05-17):

Replace in 6.6 [basic.link] paragraph 2 as follows:

A name is said to have linkage when it can denote the same object, reference, function, type, template, namespace or value as a name introduced by a declaration in another scope:

• When a name has external linkage, the entity it denotes can be referred to by names from scopes of other translation units or from other scopes of the same translation unit.
• When a name has module linkage, the entity it denotes can be referred to by names from other scopes of the same module unit (10.1 [module.unit]) or from scopes of other module units of that same module.
• When a name has internal linkage, the entity it denotes can be referred to by names from other scopes in the same translation unit.
• When a name has no linkage, the entity it denotes cannot be referred to by names from other scopes.

A name can have external linkage, module linkage, internal linkage, or no linkage, as determined by the rules below. [ Note: All declarations of an entity with a name with internal linkage appear in the same translation unit. All declarations of an entity with module linkage are attached to the same module. ---end note]

1953. Data races and common initial sequence

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

According to 6.7.1 [intro.memory] paragraph 3,

A memory location is either an object of scalar type or a maximal sequence of adjacent bit-fields all having non-zero width. [Note: Various features of the language, such as references and virtual functions, might involve additional memory locations that are not accessible to programs but are managed by the implementation. —end note] Two or more threads of execution (6.9.2 [intro.multithread]) can update and access separate memory locations without interfering with each other.

It is not clear how this relates to the permission granted in 11.4 [class.mem] paragraph 18 to inspect the common initial sequence of standard-layout structs that are members of a standard-layout union. If one thread is writing to the common initial sequence and another is reading from it via a different struct, that should constitute a data race, but the current wording does not clearly state that.

Additional notes (October, 2024)

(From submission #621.)

A similar concern arises for the following example:

  union U { int x, y; } u;
  (u.x = 1, 0) + (u.y = 2, 0);

Possible resolution [SUPERSEDED]:

Change in 6.7.1 [intro.memory] paragraph 3 as follows:

A memory location is the storage occupied by the object representation of either an object of scalar type that is not a bit-field or a maximal sequence of adjacent bit-fields all having nonzero width. ...

CWG 2024-10-25

Subclause 6.9.1 [intro.execution] paragraph 10 does not cover unsequenced object creation that does not change any bits of storage, such as a placement new invoking a trivial default constructor. The original concern in this issue was addressed by P0137R1, adding the following in 11.4.2 [class.mfct] paragraph 28:

In a standard-layout union with an active member (11.5 [class.union]) of struct type T1, it is permitted to read a non-static data member m of another union member of struct type T2 provided m is part of the common initial sequence of T1 and T2; the behavior is as if the corresponding member of T1 were nominated.

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

1. Change in 6.7.1 [intro.memory] paragraph 3 as follows:

   A memory location is the storage occupied by the object representation of either an object of scalar type that is not a bit-field or a maximal sequence of adjacent bit-fields all having nonzero width. ...

2. Change in 6.9.1 [intro.execution] paragraph 10 and add bullets as follows:

   ... The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. If The behavior is undefined if

   • a side effect on a memory location (6.7.1 [intro.memory]) or
   • starting or ending the lifetime of an object in a memory location

   is unsequenced relative to either

   • another side effect on the same memory location,
   • starting or ending the lifetime of an object occupying storage that overlaps with the memory location, or
   • a value computation using the value of any object in the same memory location,

   and they the two evaluations are not potentially concurrent (6.9.2 [intro.multithread]) , the behavior is undefined. [ Note: Starting the lifetime of an object in a memory location can end the lifetime of objects in other memory locations (6.7.4 [basic.life]). -- end note ]

   [ Note: ... ]

   [ Example:

     void g(int i) {
       i = 7, i++, i++;     // i becomes 9
       i = i++ + 1;   // the value of i is incremented
       i = i++ + i;   // undefined behavior
       i = i + 1;     // the value of i is incremented
       union U { int x, y; } u;
       (u.x = 1, 0) + (u.y = 2, 0);   // undefined behavior
     }
   

   -- end example ]

3. Change in 6.9.2.2 [intro.races] paragraph 2 as follows, adding bullets:

   Two expression evaluations conflict if one of them

   • modifies (3.1 [defns.access]) a memory location (6.7.1 [intro.memory]) or
   • starts or ends the lifetime of an object in a memory location

   and the other one

   • reads or modifies the same memory location or
   • starts or ends the lifetime of an object occupying storage that overlaps with the memory location.

   [Note 2: A modification can still conflict even if it does not alter the value of any bits. —end note]

2753. Storage reuse for string literal objects and backing arrays

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

Subclause 6.7.2 [intro.object] paragraph 9 specifies the general principle that two objects with overlapping lifetimes have non-overlapping storage, which can be observed by comparing addresses:

Unless an object is a bit-field or a subobject of zero size, the address of that object is the address of the first byte it occupies. Two objects with overlapping lifetimes that are not bit-fields may have the same address if one is nested within the other, or if at least one is a subobject of zero size and they are of different types; otherwise, they have distinct addresses and occupy disjoint bytes of storage.

After P2752, there are two exceptions: string literal objects and backing arrays for initializer lists.

Subclause 5.13.5 [lex.string] paragraph 9 specifies:

Evaluating a string-literal results in a string literal object with static storage duration (6.7.6 [basic.stc]). Whether all string-literals are distinct (that is, are stored in nonoverlapping objects) and whether successive evaluations of a string-literal yield the same or a different object is unspecified.

Subclause 9.5.4 [dcl.init.ref] paragraph 5, after application of P2752R3 (approved in June, 2023), specifies:

Whether all backing arrays are distinct (that is, are stored in non-overlapping objects) is unspecified.

It is unclear whether a backing array can overlap with a string literal object.

Furthermore, it is unclear whether any such object can overlap with named objects or temporaries, for example:

  const char (&r) [] = "foo";
  const char a[] = {'f', 'o', 'o', '\0'};

  int main() {  
    assert(&r == &a);   // allowed not to fail?
  }

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

1. Add a new paragraph before 6.7.2 [intro.object] paragraph 9 and change the latter as follows:

   An object is a potentially non-unique object if it is a string literal object (5.13.5 [lex.string]), the backing array of an initializer list (9.5.4 [dcl.init.ref]), or a subobject thereof.

   Unless an object is a bit-field or a subobject of zero size, the address of that object is the address of the first byte it occupies. Two objects with overlapping lifetimes that are not bit-fields may have the same address if one is nested within the other, or if at least one is a subobject of zero size and they are of different types, or if they are both potentially non-unique objects; otherwise, they have distinct addresses and occupy disjoint bytes of storage.

   [Example 2:

     static const char test1 = 'x';
     static const char test2 = 'x';
     const bool b = &test1 != &test2;  // always true
   
     static const char (&r) [] = "x";
     static const char *s = "x";  
     static std::initializer_list<char> il = { 'x' };
     const bool b2 = r != il.begin();        // unspecified result
     const bool b3 = r != s;                 // unspecified result
     const bool b4 = il.begin() != &test1;   // always true
     const bool b5 = r != &test1;            // always true
   

   -- end example]

2. Change in subclause 5.13.5 [lex.string] paragraph 9 as follows:

   Evaluating a string-literal results in a string literal object with static storage duration (6.7.6 [basic.stc]). [ Note: String literal objects are potentially non-unique (6.7.2 [intro.object]). Whether all string-literals are distinct (that is, are stored in nonoverlapping objects) and whether successive evaluations of a string-literal yield the same or a different object is unspecified. -- end note ]

3. Change in subclause 9.5.4 [dcl.init.ref] paragraph 5, after application of P2752R3 (approved in June, 2023), as follows:

   Whether all backing arrays are distinct (that is, are stored in non-overlapping objects) is unspecified. [ Note: Backing arrays are potentially non-unique objects (6.7.2 [intro.object]). -- end note ]

CWG 2023-07-14

CWG resolved that a named or temporary object is always disjoint from any other object, and thus cannot overlap with a string literal object or a backing array. The lines b4 and b5 in the example highlight that outcome.

Backing arrays and string literals can arbitrarily overlap among themselves; CWG believes the proposed wording achieves that outcome.

The ancillary question how address comparisons between potentially non-unique objects are treated during constant evaluation is handled in issue 2765.

2795. Overlapping empty subobjects with different cv-qualification

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

Subclause 6.7.2 [intro.object] paragraph 9 specifies:

... Two objects with overlapping lifetimes that are not bit-fields may have the same address if one is nested within the other, or if at least one is a subobject of zero size and they are of different types; otherwise, they have distinct addresses and occupy disjoint bytes of storage. [ Footnote: ... ]

Types T and const T are different types, but it is unlikely the rule is intending to differentiate along that line.

Suggested resolution [SUPERSEDED]:

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

... Two objects with overlapping lifetimes that are not bit-fields may have the same address if one is nested within the other, or if at least one is a subobject of zero size and they are of different types (ignoring top-level cv-qualifiers); otherwise, they have distinct addresses and occupy disjoint bytes of storage. [ Footnote: ... ]

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

(Hypothetically, pointer-to-member types can be empty, but might differ in non-top-level cv-qualification.)

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

... Two objects with overlapping lifetimes that are not bit-fields may have the same address if one is nested within the other, or if at least one is a subobject of zero size and they are not of different similar types (7.3.6 [conv.qual]); otherwise, they have distinct addresses and occupy disjoint bytes of storage. [ Footnote: ... ]

2719. Creating objects in misaligned storage

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

A non-allocating form of operator new can be used to create an object in storage that is not suitably aligned for the type of the object. Such attempts ought to be undefined behavior.

Proposed resolution (approved by CWG 2023-04-28):

1. Change in 6.7.3 [basic.align] paragraph 1 as follows:

   Object types have alignment requirements (6.8.2 [basic.fundamental], 6.8.4 [basic.compound]) which place restrictions on the addresses at which an object of that type may be allocated. An alignment is an implementation-defined integer value representing the number of bytes between successive addresses at which a given object can be allocated. An object type imposes an alignment requirement on every object of that type; stricter alignment can be requested using the alignment specifier (9.13.2 [dcl.align]). Attempting to create an object (6.7.2 [intro.object]) in storage that does not meet the alignment requirements of the object's type is undefined behavior.

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

   [Note 11: When the allocation function returns a value other than null, it must be a pointer to a block of storage in which space for the object has been reserved. The block of storage is assumed to be appropriately aligned (6.7.3 [basic.align]) and of the requested size. The address of the created object will not necessarily be the same as that of the block if the object is an array. —end note]

2721. When exactly is storage reused?

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

Subclause 6.7.4 [basic.life] bullet 1.5 specifies:

The lifetime of an object o of type T ends when:

• if T is a non-class type, the object is destroyed, or
• if T is a class type, the destructor call starts, or
• the storage which the object occupies is released, or is reused by an object that is not nested within o (6.7.2 [intro.object]).

Consider the expression new (p) T(x). Does the lifetime of *p end when p is returned from the allocation function, before x is evaluated? Or does the lifetime end when the constructor body starts executing, after x is evaluated?

The second option is conceivable for initialization by constructor and non-class types; for aggregate initialization, the first option must be used, because evaluation of x directly initializes a part of the resulting object. The first option is simpler to implement for constant evaluation.

Proposed resolution (approved by CWG 2023-05-12):

Change in 6.7.4 [basic.life] paragraph 1 as follows:

The lifetime of an object o of type T ends when:

• if T is a non-class type, the object is destroyed, or
• if T is a class type, the destructor call starts, or
• the storage which the object occupies is released, or is reused by an object that is not nested within o (6.7.2 [intro.object]).

When evaluating a new-expression, storage is considered reused after it is returned from the allocation function, but before the evaluation of the new-initializer (7.6.2.8 [expr.new]). [ Example:

  struct S {
    int m;
  };

  void f() {
    S x{1};
    new(&x) S(x.m);  // undefined behavior
  }

-- end example ]

1997. Placement new and previous initialization

Given the following example,

  #include <new>

  int main() {
    unsigned char buf[sizeof(int)] = {};
    int *ip = new (buf) int;
    return *ip; // 0 or undefined?
  }

Should the preceding initializsation of the buffer carry over to the value of *ip? According to 6.7.5 [basic.indet] paragraph 1,

When storage for an object with automatic or dynamic storage duration is obtained, the object has an indeterminate value, and if no initialization is performed for the object, that object retains an indeterminate value until that value is replaced (7.6.19 [expr.assign]).

In this case, no new storage is being obtained for the int object created by the new-expression.

Additional notes (August, 2024)

According to the resolution of issue 2721, storage for the elements of buf is considered reused and thus the lifetime of those elements ends when the allocation function returns. Out-of-lifetime objects cannot hold values.

2533. Storage duration of implicitly created objects

[Accepted as a DR at the March, 2024 meeting.]

In subclause 6.7.2 [intro.object] paragraph 10, operations implicitly creating objects are defined:

Some operations are described as implicitly creating objects within a specified region of storage. For each operation that is specified as implicitly creating objects, that operation implicitly creates and starts the lifetime of zero or more objects of implicit-lifetime types (6.8.1 [basic.types.general]) in its specified region of storage if...

However, the standard does not specify the storage duration that such an implicitly-created object has; this new method of object creation is not mentioned in 6.7.6.1 [basic.stc.general] paragraph 2:

Static, thread, and automatic storage durations are associated with objects introduced by declarations (6.2 [basic.def]) and implicitly created by the implementation (6.7.7 [class.temporary]). The dynamic storage duration is associated with objects created by a new-expression (7.6.2.8 [expr.new]).

With the exception of malloc, the storage duration should probably be that of the object providing storage (if any), similar to the provision for subobjects in 6.7.6.1 [basic.stc.general]:

The storage duration of subobjects and reference members is that of their complete object (6.7.2 [intro.object]).

The storage duration of an object created by a non-allocating form of an allocation function (17.6.3.4 [new.delete.placement]) should be treated similarly.

Possible resolution [SUPERSEDED]:

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

   Any implicit or explicit invocation of a function named operator new or operator new[] implicitly creates objects with dynamic storage duration in the returned region of storage and returns a pointer to a suitable created object.

2. Change in 6.7.6.1 [basic.stc.general] paragraph 2 as follows:

   Static, thread, and automatic storage durations are associated with objects introduced by declarations (6.2 [basic.def]) and implicitly created by the implementation (6.7.7 [class.temporary]). The dynamic storage duration is associated with objects created by a new-expression (7.6.2.8 [expr.new]) in storage returned by an allocation function (6.7.6.5.2 [basic.stc.dynamic.allocation]) other than a non-allocating form (17.6.3.4 [new.delete.placement]) or by C library memory allocation (20.2.12 [c.malloc]).

3. Change in 6.7.6.5.2 [basic.stc.dynamic.allocation] paragraph 3 as follows:

   For an allocation function other than a reserved placement allocation function other than a non-allocating form (17.6.3.4 [new.delete.placement]), the pointer returned on a successful call shall represent the address of storage that is aligned as follows:

4. Change in 6.7.6.1 [basic.stc.general] paragraph 1 as follows:

   The storage duration of subobjects and reference members is that of their complete object. The storage duration of an object nested within another object x is the storage duration of x (6.7.2 [intro.object]).

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

   An object created by a new-expression that invokes an allocation function with a non-allocating form (see below) has the storage duration of the object that used to occupy the region of storage where the new object is created. Objects Any other object created by a new-expression have has dynamic storage duration (6.7.6.5 [basic.stc.dynamic]). [Note 5: The lifetime of such an object is not necessarily restricted to the scope in which it is created. —end note]

6. Change in 20.2.12 [c.malloc] paragraph 4 as follows:

   These functions implicitly create objects (6.7.2 [intro.object]) with dynamic storage duration in the returned region of storage and return a pointer to a suitable created object. In the case of calloc and realloc, the objects are created before the storage is zeroed or copied, respectively.

Additional note (December, 2023)

The approach outlined above is incomplete and the wrong direction. The concept of storage duration determines when an object is created and destroyed; for dynamic storage duration, the object is created and destroyed by explicit program action.

Proposed resolution (approved by CWG 2024-01-19):

1. Change in 6.7.6.1 [basic.stc.general] paragraph 2 as follows:

   Static, thread, and automatic storage durations are associated with objects introduced by declarations (6.2 [basic.def]) and implicitly created by the implementation with temporary objects (6.7.7 [class.temporary]). The dynamic storage duration is associated with objects created by a new-expression (7.6.2.8 [expr.new]) or with implicitly created objects (6.7.2 [intro.object]).

2850. Unclear storage duration for function parameter objects

[Accepted as a DR at the March, 2024 meeting.]

(From submission #490.)

Function parameter objects have automatic storage duration and are not temporary objects (see also issue 2849). However, it is unclear how long the storage for function parameter objects lasts.

Furthermore, for temporary objects that are destroyed at the end of the full-expression, it is unclear how the destruction is ordered with respect to temporary objects destroyed at the end of the full-expression.

Proposed resolution (approved by CWG 2024-03-20):

1. Change in and combine 6.7.6.4 [basic.stc.auto] paragraph 1 and 2 as follows:

   Variables that belong to a block or parameter scope and are not explicitly declared static, thread_local, or extern have automatic storage duration. The storage for these entitiessuch variables lasts until the block in which they are created exits. [Note 1: These variables are initialized and destroyed as described in 8.8 [stmt.dcl]. -- end note]

   Variables that belong to a parameter scope also have automatic storage duration. The storage for a function parameter lasts until immediately after its destruction (7.6.1.3 [expr.call]).

2. Change in 6.7.7 [class.temporary] paragraph 8 as follows:

   The destruction of a temporary whose lifetime is not extended beyond the full-expression in which it was created is sequenced before the destruction of every temporary which is constructed earlier in the same full-expression. Let x and y each be either a temporary object whose lifetime is not extended, or a function parameter. If the lifetimes of x and y end at the end of the same full-expression, and x is initialized before y, then the destruction of y is sequenced before that of x. If the lifetime of two or more temporaries with lifetimes extending beyond the full-expressions in which they were created ends at the same point, these temporaries are destroyed at that point in the reverse order of the completion of their construction. In addition, the destruction of such temporaries shall take into account the ordering of destruction of objects with static, thread, or automatic storage duration (6.7.6.2 [basic.stc.static], 6.7.6.3 [basic.stc.thread], 6.7.6.4 [basic.stc.auto]); that is, if obj1 is an object with the same storage duration as the temporary and created before the temporary is created the temporary shall be destroyed before obj1 is destroyed; if obj2 is an object with the same storage duration as the temporary and created after the temporary is created the temporary shall be destroyed after obj2 is destroyed.

3. Change in 7.6.1.3 [expr.call] paragraph 6 as follows:

   ... It is implementation-defined whether the lifetime of a parameter ends is destroyed when the function in which it is defined returns exits (8.7.4 [stmt.return], 14.3 [except.ctor]) or at the end of the enclosing full-expression; parameters are always destroyed in the reverse order of their construction. The initialization and destruction of each parameter occurs within the context of the full-expression (6.9.1 [intro.execution]) where the function call appears.

4. Change in 8.9 [stmt.dcl] paragraph 2 as follows:

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

2822. Side-effect-free pointer zap

[Accepted as a DR at the March, 2024 meeting.]

Subclause 6.7.6.1 [basic.stc.general] paragraph 4 seems to suggest that the end of duration of a region of storage causes actual modifications to pointer objects, causing questions about data races (in the abstract machine).

Proposed resolution (approved by CWG 2024-03-20):

1. Append to 6.7.6.1 [basic.stc.general] paragraph 1:

   [ Note: After the duration of a region of storage has ended, the use of pointers to that region of storage is limited (6.8.4 [basic.compound]). -- end note ]

2. Remove 6.7.6.1 [basic.stc.general] paragraph 4 as follows:

   When the end of the duration of a region of storage is reached, the values of all pointers representing the address of any part of that region of storage become invalid pointer values (6.8.4 [basic.compound]). Indirection through an invalid pointer value and passing an invalid pointer value to a deallocation function have undefined behavior. Any other use of an invalid pointer value has implementation-defined behavior. [ Footnote: ... ]

3. Change in 6.8.4 [basic.compound] paragraph 3 as follows:

   [Note 2: A pointer past the end of an object (7.6.6 [expr.add]) is not considered to point to an unrelated object of the object's type, even if the unrelated object is located at that address. A pointer value becomes invalid when the storage it denotes reaches the end of its storage duration; see 6.7.6 [basic.stc]. —end note]

4. Insert a new paragraph after 6.8.4 [basic.compound] paragraph 3:

   A pointer value P is valid in the context of an evaluation E if P is a null pointer value, or if it is a pointer to or past the end of an object O and E happens before the end of the duration of the region of storage for O. If a pointer value P is used in an evaluation E and P is not valid in the context of E, then the behavior is undefined if E is an indirection (7.6.2.2 [expr.unary.op]) or an invocation of a deallocation function (6.7.6.5.3 [basic.stc.dynamic.deallocation]), and implementation-defined otherwise. [ Footnote: Some implementations might define that copying such a pointer value causes a system-generated runtime fault. -- end footnote ] [ Note: P can be valid in the context of E even if it points to a type unrelated to that of O or if O is not within its lifetime, although further restrictions apply to such pointer values (6.7.4 [basic.life], 7.2.1 [basic.lval], 7.6.6 [expr.add]). —end note]

5. Change in 7.6.1.9 [expr.static.cast] paragraph 14 as follows:

   ... If the original pointer value represents the address A of a byte in memory and A does not satisfy the alignment requirement of T, then the resulting pointer value (6.8.4 [basic.compound]) is unspecified. ...

6. Change in 7.6.1.10 [expr.reinterpret.cast] paragraph 5 as follows:

   A value of integral type or enumeration type can be explicitly converted to a pointer. A pointer converted to an integer of sufficient size (if any such exists on the implementation) and back to the same pointer type will have its original value (6.8.4 [basic.compound]); mappings between pointers and integers are otherwise implementation-defined.

2849. Parameter objects are not temporary objects

[Accepted as a DR at the March, 2024 meeting.]

(From submission #490.)

Parameter objects are not temporary objects, according to 6.7.7 [class.temporary] paragraph 1. An exception hinting at this in 6.7.7 [class.temporary] paragraph 7 should be removed.

Proposed resolution (approved by CWG 2024-02-02):

Change in 6.7.7 [class.temporary] paragraph 7 as follows:

The fourth context is when a temporary object other than a function parameter object is created in the for-range-initializer of a range-based for statement. If such a temporary object would otherwise be destroyed at the end of the for-range-initializer full-expression, the object persists for the lifetime of the reference initialized by the for-range-initializer.

2886. Temporaries and trivial potentially-throwing special member functions

[Accepted as a DR at the June, 2024 meeting.]

(From submission #531.)

Paper P1286R2 (Contra CWG DR1778) allowed trivial potentially-throwing special member functions. Whether such a trivial special member function is actually invoked is thus observable via the noexcept operator. Issue 2820 clarified the situation for value-initialization and removed a special case for a trivial default constructor.

Subclause 6.7.7 [class.temporary] paragraph 4 appears to normatively avoid invoking a trivial constructor or destructor, something best left to the as-if rule. There is implementation divergence for this example:

  struct C {
    C() = default;
    ~C() noexcept(false) = default;
  };

  static_assert(noexcept(C()));

A related question arises from the introduction of temporaries for function parameters and return values in 6.7.7 [class.temporary] paragraph 3. However, this situation can never result in actually throwing an exception during forward evolution: when the constructor becomes non-trivial, the permission to create a temporary object evaporates.

Proposed resolution (approved by CWG 2024-05-31):

1. Change in 6.7.7 [class.temporary] paragraph 3 as follows:

   When an object of class type X is passed to or returned from a potentially-evaluated function call, if X has at least one eligible copy or move constructor (11.4.4 [special]), each such constructor is trivial, and the destructor of X is either trivial or deleted, implementations are permitted to create a temporary object to hold the function parameter or result object. The temporary object is constructed from the function argument or return value, respectively, and the function's parameter or return object is initialized as if by using the eligible trivial constructor to copy the temporary (even if that constructor is inaccessible or would not be selected by overload resolution to perform a copy or move of the object).

2. Change in 6.7.7 [class.temporary] paragraph 4 as follows:

   When an implementation introduces a temporary object of a class that has a non-trivial constructor (11.4.5.2 [class.default.ctor], 11.4.5.3 [class.copy.ctor]), it shall ensure that a constructor is called for the temporary object. Similarly, the destructor shall be called for a temporary with a non-trivial destructor (11.4.7 [class.dtor]). Temporary objects are destroyed as the last step in evaluating the full-expression (6.9.1 [intro.execution]) that (lexically) contains the point where they were created. This is true even if that evaluation ends in throwing an exception. The value computations and side effects of destroying a temporary object are associated only with the full-expression, not with any specific subexpression.

2519. Object representation of a bit-field

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

6.7.2 [intro.object] clearly implies that bit-fields are objects; paragraphs 8-9 contain phrases like “unless an object is a bit-field...” and “a non-bit-field subobject”. However, the definition of “object representation” in 6.8.1 [basic.types.general] paragraph 4 is,

The object representation of an object of type T is the sequence of N unsigned char objects taken up by the object of type T, where N equals sizeof(T).

and thus fails to address bit-fields, which are not necessarily composed of a sequence of complete bytes.

The C Standard (6.2.6.1 paragraph 4) says,

Values stored in bit-fields consist of m bits, where m is the size specified for the bit-field. The object representation is the set of m bits the bit-field comprises in the addressable storage unit holding it.

Presumably similar wording could be adopted for C++.

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

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

The object representation of an object of a type T is the sequence of N unsigned char objects taken up by the a non-bit-field complete object of type T, where N equals sizeof(T). The value representation of an object of a type T is the set of bits in the object representation of T that participate in representing a value of type T. The object and value representation of a non-bit-field complete object of type T are the bytes and bits, respectively, of the object corresponding to the object and value representation of its type. The object representation of a bit-field object is the sequence of N bits taken up by the object, where N is the width of the bit-field (11.4.10 [class.bit]). The value representation of a bit-field object is the set of bits in the object representation that participate in representing its value. Bits in the object representation of a type or object that are not part of the value representation are padding bits. For trivially copyable types, the value representation is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-defined set of values. [ Footnote: ... ]

CWG 2023-02-06

Additional drafting is needed to constrain the definition to complete object types.

Proposed resolution (approved for C++26 by CWG 2023-02-06):

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

The object representation of an object of a complete object type T is the sequence of N unsigned char objects taken up by the a non-bit-field complete object of type T, where N equals sizeof(T). The value representation of an object of a type T is the set of bits in the object representation of T that participate in representing a value of type T. The object and value representation of a non-bit-field complete object of type T are the bytes and bits, respectively, of the object corresponding to the object and value representation of its type. The object representation of a bit-field object is the sequence of N bits taken up by the object, where N is the width of the bit-field (11.4.10 [class.bit]). The value representation of a bit-field object is the set of bits in the object representation that participate in representing its value. Bits in the object representation of a type or object that are not part of the value representation are padding bits. For trivially copyable types, the value representation is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-defined set of values. [ Footnote: ... ]

2689. Are cv-qualified std::nullptr_t fundamental types?

[Accepted as a DR at the March, 2024 meeting.]

It is unclear whether cv std::nullptr_t is a fundamental type, given that it is declared in a library header and cv-qualifications are not mentioned in 6.8.2 [basic.fundamental] paragraph 15.

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

Change in 6.8.2 [basic.fundamental] paragraph 15 as follows:

The types denoted by cv std::nullptr_t are distinct types. A value of type std::nullptr_t is a null pointer constant (7.3.12 [conv.ptr]). Such values participate in the pointer and the pointer-to-member conversions (7.3.12 [conv.ptr], 7.3.13 [conv.mem]). sizeof(std::nullptr_t) shall be equal to sizeof(void*).

The types described in this subclause are called fundamental types. [Note 11: Even if the implementation defines two or more fundamental types to have the same value representation, they are nevertheless different types. —end note]

2723. Range of representable values for floating-point types

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

The range of representable values is defined for integer types, but not for floating-point types. This term is used in 5.13.4 [lex.fcon] paragraph 3 as well as in the library, e.g. in 28.2.3 [charconv.from.chars] and 28.3.4.3.2.3 [facet.num.get.virtuals].

The C standard contains a suitable definition that we should inherit.

Proposed resolution (approved by CWG 2023-05-12):

Add a new paragraph after 6.8.2 [basic.fundamental] paragraph 12 as follows:

... Except as specified in 6.8.3 [basic.extended.fp], the object and value representations and accuracy of operations of floating-point types are implementation-defined.

The minimum range of representable values for a floating-point type is the most negative finite floating-point number representable in that type through the most positive finite floating-point number representable in that type. In addition, if negative infinity is representable in a type, the range of that type is extended to all negative real numbers; likewise, if positive infinity is representable in a type, the range of that type is extended to all positive real numbers. [ Note: Since negative and positive infinity are representable in ISO/IEC/IEEE 60559 formats, all real numbers lie within the range of representable values of a floating-point type adhering to ISO/IEC/IEEE 60559. ]

2836. Conversion rank of long double and extended floating-point types

[Accepted as a DR at the June, 2024 meeting.]

Consider:

  auto f(long double x, std::float64_t y) {
    return x + y;
  }

What is the return type of f?

Suppose an implementation uses the same size and semantics for all of double, long double, and std::float64_t. C23 prefers the IEEE interchange type (i.e. std::float64_t) over long double and double. In contrast, C++ chooses long double, which has a higher rank than double, but std::float64_t is specified to have the same rank as double.

This outcome conflicts with the documented goal of P1467 that C++ and C conversion rules be aligned.

Suggested resolution [SUPERSEDED]:

Change in 6.8.6 [conv.rank] bullet 2.5 as follows:

• ...
• An extended floating-point type with the same set of values as more than one cv-unqualified standard floating-point type has a rank equal to the highest rank of double among such types.

Additional notes (December, 2023)

The suggested resolution would make a conversion from std::float64_t to double not implicit, which is not desirable.

David Olsen, one of the authors of P1467, asserts that the deviation from C is intentional, and was discussed with the C floating-point study group.

Forwarding to EWG via paper issue 1699 to confirm that the deviation from C is intentional and thus an Annex C entry should be created.

EWG 2024-03-18

This issue should be closed as NAD.

Possible resolution [SUPERSEDED]:

Add a new paragraph in C.7.3 [diff.basic] as follows:

Affected subclause: 6.8.6 [conv.rank]
Change: Conversion rank of same-sized long double vs. std::float64_t
Rationale: Provide implicit conversion from std::float64_t to double.
Effect on original feature: Change of semantically well-defined feature.
Difficulty of converting: Trivial: explicitly convert to the desired type.
How widely used: Rarely.

CWG 2024-04-19

The name std::float64_t is not valid C. CWG resolved to adding a note to 6.8.6 [conv.rank] bullet 2.5 instead.

Proposed resolution (approved by CWG 2024-06-26):

Change in 6.8.6 [conv.rank] bullet 2.5 as follows:

• ...
• An extended floating-point type with the same set of values as more than one cv-unqualified standard floating-point type has a rank equal to the rank of double. [ Note: The treatment of std::float64_t differs from that of the analoguous _Float64 in C, for example on platforms where all of long double, double, and std::float64_t have the same set of values (see ISO/IEC 9899:2024 H.4.2). -- end note ]

2811. Clarify "use" of main

[Accepted as a DR at the March, 2024 meeting.]

Subclause 6.9.3.1 [basic.start.main] paragraph 3 specifies:

The function main shall not be used within a program. ...

It is unclear what "use" means. N3214 excluded this appearance from the clarifications of "use" that were turned into "odr-use". For example, it is unclear whether decltype(main) is allowed or not.

CWG 2023-12-01

CWG favored to ban any mention of main.

Proposed resolution (approved by CWG 2023-12-15):

Change in 6.9.3.1 [basic.start.main] paragraph 3 as follows:

The function main shall not be used within a program named by an expression. ...

2901. Unclear semantics for near-match aliased access

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

(From submission #548.)

Subclause 7.2.1 [basic.lval] paragraph 11 specifies:

... If a program attempts to access (3.1 [defns.access]) the stored value of an object through a glvalue through which it is not type-accessible, the behavior is undefined. ...

Thus, access (read or write) to an int object using an lvalue of type unsigned int is valid. However, 7.3.2 [conv.lval] bullet 3.4 does not specify the resulting value when, for example, the object contains the value -1:

• Otherwise, the object indicated by the glvalue is read (3.1 [defns.access]), and the value contained in the object is the prvalue result. ...

Similarly, 7.6.19 [expr.assign] paragraph 2 is silent for the assignment case:

In simple assignment (=), the object referred to by the left operand is modified (3.1 [defns.access]) by replacing its value with the result of the right operand.

Any concerns about accesses to the object representation are handled in the context of P1839.

Proposed resolution (approved by CWG 2024-09-13):

1. Change in 7.3.2 [conv.lval] bullet 3.4 as follows:

   • Otherwise, the object indicated by the glvalue is read (3.1 [defns.access]), and the value contained in the object is the prvalue result. Let V be the value contained in the object. If T is an integer type, the prvalue result is the value of type T congruent (6.8.2 [basic.fundamental]) to V, and V otherwise. ...

2. Change in 7.6.1.6 [expr.post.incr] paragraph 1 as follows:

   The value of a postfix ++ expression is the value of obtained by applying the lvalue-to-rvalue conversion (7.3.2 [conv.lval]) to its operand. [Note 1: The value obtained is a copy of the original value. —end note] ...

3. Change in 7.6.19 [expr.assign] paragraph 2 as follows:

   In simple assignment (=), let V be the result of the right operand; the object referred to by the left operand is modified (3.1 [defns.access]) by replacing its value with the result of the right operand V or, if the object is of integer type, with the value congruent (6.8.2 [basic.fundamental]) to V.

2933. Dangling references

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

Issue 453 clarified that there are no empty lvalues, and undefined behavior ensues when trying to create one. However, the wording now does not specify the behavior of dangling references, where the storage of the referenced object has gone away.

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

1. Change in 6.8.2 [basic.fundamental] paragraph 4 as follows:

   A pointer value P is valid in the context of an evaluation E if P is a pointer to function or a null pointer value, or if it is a pointer to or past the end of an object O and E happens before the end of the duration of the region of storage for O. If a pointer value P is used in an evaluation E and P is not valid in the context of E, then ...

2. Change in 7.2.2 [expr.type] paragraph 1 as follows:

   If an expression initially has the type “reference to T” (9.3.4.3 [dcl.ref], 9.5.4 [dcl.init.ref]), the type is adjusted to T prior to any further analysis; the value category of the expression is not altered. The expression designates Let X be the object or function denoted by the reference, and the expression is an lvalue or an xvalue, depending on the expression. If a pointer to X would be valid in the context of the evalution of the expression (6.8.2 [basic.fundamental]), the result designates X; otherwise, the behavior is undefined.

2899. Bad value representations should cause undefined behavior

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

(From editorial issue #7051.)

Consider:

static_assert(sizeof(bool) == 1);  // assumption for the example
bool f() {
  char c = 2;
  bool b = true;
  memcpy(&b, &c, 1);     // #1
  return b;              // #2
}

Assuming that false and true are represented as 0 and 1, the value representation of b now has a bad value. This should, but does not, result in undefined behavior during the lvalue-to-rvalue conversion at #2.

Proposed resolution (approved by CWG 2024-08-16):

Change in 7.3.2 [conv.lval] paragraph 3 as follows:

The result of the conversion is determined according to the following rules:

• If T is cv std::nullptr_t, the result is a null pointer constant (7.3.12 [conv.ptr]). [Note 1: Since the conversion does not access the object to which the glvalue refers, there is no side effect even if T is volatile-qualified (6.9.1 [intro.execution]), and the glvalue can refer to an inactive member of a union (11.5 [class.union]). —end note]
• Otherwise, if T has a class type, the conversion copy-initializes the result object from the glvalue.
• Otherwise, if the object to which the glvalue refers contains an invalid pointer value (6.7.6.5.3 [basic.stc.dynamic.deallocation]), the behavior is implementation-defined.
• Otherwise, if the bits in the value representation of the object to which the glvalue refers are not valid for the object's type, the behavior is undefined. [ Example:

  bool f() {
    bool b = true;
    char c = 42;
    memcpy(&b, &c, 1);
    return b;           // undefined behavior if 42 is not a valid value representation for bool
  }
  

  -- end example ]
• Otherwise, the object indicated by the glvalue is read (3.1 [defns.access]), and the value contained in the object is the prvalue result. If the result is an erroneous value (6.7.5 [basic.indet]) and the bits in the value representation are not valid for the object's type, the behavior is undefined.

2485. Bit-fields in integral promotions

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

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 an enumerated type, it is treated as any other value of that type for promotion purposes.

This description has several problems. First, the “bit-field” semantic property only makes sense for glvalue expressions, so it's unclear why these rules are described as applying to a prvalue. Perhaps this should be rephrased as something like “An expression that was a bit-field glvalue prior to the application of the lvalue-to-rvalue conversion”?

Second, suppose that char32_t is wider than int. Per paragraph 2, a char32_t prvalue promotes to unsigned long (because unsigned long is necessarily at least 32 bits wide). But per paragraph 5, a char32_t : 32 bitfield does not promote. This seems inconsistent.

Finally, it is not clear that the usual integral promotions are not applied to bit-fields. This should be made explicit.

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

1. Insert a paragraph before 7.3.7 [conv.prom] paragraph 1 as follows:

   For the purposes of 7.3.7 [conv.prom], a converted bit-field is a prvalue that is the result of an lvalue-to-rvalue conversion (7.3.2 [conv.lval]) applied to a bit-field (11.4.10 [class.bit]).

2. Change in 7.3.7 [conv.prom] paragraph 1 as follows:

   A prvalue of that is not a converted bit-field and has an integer type other than bool, char8_t, char16_t, char32_t, or wchar_t whose integer conversion rank (6.8.6 [conv.rank]) is less than the rank of int can be converted to a prvalue of type int if int can represent all the values of the source type; otherwise, the source prvalue can be converted to a prvalue of type unsigned int.

3. Change in 7.3.7 [conv.prom] paragraph 4 as follows:

   A prvalue of an unscoped enumeration type whose underlying type is fixed (9.8.1 [dcl.enum]) can be converted to a prvalue of its underlying type. Moreover, if integral promotion can be applied to its underlying type, a prvalue of an unscoped enumeration type whose underlying type is fixed can also be converted to a prvalue of the promoted underlying type. [ Note: A converted bit-field of enumeration type is treated as any other value of that type for promotion purposes. -- end note ]

4. Change in 7.3.7 [conv.prom] paragraph 5 as follows:

   A prvalue for an integral bit-field (11.4.10 [class.bit]) converted bit-field of integral type 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.

5. Move 7.3.7 [conv.prom] paragraph 2 after paragraph 5 and change as follows:

   A prvalue of type char8_t, char16_t, char32_t, or wchar_t (6.8.2 [basic.fundamental]) (including a converted bit-field that was not already promoted to int or unsigned int according to the rules above) can be converted to a prvalue of the first of the following types that can represent all the values of its underlying type: int, unsigned int, long int, unsigned long int, long long int, or unsigned long long int. If none of the types in that list can represent all the values of its underlying type, a prvalue of type char8_t, char16_t, char32_t, or wchar_t can be converted to a prvalue of , or its underlying type.

170. Pointer-to-member conversions

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

The descriptions of explicit (7.6.1.9 [expr.static.cast] paragraph 9) and implicit (7.3.13 [conv.mem] paragraph 2) pointer-to-member conversions differ in two significant ways:

1. In a static_cast, a conversion in which the class in the target pointer-to-member type is a base of the class in which the member is declared is permitted and required to work correctly, as long as the resulting pointer-to-member is eventually dereferenced with an object whose dynamic type contains the member. That is, the class of the target pointer-to-member type is not required to contain the member referred to by the value being converted. The specification of implicit pointer-to-member conversion is silent on this question.

   (This situation cannot arise in an implicit pointer-to-member conversion where the source value is something like &X::f, since you can only implicitly convert from pointer-to-base-member to pointer-to-derived-member. However, if the source value is the result of an explicit "up-cast," the target type of the conversion might still not contain the member referred to by the source value.)

2. The target type in a static_cast is allowed to be more cv-qualified than the source type; in an implicit conversion, however, the cv-qualifications of the two types are required to be identical.

The first difference seems like an oversight. It is not clear whether the latter difference is intentional or not.

(See also issue 794.)

CWG 2022-11-09

The second concern is NAD; implicit conversions allow chaining a pointer-to-member conversion with a qualification conversion.

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

1. Change in 7.3.13 [conv.mem] paragraph 2 as follows:

   A prvalue of type “pointer to member of B of type cv T”, where B is a class type, can be converted to a prvalue of type “pointer to member of D of type cv T”, where D is a complete class derived (11.7 [class.derived]) from B. If B is an inaccessible (11.8 [class.access]), ambiguous (6.5.2 [class.member.lookup]), or virtual (11.7.2 [class.mi]) base class of D, or a base class of a virtual base class of D, a program that necessitates this conversion is ill-formed. If class D does not contain the original member and is not a base class of the class containing the original member, the behavior is undefined. Otherwise, The the result of the conversion refers to the same member as the pointer to member before the conversion took place, but it refers to the base class member as if it were a member of the derived class. The result refers to the member in D's instance of B. Since the result has type “pointer to member of D of type cv T”, indirection through it with a D object is valid. The result is the same as if indirecting through the pointer to member of B with the B subobject of D. The null member pointer value is converted to the null member pointer value of the destination type. [ Footnote: ... ]

2. Change in 7.6.1.9 [expr.static.cast] paragraph 13 as follows:

   ... If class B contains the original member, or is a base or derived class of the class containing the original member, the resulting pointer to member points to the original member. ...

2892. Unclear usual arithmetic conversions

[Accepted as a DR at the June, 2024 meeting.]

(From submission #533.)

Subclause 7.4 [expr.arith.conv] bullet 1.4.1 specifies:

• If both operands have the same type, no further conversion is needed.

What does "needed" mean?

Proposed resolution (approved by CWG 2024-05-31):

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

• If both operands have the same type, no further conversion is needed performed.

2869. this in local classes

[Accepted as a DR at the June, 2024 meeting.]

(From submission #515.)

Consider:

  struct A {
    static void f() {
      struct B {
        void *g() { return this; }
       };
     }
  };

According to 7.5.3 [expr.prim.this] paragraph 3, this example is ill-formed, because this "appears within" the declaration of a static member function. The qualification "of the current class" can be read as attaching to explicit object member functions only.

Suggested resolution [SUPERSEDED]:

Change in 7.5.3 [expr.prim.this] paragraph 3 as follows:

If a declaration declares a member function or member function template of a class X, the expression this is a prvalue of type “pointer to cv-qualifier-seq X” wherever X is the current class between the optional cv-qualifier-seq and the end of the function-definition, member-declarator , or declarator. It shall not appear within the The declaration of either that determines the type of this shall declare neither a static member function or nor an explicit object member function of the current class (although its type and value category are defined within such member functions as they are within an implicit object member function).

CWG 2024-05-03

CWG preferred a smaller surgery to avoid the English parsing issue.

Proposed resolution (approved by CWG 2024-05-17):

Change in 7.5.3 [expr.prim.this] paragraph 3 as follows:

If a declaration declares a member function or member function template of a class X, the expression this is a prvalue of type “pointer to cv-qualifier-seq X” wherever X is the current class between the optional cv-qualifier-seq and the end of the function-definition, member-declarator, or declarator. It shall not appear within the declaration of either a static member function or an explicit object member function of the current class (although its type and value category are defined within such member functions as they are within an implicit object member function).

1973. Which parameter-declaration-clause in a lambda-expression?

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

According to 7.5.6.2 [expr.prim.lambda.closure] paragraph 3,

The closure type for a lambda-expression has a public inline function call operator (for a non-generic lambda) or function call operator template (for a generic lambda) (12.4.4 [over.call]) whose parameters and return type are described by the lambda-expression's parameter-declaration-clause and trailing-return-type respectively, and whose template-parameter-list consists of the specified template-parameter-list, if any.

This is insufficiently precise because the trailing-return-type might itself contain a parameter-declaration-clause.

Suggested resolution [SUPERSEDED]:

Change in 7.5.6.1 [expr.prim.lambda.general] paragraph 5 as follows:

If a lambda-declarator does not include a start with a parenthesized parameter-declaration-clause, it is as if () were inserted at the start of the lambda-declarator. A lambda-expression's parameter-declaration-clause is the (possibly empty) parameter-declaration-clause of the lambda-expression's lambda-declarator. If the lambda-declarator does not include a trailing-return-type, the lambda return type is auto, which is deduced from return statements as described in 9.2.9.7 [dcl.spec.auto].

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

1. Change in 7.5.6.2 [expr.prim.lambda.closure] paragraph 3 as follows:

   The closure type for a lambda-expression has a public inline function call operator (for a non-generic lambda) or function call operator template (for a generic lambda) (12.4.4 [over.call]) whose parameters and return type are described by those of the lambda-expression's parameter-declaration-clause and trailing-return-type respectively, and whose template-parameter-list consists of the specified template-parameter-list, if any.

2. Change in 7.5.6.1 [expr.prim.lambda.general] paragraph 5 as follows:

   If a lambda-declarator does not include a parameter-declaration-clause, it is as if () were inserted at the start of the lambda-declarator. A lambda-expression's parameter-declaration-clause is the parameter-declaration-clause of the lambda-expression's lambda-declarator, if any, or empty otherwise. If the lambda-declarator does not include a trailing-return-type, the lambda return type is auto, which is deduced from return statements as described in 9.2.9.7 [dcl.spec.auto].

2542. Is a closure type a structural type?

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

Consider:

  template <auto V>
  void foo() {}

  void bar() {
    foo<[i = 3] { return i; }>();
  }

It is unclear whether the data members of a closure type are public or private. This makes a difference, since it affects whether a closure type is a structural type or not (13.2 [temp.param] paragraph 7:

A structural type is one of the following:

• a scalar type, or
• an lvalue reference type, or
• a literal class type with the following properties:
  • all base classes and non-static data members are public and non-mutable and
  • the types of all bases classes and non-static data members are structural types or (possibly multi-dimensional) array thereof.

Proposed resolution (approved by CWG 2023-03-30):

Change in 7.5.6.2 [expr.prim.lambda.closure] paragraph 2 as follows:

... The closure type is not an aggregate type (9.5.2 [dcl.init.aggr]) and not a structural type (13.2 [temp.param]). ...

2561. Conversion to function pointer for lambda with explicit object parameter

[Accepted as a DR at the June, 2024 meeting.]

P0847R7 (Deducing this) (approved October, 2021) added explicit-object member functions. Consider:

  struct C {
    C(auto) { }
  };

  void foo() {
    auto l = [](this C) { return 1; };
    void (*fp)(C) = l;
    fp(1); // same effect as decltype(l){}() or decltype(l){}(1) ?
  }

Subclause 7.5.6.2 [expr.prim.lambda.closure] paragraph 8 does not address explicit object member functions:

The closure type for a non-generic lambda-expression with no lambda-capture whose constraints (if any) are satisfied has a conversion function to pointer to function with C++ language linkage (9.12 [dcl.link]) having the same parameter and return types as the closure type's function call operator. The conversion is to “pointer to noexcept function” if the function call operator has a non-throwing exception specification. The value returned by this conversion function is the address of a function F that, when invoked, has the same effect as invoking the closure type's function call operator on a default-constructed instance of the closure type. F is a constexpr function if...

Suggested resolution [SUPERSEDED]:

1. Change in 7.5.6.2 [expr.prim.lambda.closure] paragraph 8 as follows:

   ... The value returned by this conversion function is

   • for a lambda-expression whose parameter-declaration-clause has an explicit object parameter, the address of the function call operator (7.6.2.2 [expr.unary.op];
   • otherwise, the address of a function F that, when invoked, has the same effect as invoking the closure type's function call operator on a default-constructed instance of the closure type.

   F is a constexpr function if... is an immediate function.

   [ Example:

     struct C {
       C(auto) { }
     };
   
     void foo() {
       auto a = [](C) { return 0; };
       int (*fp)(C) = a;   // OK
       fp(1);              // same effect as decltype(a){}(1)
       auto b = [](this C) { return 1; };
       fp = b;             // OK
       fp(1);              // same effect as (&decltype(b)::operator())(1)
     }
   

   -- end example ]

2. Change in 7.5.6.2 [expr.prim.lambda.closure] paragraph 11 as follows:

   The value returned by any given specialization of this conversion function template is

   • for a lambda-expression whose parameter-declaration-clause has an explicit object parameter, the address of the corresponding function call operator template specialization (7.6.2.2 [expr.unary.op]);
   • otherwise, the address of a function F that, when invoked, has the same effect as invoking the generic lambda's corresponding function call operator template specialization on a default-constructed instance of the closure type.

   F is a constexpr function if...

CWG 2023-06-17

Requesting guidance from EWG with paper issue 1689.

Additional notes (October, 2023)

Additional examples demonstrating implementation divergence between clang and MSVC:

  struct Any { Any(auto) {} };
  auto x = [](this auto self, int x) { return x; };
  auto y = [](this Any self, int x) { return x; };
  auto z = [](this int (*self)(int), int x) { return x; };
  int main() {
    x(1);
    y(1);
    z(1);
    int (*px)(int) = +x; // MSVC
    int (*py1)(int) = +y; // MSVC
    int (*py2)(Any, int) = +y; // Clang
    int (*pz1)(int) = +z; // MSVC
    int (*pz2)(int (*)(int), int) = +z; // Clang
  }

Additional notes (November, 2023)

Additional example:

  auto c2 = [](this auto self) { return sizeof(self); };
  struct Derived2 : decltype(c) { int value; } d2;
  struct Derived3 : decltype(c) { int value[10]; } d3;

For MSVC, d2() == 4 and d3() == 40, but +d2 and +d3 both point to functions returning 1.

EWG 2023-11-07

Move forward with option 1 "punt" from D3031 for C++26. A future paper can explore other solutions.

Proposed resolution (approved by CWG 2024-04-19):

1. Change the example in 7.5.6.1 [expr.prim.lambda.general] paragraph 6 as follows:

     int i = [](int i, auto a) { return i; }(3, 4);  // OK, a generic lambda
     int j = []<class T>(T t, int i) { return i; }(3, 4);  // OK, a generic lambda
     auto x = [](int i, auto a) { return i; };             // OK, a generic lambda
     auto y = [](this auto self, int i) { return i; };      // OK, a generic lambda
     auto z = []<class T>(int i) { return i; };             // OK, a generic lambda
   
   

2. Change in 7.5.6.2 [expr.prim.lambda.closure] paragraph 9 as follows:

   The closure type for a non-generic lambda-expression with no lambda-capture and no explicit object parameter (9.3.4.6 [dcl.fct]) whose constraints (if any) are satisfied has a conversion function to pointer to function with C++ language linkage (9.12 [dcl.link]) having the same parameter and return types as the closure type's function call operator. ...

3. Change in 7.5.6.2 [expr.prim.lambda.closure] paragraph 10 as follows:

   For a generic lambda with no lambda-capture and no explicit object parameter (9.3.4.6 [dcl.fct]), the closure type has a conversion function template to pointer to function. ...

CWG 2023-11-09

Keeping in review status in anticipation of a paper proposing reasonable semantics for the function pointer conversions.

EWG 2024-03-18

Progress with option #1 of P3031R0, affirming the direction of the proposed resolution.

2845. Make the closure type of a captureless lambda a structural type

[Accepted as a DR at the March, 2024 meeting.]

Issue 2542 (approved in June, 2023) made all closure types not be structural types, i.e. unsuitable for use as non-type template parameters. This causes an inconsistency with the treatment of the pointer-to-function conversion for closure types with no captures:

  template <auto V>
  void foo() {}

  void bar() {
    foo<[i = 3] { return i; }>();   // #1: error
    foo<[]{}>();                    // #2: error
    foo<+[]{}>();                   // #3: OK, a function pointer is a structural type
  }

Proposed resolution (approved by CWG 2024-02-02):

1. Change in 7.5.6.2 [expr.prim.lambda.closure] paragraph 3 as follows:

   The closure type is not an aggregate type (9.5.2 [dcl.init.aggr]) and not ; it is a structural type (13.2 [temp.param]) if and only if the lambda has no lambda-capture. An implementation may define the closure type differently from ...

2. Change in 13.6 [temp.type] paragraph 2 as follows:

   Two values are template-argument-equivalent if they are of the same type and

   • ...
   • they are of a closure type (7.5.6.2 [expr.prim.lambda.closure]), or
   • they are of class type and their corresponding direct subobjects and reference members are template-argument-equivalent.

2881. Type restrictions for the explicit object parameter of a lambda

[Accepted as a DR at the June, 2024 meeting.]

Subclause 7.5.6.2 [expr.prim.lambda.closure] paragraph 5 restricts the type of an explicit object parameter of a lambda to the closure type or classes derived from the closure type. It neglects to consider ambiguous or private derivation scenarios.

Proposed resolution (approved by CWG 2024-06-26):

1. Change in 7.5.6.2 [expr.prim.lambda.closure] paragraph 5 as follows:

   Given a lambda with a lambda-capture, the type of the explicit object parameter, if any, of the lambda's function call operator (possibly instantiated from a function call operator template) shall be either:

   • the closure type
   • a class type publicly and unambiguously derived from the closure type, or
   • a reference to a possibly cv-qualified such type.

2. Add a new bullet after 13.10.3.1 [temp.deduct.general] bullet 11.10:

   • ...
   • Attempting to create a function type in which a parameter has a type of void, or in which the return type is a function type or array type.
   • Attempting to give to an explicit object parameter of a lambda's function call operator a type not permitted for such (7.5.6.2 [expr.prim.lambda.closure]).

CWG 2024-06-26

The following example is not supported by the proposed resolution and remains ill-formed:

  int main() {
    int x = 0;
    auto lambda = [x] (this auto self) { return x; };
    using Lambda = decltype(lambda);
    struct D : private Lambda {
      D(Lambda l) : Lambda(l) {}
      using Lambda::operator();
      friend Lambda;
    } d(lambda);
    d();
  } 

2560. Parameter type determination in a requirement-parameter-list

[Accepted as a DR at the March, 2024 meeting.]

Consider:

  template<typename T>
    requires requires (T p[10]) { (decltype(p))nullptr; }
  int v = 42;
  auto r = v<int>; // well-formed? 

This example is only well-formed if the type of the parameter p is adjusted to T*, but the provisions in 9.3.4.6 [dcl.fct] paragraph 5 cover function parameters only.

One option is to specify application of the same adjustments as for function parameters. Another option is to specify rules that arguably are more useful in a requires-expression.

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

Change in 7.5.8.1 [expr.prim.req.general] paragraph 3 as follows:

A requires-expression may introduce local parameters using a parameter-declaration-clause (9.3.4.6 [dcl.fct]). A local parameter of a requires-expression shall not have a default argument. The type of such a parameter is determined as specified for a function parameter in 9.3.4.6 [dcl.fct]. These parameters have no linkage, storage, or lifetime; they are only used as notation for the purpose of defining requirements. The parameter-declaration-clause of a requirement-parameter-list shall not terminate with an ellipsis.
[Example 2:

  template<typename T>
  concept C = requires(T t, ...) {  // error: terminates with an ellipsis
    t;
  };
  template<typename T>
  concept C2 = requires(T p[2]) {
    (decltype(p))nullptr;           // OK, p has type "pointer to T"
  };

—end example]

CWG 2023-06-17

There are arguments in favor of both options. Forwarded to EWG with paper issue 1582.

EWG 2023-11-07

Accept the proposed resolution and forward to CWG for inclusion in C++26.

2911. Unclear meaning of expressions "appearing within" subexpressions

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

(From submission #562.)

Subclause 7.5.8.1 [expr.prim.req.general] paragraph 2 specifies:

A requires-expression is a prvalue of type bool whose value is described below. Expressions appearing within a requirement-body are unevaluated operands (7.2.3 [expr.context]).

A constant-expression used as a non-type template argument "appearing within" the requirement-body should not be considered an "unevaluated operand". Similarly, bodies of lambda-expressions should not be in focus of "appearing within".

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

1. Change in 7.2.3 [expr.context] paragraph 1 as follows:

   In some contexts, unevaluated operands appear (7.5.8 [expr.prim.req] 7.5.8.2 [expr.prim.req.simple], 7.5.8.4 [expr.prim.req.compound], 7.6.1.8 [expr.typeid], 7.6.2.5 [expr.sizeof], 7.6.2.7 [expr.unary.noexcept], 9.2.9.6 [dcl.type.decltype], 13.1 [temp.pre], 13.7.9 [temp.concept]). An unevaluated operand is not evaluated.

2. Change in 7.5.8.1 [expr.prim.req.general] paragraph 2 as follows:

   A requires-expression is a prvalue of type bool whose value is described below. Expressions appearing within a requirement-body are unevaluated operands (7.2.3 [expr.context]).

3. Change in 7.5.8.2 [expr.prim.req.simple] paragraph 1 as follows:

   A simple-requirement asserts the validity of an expression. The expression is an unevaluated operand. [Note 1: The enclosing requires-expression will evaluate to false if substitution of template arguments into the expression fails. The expression is an unevaluated operand (7.2.3 [expr.context]). —end note] ...

4. Change in 7.5.8.4 [expr.prim.req.compound] paragraph 1 as follows:

   A compound-requirement asserts properties of the expression E. The expression is an unevaluated operand. Substitution of template arguments (if any) and verification of semantic properties proceed in the following order:

1642. Missing requirements for prvalue operands

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

Although the note in 7.2.1 [basic.lval] paragraph 1 states that

The discussion of each built-in operator in Clause 7 [expr] indicates the category of the value it yields and the value categories of the operands it expects

in fact, many of the operators that take prvalue operands do not make that requirement explicit. Possible approaches to address this failure could be a blanket statement that an operand whose value category is not stated is assumed to be a prvalue; adding prvalue requirements to each operand description for which it is missing; or changing the description of the usual arithmetic conversions to state that they imply the lvalue-to-rvalue conversion, which would cover the majority of the omissions.

(See also issue 1685, which deals with an inaccurately-specified value category.)

Proposed resolution (approved by CWG 2023-04-28):

1. Change in 7.2.1 [basic.lval] paragraph 6 as follows:

   Whenever a glvalue appears as an operand of an operator that expects requires a prvalue for that operand, the lvalue-to-rvalue (7.3.2 [conv.lval]), array-to-pointer (7.3.3 [conv.array]), or function-to-pointer (7.3.4 [conv.func]) standard conversions are applied to convert the expression to a prvalue. ...

2. Change in 7.3.1 [conv.general] paragraph 1 as follows:

   ... A standard conversion sequence will be applied to an expression if necessary to convert it to an expression having a required destination type and value category. ...

3. Add to the bulleted list in 7.4 [expr.arith.conv] paragraph 1 as follows:

   ... This pattern is called the usual arithmetic conversions, which are defined as follows:

   • The lvalue-to-rvalue conversion (7.3.2 [conv.lval]) is applied to each operand and the resulting prvalues are used in place of the original operands for the remainder of this section.
   • If either operand is of scoped enumeration type (9.8.1 [dcl.enum]), no conversions are performed; if the other operand does not have the same type, the expression is ill-formed.
   • ...

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

   ... For a call to a non-member function or to a static member function, the postfix expression shall be either be an lvalue that refers to a function (in which case the function-to-pointer standard conversion (7.3.4 [conv.func]) is suppressed on the postfix expression), or have a prvalue of function pointer type.

5. Change in 7.6.2.2 [expr.unary.op] paragraph 7 as follows:

   The operand of the unary + operator shall have be a prvalue of arithmetic, unscoped enumeration, or pointer type and the result is the value of the argument. Integral promotion is performed on integral or enumeration operands. ...

6. Change in 7.6.2.2 [expr.unary.op] paragraph 8 as follows:

   The operand of the unary - operator shall have be a prvalue of arithmetic or unscoped enumeration type and the result is the negative of its operand. Integral promotion is performed on integral or enumeration operands. ...

7. Change in 7.6.2.2 [expr.unary.op] paragraph 10 as follows:

   The operand of the ~ operator shall have be a prvalue of integral or unscoped enumeration type. Integral promotions are performed. ...

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

   ... The operand shall be of pointer to object type or of class type. If the operand is of class type, the operand it is contextually implicitly converted (7.3 [conv]) to a pointer to object type. [ Footnote: ... ] Otherwise, it shall be a prvalue of pointer to object type. The delete-expression has type void.

9. Change in 7.6.4 [expr.mptr.oper] paragraph 2 and 3 as follows:

   The binary operator .* binds its second operand, which shall be a prvalue of type “pointer to member of T” to its first operand, which shall be ...

   The binary operator ->* binds its second operand, which shall be a prvalue of type “pointer to member of T” to its first operand, which shall be ...

10. Change in 7.6.6 [expr.add] paragraph 1 as follows:

    The additive operators + and - group left-to-right. The Each operand shall be a prvalue. If both operands have arithmetic or unscoped enumeration type, the usual arithmetic conversions (7.4 [expr.arith.conv]) are performed for operands of arithmetic or enumeration type. Otherwise, if one operand has arithmetic or unscoped enumeration type, integral promotion is applied (7.3.7 [conv.prom]) to that operand. A converted or promoted operand is used in place of the corresponding original operand for the remainder of this section. ... For addition, either both operands shall have arithmetic or unscoped enumeration type, or one operand shall be a pointer to a completely-defined object type and the other shall have integral or unscoped enumeration type.

11. Change in 7.6.6 [expr.add] paragraph 2 as follows:

    For subtraction, one of the following shall hold:

    • both operands have arithmetic or unscoped enumeration type; or
    • both operands are pointers to cv-qualified or cv-unqualified versions of the same completely-defined object type; or
    • the left operand is a pointer to a completely-defined object type and the right operand has integral or unscoped enumeration type.

12. Change in 7.6.7 [expr.shift] paragraph 1 as follows:

    ... The operands shall be prvalues of integral or unscoped enumeration type and integral promotions are performed. ...

13. Change in 9.5.1 [dcl.init.general] bullet 16.9 as follows:

    • ...
    • Otherwise, the initial value of the object being initialized is the (possibly converted) value of the initializer expression. A standard conversion sequence (7.3 [conv]) will be is used, if necessary, to convert the initializer expression to a prvalue of the cv-unqualified version of the destination type; no user-defined conversions are considered. ...
    • ...

2283. Missing complete type requirements

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

P0135R1 (Wording for guaranteed copy elision through simplified value categories) removes complete type requirements from 7.6.1.3 [expr.call] (under the assumption that subclause 9.5 [dcl.init] has them; apparently it does not) and from 7.6.1.8 [expr.typeid] paragraph 3. These both appear to be bad changes and should presumably be reverted.

Additional notes (October, 2024)

An almost-editorial change (approved by CWG 2021-08-24) restored a consistent complete-type requirement for typeid; see cplusplus/draft#4827.

Proposed resolution (approved by CWG 2024-10-25):

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

A function call is an lvalue if the result type is an lvalue reference type or an rvalue reference to function type, an xvalue if the result type is an rvalue reference to object type, and a prvalue otherwise. If it is a non-void prvalue, the type of the function call expression shall be complete, except as specified in 9.2.9.6 [dcl.type.decltype].

2715. "calling function" for parameter initialization may not exist

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

Subclause 7.6.1.3 [expr.call] paragraph 6 specifies:

... The initialization and destruction of each parameter occurs within the context of the calling function. [Example 2: The access of the constructor, conversion functions or destructor is checked at the point of call in the calling function. If a constructor or destructor for a function parameter throws an exception, the search for a handler starts in the calling function; in particular, if the function called has a function-try-block (14.1 [except.pre]) with a handler that can handle the exception, this handler is not considered. —end example]

However, there is no calling function in the case where a function call appears in the initializer of a namespace-scope variable. Likewise, some constant expressions appearing in a type-id do not have calling functions, either. For example:

  class C {
   private:
    constexpr int C(int) {}
    friend void foo(int (*a)[1]) noexcept;
  };

  constexpr int bar(C) { return 1; }

  void foo(int (&a)[bar(1)]) noexcept(bar(2) > 0); // presumably OK because of friendship

Proposed resolution (approved by CWG 2023-04-28):

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

... The initialization and destruction of each parameter occurs within the context of the calling function full-expression (6.9.1 [intro.execution]) where the function call appears. [Example 2: The access (11.8.1 [class.access.general]) of the constructor, conversion functions, or destructor is checked at the point of call in the calling function. If a constructor or destructor for a function parameter throws an exception, the search for a handler starts in the calling function; in particular, if the function called has a any function-try-block (14.1 [except.pre]) of the called function with a handler that can handle the exception, this handler is not considered. —end example]

2894. Functional casts create prvalues of reference type

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

(From submission #536.)

For T{...}, the rule in 7.6.1.4 [expr.type.conv] paragraph 2 yields a prvalue of reference type if T is a reference type:

... Otherwise, the expression is a prvalue of the specified type whose result object is direct-initialized (9.4) with the initializer. ...

Also, it should be clarified that void(1, 2) and void{1} are ill-formed.

Possible resolution [SUPERSEDED]:

Change in 7.6.1.4 [expr.type.conv] paragraph 1 and 2 as follows:

A simple-type-specifier (9.2.9.3 [dcl.type.simple]) or typename-specifier (13.8 [temp.res]) followed by a parenthesized optional expression-list or by a braced-init-list (the initializer) constructs a value of the specified type given the initializer. If the type is a placeholder for a deduced class type, it is replaced by the return type of the function selected by overload resolution for class template deduction (12.2.2.9 [over.match.class.deduct]) for the remainder of this subclause. Otherwise, if the type contains a placeholder type, it is replaced by the type determined by placeholder type deduction (9.2.9.7.2 [dcl.type.auto.deduct]). Let T denote the resulting type. [ Example: ... ]

If the initializer is a parenthesized single expression, the type conversion expression is equivalent to the corresponding cast expression (7.6.3 [expr.cast]). Otherwise, if the type T is cv void and , the initializer is shall be () or {} (after pack expansion, if any), and the expression is a prvalue of type void that performs no initialization. Otherwise, the expression is a prvalue of the specified type whose result object is direct-initialized (9.5 [dcl.init]) with the initializer has the same effect as direct-initializing an invented variable t of type T from the initializer and then using t as the result of the expression. The result is an lvalue if T is an lvalue reference type or an rvalue reference to function type, an xvalue if T is an rvalue reference to object type, and a prvalue otherwise. If the initializer is a parenthesized optional expression-list, the specified type T shall not be an array type.

CWG 2024-06-14

The resolution above introduces an additional variable even for a prvalue, which defeats mandatory copy elision. Use the pattern from 7.6.1.9 [expr.static.cast] paragraph 4 instead.

Proposed resolution (approved by CWG 2024-10-25):

Change in 7.6.1.4 [expr.type.conv] paragraph 1 and 2 as follows, move the example to the bottom, and add bullets:

A simple-type-specifier (9.2.9.3 [dcl.type.simple]) or typename-specifier (13.8 [temp.res]) followed by a parenthesized optional expression-list or by a braced-init-list (the initializer) constructs a value of the specified type given the initializer. If the type is a placeholder for a deduced class type, it is replaced by the return type of the function selected by overload resolution for class template deduction (12.2.2.9 [over.match.class.deduct]) for the remainder of this subclause. Otherwise, if the type contains a placeholder type, it is replaced by the type determined by placeholder type deduction (9.2.9.7.2 [dcl.type.auto.deduct]). Let T denote the resulting type. [ Example: ... ]

Then:

• If the initializer is a parenthesized single expression, the type conversion expression is equivalent to the corresponding cast expression (7.6.3 [expr.cast]).
• Otherwise, if the type T is cv void and , the initializer is shall be () or {} (after pack expansion, if any), and the expression is a prvalue of type void that performs no initialization.
• Otherwise, if T is a reference type, the expression has the same effect as direct-initializing an invented variable t of type T from the initializer and then using t as the result of the expression; the result is an lvalue if T is an lvalue reference type or an rvalue reference to function type and an xvalue otherwise.
• Otherwise, the expression is a prvalue of the specified type T whose result object is direct-initialized (9.5 [dcl.init]) with the initializer.

If the initializer is a parenthesized optional expression-list, the specified type T shall not be an array type.

[Example: ... ]

2725. Overload resolution for non-call of class member access

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

Consider:

  struct A {
    static void f();
    static void f(int);
  } x;
  void (*p)() = x.f;   // error

This is ill-formed as confirmed by issue 61. Various other changes (see issue 2241) have put the following example into the same category:

  struct B {
    static void f();
  } y;
  void (*q)() = y.f;   // error

If this is the intended outcome (although major implementations disagree), then the rules in 7.6.1.5 [expr.ref] should be clarified accordingly.

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

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

• ...
• If E2 is an overload set, the expression shall be the (possibly-parenthesized) left-hand operand of a member function call (7.6.1.3 [expr.call]), and function overload resolution (12.2 [over.match]) is used to select the function to which E2 refers. The type of E1.E2 is the type of E2 and E1.E2 refers to the function referred to by E2.
  • If E2 refers to a static member function, E1.E2 is an lvalue.
  • Otherwise (when E2 refers to a non-static member function), E1.E2 is a prvalue. The expression can be used only as the left-hand operand of a member function call (11.4.2 [class.mfct]). [Note 5: Any redundant set of parentheses surrounding the expression is ignored (7.5.4 [expr.prim.paren]). —end note]
• ...

This also addresses issue 1038.

2748. Accessing static data members via null pointer

[Accepted as a DR at the March, 2024 meeting.]

Consider:

  struct C { static int foo; };
  C* c = nullptr;

The behavior of (*c).foo is clearly undefined per 7.6.1.5 [expr.ref] paragraph 1:

The postfix expression before the dot or arrow is evaluated ...

However, the treatment of c->foo is less clear, because the transformation to the form (*(E1)).E2 occurs later.

Proposed resolution (approved by CWG 2023-12-15):

Move a part of 7.6.1.5 [expr.ref] paragraph 1 to before paragraph 3 and edit as follows:

A postfix expression followed by a dot . or an arrow ->, optionally followed by the keyword template, and then followed by an id-expression, is a postfix expression. The postfix expression before the dot or arrow is evaluated; [ Footnote: ... ] the result of that evaluation, together with the id-expression, determines the result of the entire postfix expression. [Note 1: If the keyword template is used, the following unqualified name is considered to refer to a template (13.3 [temp.names]). If a simple-template-id results and is followed by a ::, the id-expression is a qualified-id. —end note]

For the first option (dot) the first expression shall be a glvalue. For the second option (arrow) the first expression shall be a prvalue having pointer type. The expression E1->E2 is converted to the equivalent form (*(E1)).E2; the remainder of 7.6.1.5 [expr.ref] will address only the first option (dot). [ Footnote: ... ]

The postfix expression before the dot is evaluated; [ Footnote: ... ] the result of that evaluation, together with the id-expression, determines the result of the entire postfix expression.

2813. Class member access with prvalues

[Accepted as a DR at the March, 2024 meeting.]

Subclause 7.6.1.5 [expr.ref] paragraph 2 specifies:

For the first option (dot) the first expression shall be a glvalue. ...

This provision forces a temporary materialization conversion (i.e. a copy) per 7.2.1 [basic.lval] paragraph 7:

Whenever a prvalue appears as an operand of an operator that expects a glvalue for that operand, the temporary materialization conversion (7.3.5 [conv.rval]) is applied to convert the expression to an xvalue.

However, this is limiting in the case that an explicit object member function with a by-value object parameter is invoked for a non-copyable class object, for example:

  struct X {
    X() = default;

    X(const X&) = delete;
    X& operator=(const X&) = delete;

    void f(this X self) { }
  };

  void f() {
    X{}.f();   // OK?
  }

The example ought to be well-formed.

Proposed resolution (reviewed by CWG 2024-02-16) [SUPERSEDED]:

1. Change in 6.7.7 [class.temporary] paragraph 2 as follows:

   ... [Note 3: Temporary objects are materialized:

   • when binding a reference to a prvalue (9.5.4 [dcl.init.ref], 7.6.1.4 [expr.type.conv], 7.6.1.7 [expr.dynamic.cast], 7.6.1.9 [expr.static.cast], 7.6.1.11 [expr.const.cast], 7.6.3 [expr.cast]),
   • when performing certain member access accesses on a class prvalue (7.6.1.5 [expr.ref], 7.6.4 [expr.mptr.oper]),
   • when invoking an implicit object member function on a class prvalue (7.6.1.3 [expr.call]),
   • ...

   —end note]

2. Change in 7.6.1.3 [expr.call] paragraph 6 as follows:

   When a function is called, each parameter (9.3.4.6 [dcl.fct]) is initialized (9.5 [dcl.init], 11.4.5.3 [class.copy.ctor]) with its corresponding argument. If the function is an explicit object member function and there is an implied object argument (12.2.2.2.2 [over.call.func]), the list of provided arguments is preceded by the implied object argument for the purposes of this correspondence. If there is no corresponding argument, the default argument for the parameter is used. [Example 1:

   template<typename ...T> int f(int n = 0, T ...t);
   int x = f<int>(); // error: no argument for second function parameter
   

   —end example] If the function is a static member function invoked using class member access syntax, the object expression is a discarded-value expression (7.2.3 [expr.context]). If the function is an implicit object member function, the object expression of the class member access shall be a glvalue and the this parameter of the function (7.5.3 [expr.prim.this]) is initialized with a pointer to the object of the call, converted as if by an explicit type conversion (7.6.3 [expr.cast]). [Note 5: There is no access or ambiguity checking on this conversion; the access checking and disambiguation are done as part of the (possibly implicit) class member access operator. See 6.5.2 [class.member.lookup], 11.8.3 [class.access.base], and 7.6.1.5 [expr.ref]. —end note] When a function is called, the type of any parameter shall not be a class type that is either incomplete or abstract. [Note 6: This still allows a parameter to be a pointer or reference to such a type. However, it prevents a passed-by-value parameter to have an incomplete or abstract class type. —end note] It is implementation-defined whether ...

3. Change in 7.6.1.5 [expr.ref] paragraph 2 as follows:

   For the first option (dot), if the id-expression is a data member, the first expression shall be a glvalue. For the second option (arrow), the first expression shall be a prvalue having pointer type. ...

CWG 2024-02-16

When a class member access refers to a static data member or a member enumerator, the object expression should also be treated as a discarded-value expression.

Proposed resolution (approved by CWG 2024-03-01):

1. Change in 6.7.7 [class.temporary] paragraph 2 as follows:

   ... [Note 3: Temporary objects are materialized:

   • when binding a reference to a prvalue (9.5.4 [dcl.init.ref], 7.6.1.4 [expr.type.conv], 7.6.1.7 [expr.dynamic.cast], 7.6.1.9 [expr.static.cast], 7.6.1.11 [expr.const.cast], 7.6.3 [expr.cast]),
   • when performing certain member access accesses on a class prvalue (7.6.1.5 [expr.ref], 7.6.4 [expr.mptr.oper]),
   • when invoking an implicit object member function on a class prvalue (7.6.1.3 [expr.call]),
   • ...

   —end note]

2. Change in 7.6.1.3 [expr.call] paragraph 6 as follows:

   When a function is called, each parameter (9.3.4.6 [dcl.fct]) is initialized (9.5 [dcl.init], 11.4.5.3 [class.copy.ctor]) with its corresponding argument. If the function is an explicit object member function and there is an implied object argument (12.2.2.2.2 [over.call.func]), the list of provided arguments is preceded by the implied object argument for the purposes of this correspondence. If there is no corresponding argument, the default argument for the parameter is used. [Example 1:

   template<typename ...T> int f(int n = 0, T ...t);
   int x = f<int>(); // error: no argument for second function parameter
   

   —end example] If the function is an implicit object member function, the object expression of the class member access shall be a glvalue and the this parameter of the function (7.5.3 [expr.prim.this]) is initialized with a pointer to the object of the call, converted as if by an explicit type conversion (7.6.3 [expr.cast]). [Note 5: There is no access or ambiguity checking on this conversion; the access checking and disambiguation are done as part of the (possibly implicit) class member access operator. See 6.5.2 [class.member.lookup], 11.8.3 [class.access.base], and 7.6.1.5 [expr.ref]. —end note] When a function is called, the type of any parameter shall not be a class type that is either incomplete or abstract. [Note 6: This still allows a parameter to be a pointer or reference to such a type. However, it prevents a passed-by-value parameter to have an incomplete or abstract class type. —end note] It is implementation-defined whether ...

3. Change in 7.6.1.5 [expr.ref] paragraph 2 as follows:

   For the first option (dot), if the id-expression names a static member or an enumerator, the first expression is a discarded-value expression (7.2.3 [expr.context]); if the id-expression names a non-static data member, the first expression shall be a glvalue. For the second option (arrow), the first expression shall be a prvalue having pointer type. ...

2855. Undefined behavior in postfix increment

[Accepted as a DR at the March, 2024 meeting.]

(From submission #479.)

Consider:

  int8_t x = 127;
  x++;

This has undefined behavior, because the resulting value is not representable as an int8_t. In contrast,

  int8_t x = 127;
  ++x;

is well-defined, because it is equivalent to x += 1, which is equivalent to x = (int)x + 1 after the usual arithmetic conversions (7.4 [expr.arith.conv]). No arithmetic overflow occurs. The presence or absence of undefined behavior is detectable in constant evaluation.

Proposed resolution (approved by CWG 2024-02-16):

1. Change in 7.6.1.6 [expr.post.incr] paragraph 1 as follows:

   The value of a postfix ++ expression is the value of its operand. [Note 1: The value obtained is a copy of the original value. —end note] The operand shall be a modifiable lvalue. The type of the operand shall be an arithmetic type other than cv bool, or a pointer to a complete object type. An operand with volatile-qualified type is deprecated; see D.4 [depr.volatile.type]. The value of the operand object is modified (3.1 [defns.access]) by adding 1 to it as if it were the operand of the prefix ++ operator (7.6.2.3 [expr.pre.incr]). The value computation of the ++ expression is sequenced before the modification of the operand object. With respect to an indeterminately-sequenced function call, the operation of postfix ++ is a single evaluation. [Note 2: Therefore, a function call cannot intervene between the lvalue-to-rvalue conversion and the side effect associated with any single postfix ++ operator. —end note] The result is a prvalue. The type of the result is the cv-unqualified version of the type of the operand. If the operand is a bit-field that cannot represent the incremented value, the resulting value of the bit-field is implementation-defined. See also 7.6.6 [expr.add] and 7.6.19 [expr.assign].

2. Change in 7.6.2.3 [expr.pre.incr] as follows:

   The operand of prefix ++ or -- is modified (3.1 [defns.access]) by adding 1. The operand shall be a modifiable lvalue. The type of the operand shall not be an arithmetic type other than of type cv bool, or a pointer to a completely-defined object type. An operand with volatile-qualified type is deprecated; see D.4 [depr.volatile.type]. The result is the updated operand; it is an lvalue, and it is a bit-field if the operand is a bit-field. The expression ++x is otherwise equivalent to x+=1 and the expression --x is otherwise equivalent to x-=1 . [Note 1: See the discussions of addition (7.6.6 [expr.add]) and assignment operators (7.6.19 [expr.assign]) for information on conversions. —end note]

   The operand of prefix -- is modified (3.1 [defns.access]) by subtracting 1. The requirements on the operand of prefix -- and the properties of its result are otherwise the same as those of prefix ++. [Note 2: For postfix increment and decrement, see 7.6.1.6 [expr.post.incr]. —end note]

2861. dynamic_cast on bad pointer value

[Accepted as a DR at the June, 2024 meeting.]

(From submission #497.)

Base-to-derived casts and cross-casts need to inspect the vtable of a polymorphic type. However, this is not defined as an "access" and there is no provision for undefined behavior analoguous to 7.2.1 [basic.lval] paragraph 11.

Proposed resolution (approved by CWG 2024-06-26):

1. Add a new paragraph after 7.6.1.7 [expr.dynamic.cast] paragraph 6 as follows:

   If v is a null pointer value, the result is a null pointer value.

   If v has type "pointer to cv U" and v does not point to an object whose type is similar (7.3.6 [conv.qual]) to U and that is within its lifetime or within its period of construction or destruction (11.9.5 [class.cdtor]), the behavior is undefined. If v is a glvalue of type U and v does not refer to an object whose type is similar to U and that is within its lifetime or within its period of construction or destruction, the behavior is undefined.

2. Change in 7.3.12 [conv.ptr] paragraph 3 as follows:

   A prvalue v of type “pointer to cv D”, where D is a complete class type, can be converted to a prvalue of type “pointer to cv B”, where B is a base class (11.7 [class.derived]) of D. If B is an inaccessible (11.8 [class.access]) or ambiguous (6.5.2 [class.member.lookup]) base class of D, a program that necessitates this conversion is ill-formed. The result of the conversion is a pointer to the base class subobject of the derived class object. The null pointer value is converted to the null pointer value of the destination type. If v is a null pointer value, the result is a null pointer value. Otherwise, if B is a virtual base class of D and v does not point to an object whose type is similar (7.3.6 [conv.qual]) to D and that is within its lifetime or within its period of construction or destruction (11.9.5 [class.cdtor]), the behavior is undefined. Otherwise, the result is a pointer to the base class subobject of the derived class object.

1954. typeid null dereference check in subexpressions

[Accepted as a DR at the March, 2024 meeting.]

According to 7.6.1.8 [expr.typeid] paragraph 2,

If the glvalue expression is obtained by applying the unary * operator to a pointer⁶⁹ and the pointer is a null pointer value (7.3.12 [conv.ptr]), the typeid expression throws an exception (14.2 [except.throw]) of a type that would match a handler of type std::bad_typeid exception (17.7.5 [bad.typeid]).

The footnote makes clear that this requirement applies without regard to parentheses, but it is unspecified whether it applies when the dereference occurs in a subexpression of the operand (e.g., in the second operand of the comma operator or the second or third operand of a conditional operator). There is implementation divergence on this question.

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

Insert a new paragraph before 7.6.1.8 [expr.typeid] paragraph 3 and change the latter as follows:

If an expression operand of typeid is a possibly-parenthesized unary-expression whose unary-operator is * and whose operand evaluates to a null pointer value (6.8.4 [basic.compound]), the typeid expression throws an exception (14.2 [except.throw]) of a type that would match a handler of type std::bad_typeid (17.7.5 [bad.typeid]). [ Note: In other contexts, evaluating such a unary-expression results in undefined behavior (7.6.2.2 [expr.unary.op]) -- end note ]

When typeid is applied to a glvalue whose type is a polymorphic class type (11.7.3 [class.virtual]), the result refers to a std::type_info object representing the type of the most derived object (6.7.2 [intro.object]) (that is, the dynamic type) to which the glvalue refers. If the glvalue is obtained by applying the unary * operator to a pointer [ Footnote: ... ] and the pointer is a null pointer value (6.8.4 [basic.compound]), the typeid expression throws an exception (14.2 [except.throw]) of a type that would match a handler of type std::bad_typeid exception (17.7.5 [bad.typeid]).

2718. Type completeness for derived-to-base conversions

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

Issue 2310 clarified class completeness requirements for derived-to-base pointer conversions, but neglected the corresponding lvalue conversion.

Proposed resolution (approved by CWG 2023-04-28):

Change in 7.6.1.9 [expr.static.cast] paragraph 2 as follows:

An lvalue of type “cv1 B”, where B is a class type, can be cast to type “reference to cv2 D”, where D is a complete class derived (11.7 [class.derived]) from B, if cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. ...

2882. Unclear treatment of conversion to void

[Accepted as a DR at the June, 2024 meeting.]

The ordering of paragraphs in 7.6.1.9 [expr.static.cast] appears to imply that an attempt is made to form an implicit conversion sequence for conversions to void, possibly considering user-defined conversion functions to void. This is not intended.

Proposed resolution (approved by CWG 2024-05-31):

1. Move 7.6.1.9 [expr.static.cast] paragraph 6 to before paragraph 4, strike paragraph 5, and adjust paragraph 7:

   Any expression can be explicitly converted to type cv void, in which case the operand is a discarded-value expression (7.2 [expr.prop]). [Note 3: Such a static_cast has no result as it is a prvalue of type void; see 7.2.1 [basic.lval]. —end note] [Note 4: However, if the value is in a temporary object (6.7.7 [class.temporary]), the destructor for that object is not executed until the usual time, and the value of the object is preserved for the purpose of executing the destructor. —end note]

   An Otherwise, an expression E can be explicitly converted to a type T if there is an implicit conversion sequence (12.2.4.2 [over.best.ics]) from E to T, if overload resolution ...

   Otherwise, the static_cast shall perform one of the conversions listed below. No other conversion shall be performed explicitly using a static_cast.

   Any expression can be explicitly converted to type cv void, in which case the operand is a discarded-value expression (7.2 [expr.prop]). [Note 3: Such a static_cast has no result as it is a prvalue of type void; see 7.2.1 [basic.lval]. —end note] [Note 4: However, if the value is in a temporary object (6.7.7 [class.temporary]), the destructor for that object is not executed until the usual time, and the value of the object is preserved for the purpose of executing the destructor. —end note]

   The Otherwise, the inverse of any a standard conversion sequence (7.3 [conv]) not containing an lvalue-to-rvalue (7.3.2 [conv.lval]), array-to-pointer (7.3.3 [conv.array]), function-to-pointer (7.3.4 [conv.func]), null pointer (7.3.12 [conv.ptr]), null member pointer (7.3.13 [conv.mem]), boolean (7.3.15 [conv.bool]), or function pointer (7.3.14 [conv.fctptr]) conversion, can be performed explicitly using static_cast. A program is ill-formed if it uses static_cast to perform the inverse of an ill-formed standard conversion sequence.

2. Add a new paragraph after 7.6.1.9 [expr.static.cast] paragraph 14:

   A prvalue of type “pointer to cv1 void” can be converted to a prvalue of type “pointer to cv2 T”, ... Otherwise, the pointer value is unchanged by the conversion. [Example 3: ... —end example]

   No other conversion can be performed using static_cast.

2780. reinterpret_cast to reference to function types

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

Subclause 7.6.1.10 [expr.reinterpret.cast] paragraph 11 specifies:

A glvalue of type T1, designating an object x, can be cast to the type “reference to T2” if an expression of type “pointer to T1” can be explicitly converted to the type “pointer to T2” using a reinterpret_cast. The result is that of *reinterpret_cast<T2 *>(p) where p is a pointer to x of type “pointer to T1”. No temporary is created, no copy is made, and no constructors (11.4.5 [class.ctor]) or conversion functions (11.4.8 [class.conv]) are called. [ Footnote: ... ]

The wording does not cover references to function type, only references to object types. All major implementations accept the following example:

  void f() {}

  void(&g())(int) {
    return reinterpret_cast<void(&)(int)>(f);
  }

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

Change in 7.6.1.10 [expr.reinterpret.cast] paragraph 11 as follows:

A glvalue of type T1, designating an object or function x, can be cast to the type “reference to T2” if an expression of type “pointer to T1” can be explicitly converted to the type “pointer to T2” using a reinterpret_cast. The result is that of *reinterpret_cast<T2 *>(p) where p is a pointer to x of type “pointer to T1”. No temporary is created, no copy is made, and no constructors (11.4.5 [class.ctor]) or conversion functions (11.4.8 [class.conv]) are called. [ Footnote: ... ]

2939. Do not allow reinterpret_cast from prvalue to rvalue reference

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

(From submission #617.)

In 7.6.1.10 [expr.reinterpret.cast] paragraph 11, there is an issue similar to the one described in issue 2879: The operand for a cast to reference type can be a "glvalue of type T1", which implies that a prvalue is also acceptable, because it is materialized per 7.2.1 [basic.lval] paragraph 7. However, no implementation accepts reinterpret_cast<double&&>(0).

Suggested resolution [SUPERSEDED]:

1. Change in 7.6.1.10 [expr.reinterpret.cast] paragraph 1 as follows:

   The result of the expression reinterpret_cast<T>(v) is the result of converting the expression v to type T. If T is an lvalue reference type or an rvalue reference to function type, the result is an lvalue; if T is an rvalue reference to object type, the result is an xvalue; otherwise, the result is a prvalue and the lvalue-to-rvalue (7.3.2 [conv.lval]), array-to-pointer (7.3.3 [conv.array]), and function-to-pointer (7.3.4 [conv.func]) standard conversions are performed on the expression v. The temporary materialization conversion (7.3.5 [conv.rval]) is not performed on v. Conversions that can be performed explicitly using reinterpret_cast are listed below. No other conversion can be performed explicitly using reinterpret_cast.

2. Remove 7.6.1.10 [expr.reinterpret.cast] paragraph 3:

   [Note 1: The mapping performed by reinterpret_cast might, or might not, produce a representation different from the original value. —end note]

3. Remove from 7.6.1.10 [expr.reinterpret.cast] paragraph 6 as follows:

   ... [Note 5: See also 7.3.12 [conv.ptr] for more details of pointer conversions. —end note]

4. Change in 7.6.1.10 [expr.reinterpret.cast] paragraph 11 as follows:

   A glvalue of type T1, designating an object or function x, can be cast to the type “reference to T2” if an expression of type “pointer to T1” can be explicitly converted to the type “pointer to T2” using a reinterpret_cast. The result is that of *reinterpret_cast<T2 *>(p) where p is a pointer to x of type “pointer to T1”. [ Note: No temporary is created, no copy is made, and no constructors (11.4.5 [class.ctor]) or conversion functions (11.4.8 [class.conv]) are called [ Footnote: ... ]. -- end note ]

CWG 2024-10-11

The note in 7.6.1.10 [expr.reinterpret.cast] paragraph 3 should be kept, and the list of exceptions in 7.2.1 [basic.lval] paragraph 7 established by issue 2879 should be amended with a cross-reference to 7.6.1.10 [expr.reinterpret.cast].

Proposed resolution (approved by CWG 2024-11-22):

1. Change in 7.2.1 [basic.lval] paragraph 7 as follows:

   Unless otherwise specified (7.6.1.10 [expr.reinterpret.cast], 7.6.1.11 [expr.const.cast]), whenever a prvalue appears as an operand of an operator that expects a glvalue for that operand, the temporary materialization conversion (7.3.5 [conv.rval]) is applied to convert the expression to an xvalue.

2. Remove from 7.6.1.10 [expr.reinterpret.cast] paragraph 6 as follows:

   ... [Note 5: See also 7.3.12 [conv.ptr] for more details of pointer conversions. —end note]

3. Change in 7.6.1.10 [expr.reinterpret.cast] paragraph 11 as follows:

   A If v is a glvalue of type T1, designating an object or function x, it can be cast to the type “reference to T2” if an expression of type “pointer to T1” can be explicitly converted to the type “pointer to T2” using a reinterpret_cast. The result is that of *reinterpret_cast<T2 *>(p) where p is a pointer to x of type “pointer to T1”. [ Note: No temporary is materialized (7.3.5 [conv.rval]) or created, no copy is made, and no constructors (11.4.5 [class.ctor]) or conversion functions (11.4.8 [class.conv]) are called [ Footnote: ... ]. -- end note ]

2879. Undesired outcomes with const_cast

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

(From submissions #526, #232, and #342.)

The resolution of issue 891 intended to make const_cast<int&&>(2) ill-formed. However, combined with the temporary materialization conversion turning prvalues into glvalues (7.1 [expr.pre] paragraph 7, this is now well-formed.

Also, the current rules regrettably allow const_cast<int>(0) and const_casts involving function pointers and pointers to member functions. The latter is non-normatively considered disallowed by the note in 7.6.1.11 [expr.const.cast] paragraph 9.

Major implementations except MSVC agree with the proposed direction of this issue.

Suggested resolution [SUPERSEDED]:

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

   For two similar types T1 and T2 (7.3.6 [conv.qual]), a prvalue of type T1 may be explicitly converted to the type T2 using a const_cast if, considering the qualification-decompositions of both types, each Pi1 is the same as Pi2 for all i. The result of a const_cast refers to the original entity.

   If T is an object pointer type or pointer to data member type, the type of v shall be similar to T and the corresponding P_i components of the qualification decompositions of T and the type of v shall be the same (7.3.6 [conv.qual]). If v is a null pointer or null member pointer, the result is a null pointer or null member pointer, respectively. Otherwise, the result points to or past the end of the same object or member, respectively, as v.

   [ Example: ... ]

2. Change in 7.6.1.11 [expr.const.cast] paragraph 4 as follows:

   For two object types T1 and T2, if a pointer to T1 can be explicitly converted to the type “pointer to T2” using a const_cast, then the following conversions can also be made:

   • an lvalue of type T1 can be explicitly converted to an lvalue of type T2 using the cast const_cast<T2&>;
   • a glvalue of type T1 can be explicitly converted to an xvalue of type T2 using the cast const_cast<T2&&>; and
   • if T1 is a class type, a prvalue of type T1 can be explicitly converted to an xvalue of type T2 using the cast const_cast<T2&&>.

   The result of a reference const_cast refers to the original object if the operand is a glvalue and to the result of applying the temporary materialization conversion (7.3.5 [conv.rval]) otherwise.

   Otherwise, T shall be a reference type. Let T1 be the type of v and T2 be the type referred to by T. A const_cast from "pointer to T1" to "pointer to T2" shall be valid. If T is an lvalue reference type, v shall be an lvalue. Otherwise, if T2 is a class type and v is a prvalue, the temporary materialization conversion (7.3.5 [conv.rval]) is applied. Otherwise, the temporary materialization conversion is not applied and v shall be a glvalue. The result refers to the same object as the (possibly converted) operand.

3. Remove 7.6.1.11 [expr.const.cast] paragraph 5:

   A null pointer value (6.8.4 [basic.compound]) is converted to the null pointer value of the destination type. The null member pointer value (7.3.13 [conv.mem]) is converted to the null member pointer value of the destination type.

Suggested resolution [SUPERSEDED]:

1. Change in 7.6.1.11 [expr.const.cast] paragraph 1 as follows:

   The result of the expression const_cast<T>(v) is of type T. If T is an lvalue reference to object type, the result is an lvalue; if T is an rvalue reference to object type, the result is an xvalue; otherwise, the result is a prvalue and the lvalue-to-rvalue (7.3.2 [conv.lval]), array-to-pointer (7.3.3 [conv.array]), and function-to-pointer (7.3.4 [conv.func]) standard conversions are performed on the expression v. The temporary materialization conversion (7.3.5 [conv.rval]) is not performed on v, other than as specified below. Conversions that can be performed explicitly using const_cast are listed below. No other conversion shall be performed explicitly using const_cast.

2. Change in 7.6.1.11 [expr.const.cast] paragraph 3 as follows:

   For two similar object pointer or pointer to data member types T1 and T2 (7.3.6 [conv.qual]), a prvalue of type T1 may can be explicitly converted to the type T2 using a const_cast if, considering the qualification-decompositions of both types, each Pi1 is the same as Pi2 for all i. The result of a const_cast refers to the original entity. If v is a null pointer or null member pointer, the result is a null pointer or null member pointer, respectively. Otherwise, the result points to or past the end of the same object, or points to the same member, respectively, as v.

3. Change in 7.6.1.11 [expr.const.cast] paragraph 4 as follows:

   For two object types T1 and T2, if a pointer to T1 can be explicitly converted to the type “pointer to T2” using a const_cast, then the following conversions can also be made:

   • an lvalue of type T1 can be explicitly converted to an lvalue of type T2 using the cast const_cast<T2&>;
   • a glvalue of type T1 can be explicitly converted to an xvalue of type T2 using the cast const_cast<T2&&>; and
   • if T1 is a class type, a prvalue of type T1 can be explicitly converted to an xvalue of type T2 using the cast const_cast<T2&&>. The temporary materialization conversion is performed on v.

   The result of a reference const_cast refers to the original same object if as the (possibly converted) operand is a glvalue and to the result of applying the temporary materialization conversion (7.3.5 [conv.rval]) otherwise.

4. Remove 7.6.1.11 [expr.const.cast] paragraph 5:

   A null pointer value (6.8.4 [basic.compound]) is converted to the null pointer value of the destination type. The null member pointer value (7.3.13 [conv.mem]) is converted to the null member pointer value of the destination type.

CWG 2024-05-31

The existing example in 7.6.1.11 [expr.const.cast] paragraph 3 shows the temporary materialization conversion applied to an array type. The example would be made ill-formed by the suggested resolution above. More investigation is advised.

Suggested resolution [SUPERSEDED]:

1. Change in 7.6.1.11 [expr.const.cast] paragraph 1 as follows:

   The result of the expression const_cast<T>(v) is of type T. If T is an lvalue reference to object type, the result is an lvalue; if T is an rvalue reference to object type, the result is an xvalue; otherwise, the result is a prvalue and the lvalue-to-rvalue (7.3.2 [conv.lval]), array-to-pointer (7.3.3 [conv.array]), and function-to-pointer (7.3.4 [conv.func]) standard conversions are performed on the expression v. The temporary materialization conversion (7.3.5 [conv.rval]) is not performed on v, other than as specified below. Conversions that can be performed explicitly using const_cast are listed below. No other conversion shall be performed explicitly using const_cast.

2. Change in 7.6.1.11 [expr.const.cast] paragraph 3 as follows:

   For two similar object pointer or pointer to data member types T1 and T2 (7.3.6 [conv.qual]), a prvalue of type T1 may can be explicitly converted to the type T2 using a const_cast if, considering the qualification-decompositions of both types, each Pi1 is the same as Pi2 for all i. The result of a const_cast refers to the original entity. If v is a null pointer or null member pointer, the result is a null pointer or null member pointer, respectively. Otherwise, the result points to or past the end of the same object, or points to the same member, respectively, as v. [Example 1:

     typedef int *A[3];                // array of 3 pointer to int
     typedef const int *const CA[3];   // array of 3 const pointer to const int
     CA &&r = A{};        // OK, reference binds to temporary array object
                          // after qualification conversion to type CA
     A &&r1 = const_cast<A>(CA{});     // error: temporary array decayed to pointer
   
     A &&r2 = const_cast<A&&>(CA{});    // OK
   

   -- end example]

3. Change in 7.6.1.11 [expr.const.cast] paragraph 4 as follows:

   For two object types T1 and T2, if a pointer to T1 can be explicitly converted to the type “pointer to T2” using a const_cast, then the following conversions can also be made:

   • an lvalue of type T1 can be explicitly converted to an lvalue of type T2 using the cast const_cast<T2&>;
   • a glvalue of type T1 can be explicitly converted to an xvalue of type T2 using the cast const_cast<T2&&>; and
   • if T1 is a class or array type, a prvalue of type T1 can be explicitly converted to an xvalue of type T2 using the cast const_cast<T2&&>. The temporary materialization conversion is performed on v.

   The result of a reference const_cast refers to the original same object if as the (possibly converted) operand is a glvalue and to the result of applying the temporary materialization conversion (7.3.5 [conv.rval]) otherwise.

   [Example 2:

     typedef int *A[3];                // array of 3 pointer to int
     typedef const int *const CA[3];   // array of 3 const pointer to const int
   
     auto &&r2 = const_cast<A&&>(CA{}); // OK, temporary materialization conversion is performed
   

   -- end example]

4. Remove 7.6.1.11 [expr.const.cast] paragraph 5:

   A null pointer value (6.8.4 [basic.compound]) is converted to the null pointer value of the destination type. The null member pointer value (7.3.13 [conv.mem]) is converted to the null member pointer value of the destination type.

5. Change in 9.5.4 [dcl.init.ref] bullet 5.3 as follows:

   [Example 5: ...

     constexpr int f() {
       const int &x = 42;
       const_cast<int &>(x) = 1;  // undefined behavior
       return x;
     }
     constexpr int z = f();          // error: not a constant expression
   

     typedef int *AP[3];        // array of 3 pointer to int
     typedef const int *const ACPC[3]; // array of 3 const pointer to const int
     ACPC &&r = AP{};          // binds directly
   

   -- end example]

This resolution also resolve issue 1965.

CWG 2024-10-11

Subclause 7.2.1 [basic.lval] paragraph 7 should be amended with "unless otherwise specified" and cross-references to the exceptions.

Proposed resolution (approved by CWG 2024-10-25)

1. Change in 7.2.1 [basic.lval] paragraph 7 as follows:

   Whenever Unless otherwise specified (7.6.1.11 [expr.const.cast]), whenever a prvalue appears as an operand of an operator that expects a glvalue for that operand, the temporary materialization conversion (7.3.5 [conv.rval]) is applied to convert the expression to an xvalue.

2. Change in 7.6.1.11 [expr.const.cast] paragraph 1 as follows:

   The result of the expression const_cast<T>(v) is of type T. If T is an lvalue reference to object type, the result is an lvalue; if T is an rvalue reference to object type, the result is an xvalue; otherwise, the result is a prvalue and the lvalue-to-rvalue (7.3.2 [conv.lval]), array-to-pointer (7.3.3 [conv.array]), and function-to-pointer (7.3.4 [conv.func]) standard conversions are performed on the expression v. The temporary materialization conversion (7.3.5 [conv.rval]) is not performed on v, other than as specified below. Conversions that can be performed explicitly using const_cast are listed below. No other conversion shall be performed explicitly using const_cast.

3. Change in 7.6.1.11 [expr.const.cast] paragraph 3 as follows:

   For two similar object pointer or pointer to data member types T1 and T2 (7.3.6 [conv.qual]), a prvalue of type T1 may can be explicitly converted to the type T2 using a const_cast if, considering the qualification-decompositions of both types, each Pi1 is the same as Pi2 for all i. The result of a const_cast refers to the original entity. If v is a null pointer or null member pointer, the result is a null pointer or null member pointer, respectively. Otherwise, the result points to or past the end of the same object, or points to the same member, respectively, as v. [Example 1:

     typedef int *A[3];                // array of 3 pointer to int
     typedef const int *const CA[3];   // array of 3 const pointer to const int
     CA &&r = A{};        // OK, reference binds to temporary array object
                          // after qualification conversion to type CA
     A &&r1 = const_cast<A>(CA{});     // error: temporary array decayed to pointer
   
     A &&r2 = const_cast<A&&>(CA{});    // OK
   

   -- end example]

4. Change in 7.6.1.11 [expr.const.cast] paragraph 4 as follows:

   For two object types T1 and T2, if a pointer to T1 can be explicitly converted to the type “pointer to T2” using a const_cast, then the following conversions can also be made:

   • an lvalue of type T1 can be explicitly converted to an lvalue of type T2 using the cast const_cast<T2&>;
   • a glvalue of type T1 can be explicitly converted to an xvalue of type T2 using the cast const_cast<T2&&>; and
   • if T1 is a class or array type, a prvalue of type T1 can be explicitly converted to an xvalue of type T2 using the cast const_cast<T2&&>. The temporary materialization conversion is performed on v.

   The result of a reference const_cast refers to the original same object if as the (possibly converted) operand is a glvalue and to the result of applying the temporary materialization conversion (7.3.5 [conv.rval]) otherwise.

   [Example 2:

     typedef int *A[3];                // array of 3 pointer to int
     typedef const int *const CA[3];   // array of 3 const pointer to const int
   
     auto &&r2 = const_cast<A&&>(CA{}); // OK, temporary materialization conversion is performed
   

   -- end example]

5. Remove 7.6.1.11 [expr.const.cast] paragraph 5:

   A null pointer value (6.8.4 [basic.compound]) is converted to the null pointer value of the destination type. The null member pointer value (7.3.13 [conv.mem]) is converted to the null member pointer value of the destination type.

6. Change in 9.5.4 [dcl.init.ref] bullet 5.3 as follows:

   [Example 5: ...

     constexpr int f() {
       const int &x = 42;
       const_cast<int &>(x) = 1;  // undefined behavior
       return x;
     }
     constexpr int z = f();          // error: not a constant expression
   

     typedef int *AP[3];        // array of 3 pointer to int
     typedef const int *const ACPC[3]; // array of 3 const pointer to const int
     ACPC &&r = AP{};          // binds directly
   

   -- end example]

This resolution also resolve issue 1965.

2823. Implicit undefined behavior when dereferencing pointers

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

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

The unary * operator performs indirection. Its operand shall be a prvalue of type “pointer to T”, where T is an object or function type. The operator yields an lvalue of type T denoting the object or function to which the operand points.

It is unclear what happens if the operand does not point to an object or function.

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

Change in 7.6.2.2 [expr.unary.op] paragraph 1 as follows:

The unary * operator performs indirection. Its operand shall be a prvalue of type “pointer to T”, where T is an object or function type. The operator yields an lvalue of type T denoting the object or function to which the operand points. If the operand points to an object or function, the result denotes that object or function; otherwise, the behavior is undefined except as specified in 7.6.1.8 [expr.typeid].

2668. co_await in a lambda-expression

[Accepted as a DR at the March, 2024 meeting.]

Subclause 7.6.2.4 [expr.await] paragraph 2 disallows an await-expression to appear in the body of a lambda-expression:

An await-expression shall appear only in a potentially-evaluated expression within the compound-statement of a function-body outside of a handler (14.1 [except.pre]). ...

This is probably unintended.

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

Change in 7.6.2.4 [expr.await] paragraph 2 as follows:

An await-expression shall appear only in as a potentially-evaluated expression within the compound-statement of a function-body or lambda-expression, in either case outside of a handler (14.1 [except.pre]). ...

2722. Temporary materialization conversion for noexcept operator

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

It is unclear whether noexcept(A()) applies the temporary materialization conversion to the prvalue A(). The resolution of issue 1354 suggests that it does so that the destructor is (notionally) invoked.

Proposed resolution (approved by CWG 2023-05-12):

Change in 7.6.2.7 [expr.unary.noexcept] paragraph 3 as follows:

If the operand is a prvalue, the temporary materialization conversion (7.3.5 [conv.rval]) is applied. The result of the noexcept operator is true unless the expression full-expression of the operand is potentially-throwing (14.5 [except.spec]).

2792. Clean up specification of noexcept operator

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

The introductory sentence "can throw an exception" is misleading, because it might be interpreted to cover exceptions thrown as the result of encountering undefined behavior.

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

Change all of 7.6.2.7 [expr.unary.noexcept] as follows:

The noexcept operator determines whether the evaluation of its operand, which is an unevaluated operand (7.2.3 [expr.context]), can throw an exception (14.2 [except.throw]).

noexcept-expression:
        noexcept ( expression )

The operand of the noexcept operator is an unevaluated operand (7.2.3 [expr.context]). If the operand is a prvalue, the temporary materialization conversion (7.3.5 [conv.rval]) is applied.

The result of the noexcept operator is a prvalue of type bool. The result is false if the full-expression of the operand is potentially-throwing (14.5 [except.spec]), and true otherwise.

[Note 1: A noexcept-expression is an integral constant expression (7.7 [expr.const]). —end note]

If the operand is a prvalue, the temporary materialization conversion (7.3.5 [conv.rval]) is applied. The result of the noexcept operator is true unless the full-expression of the operand is potentially-throwing (14.5 [except.spec]).

2102. Constructor checking in new-expression

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

According to 7.6.2.8 [expr.new] paragraph 25,

If the new-expression creates an object or an array of objects of class type, access and ambiguity control are done for the allocation function, the deallocation function (11.4.11 [class.free]), and the constructor (11.4.5 [class.ctor]).

The mention of “the constructor” here is strange. For the “object of class type” case, access and ambiguity control are done when we perform initialization in paragraph 17, and we might not be calling a constructor anyway (for aggregate initialization). This seems wrong.

For the “array of objects of class type” case, it makes slightly more sense (we need to check the trailing array elements can be default-initialized) but again (a) we aren't necessarily using a constructor, (b) we should say which constructor — and we may need overload resolution to find it, and (c) shouldn't this be part of initialization, so we can distinguish between the cases where we should copy-initialize from {} and the cases where we should default-initialize?

Additional notes (May, 2023):

It is unclear whether default-initialization is required to be well-formed even for an array with no elements.

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

1. Insert a new paragraph before 7.6.2.8 [expr.new] paragraph 9:

   If the allocated type is an array, the new-initializer is a braced-init-list, and the expression is potentially-evaluated and not a core constant expression, the semantic constraints of copy-initializing a hypothetical element of the array from an empty initializer list are checked (9.5.5 [dcl.init.list]). [ Note: The array can contain more elements than there are elements in the braced-init-list, requiring initialization of the remainder of the array elements from an empty initializer list. -- end note ]

   Objects created by a new-expression have dynamic storage duration (6.7.6.5 [basic.stc.dynamic]). ...

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

   If the new-expression creates an object or an array of objects of class type, access and ambiguity control are done for the allocation function, the deallocation function (6.7.6.5.3 [basic.stc.dynamic.deallocation]), and the constructor (11.4.5 [class.ctor]) selected for the initialization (if any). If the new-expression creates an array of objects of class type, the destructor is potentially invoked (11.4.7 [class.dtor]).

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

   A declaration of a placement deallocation function matches the declaration of a placement allocation function if it has the same number of parameters and, after parameter transformations (9.3.4.6 [dcl.fct]), all parameter types except the first are identical. If the lookup finds a single matching deallocation function, that function will be called; otherwise, no deallocation function will be called. If the lookup finds a usual deallocation function and that function, considered as a placement deallocation function, would have been selected as a match for the allocation function, the program is ill-formed. For a non-placement allocation function, the normal deallocation function lookup is used to find the matching deallocation function (7.6.2.9 [expr.delete]). In any case, the matching deallocation function (if any) shall be non-deleted and accessible from the point where the new-expression appears.

4. Change in 9.5.1 [dcl.init.general] paragraph 7 as follows:

   To default-initialize an object of type T means:

   • ...
   • If T is an array type, the semantic constraints of default-initializing a hypothetical element shall be met and each element is default-initialized.
   • ...

5. Change in 9.5.1 [dcl.init.general] paragraph 9 as follows:

   To value-initialize an object of type T means:

   • if If T is a (possibly cv-qualified) class type (Clause 11 [class]), then
     • if T has either no default constructor (11.4.5.2 [class.default.ctor]) or a default constructor that is user-provided or deleted, then the object is default-initialized;
     • otherwise, the object is zero-initialized and the semantic constraints for default-initialization are checked, and if T has a non-trivial default constructor, the object is default-initialized;.
   • if If T is an array type, the semantic constraints of value-initializing a hypothetical element shall be met and each element is value-initialized;.
   • otherwiseOtherwise, the object is zero-initialized.

2729. Meaning of new-type-id

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

Subclause 7.6.2.8 [expr.new] paragraph 1 introduces the grammar non-terminal new-type-id, but never specifies its meaning.

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

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

   The new-expression attempts to create an object of the type-id (9.3.2 [dcl.name]) or new-type-id (9.3.2 [dcl.name]) to which it is applied. The type of that object is the allocated type. This type shall be a complete object type (6.8.1 [basic.types.general]), but not an abstract class type (11.7.4 [class.abstract]) or array thereof (6.7.2 [intro.object]).

2. Change in 9.3.2 [dcl.name] paragraph 1 as follows:

   To specify type conversions explicitly, and as an argument of sizeof, alignof, new, or typeid, the name of a type shall be specified. This can be done with a type-id or new-type-id (7.6.2.8 [expr.new]), which is syntactically a declaration for a variable or function of that type that omits the name of the entity.

2728. Evaluation of conversions in a delete-expression

[Accepted as a DR at the June, 2024 meeting.]

Subclause 7.6.2.9 [expr.delete] paragraph 4 specifies:

The cast-expression in a delete-expression shall be evaluated exactly once.

Due to the reference to the syntactic non-terminal cast-expression, it is unclear whether that includes the conversion to pointer type specified in 7.6.2.9 [expr.delete] paragraph 2.

Proposed resolution (approved by CWG 2024-03-01) [SUPERSEDED]:

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

   ... The operand shall be of class type or a prvalue of pointer to object type or of class type. If of class type, the operand is contextually implicitly converted (7.3 [conv]) to a prvalue pointer to object type. [ Footnote: ... ] The converted operand is used in place of the original operand for the remainder of this subclause. The delete-expression has type void.

   If the operand has a class type, the operand is converted to a pointer type by calling the above-mentioned conversion function, and the converted operand is used in place of the original operand for the remainder of this subclause. ...

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

   The cast-expression in operand of a delete-expression shall be evaluated exactly once.

Proposed resolution (approved by CWG 2024-03-20):

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

   ... The first alternative is a single-object delete expression, and the second is an array delete expression. Whenever the delete keyword is immediately followed by empty square brackets, it shall be interpreted as the second alternative. [ Footnote: ... ] If the operand is of class type, it is contextually implicitly converted (7.3 [conv]) to a pointer to object type and the converted operand is used in place of the original operand for the remainder of this subclause. [ Footnote: ...] Otherwise, it shall be a prvalue of pointer to object type. The delete-expression has type void.

   If the operand has a class type, the operand is converted to a pointer type by calling the above-mentioned conversion function, and the converted operand is used in place of the original operand for the remainder of this subclause. ...

2. Delete 7.6.2.9 [expr.delete] paragraph 4:

   The cast-expression in a delete-expression shall be evaluated exactly once.

2758. What is "access and ambiguity control"?

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

Subclause 7.6.2.9 [expr.delete] paragraph 12 specifies:

Access and ambiguity control are done for both the deallocation function and the destructor (11.4.7 [class.dtor], 11.4.11 [class.free]).

It is unclear what that means. In particular, ambiguity checking is part of overload resolution, and access checking requires a point of reference.

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

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

   If the value of the operand of the delete-expression is not a null pointer value and the selected deallocation function (see below) is not a destroying operator delete, evaluating the delete-expression will invoke invokes the destructor (if any) for the object or the elements of the array being deleted. The destructor shall be accessible from the point where the delete-expression appears. In the case of an array, the elements will be are destroyed in order of decreasing address (that is, in reverse order of the completion of their constructor; see 11.9.3 [class.base.init]).

2. Change in 7.6.2.9 [expr.delete] paragraph 10

   If more than one deallocation function is found, the The deallocation function to be called is selected as follows:

   • ...

   Unless the deallocation function is selected at the point of definition of the dynamic type's virtual destructor, the selected deallocation function shall be accessible from the point where the delete-expression appears.

3. Remove 7.6.2.9 [expr.delete] paragraph 12:

   Access and ambiguity control are done for both the deallocation function and the destructor (11.4.7 [class.dtor], 11.4.11 [class.free]).

2828. Ambiguous interpretation of C-style cast

[Accepted as a DR at the March, 2024 meeting.]

(From editorial issue 5355.)

Consider:

   int*** ptr = 0;
   auto t = (int const*const*const*)ptr;

There is more than one way how this can be interpreted as a static_cast followed by a const_cast, namely:

  const_cast<int const * const * const * >(static_cast<int * * const * >(ptr));
  const_cast<int const * const * const * >(static_cast<int * const * const * >(ptr));

Subclause 7.6.3 [expr.cast] paragraph 4 makes such a program ill-formed:

... If a conversion can be interpreted in more than one way as a static_cast followed by a const_cast, the conversion is ill-formed.

Proposed resolution (approved by CWG 2024-03-20):

Change in 7.6.3 [expr.cast] paragraph 4 as follows:

... If a conversion can be interpreted in more than one of the ways listed above, the interpretation that appears first in the list is used, even if a cast resulting from that interpretation is ill-formed. If a conversion can be interpreted in more than one way as a static_cast followed by a const_cast is used and the conversion can be interpreted in more than one way as such, the conversion is ill-formed. [ Example 1 :

  struct A { };
  struct I1 : A { };
  struct I2 : A { };
  struct D : I1, I2 { };
  A* foo( D* p ) {
    return (A*)( p );  // ill-formed static_cast interpretation
  }

  int*** ptr = 0;
  auto t = (int const*const*const*)ptr;  // OK, const_cast interpretation

  struct S {
    operator const int*();
    operator volatile int*();
  };
  int *p = (int*)S();  // error: two possible interpretations using static_cast followed by const_cast

-- end example ]

2853. Pointer arithmetic with pointer to hypothetical element

[Accepted as a DR at the March, 2024 meeting.]

(From submission #495.)

The phrasing in 7.6.6 [expr.add] bullet 4.2 excludes pointer arithmetic on a pointer pointing to the hypothetical (past-the-end) array element.

Proposed resolution (approved by CWG 2024-02-16):

Change in 7.6.6 [expr.add] bullet 4.2 as follows:

• ...
• Otherwise, if P points to an a (possibly-hypothetical) array element i of an array object x with n elements (9.3.4.5 [dcl.array]), [ Footnote: ... ] the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) array element i + j of x if 0 <= i + j <= n and the expression P - J points to the (possibly-hypothetical) array element i - j of x if 0 <= i - j <= n.

2724. Clarify rounding for arithmetic right shift

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

(From editorial issue 6225.)

Subclause 7.6.7 [expr.shift] paragraph 3 specifies:

The value of E1 >> E2 is E1/2^E2, rounded down.

It is unclear whether "rounded down" means "towards zero" or "towards negative infinity".

Proposed resolution (approved by CWG 2023-05-12):

Change in 7.6.7 [expr.shift] paragraph 3 as follows:

The value of E1 >> E2 is E1/2^E2, rounded down towards negative infinity.

2749. Treatment of "pointer to void" for relational comparisons

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

(From editorial issue 6173.)

Subclause 7.6.9 [expr.rel] paragraph 4 and paragraph 5 specify:

The result of comparing unequal pointers to objects [ Footnote: ] is defined in terms of a partial order consistent with the following rules: ...

[Note 1: A relational operator applied to unequal function pointers or to unequal pointers to void yields an unspecified result. -- end note]

Comparing pointers to objects that are stored in a variable of type "pointer to void" should be fine.

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

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

The result of comparing unequal pointers to objects [ Footnote: ... ] is defined in terms of a partial order consistent with the following rules: ...

[Note 1: A relational operator applied to unequal function pointers or to unequal pointers to void yields an unspecified result. A pointer value of type "pointer to cv void" can point to an object (6.8.4 [basic.compound]). -- end note]

2796. Function pointer conversions for relational operators

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

Consider:

  void f() {}
  void g() noexcept {}

  void q() {
    bool b1 = f == g;     // OK
    bool b2 = f > g;      // error: different types
  }

For the equality operators, 7.6.10 [expr.eq] paragraph 3 specifies:

If at least one of the operands is a pointer, pointer conversions (7.3.12 [conv.ptr]), function pointer conversions (7.3.14 [conv.fctptr]), and qualification conversions (7.3.6 [conv.qual]) are performed on both operands to bring them to their composite pointer type (7.2.2 [expr.type]). Comparing pointers is defined as follows: ...

In contrast, the corresponding rule for relational operators in 7.6.9 [expr.rel] paragraph 3 specifies:

The usual arithmetic conversions (7.4 [expr.arith.conv]) are performed on operands of arithmetic or enumeration type. If both operands are pointers, pointer conversions (7.3.12 [conv.ptr]) and qualification conversions (7.3.6 [conv.qual]) are performed to bring them to their composite pointer type (7.2.2 [expr.type]). After conversions, the operands shall have the same type.

However, all major implementations accept the example.

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

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

The usual arithmetic conversions (7.4 [expr.arith.conv]) are performed on operands of arithmetic or enumeration type. If both operands are pointers, pointer conversions (7.3.12 [conv.ptr]), function pointer conversions (7.3.14 [conv.fctptr]), and qualification conversions (7.3.6 [conv.qual]) are performed to bring them to their composite pointer type (7.2.2 [expr.type]). After conversions, the operands shall have the same type.

2865. Regression on result of conditional operator

[Accepted as a DR at the June, 2024 meeting.]

Consider:

  #include <concepts>

  template <class T> T get();

  template <class T>
  using X = decltype(true ? get<T const&>() : get<T>());

  struct C { };

  static_assert(std::same_as<X<int>, int>);
  static_assert(std::same_as<X<C>, C const>);  // #1

Before Issue 1895, #1 was well-formed. With the reformulation based on conversion sequences, #1 is now ill-formed because both conversion sequences can be formed.

Proposed resolution (approved by CWG 2024-05-03):

Change in 7.6.16 [expr.cond] bullet 4.3 as follows:

• ...
• If E2 is a prvalue or if neither of the conversion sequences above can be formed and at least one of the operands has (possibly cv-qualified) class type:
  • if T1 and T2 are the same class type (ignoring cv-qualification):
    • and if T2 is at least as cv-qualified as T1, the target type is T2,
    • otherwise, no conversion sequence is formed for this operand;
  • otherwise, if T2 is a base class of T1, the target type is cv1 T2, where cv1 denotes the cv-qualifiers of T1, ;
  • otherwise, the target type is the type that E2 would have after applying the lvalue-to-rvalue (7.3.2 [conv.lval]), array-to-pointer (7.3.3 [conv.array]), and function-to-pointer (7.3.4 [conv.func]) standard conversions.

2906. Lvalue-to-rvalue conversion of class types for conditional operator

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

(From submission #550.)

There are two known situations where the lvalue-to-rvalue conversion is applied to class types, which can be non-constexpr even if the resulting copy constructor invocation would be constexpr (7.7 [expr.const] bullet 5.9). The other such situation is 7.6.1.3 [expr.call] paragraph 11. Here, the concern is with 7.6.16 [expr.cond] paragraph 7, which can be invoked for class types; for example:

  struct S {};
  S a;
  constexpr S b = a;        // OK, call to implicitly-declared copy constructor
  constexpr S d = false ? S{} : a; // error: lvalue-to-rvalue conversion of 'a' is not a constant expression

Major implementations disagree with the ill-formed outcome.

Proposed resolution (approved by CWG 2024-06-26):

Change in 7.6.16 [expr.cond] paragraph 7 as follows:

Otherwise, the result is a prvalue. If the second and third operands do not have the same type, ...

Lvalue-to-rvalue (7.3.2 [conv.lval]), array-to-pointer Array-to-pointer (7.3.3 [conv.array]), and function-to-pointer (7.3.4 [conv.func]) standard conversions are performed on the second and third operands. After those conversions, one of the following shall hold:

• The second and third operands have the same type; the result is of that type and the result object is initialized copy-initialized using the selected operand.
• The second and third operands have arithmetic or enumeration type; the usual arithmetic conversions (7.4 [expr.arith.conv]) are performed to bring them to a common type, and the result is of that type.
• One or both of the second and third operands have pointer type; lvalue-to-rvalue (7.3.2 [conv.lval]), pointer conversions (7.3.12 [conv.ptr]), function pointer conversions (7.3.14 [conv.fctptr]), and qualification conversions (7.3.6 [conv.qual]) are performed to bring them to their composite pointer type (7.2.2 [expr.type]). The result is of the composite pointer type.
• One or both of the second and third operands have pointer-to-member type; lvalue-to-rvalue (7.3.2 [conv.lval]), pointer to member conversions (7.3.13 [conv.mem]), function pointer conversions (7.3.14 [conv.fctptr]), and qualification conversions (7.3.6 [conv.qual]) are performed to bring them to their composite pointer type (7.2.2 [expr.type]). The result is of the composite pointer type.
• Both the second and third operands have type std::nullptr_t or one has that type and the other is a null pointer constant. The result is of type std::nullptr_t.

2699. Inconsistency of throw-expression specification

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

Subclause 7.6.18 [expr.throw] paragraph 2 and 3 specify:

Evaluating a throw-expression with an operand throws an exception (14.2 [except.throw]); the type of the exception object is determined by removing any top-level cv-qualifier s from the static type of the operand and adjusting the type from “array of T” or function type T to “pointer to T”.

A throw-expression with no operand rethrows the currently handled exception (14.4 [except.handle]). The exception is reactivated with the existing exception object; no new exception object is created. The exception is no longer considered to be caught.

This means that throwing a value of type const char[3] would throw a char* rather than const char*, which is not intended.

Proposed resolution (approved by CWG 2023-03-03):

Change in 7.6.18 [expr.throw] paragraph 2 through 4 as follows:

Evaluating a A throw-expression with an operand throws an exception (14.2 [except.throw]); the. The array-to-pointer (7.3.3 [conv.array]) and function-to-pointer (7.3.4 [conv.func]) standard conversions are performed on the operand. The type of the exception object is determined by removing any top-level cv-qualifiers from the static type of the (possibly converted) operand and adjusting the type from “array of T” or function type T to “pointer to T”.

A throw-expression with no operand rethrows the currently handled exception (14.4 [except.handle]). If no exception is presently being handled, the function std:: terminate is invoked (14.6.2 [except.terminate]). The Otherwise, the exception is reactivated with the existing exception object; no new exception object is created. The exception is no longer considered to be caught.

If no exception is presently being handled, evaluating a throw-expression with no operand calls std:: terminate() (14.6.2 [except.terminate]).

2711. Source for copy-initializing the exception object

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

Neither 14.2 [except.throw] nor 7.6.18 [expr.throw] specifiy the source for copy-initializing the exception object.

Proposed resolution (based on the resolution of issue 2699; approved by CWG 2023-06-12):

1. Change in 7.6.18 [expr.throw] paragraph 2 as follows:

   Evaluating a throw-expression with an operand throws an exception (14.2 [except.throw]); the type of the exception object is determined by removing any top-level cv-qualifiers from the static type of the operand and adjusting the type from “array of T” or function type T to “pointer to T”. The exception object is copy-initialized (9.5.1 [dcl.init.general]) from the (possibly converted) operand.

2. Change in 14.2 [except.throw] paragraph 3 as follows:

   Throwing an exception copy-initializes (9.5 [dcl.init], 11.4.5.3 [class.copy.ctor]) a temporary object, called the exception object. If the type of the exception object would be an incomplete type (6.8.1 [basic.types.general]), an abstract class type (11.7.4 [class.abstract]), or a pointer to an incomplete type other than cv void (6.8.4 [basic.compound]), the program is ill-formed.

2944. Unsequenced throw-expressions

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

(From submission #626.)

The semantics of unsequenced throw-expressions is unclear. For example:

  (throw /* ... */, 0) + (throw /* ... */, 0);

This appears to cause two unsequenced transfers of control, which makes little sense. In contrast, a co_await expression is indivisible (6.9.1 [intro.execution] paragraph 11) per issue 2466.

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

Change in 6.9.1 [intro.execution] paragraph 11 as follows, adding bullets:

When invoking a function (whether or not the function is inline), every argument expression and the postfix expression designating the called function are sequenced before every expression or statement in the body of the called function. For each

• function invocation,
• evaluation of an await-expression (7.6.2.4 [expr.await]), or
• evaluation of a throw-expression (7.6.18 [expr.throw])

F, each evaluation that does not occur within F but is evaluated on the same thread and as part of the same signal handler (if any) is either sequenced before all evaluations that occur within F or sequenced after all evaluations that occur within F; [ Foonote: ... ] if F invokes or resumes a coroutine (7.6.2.4 [expr.await]), only evaluations subsequent to the previous suspension (if any) and prior to the next suspension (if any) are considered to occur within F.

CWG 2024-11-08

Check with implementers (in particular MSVC) that the proposed resolution is acceptable.

2768. Assignment to enumeration variable with a braced-init-list

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

Consider:

   enum class E {E1};

   void f() {
     E e;
     e = E{0}; // #1
     e = {0};  // #2
   }

#1 first initializes a temporary of type E and then assigns that to e. For #2, 7.6.19 [expr.assign] bullet 8.1 specifies that #2 is equivalent to #1:

A braced-init-list may appear on the right-hand side of

• an assignment to a scalar, in which case the initializer list shall have at most a single element. The meaning of x = {v}, where T is the scalar type of the expression x, is that of x = T{v}. The meaning of x = {} is x = T{}.
• ...

However, there is no syntactic hint that #2 would invoke direct-initialization, and in fact gcc, icc, and MSVC reject #2, but clang accepts.

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

Change in 7.6.19 [expr.assign] paragraph 8 as follows:

A braced-init-list B may appear on the right-hand side of

• an assignment to a scalar of type T, in which case the initializer list B shall have at most a single element. The meaning of x = {v}B is x = t, where t is an invented temporary variable declared and initialized as T t = B, where T is the scalar type of the expression x, is that of x = T{v}. The meaning of x = {} is x = T{}.
• an assignment to an object of class type, in which case the initializer list B is passed as the argument to the assignment operator function selected by overload resolution (12.4.3.2 [over.assign], 12.2 [over.match]).

2552. Constant evaluation of non-defining variable declarations

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

Paper P2242 (Non-literal variables (and labels and gotos) in constexpr functions) added 7.7 [expr.const] bullet 5.2:

• a control flow that passes through a declaration of a variable with static (6.7.6.2 [basic.stc.static]) or thread (6.7.6.3 [basic.stc.thread]) storage duration;

It seems that block-scope extern (i.e. non-defining) declarations are covered by the above bullet, but only definitions should be in view here.

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

1. Change in 7.7 [expr.const] bullet 5.2 as follows:

   • a control flow that passes through a declaration of a block variable (6.4.3 [basic.scope.block]) with static (6.7.6.2 [basic.stc.static]) or thread (6.7.6.3 [basic.stc.thread]) storage duration;

2710. Loops in constant expressions

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

Iteration statements such as while and for loops are specified by equivalent code involving goto (8.6.2 [stmt.while] paragraph 2, 8.6.4 [stmt.for] paragraph 1, 8.6.5 [stmt.ranged] paragraph 1). The goto statement cannot be evaluated in constant expressions (7.7 [expr.const] bullet 5.30), thus while and for loops cannot be evaluated in constant expressions. Similar concerns arise for continue (8.7.3 [stmt.cont] paragraph 1).

However, that is neither intended nor existing practice.

Suggested resolution [SUPERSEDED]:

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

An expression E is a core constant expression unless the evaluation of E, following the rules of the abstract machine (6.9.1 [intro.execution]), would evaluate one of the following:

• ...
• a goto statement (8.7.6 [stmt.goto]) unless it is introduced by replacing an iteration-statement (8.6 [stmt.iter]) or a continue statement (8.7.3 [stmt.cont]) with its equivalent.

CWG 2023-03-30

Keep the rule non-normative and non-exhaustive.

Proposed resolution (approved by CWG 2023-04-28):

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

An expression E is a core constant expression unless the evaluation of E, following the rules of the abstract machine (6.9.1 [intro.execution]), would evaluate one of the following:

• ...
• a goto statement (8.7.6 [stmt.goto]). [ Note: A goto statement introduced by equivalence (Clause 8 [stmt]) is not in scope. For example, a while statement (8.6.2 [stmt.while]) can be executed during constant evaluation. -- end note ].

2750. construct_at without constructor call

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

Subclause 7.7 [expr.const] paragraph 6 talks about invoking the "underlying constructor", but there is no constructor when creating an aggregate or a scalar type.

Proposed resolution:

For the purposes of determining whether an expression E is a core constant expression, the evaluation of 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, is ignored. Similarly, the evaluation of the body of std::construct_at or std::ranges::construct_at is considered to include only the underlying constructor call initialization of the T object 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.

2755. Incorrect wording applied by P2738R1

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

P2738R1 (constexpr cast from void*: towards constexpr type-erasure) applied incorrect wording to 7.7 [expr.const] bullet 5.14:

• ...
• a conversion from a prvalue P of type ”pointer to cv void” to a pointer-to-object type T unless P points to an object whose type is similar to T;
• ...

The issue is that T is defined to be a pointer type, but the "similar to" phrasing uses it as the pointee type.

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

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

• ...
• a conversion from a prvalue P of type ”pointer to cv void” to a pointer-to-object type T "cv1 pointer to T", where T is not cv2 void, unless P points to an object whose type is similar to T;
• ...

2760. Defaulted constructor that is an immediate function

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

Consider:

  consteval int f(int);
  struct S {
   int x = f(0);
   S() = default;
  };

  int main() {
    S s;     // OK?
  }

Is S an immediate function?

The relevant specification is in 7.7 [expr.const] paragraph 18:

An immediate function is a function or constructor that is

• declared with the consteval specifier, or
• an immediate-escalating function F whose function body contains an immediate-escalating expression E such that E's innermost enclosing non-block scope is F's function parameter scope.

Suggested resolution [SUPERSEDED]:

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

An immediate function is a function or constructor that is

• declared with the consteval specifier, or
• an immediate-escalating function F whose function body contains an immediate-escalating expression E such that E's innermost enclosing non-block scope is F's function parameter scope, or
• an immediate-escalating default constructor of a class which has at least one non-static data member with an immediate-escalating default member initializer.

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

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

   An immediate function is a function or constructor that is

   • declared with the consteval specifier, or
   • an immediate-escalating function F whose function body contains an immediate-escalating expression E such that E's innermost enclosing non-block scope is F's function parameter scope. [ Note: Default member initializers used to initialize a base or member subobject (11.9.3 [class.base.init]) are considered to be part of the function body (9.6.1 [dcl.fct.def.general]). -- end note ]

2. Change in 9.6.1 [dcl.fct.def.general] paragraph 1 as follows:

   Any informal reference to the body of a function should be interpreted as a reference to the non-terminal function-body, including, for a constructor, default member initializers or default initialization used to initialize a base or member subobject in the absence of a mem-initializer-id (11.9.3 [class.base.init]).

2763. Ignorability of [[noreturn]] during constant evaluation

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

Subclause 9.13.10 [dcl.attr.noreturn] paragraph 2 specifies:

If a function f is called where f was previously declared with the noreturn attribute and f eventually returns, the behavior is undefined.

Undefineed behavior is, in general, detected during constant evaluation, thus requiring an implementation to actually support the noreturn attribute, such as in the following example:

  [[noreturn]] constexpr void f() {}
  constexpr int x = (f(), 0);

It might be desirable to treat the assume and noreturn attributes alike in that regard.

Proposed resolution (approved by CWG 2023-07-14) [SUPERSEDED]:

Split into a separate paragraph and change 7.7 [expr.const] paragraph 5 as follows:

It is unspecified whether E is a core constant expression if E satisfies the constraints of a core constant expression, but evaluation of E would evaluate

• an operation that has undefined behavior as specified in Clause 16 through Clause 33,
• an invocation of the va_start macro (17.14.2 [cstdarg.syn]), or
• a return statement in a function that was previously declared with the noreturn attribute (9.13.10 [dcl.attr.noreturn]), or
• a statement with an assumption (9.13.3 [dcl.attr.assume]) whose converted conditional-expression, if evaluated where the assumption appears, would not disqualify E from being a core constant expression and would not evaluate to true. [ Note: .... ]

CWG 2023-07-14

As an alternative, all of 9.13 [dcl.attr] could be added to the "library undefined behavior" bullet. However, CWG felt that a case-by-case consideration is warranted, given that assumptions set precedent in requiring special treatment.

Possible resolution (reviewed by CWG 2023-08-25) [SUPERSEDED]:

Split into a separate paragraph and change 7.7 [expr.const] paragraph 5 as follows:

• ...
• an operation that would have undefined behavior as specified in Clause 4 [intro] through Clause 15 [cpp], excluding 9.13.3 [dcl.attr.assume] and 9.13.10 [dcl.attr.noreturn]; [ Footnote: ...]
• ...

It is unspecified whether E is a core constant expression if E satisfies the constraints of a core constant expression, but evaluation of E would evaluate

• an operation that has undefined behavior as specified in Clause 16 through Clause 33,
• an invocation of the va_start macro (17.14.2 [cstdarg.syn]), or
• a return statement in a function that was previously declared with the noreturn attribute (9.13.10 [dcl.attr.noreturn]), or
• a statement with an assumption (9.13.3 [dcl.attr.assume]) whose converted conditional-expression, if evaluated where the assumption appears, would not disqualify E from being a core constant expression and would not evaluate to true. [ Note: .... ]

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

Split into a separate paragraph and change 7.7 [expr.const] paragraph 5 as follows:

• ...
• an operation that would have undefined behavior as specified in Clause 4 [intro] through Clause 15 [cpp], excluding 9.13.3 [dcl.attr.assume] and 9.13.10 [dcl.attr.noreturn]; [ Footnote: ...]
• ...

It is unspecified whether E is a core constant expression if E satisfies the constraints of a core constant expression, but evaluation of E would evaluate

• an operation that has undefined behavior as specified in Clause 16 through Clause 33,
• an invocation of the va_start macro (17.14.2 [cstdarg.syn]), or
• a call to a function that was previously declared with the noreturn attribute (9.13.10 [dcl.attr.noreturn]) and that call returns to its caller, or
• a statement with an assumption (9.13.3 [dcl.attr.assume]) whose converted conditional-expression, if evaluated where the assumption appears, would not disqualify E from being a core constant expression and would not evaluate to true. [ Note: .... ]

2798. Manifestly constant evaluation of the static_assert message

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

The message of a static_assert declaration is a conditional-expression and thus is not manifestly constant evaluated. Consider this example:

  struct X {
    std::string s;
    const char *p;
  };
  consteval X f() { return {.s = "some long string that requires a heap allocation", .p = "hello"}; }

  static_assert(cond, f().p);

The example is ill-formed, because the immediate invocation f() lets a pointer to the heap escape.

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

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

   [Note 11: Except for a static_assert-message, a A manifestly constant-evaluated expression is evaluated even in an unevaluated operand (7.2.3 [expr.context]). —end note]

2. Change the grammar in 9.1 [dcl.pre] as follows:

   static_assert-message:
     unevaluated-string
     conditional-expression constant-expression
   

3. Change in 9.1 [dcl.pre] bullet 11.2 as follows:

   • ...
   • if the static_assert-message is a conditional-expression constant-expression M, ...

2851. Allow floating-point conversions in converted constant expressions

[Accepted as a DR at the March, 2024 meeting.]

(From submission #456.)

With the adoption of P1907R1, non-type template parameters of floating-point types have been introduced. It is surprising that a double value cannot be passed as a template argument for a template parameter of type long double, because floating-point conversions are not allowed in converted constant expressions.

Proposed resolution (approved by CWG 2024-02-16):

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

A converted constant expression of type T is an expression, implicitly converted to type T, where the converted expression is a constant expression and the implicit conversion sequence contains only

• user-defined conversions,
• lvalue-to-rvalue conversions (7.3.2 [conv.lval]),
• array-to-pointer conversions (7.3.3 [conv.array]),
• function-to-pointer conversions (7.3.4 [conv.func]),
• qualification conversions (7.3.6 [conv.qual]),
• integral promotions (7.3.7 [conv.prom]),
• integral conversions (7.3.9 [conv.integral]) other than narrowing conversions (9.5.5 [dcl.init.list]),
• floating-point promotions (7.3.8 [conv.fpprom]),
• floating-point conversions (7.3.10 [conv.double]) where the source value can be represented exactly in the destination type,
• null pointer conversions (7.3.12 [conv.ptr]) from std::nullptr_t,
• null member pointer conversions (7.3.13 [conv.mem]) from std::nullptr_t, and
• function pointer conversions (7.3.14 [conv.fctptr]),

and where the reference binding (if any) binds directly.

2907. Constant lvalue-to-rvalue conversion on uninitialized std::nullptr_t

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

(From submission #215.)

Consider:

  void f() {
    std::nullptr_t np;       // uninitialized, thus np contains an erroneous value
    constexpr void *p1 = np; // error: converted initializer is not a constant expression
  }

The lvalue-to-rvalue conversion on np does not actually read the value of np (7.3.2 [conv.lval] bullet 3.1), yet the situation is made ill-formed by 7.7 [expr.const] bullet 5.9.

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

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

An expression E is a core constant expression unless the evaluation of E, following the rules of the abstract machine (6.9.1 [intro.execution]), would evaluate one of the following:

• ...
• an lvalue-to-rvalue conversion (7.3.2 [conv.lval]) unless it is applied to
  • a glvalue of type cv std::nullptr_t,
  • a non-volatile glvalue that refers to an object that is usable in constant expressions, or
  • a non-volatile glvalue of literal type that refers to a non-volatile object whose lifetime began within the evaluation of E;
• ...

2909. Subtle difference between constant-initialized and constexpr

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

Subclause 7.7 [expr.const] paragraph 2 defines "constant-initialized" using the following rule:

A variable or temporary object o is constant-initialized if

• either it has an initializer or its default-initialization results in some initialization being performed, and
• ...

However, the rules for constexpr are slightly different, per 9.2.6 [dcl.constexpr] paragraph 6:

A constexpr specifier used in an object declaration declares the object as const. Such an object shall have literal type and shall be initialized. ...

The difference manifests for an example such as:

  struct S {};
  int main() {
    constexpr S s;       // OK
    constexpr S s2 = s;  // error: s is not constant-initialized
  }

Is the difference intentional?

Proposed resolution (approved by CWG 2024-10-25):

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

A variable or temporary object o is constant-initialized if

• either it has an initializer or its default-initialization results in some initialization being performed type is const-default-constructible (9.5.1 [dcl.init.general]), and
• ...

2922. constexpr placement-new is too permissive

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

constexpr placement new requires (just) pointer-interconvertibility for the argument pointer, whereas static_cast from void* to T* requires similarity. Requiring pointer-interconvertibility would not allow to differentiate two members of some union of the same type; such differentiation is required to diagnose access to inactive union members.

Proposed resolution (approved by CWG 2024-08-16):

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

• the selected allocation function is a non-allocating form (17.6.3.4 [new.delete.placement]) with an allocated type T, where
  • the placement argument to the new-expression points to an object that is pointer-interconvertible with an object of whose type is similar to T (7.3.6 [conv.qual]) or, if T is an array type, with to the first element of an object of a type similar to T, and
  • the placement argument points to storage whose duration began within the evaluation of E;

CWG 2024-11-19

The proposed resolution does not address the ambiguity with different union members of the same type, but is a good fix to increase consistency with static_cast regardless.

2825. Range-based for statement using a braced-init-list

[Accepted as a DR at the March, 2024 meeting.]

Consider:

  for (int i : { 1, 2, 3 })  // argument-dependent lookup for begin(std::initializer_list<int>)
    /* ... */;

This is undesirable; instead, a member function begin should be preferred.

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

Change in 8.6.5 [stmt.ranged] bullet 1.3 as follows:

begin-expr and end-expr are determined as follows:

• if the for-range-initializer is an expression of type of range is a reference to an array type R, begin-expr and end-expr are range and range + N, respectively, where N is the array bound. If R is an array of unknown bound or an array of incomplete type, the program is ill-formed;
• if the for-range-initializer is an expression of type of range is a reference to a class type C, and searches in the scope of C (6.5.2 [class.member.lookup]) for the names begin and end each find at least one declaration, begin-expr and end-expr are range .begin() and range .end(), respectively;
• otherwise, begin-expr and end-expr are begin(range ) and end(range ), respectively, where begin and end undergo argument-dependent lookup (6.5.4 [basic.lookup.argdep]). [Note 1: Ordinary unqualified lookup (6.5.3 [basic.lookup.unqual]) is not performed. —end note]

Additional notes (November, 2023)

Forwarded to EWG via paper issue 1694 for confirmation of the design direction.

EWG 2023-11-09

Approved by EWG.

2791. Unclear phrasing about "returning to the caller"

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

In 8.7.4 [stmt.return] and 8.7.5 [stmt.return.coroutine], the standard uses the phrasing "returns to its caller" when specifying return or co_return. It would be better to talk about transfer of control, which is a term used elsewhere in the standard.

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

1. Change in 7.6.2.4 [expr.await] paragraph 1 as follows:

   The co_await expression is used to suspend evaluation of a coroutine (9.6.4 [dcl.fct.def.coroutine]) while awaiting completion of the computation represented by the operand expression. Suspending the evaluation of a coroutine transfers control to its caller or resumer.

2. Change 8.7.4 [stmt.return] paragraph 1 as follows:

   A function returns control to its caller by the return statement.

3. Change 8.7.5 [stmt.return.coroutine] paragraph 1 as follows:

   A coroutine returns to its caller or resumer (9.6.4 [dcl.fct.def.coroutine]) by the co_return statement or when suspended (7.6.2.4 [expr.await]). A co_return statement transfers control to the caller or resumer of a coroutine (9.6.4 [dcl.fct.def.coroutine]). A coroutine shall not enclose a return statement (8.7.4 [stmt.return]).

4. Change in 9.6.4 [dcl.fct.def.coroutine] paragraph 10 as follows:

   If the allocation function returns nullptr, the coroutine returns transfers control to the caller of the coroutine and the return value is obtained by a call to T::get_return_object_on_allocation_failure(), where T is the promise type.

2556. Unusable promise::return_void

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

Subclause 8.7.5 [stmt.return.coroutine] paragraph 3 specifies:

If p.return_void() is a valid expression, flowing off the end of a coroutine's function-body is equivalent to a co_return with no operand; otherwise flowing off the end of a coroutine's function-body results in undefined behavior.

However, 9.6.4 [dcl.fct.def.coroutine] paragraph 6 suggests:

If searches for the names return_void and return_value in the scope of the promise type each find any declarations, the program is ill-formed. [Note: If return_void is found, flowing off the end of a coroutine is equivalent to a co_return with no operand. Otherwise, flowing off the end of a coroutine results in undefined behavior (8.7.5 [stmt.return.coroutine]). —end note]

The difference is between the conditions "valid expression" and "found by name lookup". Effectively, it means that undefined behavior might result where the implementation could instead diagnose an ill-formed use of return_void (for example, because it is inaccessible, deleted, or the function call requires arguments).

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

Change in 8.7.5 [stmt.return.coroutine] paragraph 3 as follows:

If p.return_void() is a valid expression a search for the name return_void in the scope of the promise type finds any declarations, flowing off the end of a coroutine's function-body is equivalent to a co_return with no operand; otherwise flowing off the end of a coroutine's function-body results in undefined behavior.

1223. Syntactic disambiguation and trailing-return-types

Because the restriction that a trailing-return-type can appear only in a declaration with “the single type-specifier auto” (9.3.4.6 [dcl.fct] paragraph 2) is a semantic, not a syntactic, restriction, it does not influence disambiguation, which is “purely syntactic” (8.10 [stmt.ambig] paragraph 3). Consequently, some previously unambiguous expressions are now ambiguous. For example:

struct A {
  A(int *);
  A *operator()(void);
  int B;
};

int *p;
typedef struct BB { int C[2]; } *B, C;

void foo() {
// The following line becomes invalid under C++0x:
  A (p)()->B;  // ill-formed function declaration

// In the following,
// - B()->C is either type-id or class member access expression
// - B()->C[1] is either type-id or subscripting expression
// N3126 subclause 8.2 [dcl.ambig.res] does not mention an ambiguity
// with these forms of expression
  A a(B ()->C);  // function declaration or object declaration
  sizeof(B ()->C[1]);  // sizeof(type-id) or sizeof on an expression
}

Notes from the March, 2011 meeting:

CWG agreed that the presence of auto should be considered in disambiguation, even though it is formally handled semantically rather than syntactically.

CWG 2023-05-12

Both 8.10 [stmt.ambig] and 9.3.3 [dcl.ambig.res] need to be adjusted.

CWG 2023-06-13

Addressed by paper P2915R0, approved in June, 2023.

2531. Static data members redeclared as constexpr

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

C++17 made constexpr static data members implicitly inline (9.2.6 [dcl.constexpr] paragraph 1):

A function or static data member declared with the constexpr or consteval specifier is implicitly an inline function or variable (9.2.8 [dcl.inline]).

However, that makes the following well-formed C++14 program ill-formed, no diagnostic required, per 9.2.8 [dcl.inline] paragraph 5:

If a function or variable with external or module linkage is declared inline in one definition domain, an inline declaration of it shall be reachable from the end of every definition domain in which it is declared; no diagnostic is required.

  // x.hh
  struct X {
    static const int x;
  };

  // TU 1
  #include "x.hh"
  constexpr int X::x{};

  // TU 2
  #include "x.hh"
  int main() { return !&X::x; }

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

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

A function or static data member declared with the constexpr or consteval specifier on its first declaration is implicitly an inline function or variable (9.2.8 [dcl.inline]).

Drafting note: Functions must be declared constexpr on every declaration if on any, so this isn't a change for them.

2634. Avoid circularity in specification of scope for friend class declarations

[Accepted as a DR at the March, 2024 meeting.]

Consider:

auto f(struct X* ptr) {
  struct D {
    private:
      int d;
      friend class X;      // #1
  };
  return D{};
}
X* b = 0;
struct X {
  void show() {
    auto t = f(0);
    t.d = 10;              // #2 error: ::X is not a friend of f::D
  }
};

The target scope for #2 is f's block scope, making ::X not a friend of f::D. Thus the access at #2 is ill-formed. Clang disagrees.

Subclause 9.2.9.5 [dcl.type.elab] paragraph 3 specifies:

... If E contains an identifier but no nested-name-specifier and (unqualified) lookup for the identifier finds nothing, E shall not be introduced by the enum keyword and declares the identifier as a class-name. The target scope of E is the nearest enclosing namespace or block scope.

If an elaborated-type-specifier appears with the friend specifier as an entire member-declaration, the member-declaration shall have one of the following forms:

friend class-key nested-name-specifieropt identifier ;
...

Any unqualified lookup for the identifier (in the first case) does not consider scopes that contain the target scope; no name is bound.

This specification is circular in that the target scope that limits unqualified lookup is defined only if the identifier is actually declared, but the identifier is declared only if lookup finds nothing.

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

Change in 9.2.9.5 [dcl.type.elab] paragraph 4 as follows:

... Any unqualified lookup for the identifier (in the first case) does not consider scopes that contain the target nearest enclosing namespace or block scope; no name is bound. [ Note: ... ]

2874. Qualified declarations of partial specializations

[Accepted as a DR at the June, 2024 meeting.]

(From submission #521.)

Consider:

  namespace N {
    template<typename T>
    struct A;
  }

  template<>
  struct N::A<int>;     // OK

  template<typename T>
  struct N::A<T*>;      // error: invalid use of elaborated-type-specifier with a qualified-id

However, all major implementations support this.

Proposed resolution (approved by CWG 2024-05-17):

Change in 9.2.9.5 [dcl.type.elab] paragraph 2 as follows:

If an elaborated-type-specifier is the sole constituent of a declaration, the declaration is ill-formed unless it is an explicit specialization (13.9.4 [temp.expl.spec]), a partial specialization (13.7.6 [temp.spec.partial]), an explicit instantiation (13.9.3 [temp.explicit]), or it has one of the following forms:

  class-key attribute-specifier-seqopt identifier ;
  class-key attribute-specifier-seqopt simple-template-id ;

In the first case, the elaborated-type-specifier declares the identifier as a class-name. The second case shall appear only in an explicit-specialization (13.9.4 [temp.expl.spec]) or in a template-declaration (where it declares a partial specialization (13.7 [temp.decls]). The attribute-specifier-seq, if any, appertains to the class or template being declared.

2476. placeholder-type-specifiers and function declarators

[Accepted as a DR at the March, 2024 meeting.]

According to 9.2.9.7.1 [dcl.spec.auto.general] paragraph 3,

The placeholder type can appear with a function declarator in the decl-specifier-seq, type-specifier-seq, conversion-function-id, or trailing-return-type, in any context where such a declarator is valid. If the function declarator includes a trailing-return-type (9.3.4.6 [dcl.fct]), that trailing-return-type specifies the declared return type of the function. Otherwise, the function declarator shall declare a function.

This wording disallows a declaration like

   int f();
   auto (*fp)()=f;

The requirement to declare a function was introduced by the resolution of issue 1892.

Proposed resolution (April, 2021) [SUPERSEDED]:

Change 9.2.9.7.1 [dcl.spec.auto.general] paragraph 3 as follows:

The placeholder type can appear with a function declarator in the decl-specifier-seq, type-specifier-seq, conversion-function-id, or trailing-return-type, in any context where such a declarator is valid if the function declarator includes a trailing-return-type T (9.3.4.6 [dcl.fct]) or declares a function. If the function declarator includes a trailing-return-type (9.3.4.6 [dcl.fct]), that trailing-return-type specifies In the former case, T is the declared return type of the function. Otherwise, the function declarator shall declare a function. If the declared return type of the a function contains a placeholder type, the return type of the function is deduced from non-discarded return statements, if any, in the body of the function (8.5.2 [stmt.if]).

Additional notes (May, 2021):

It was observed that the proposed resolution above does not address the example in the issue, since fp neither has a trailing-return-type nor declares a function. Presumably another case in which a function declarator with a placeholder return type should be permitted is in the declaration of a variable in which the type is deduced from its initializer.

It was also noted in passing that the deduction in the example is only partial: the parameter-type-list is specified by the declarator and only the return type is deduced from the initializer. Although this example is supported by current implementations, there is implementation divergence in the support of another case in which only part of the variable's type is deduced:

    auto (&ar)[2] = L"a";  // Array bound declared, element type deduced

This issue is related to issue 1892, which prohibited cases like

    std::vector<auto(*)()> v;

The ultimate outcome of the two issues should be:

    int f();
    auto (*fp1)() = f;       // OK
    auto (*fp2)()->int = f;  // OK
    auto (*fp3)()->auto = f; // OK

    template<typename T> struct C { };
    C<auto(*)()> c1;         // Not OK
    C<auto(*)()->int> c2;    // OK
    C<auto(*)()->auto> c3;   // Not OK

Proposed resolution (January, 2023) [SUPERSEDED]:

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

   A placeholder-type-specifier designates a placeholder type that will be replaced later, typically by deduction from an initializer.

2. Change and split 9.2.9.7.1 [dcl.spec.auto.general] paragraph 3 as follows:

   A placeholder type can appear with a function declarator in the decl-specifier-seq, type-specifier-seq, conversion-function-id, or trailing-return-type, in any context where such for a function declarator is valid that includes a trailing-return-type (9.3.4.6 [dcl.fct]). If the function declarator includes a trailing-return-type (9.3.4.6 [dcl.fct]), that trailing-return-type specifies the declared return type of the function.

   Otherwise, the A placeholder type can appear in the decl-specifier-seq or type-specifier-seq in the declared return type of a function declarator shall declare that declares a function. If the declared return type of the function contains a placeholder type, ; the return type of the function is deduced from non-discarded return statements, if any, in the body of the function (8.5.2 [stmt.if]).

3. Change in 9.2.9.7.1 [dcl.spec.auto.general] paragraph 4 as follows:

   The type of a variable declared using a placeholder type is deduced from its initializer. This use is allowed in an initializing declaration (9.5 [dcl.init]) of a variable. The placeholder type shall appear as one of the decl-specifiers in the decl-specifier-seq and or as one of the type-specifiers in a trailing-return-type that specifies the type that replaces such a decl-specifier; the decl-specifier-seq shall be followed by one or more declarators, each of which shall be followed by a non-empty initializer. [ Example:

     ...
     auto f() -> int;                // OK, f returns int
     auto (*fp)() -> auto = f;       // OK
     ...
   

   -- end example ]

4. Change in 9.3.4.6 [dcl.fct] paragraph 1 as follows:

   In a declaration T D where D has the form

   D1 ( parameter-declaration-clause ) cv-qualifier-seqopt
     ref-qualifieropt noexcept-specifieropt attribute-specifier-seqopt trailing-return-typeopt
   

   and the type of the contained declarator-id in the declaration T D1 is "derived-declarator-type-list T",:

   • If the trailing-return-type is present, T shall be the single type-specifier auto, and the declared return type of the function type is the type specified by the trailing-return-type.
   • Otherwise, the declared return type of the function type is T.

   theThe type of the declarator-id in D is "derived-declarator-type-list noexceptopt function of parameter-type-list cv-qualifier-seqopt ref-qualifieropt returning T U", where

   • the parameter-type-list is derived from the parameter-declaration-clause as described below,
   • U is the declared return type, and
   • the optional noexcept is present if and only if the exception specification (14.5 [except.spec]) is non-throwing.

   The optional attribute-specifier-seq appertains to the function type.

5. Remove 9.3.4.6 [dcl.fct] paragraph 2:

   In a declaration T D where D has the form

   D1 ( parameter-declaration-clause ) cv-qualifier-seqopt
     ref-qualifieropt noexcept-specifieropt attribute-specifier-seqopt trailing-return-type
   

   and the type ... The optional attribute-specifier-seq appertains to the function type.

6. Change in 11.4.8.3 [class.conv.fct] paragraph 1 as follows:

   A declaration whose declarator-id has an unqualified-id that is a conversion-function-id declares a conversion function; its declarator shall be a function declarator (9.3.4.6 [dcl.fct]) of the form

   ptr-declarator noptr-declarator ( parameter-declaration-clause ) cv-qualifier-seqopt
         ref-qualifier-seqopt noexcept-specifieropt attribute-specifier-seqopt parameters-and-qualifiers
   

   where the ptr-declarator noptr-declarator consists solely of an id-expression, an optional attribute-specifier-seq, and optional surrounding parentheses, and the id-expression has one of the following forms: ...

7. Change in 11.4.8.3 [class.conv.fct] paragraph 2 as follows:

   A conversion function shall have no non-object parameters and shall be a non-static member function of a class or class template X; its declared return type is the conversion-type-id and it specifies a conversion from X to the type specified by the conversion-type-id interpreted as a type-id (9.3.2 [dcl.name]). A decl-specifier in the decl-specifier-seq of a conversion function (if any) shall not be a defining-type-specifier .

8. Remove 11.4.8.3 [class.conv.fct] paragraph 3:

   The type of the conversion function is “noexceptopt function taking no parameter cv-qualifier-seq opt ref-qualifier opt returning conversion-type-id”.

CWG 2023-06

This does not address void f2(auto (*)() -> auto);

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

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

   A placeholder-type-specifier designates a placeholder type that will be replaced later, typically by deduction from an initializer.

2. Change 9.2.9.7.1 [dcl.spec.auto.general] paragraph 2 as follows:

   A The type of a parameter-declaration of a function declaration (9.3.4.6 [dcl.fct]), lambda-expression (7.5.6 [expr.prim.lambda]), or template-parameter (13.2 [temp.param]) can be declared using a placeholder-type-specifier of the form type-constraint_opt auto can be used as a decl-specifier of the decl-specifier-seq of a parameter-declaration of a function declaration or lambda-expression and, if it is not the auto type-specifier introducing. The placeholder type shall appear as one of the decl-specifiers in the decl-specifier-seq or as one of the type-specifiers in a trailing-return-type , that specifies the type that replaces such a decl-specifier (see below); the placeholder type is a generic parameter type placeholder of the function declaration or, lambda-expression, or template-parameter, respectively.

3. Change and split 9.2.9.7.1 [dcl.spec.auto.general] paragraph 3 as follows:

   A placeholder type can appear with a function declarator in the decl-specifier-seq, type-specifier-seq, conversion-function-id, or trailing-return-type, in any context where such for a function declarator is valid that includes a trailing-return-type (9.3.4.6 [dcl.fct]). If the function declarator includes a trailing-return-type (9.3.4.6 [dcl.fct]), that trailing-return-type specifies the declared return type of the function.

   Otherwise, the A placeholder type can appear in the decl-specifier-seq or type-specifier-seq in the declared return type of a function declarator shall declare that declares a function. If the declared return type of the function contains a placeholder type, ; the return type of the function is deduced from non-discarded return statements, if any, in the body of the function (8.5.2 [stmt.if]).

4. Change in 9.2.9.7.1 [dcl.spec.auto.general] paragraph 4 as follows:

   The type of a variable declared using a placeholder type is deduced from its initializer. This use is allowed in an initializing declaration (9.5 [dcl.init]) of a variable. The placeholder type shall appear as one of the decl-specifiers in the decl-specifier-seq and or as one of the type-specifiers in a trailing-return-type that specifies the type that replaces such a decl-specifier; the decl-specifier-seq shall be followed by one or more declarators, each of which shall be followed by a non-empty initializer. [ Example:

     ...
     auto f() -> int;                // OK, f returns int
     auto (*fp)() -> auto = f;       // OK
     ...
   

   -- end example ]

5. Change and split 9.2.9.7.1 [dcl.spec.auto.general] paragraph 5 as follows:

   A placeholder type can also be used in the type-specifier-seq in of the new-type-id or in the type-id of a new-expression (7.6.2.8 [expr.new]) and as a decl-specifier of the parameter-declaration's decl-specifier-seq in a template-parameter (13.2 [temp.param]). In such a type-id, the placeholder type shall appear as one of the type-specifiers in the type-specifier-seq or as one of the type-specifiers in a trailing-return-type that specifies the type that replaces such a type-specifier.

   The auto type-specifier can also be used as the simple-type-specifier in an explicit type conversion (functional notation) (7.6.1.4 [expr.type.conv]).

6. Change in 9.3.4.6 [dcl.fct] paragraph 1 as follows:

   In a declaration T D where T may be empty and D has the form

   D1 ( parameter-declaration-clause ) cv-qualifier-seqopt
     ref-qualifieropt noexcept-specifieropt attribute-specifier-seqopt trailing-return-typeopt
   

   a derived-declarator-type-list is determined as follows: and

   • If the unqualified-id of the declarator-id is a conversion-function-id, the derived-declarator-type-list is empty.
   • Otherwise, the derived-declarator-type-list is as appears in the type "derived-declarator-type-list T" of the contained declarator-id in the declaration T D1 is "derived-declarator-type-list T".

   The declared return type U of the function type is determined as follows:

   • If the trailing-return-type is present, T shall be the single type-specifier auto, and U is the type specified by the trailing-return-type.
   • Otherwise, if the declaration declares a conversion function, see 11.4.8.3 [class.conv.fct].
   • Otherwise, U is T.

   theThe type of the declarator-id in D is "derived-declarator-type-list noexceptopt function of parameter-type-list cv-qualifier-seqopt ref-qualifieropt returning T U", where

   • the parameter-type-list is derived from the parameter-declaration-clause as described below and
   • the optional noexcept is present if and only if the exception specification (14.5 [except.spec]) is non-throwing.

   The optional attribute-specifier-seq appertains to the function type.

7. Remove 9.3.4.6 [dcl.fct] paragraph 2:

   In a declaration T D where D has the form

   D1 ( parameter-declaration-clause ) cv-qualifier-seqopt
     ref-qualifieropt noexcept-specifieropt attribute-specifier-seqopt trailing-return-type
   

   and the type ... The optional attribute-specifier-seq appertains to the function type.

8. Change in 11.4.8.3 [class.conv.fct] paragraph 1 as follows:

   A declaration whose declarator-id has an unqualified-id that is a conversion-function-id declares a conversion function; its declarator shall be a function declarator (9.3.4.6 [dcl.fct]) of the form

   ptr-declarator noptr-declarator ( parameter-declaration-clause ) cv-qualifier-seqopt
         ref-qualifier-seqopt noexcept-specifieropt attribute-specifier-seqopt parameters-and-qualifiers
   

   where the ptr-declarator noptr-declarator consists solely of an id-expression, an optional attribute-specifier-seq, and optional surrounding parentheses, and the id-expression has one of the following forms: ...

9. Change in 11.4.8.3 [class.conv.fct] paragraph 2 as follows:

   A conversion function shall have no non-object parameters and shall be a non-static member function of a class or class template X; its declared return type is the conversion-type-id and it specifies a conversion from X to the type specified by the conversion-type-id interpreted as a type-id (9.3.2 [dcl.name]). A decl-specifier in the decl-specifier-seq of a conversion function (if any) shall not be a defining-type-specifier .

10. Remove 11.4.8.3 [class.conv.fct] paragraph 3:

    The type of the conversion function is “noexceptopt function taking no parameter cv-qualifier-seq opt ref-qualifier opt returning conversion-type-id”.

2831. Non-templated function definitions and requires-clauses

[Accepted as a DR at the March, 2024 meeting.]

(From editorial issue 3936.)

Subclause 9.3.1 [dcl.decl.general] paragraph 4 specifies:

The optional requires-clause in an init-declarator or member-declarator shall be present only if the declarator declares a templated function (13.1 [temp.pre]). ...

This rule does not address function definitions, because those have neither an init-declarator nor a member-declarator.

Proposed resolution (approved by CWG 2024-03-20):

Change in 9.6.1 [dcl.fct.def.general] paragraph 1 as follows:

... The optional attribute-specifier-seq in a function-definition appertains to the function. A virt-specifier-seq can be part of a function-definition only if it is function-definition with a virt-specifier-seq shall be a member-declaration (11.4 [class.mem]). A function-definition with a requires-clause shall define a templated function.

453. References may only bind to “valid” objects

[Accepted as a DR at the March, 2024 meeting.]

9.3.4.3 [dcl.ref] paragraph 4 says:

A reference shall be initialized to refer to a valid object or function. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the "object" obtained by dereferencing a null pointer, which causes undefined behavior ...]

What is a "valid" object? In particular the expression "valid object" seems to exclude uninitialized objects, but the response to Core Issue 363 clearly says that's not the intent. This is an example (overloading construction on constness of *this) by John Potter, which I think is supposed to be legal C++ though it binds references to objects that are not initialized yet:

 struct Fun {
    int x, y;
    Fun (int x, Fun const&) : x(x), y(42) { }
    Fun (int x, Fun&) : x(x), y(0) { }
  };
  int main () {
    const Fun f1 (13, f1);
    Fun f2 (13, f2);
    cout << f1.y << " " << f2.y << "\n";
  }

Suggested resolution: Changing the final part of 9.3.4.3 [dcl.ref] paragraph 4 to:

A reference shall be initialized to refer to an object or function. From its point of declaration on (see 6.4.2 [basic.scope.pdecl]) its name is an lvalue which refers to that object or function. The reference may be initialized to refer to an uninitialized object but, in that case, it is usable in limited ways (6.7.4 [basic.life], paragraph 6) [Note: On the other hand, a declaration like this:

    int & ref = *(int*)0;

is ill-formed because ref will not refer to any object or function ]

I also think a "No diagnostic is required." would better be added (what about something like int& r = r; ?)

Proposed Resolution (October, 2004) [SUPERSEDED]:

(Note: the following wording depends on the proposed resolution for issue 232.)

Change 9.3.4.3 [dcl.ref] paragraph 4 as follows:

A reference shall be initialized to refer to a valid object or function. If an lvalue to which a reference is directly bound designates neither an existing object or function of an appropriate type (9.5.4 [dcl.init.ref]), nor a region of memory of suitable size and alignment to contain an object of the reference's type (6.7.2 [intro.object], 6.7.4 [basic.life], 6.8 [basic.types]), the behavior is undefined. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” empty lvalue obtained by dereferencing a null pointer, which causes undefined behavior. As does not designate an object or function. Also, as described in 11.4.10 [class.bit], a reference cannot be bound directly to a bit-field. ]

The name of a reference shall not be used in its own initializer. Any other use of a reference before it is initialized results in undefined behavior. [Example:

  int& f(int&);
  int& g();

  extern int& ir3;
  int* ip = 0;

  int& ir1 = *ip;     // undefined behavior: null pointer
  int& ir2 = f(ir3);  // undefined behavior: ir3 not yet initialized
  int& ir3 = g();
  int& ir4 = f(ir4);  // ill-formed: ir4 used in its own initializer

—end example]

Rationale: The proposed wording goes beyond the specific concerns of the issue. It was noted that, while the current wording makes cases like int& r = r; ill-formed (because r in the initializer does not "refer to a valid object"), an inappropriate initialization can only be detected, if at all, at runtime and thus "undefined behavior" is a more appropriate treatment. Nevertheless, it was deemed desirable to continue to require a diagnostic for obvious compile-time cases.

It was also noted that the current Standard does not say anything about using a reference before it is initialized. It seemed reasonable to address both of these concerns in the same wording proposed to resolve this issue.

Notes from the April, 2005 meeting:

The CWG decided that whether to require an implementation to diagnose initialization of a reference to itself should be handled as a separate issue (504) and also suggested referring to “storage” instead of “memory” (because 6.7.2 [intro.object] defines an object as a “region of storage”).

Proposed Resolution (April, 2005) [SUPERSEDED]:

(Note: the following wording depends on the proposed resolution for issue 232.)

Change 9.3.4.3 [dcl.ref] paragraph 4 as follows:

A reference shall be initialized to refer to a valid object or function. If an lvalue to which a reference is directly bound designates neither an existing object or function of an appropriate type (9.5.4 [dcl.init.ref]), nor a region of storage of suitable size and alignment to contain an object of the reference's type (6.7.2 [intro.object], 6.7.4 [basic.life], 6.8 [basic.types]), the behavior is undefined. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” empty lvalue obtained by dereferencing a null pointer, which causes undefined behavior. As does not designate an object or function. Also, as described in 11.4.10 [class.bit], a reference cannot be bound directly to a bit-field. ]

Any use of a reference before it is initialized results in undefined behavior. [Example:

  int& f(int&);
  int& g();

  extern int& ir3;
  int* ip = 0;

  int& ir1 = *ip;     // undefined behavior: null pointer
  int& ir2 = f(ir3);  // undefined behavior: ir3 not yet initialized
  int& ir3 = g();
  int& ir4 = f(ir4);  // undefined behavior: ir4 used in its own initializer

—end example]

Note (February, 2006):

The word “use” in the last paragraph of the proposed resolution was intended to refer to the description in 6.3 [basic.def.odr] paragraph 2. However, that section does not define what it means for a reference to be “used,” dealing only with objects and functions. Additional drafting is required to extend 6.3 [basic.def.odr] paragraph 2 to apply to references.

Additional note (May, 2008):

The proposed resolution for issue 570 adds wording to define “use” for references.

Note, January, 2012:

The resolution should also probably deal with the fact that the “one-past-the-end” address of an array does not designate a valid object (even if such a pointer might “point to” an object of the correct type, per 6.8.4 [basic.compound]) and thus is not suitable for the lvalue-to-rvalue conversion.

CWG 2023-11-06

We need a (possibly out-of-lifetime) object, not just a region of storage here. Empty lvalues do not exist. Otherwise, the direction is confirmed.

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

1. Change in 7.2.1 [basic.lval] paragraph 11 as follows:

   An object of dynamic type T_obj is type-accessible through a glvalue of type T_ref if T_ref is similar (7.3.6 [conv.qual]) to:

   • T_obj,
   • a type that is the signed or unsigned type corresponding to T_obj, or
   • a char, unsigned char, or std:byte type.

   If a program attempts to access (3.1 [defns.access]) the stored value of an object through a glvalue whose type is not similar (7.3.6 [conv.qual]) to one of the following types through which it is not type-accessible, the behavior is undefined:.[ Footnote: ... ]

   • the dynamic type of the object,
   • a type that is the signed or unsigned type corresponding to the dynamic type of the object, or
   • a char, unsigned char, or std::byte type.

   If a program invokes a defaulted copy/move constructor or copy/move assignment operator for a union of type U with a glvalue argument that does not denote an object of type cv U within its lifetime, the behavior is undefined.

2. Change in 7.6.1.3 [expr.call] paragraph 5 as follows:

   A type T_call is call-compatible with a function type T_func if T_call is the same type as T_func or if the type "pointer to T_func" can be converted to type "pointer to T_call" via a function pointer conversion (7.3.14 [conv.fctptr]). Calling a function through an expression whose function type E is different from the function is not call-compatible with the type F of the called function's definition results in undefined behavior unless the type “pointer to F” can be converted to the type “pointer to E” via a function pointer conversion (7.3.14 [conv.fctptr]). [Note 4: The exception applies This requirement allows the case when the expression has the type of a potentially-throwing function, but the called function has a non-throwing exception specification, and the function types are otherwise the same. —end note]

3. Change and split in 9.3.4.3 [dcl.ref] paragraph 5 as follows:

   There shall be no references to references, no arrays of references, and no pointers to references. The declaration of a reference shall contain an initializer (9.5.4 [dcl.init.ref]) except when the declaration contains an explicit extern specifier (9.2.2 [dcl.stc]), is a class member (11.4 [class.mem]) declaration within a class definition, or is the declaration of a parameter or a return type (9.3.4.6 [dcl.fct]); see 6.2 [basic.def]. A reference shall be initialized to refer to a valid object or function.

   Attempting to bind a reference to a function where the initializer is a glvalue whose type is not call-compatible (7.6.1.3 [expr.call]) with the type of the function's definition results in undefined behavior. Attempting to bind a reference to an object where the initializer is a glvalue through which the object is not type-accessible (7.2.1 [basic.lval]) results in undefined behavior. [Note 2: In particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by indirection through a null pointer, which causes undefined behavior. The object designated by such a glvalue can be outside its lifetime (6.7.4 [basic.life]). Because a null pointer value or a pointer past the end of an object does not point to an object, a reference in a well-defined program cannot refer to such things; see 7.6.2.2 [expr.unary.op]. As described in 11.4.10 [class.bit], a reference cannot be bound directly to a bit-field. —end note] An odr-use (6.3 [basic.def.odr]) of a reference that does not happen after (6.9.2.2 [intro.races]) its initialization results in undefined behavior. [ Example:

   int &f(int&);
   int &g();
   extern int &ir3;
   int *ip = 0;
   int &ir1 = *ip;    // undefined behavior: null pointer
   int &ir2 = f(ir3); // undefined behavior: ir3 not yet initialized
   int &ir3 = g();
   int &ir4 = f(ir4); // undefined behavior: ir4 used in its own initializer
   

   -- end example ]

Additional notes (November, 2023):

An odr-use is a property of the program, not an evaluation that participates in the "happens before" relation.

Proposed resolution (approved by CWG 2024-03-20):

1. Change in 7.2.1 [basic.lval] paragraph 11 as follows:

   An object of dynamic type T_obj is type-accessible through a glvalue of type T_ref if T_ref is similar (7.3.6 [conv.qual]) to:

   • T_obj,
   • a type that is the signed or unsigned type corresponding to T_obj, or
   • a char, unsigned char, or std:byte type.

   If a program attempts to access (3.1 [defns.access]) the stored value of an object through a glvalue whose type is not similar (7.3.6 [conv.qual]) to one of the following types through which it is not type-accessible, the behavior is undefined:.[ Footnote: ... ]

   • the dynamic type of the object,
   • a type that is the signed or unsigned type corresponding to the dynamic type of the object, or
   • a char, unsigned char, or std::byte type.

   If a program invokes a defaulted copy/move constructor or copy/move assignment operator for a union of type U with a glvalue argument that does not denote an object of type cv U within its lifetime, the behavior is undefined.

2. Change in 7.6.1.3 [expr.call] paragraph 5 as follows:

   A type T_call is call-compatible with a function type T_func if T_call is the same type as T_func or if the type "pointer to T_func" can be converted to type "pointer to T_call" via a function pointer conversion (7.3.14 [conv.fctptr]). Calling a function through an expression whose function type E is different from the function is not call-compatible with the type F of the called function's definition results in undefined behavior unless the type “pointer to F” can be converted to the type “pointer to E” via a function pointer conversion (7.3.14 [conv.fctptr]). [Note 4: The exception applies This requirement allows the case when the expression has the type of a potentially-throwing function, but the called function has a non-throwing exception specification, and the function types are otherwise the same. —end note]

3. Change and split in 9.3.4.3 [dcl.ref] paragraph 5 as follows:

   There shall be no references to references, no arrays of references, and no pointers to references. The declaration of a reference shall contain an initializer (9.5.4 [dcl.init.ref]) except when the declaration contains an explicit extern specifier (9.2.2 [dcl.stc]), is a class member (11.4 [class.mem]) declaration within a class definition, or is the declaration of a parameter or a return type (9.3.4.6 [dcl.fct]); see 6.2 [basic.def]. A reference shall be initialized to refer to a valid object or function.

   Attempting to bind a reference to a function where the converted initializer is a glvalue whose type is not call-compatible (7.6.1.3 [expr.call]) with the type of the function's definition results in undefined behavior. Attempting to bind a reference to an object where the converted initializer is a glvalue through which the object is not type-accessible (7.2.1 [basic.lval]) results in undefined behavior. [Note 2: In particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by indirection through a null pointer, which causes undefined behavior. The object designated by such a glvalue can be outside its lifetime (6.7.4 [basic.life]). Because a null pointer value or a pointer past the end of an object does not point to an object, a reference in a well-defined program cannot refer to such things; see 7.6.2.2 [expr.unary.op]. As described in 11.4.10 [class.bit], a reference cannot be bound directly to a bit-field. —end note] The behavior of an evaluation of a reference (7.5.5 [expr.prim.id], 7.6.1.5 [expr.ref]) that does not happen after (6.9.2.2 [intro.races]) the initialization of the reference is undefined. [ Example:

   int &f(int&);
   int &g();
   extern int &ir3;
   int *ip = 0;
   int &ir1 = *ip;    // undefined behavior: null pointer
   int &ir2 = f(ir3); // undefined behavior: ir3 not yet initialized
   int &ir3 = g();
   int &ir4 = f(ir4); // undefined behavior: ir4 used in its own initializer
   
   char x alignas(int);
   int &ir5 = *reinterpret_cast<int *>(&x);  // undefined behavior: initializer refers to char object
   

   -- end example ]

2550. Type "reference to cv void" outside of a declarator

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

9.3.4.3 [dcl.ref] paragraph 1 specifies:

A declarator that specifies the type “reference to cv void” is ill-formed.

A declarator does not contain the leading decl-specifier-seq of a declaration, so the following example is not covered by the prohibition:

  void f(void& x);

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

Change in 9.3.4.3 [dcl.ref] paragraph 1 as follows:

A declarator that specifies Forming the type “reference to cv void” is ill-formed.

2846. Out-of-class definitions of explicit object member functions

[Accepted as a DR at the March, 2024 meeting.]

(From submission #493.)

Consider:

  struct A {
    void f(this A&);
  };
  void A::f(this A&) { }    // #1

This is accepted by all major implementations. However, 9.3.4.6 [dcl.fct] paragraph 6 specifies:

An explicit-object-parameter-declaration is a parameter-declaration with a this specifier. An explicit-object-parameter-declaration shall appear only as the first parameter-declaration of a parameter-declaration-list of either:

• a member-declarator that declares a member function (11.4 [class.mem]), or
• a lambda-declarator (7.5.6 [expr.prim.lambda]).

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

The function-definition at #1 is neither of the two allowed options.

Similar concerns arise for explicit instantiations and explicit specializations.

Proposed resolution (approved by CWG 2024-02-16):

Change in 9.3.4.6 [dcl.fct] paragraph 6 as follows:

An explicit-object-parameter-declaration is a parameter-declaration with a this specifier. An explicit-object-parameter-declaration shall appear only as the first parameter-declaration of a parameter-declaration-list of either one of:

• a member-declarator that declares declaration of a member function or member function template (11.4 [class.mem]), or
• an explicit instantiation (13.9.3 [temp.explicit]) or explicit specialization (13.9.4 [temp.expl.spec]) of a templated member function, or
• a lambda-declarator (7.5.6 [expr.prim.lambda]).

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

2915. Explicit object parameters of type void

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

(From submission #578.)

Consider:

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

This ought to be an ill-formed parameter of type void.

Proposed resolution (approved by CWG 2024-08-16):

Change in 9.3.4.6 [dcl.fct] paragraph 3 as follows:

If the parameter-declaration-clause is empty, the function takes no arguments. A parameter list consisting of a single unnamed non-object parameter of non-dependent type void is equivalent to an empty parameter list. Except for this special case, a parameter shall not have type cv void.

2683. Default arguments for member functions of templated nested classes

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

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

Except for member functions of class templates, the default arguments in a member function definition that appears outside of the class definition are added to the set of default arguments provided by the member function declaration in the class definition; the program is ill-formed if a default constructor (11.4.5.2 [class.default.ctor]), copy or move constructor (11.4.5.3 [class.copy.ctor]), or copy or move assignment operator (11.4.6 [class.copy.assign]) is so declared. Default arguments for a member function of a class template shall be specified on the initial declaration of the member function within the class template.

That rule appears to allow adding default arguments for member functions of classes that are nested within class templates, for example:

  template<class> struct A { struct B { void c(int); }; };
  template<class T> void A<T>::B::c(int = 0) {}

MSVC accepts; gcc and clang reject.

Proposed resolution (approved by CWG 2023-03-03):

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

Except for member functions of class templates templated classes, the default arguments in a member function definition that appears outside of the class definition are added to the set of default arguments provided by the member function declaration in the class definition; the program is ill-formed if a default constructor (11.4.5.2 [class.default.ctor]), copy or move constructor (11.4.5.3 [class.copy.ctor]), or copy or move assignment operator (11.4.6 [class.copy.assign]) is so declared. Default arguments for a member function of a templated class template shall be specified on the initial declaration of the member function within the templated class template.

2708. Parenthesized initialization of arrays

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

Consider:

  const int arr[2](1,2);

This is accepted by all major implementations, yet 9.5.1 [dcl.init.general] paragraph 13 prohibits it:

If the entity being initialized does not have class type, the expression-list in a parenthesized initializer shall be a single expression.

Presumably, this was an oversight when adding parenthesized aggregate initialization.

Proposed resolution (approved by CWG 2023-04-28):

Change in 9.5.1 [dcl.init.general] paragraph 13 as follows:

If the entity being initialized does not have class or array type, the expression-list in a parenthesized initializer shall be a single expression.

2820. Value-initialization and default constructors

[Accepted as a DR at the March, 2024 meeting.]

Subclause 9.5.1 [dcl.init.general] paragraph 9 specifies:

To value-initialize an object of type T means:

• if T is a (possibly cv-qualified) class type (Clause Clause 11 [class]), then
  • if T has either no default constructor (11.4.5.2 [class.default.ctor]) or a default constructor that is user-provided or deleted, then the object is default-initialized;
  • otherwise, the object is zero-initialized and the semantic constraints for default-initialization are checked, and if T has a non-trivial default constructor, the object is default-initialized;
• if T is an array type, ...

The specification about checking the semantic constraints and invoking only non-trivial default constructors is overly convoluted. Omitting a call to a trivial constructor is an as-if optimization that should not be prescribed by the standard.

Proposed resolution (approved by CWG 2024-01-19):

Change in 9.5.1 [dcl.init.general] bullet 9.1.2 as follows:

• ...
• otherwise, the object is zero-initialized and the semantic constraints for default-initialization are checked, and if T has a non-trivial default constructor, the object is then default-initialized;

2824. Copy-initialization of arrays

[Accepted as a DR at the March, 2024 meeting.]

Consider:

  std::string arr[] = "some string";

Prior to the application of paper P0960R3 (Allow initializing aggregates from a parenthesized list of values), this was ill-formed, but now it is well-formed. However, the specification talks about an expression-list as part of the initializer, which does not exist in this case.

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

Change in 9.5.1 [dcl.init.general] bullet 16.5 as follows:

Otherwise, if the destination type is an array, the object is initialized as follows. The initializer shall be of the form ( expression-list ). Let x1 , . . . , xk be the elements of the expression-list. If the destination type is an array of unknown bound, it is defined as having k elements. Let n denote the array size after this potential adjustment. If k is greater than n, the program is ill-formed. Otherwise, ...

2859. Value-initialization with multiple default constructors

[Accepted as a DR at the June, 2024 meeting.]

(From submission #501.)

Subclause 9.5.1 [dcl.init.general] paragraph 9 specifies (as modified by issue 2820):

To value-initialize an object of type T means:

• If T is a (possibly cv-qualified) class type (Clause 11 [class]), then
  • if T has either no default constructor (11.4.5.2 [class.default.ctor]) or a default constructor that is user-provided or deleted, then the object is default-initialized;
  • otherwise, the object is zero-initialized and then default-initialized.
• ...

Per the specification, no zero-initialization occurs if the class has any user-provided default constructor, even if that constructor is not actually selected for the default initialization. This is observable in a constant expression, where reads of uninitialized data members are ill-formed.

Proposed resolution (approved by CWG 2024-04-05):

1. Change in 6.7.4 [basic.life] paragraph 1 as follows:

   The lifetime of an object or reference is a runtime property of the object or reference. A variable is said to have vacuous initialization if it is default-initialized, no other initialization is performed, and, if it is of class type or a (possibly multidimensional) array thereof, a trivial constructor of that class type has a trivial default constructor is selected for the default-initialization. The lifetime of an object of type T begins when: ...

2. Change in 9.5.1 [dcl.init.general] paragraph 9 as follows:

   To value-initialize an object of type T means:

   • If T is a (possibly cv-qualified) class type (Clause 11 [class]), then
     • if T has either no default constructor (11.4.5.2 [class.default.ctor]) or a default constructor that is user-provided or deleted, then the object is default-initialized;
     • otherwise, the object is zero-initialized and then default-initialized.
     let C be the constructor selected to default-initialize the object, if any. If C is not user-provided, the object is first zero-initialized. In all cases, the object is then default-initialized.
   • ...

2895. Initialization should ignore the destination type's cv-qualification

[Accepted as a DR at the June, 2024 meeting.]

(From submission #541.)

Initialization of cv T follows the same rules as initialization of T. Issue 2830 clarified this for list-initialization. Further amendments are needed to properly handle cv-qualified versions of char8_t and char16_t as well as bool.

Proposed resolution (approved by CWG 2024-06-14):

1. Change in 9.5.1 [dcl.init.general] paragraph 16 as follows:

   The semantics of initializers are as follows. The destination type is the cv-unqualified type of the object or reference being initialized and the source type is the type of the initializer expression. If the initializer is not a single (possibly parenthesized) expression, the source type is not defined.

2. Change in 9.5.1 [dcl.init.general] bullet 16.6 as follows:

   • Otherwise, if the destination type is a (possibly cv-qualified) class type:
     • If the initializer expression is a prvalue and the cv-unqualified version of the source type is the same class as the class of as the destination type, the initializer expression is used to initialize the destination object. [Example 2: T x = T(T(T())); value-initializes x. —end example]
     • Otherwise, if the initialization is direct-initialization, or if it is copy-initialization where the cv-unqualified version of the source type is the same class as, or a derived class of, the class of as or is derived from the destination type, constructors are considered. The applicable constructors are enumerated (12.2.2.4 [over.match.ctor]), and the best one is chosen through overload resolution (12.2 [over.match]). Then:

3. Change in 9.5.1 [dcl.init.general] bullet 16.9 as follows:

   • Otherwise, the initial value of the object being initialized is the (possibly converted) value of the initializer expression. A standard conversion sequence (7.3 [conv]) is used to convert the initializer expression to a prvalue of the cv-unqualified version of the destination type; no user-defined conversions are considered. If the conversion cannot be done, the initialization is ill-formed. When initializing a bit-field with a value that it cannot represent, the resulting value of the bit-field is implementation-defined. [ Note: ... ]

2149. Brace elision and array length deduction

[Accepted as a DR as paper P3106R1 at the March, 2024 meeting.]

According to 9.5.2 [dcl.init.aggr] paragraph 4,

An array of unknown size initialized with a brace-enclosed initializer-list containing n initializer-clauses, where n shall be greater than zero, is defined as having n elements (9.3.4.5 [dcl.array]).

However, the interaction of this with brace elision is not clear. For instance, in the example in paragraph 7,

  struct X { int i, j, k = 42; };
  X a[] = { 1, 2, 3, 4, 5, 6 };
  X b[2] = { { 1, 2, 3 }, { 4, 5, 6 } };

a and b are said to have the same value, even though there are six initializer-clauses in the initializer list in a's initializer and two in b's initializer.

Similarly, 13.10.3.2 [temp.deduct.call] paragraph 1 says,

in the P'[N] case, if N is a non-type template parameter, N is deduced from the length of the initializer list

Should that take into account the underlying type of the array? For example,

  template<int N> void f1(const X(&)[N]);
  f1({ 1, 2, 3, 4, 5, 6 }); // Is N deduced to 2 or 6?

  template<int N> void f2(const X(&)[N][2]);
  f2({ 1, 2, 3, 4, 5, 6 }); // Is N deduced to 1 or 6?

Additional notes (April, 2024)

The situation with arrays of unknown bound was clarified by P3106R1. The concern about template argument deduction was left untouched; the existing wording in 13.10.3.2 [temp.deduct.call] paragraph 1 seems to be clear, rendering the two examples shown above ill-formed, because deduction of P' against the integer arguments fails.

233. References vs pointers in UDC overload resolution

[Accepted as a DR at the June, 2024 meeting.]

There is an inconsistency in the handling of references vs pointers in user defined conversions and overloading. The reason for that is that the combination of 9.5.4 [dcl.init.ref] and 7.3.6 [conv.qual] circumvents the standard way of ranking conversion functions, which was probably not the intention of the designers of the standard.

Let's start with some examples, to show what it is about:

    struct Z { Z(){} };

    struct A {
       Z x;

       operator Z *() { return &x; }
       operator const Z *() { return &x; }
    };

    struct B {
       Z x;

       operator Z &() { return x; }
       operator const Z &() { return x; }
    };

    int main()
    {
       A a;
       Z *a1=a;
       const Z *a2=a; // not ambiguous

       B b;
       Z &b1=b;
       const Z &b2=b; // ambiguous
    }

So while both classes A and B are structurally equivalent, there is a difference in operator overloading. I want to start with the discussion of the pointer case (const Z *a2=a;): 12.2.4 [over.match.best] is used to select the best viable function. Rule 4 selects A::operator const Z*() as best viable function using 12.2.4.3 [over.ics.rank] since the implicit conversion sequence const Z* -> const Z* is a better conversion sequence than Z* -> const Z*.

So what is the difference to the reference case? Cv-qualification conversion is only applicable for pointers according to 7.3.6 [conv.qual]. According to 9.5.4 [dcl.init.ref] paragraphs 4-7 references are initialized by binding using the concept of reference-compatibility. The problem with this is, that in this context of binding, there is no conversion, and therefore there is also no comparing of conversion sequences. More exactly all conversions can be considered identity conversions according to 12.2.4.2.5 [over.ics.ref] paragraph 1, which compare equal and which has the same effect. So binding const Z* to const Z* is as good as binding const Z* to Z* in terms of overloading. Therefore const Z &b2=b; is ambiguous. [12.2.4.2.5 [over.ics.ref] paragraph 5 and 12.2.4.3 [over.ics.rank] paragraph 3 rule 3 (S1 and S2 are reference bindings ...) do not seem to apply to this case]

There are other ambiguities, that result in the special treatment of references: Example:

    struct A {int a;};
    struct B: public A { B() {}; int b;};

    struct X {
       B x;
       operator A &() { return x; }
       operator B &() { return x; }
    };

    main()
    {
       X x;
       A &g=x; // ambiguous
    }

Since both references of class A and B are reference compatible with references of class A and since from the point of ranking of implicit conversion sequences they are both identity conversions, the initialization is ambiguous.

So why should this be a defect?

• References behave fundamentally different from pointers in combination with user defined conversions, although there is no reason to have this different treatment.
• This difference only shows up in combination with user defined conversion sequences, for all other cases, there are special rules, e.g. 12.2.4.3 [over.ics.rank] paragraph 3 rule 3.

So overall I think this was not the intention of the authors of the standard.

So how could this be fixed? For comparing conversion sequences (and only for comparing) reference binding should be treated as if it was a normal assignment/initialization and cv-qualification would have to be defined for references. This would affect 9.5.4 [dcl.init.ref] paragraph 6, 7.3.6 [conv.qual] and probably 12.2.4.3 [over.ics.rank] paragraph 3.

Another fix could be to add a special case in 12.2.4 [over.match.best] paragraph 1.

CWG 2023-06-13

It was noted that the second example is not ambiguous, because a derived-to-base conversion is compared against an identity conversion. However, 12.2.4.2.5 [over.ics.ref] paragraph 1 needs a wording fix so that it applies to conversion functions as well. CWG opined that the first example be made valid, by adding a missing tie-breaker for the conversion function case.

Proposed resolution (approved by CWG 2024-04-19):

1. Change in 12.2.4.1 [over.match.best.general] bullet 2.2 as follows:

   • ...
   • the context is an initialization by user-defined conversion (see 9.5 [dcl.init], 12.2.2.6 [over.match.conv], and 12.2.2.7 [over.match.ref]) and the standard conversion sequence from the return type result of F1 to the destination type (i.e., the type of the entity being initialized) is a better conversion sequence than the standard conversion sequence from the return type result of F2 to the destination type
   • ...

2. Add a new sub-bullet to 12.2.4.3 [over.ics.rank] bullet 3.2 as follows:

   • ...
   • S1 and S2 include reference bindings (9.5.4 [dcl.init.ref]), and the types to which the references refer are the same type except for top-level cv-qualifiers, and the type to which the reference initialized by S2 refers is more cv-qualified than the type to which the reference initialized by S1 refers. [ Example: ... -- end example ] or, if not that,
   • S1 and S2 bind the same reference type "reference to T" and have source types V1 and V2, respectively, where the standard conversion sequence from V1* to T* is better than the standard conversion sequence from V2* to T*. [ Example:

       struct Z {};
     
       struct A {
         operator Z&();
         operator const Z&();       // #1
       };
     
       struct B {
         operator Z();
         operator const Z&&();      // #2
       };
     
       const Z& r1 = A();          // OK, uses #1
       const Z&& r2 = B();         // OK, uses #2
     

     --- end example]

2657. Cv-qualification adjustment when binding reference to temporary

[Accepted as a DR at the March, 2024 meeting.]

Core issue 2481 was resolved by clarifying that the temporary object in p5.4.2 is cv-qualified if the reference being initialized is cv-qualified. However, this is not the right bullet point for the example given,

  constexpr const int &r = 42;

Such an initialization would actually use bullet 5.3.1 instead. (5.4.2 would be used if the initializer were, for example, 3.14.) We therefore need to make a similar clarification in bullet 5.3, and ideally using the same language.

Proposed resolution (approved by CWG 2024-03-20):

1. Change in 9.5.4 [dcl.init.ref] bullet 5.3 as follows:

   Otherwise, if the initializer expression

   • is an rvalue (but not a bit-field) or function lvalue and “cv1 T1” is reference-compatible with “cv2 T2”, or
   • has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be converted to an rvalue or function lvalue of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3” (see 12.2.2.7 [over.match.ref]),

   then the initializer expression in the first case and the converted expression in the second case is called the converted initializer. If the converted initializer is a prvalue, let its type be denoted by T4; the temporary materialization conversion (7.3.5 [conv.rval]) is applied, considering the type of the prvalue to be is adjusted to type “cv1 T4” (7.3.6 [conv.qual]) and the temporary materialization conversion (7.3.5 [conv.rval]) is applied. In any case, the reference binds to the resulting glvalue (or to an appropriate base class subobject).

2. Append to the example in 9.5.4 [dcl.init.ref] bullet 5.3 as follows:

     B&& rrb = x;  // binds directly to the result of operator B
   
     constexpr int f() {
       const int &x = 42;
       const_cast<int &>(x) = 1;  // undefined behavior
       return x;
     }
     constexpr int z = f();   // error: not a constant expression
   

3. Change the example in 9.5.4 [dcl.init.ref] bullet 5.4 as follows:

     const double& rcd2 = 2;   // rcd2 refers to temporary with type const double and value 2.0
   

2801. Reference binding with reference-related types

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

Consider:

  int* p;
  const int*&& r = static_cast<int*&&>(p);

The intent of core issues 2018 and 2352 was to make this example ill-formed, because it surprisingly introduces a temporary.

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

Change in 9.5.4 [dcl.init.ref] bullet 5.4 as follows:

• Otherwise:, T1 shall not be reference-related to T2.
  • If T1 or T2 is a class type and T1 is not reference-related to T2, user-defined conversions are considered using the rules for copy-initialization of an object of type “cv1 T1” by user-defined conversion (9.5 [dcl.init], 12.2.2.5 [over.match.copy], 12.2.2.6 [over.match.conv]); the program is ill-formed if the corresponding non-reference copy-initialization would be ill-formed. The result of the call to the conversion function, as described for the non-reference copy-initialization, is then used to direct-initialize the reference. For this direct-initialization, user-defined conversions are not considered.
  • Otherwise, the initializer expression is implicitly converted to a prvalue of type “T1”. The temporary materialization conversion is applied, considering the type of the prvalue to be “cv1 T1”, and the reference is bound to the result.
  If T1 is reference-related to T2:
  • cv1 shall be the same cv-qualification as, or greater cv-qualification than, cv2; and
  • if the reference is an rvalue reference, the initializer expression shall not be an lvalue. [Note 3: This can be affected by whether the initializer expression is move-eligible (7.5.5.2 [expr.prim.id.unqual]). —end note]

2252. Enumeration list-initialization from the same type

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

According to 9.5.5 [dcl.init.list] bullet 3.8,

Otherwise, if T is an enumeration with a fixed underlying type (9.8.1 [dcl.enum]), the initializer-list has a single element v, and the initialization is direct-list-initialization, the object is initialized with the value T(v) (7.6.1.4 [expr.type.conv]); if a narrowing conversion is required to convert v to the underlying type of T , the program is ill-formed.

This could be read as requiring that there be a conversion from v to the underlying type of T, leaving the status of an example like the following unclear:

  enum class E {};
  struct X { operator E(); };
  E{X()}; // ok? 

Notes from the March, 2018 meeting:

CWG disagreed that the existing wording requires such a conversion, only that if such a conversion is possble, it must not narrow. A formulation along the lines of “if that initialization involves a narrowing conversion to the underlying type of T...” was suggested to clarify the intent. This will be handled editorially, and the issue will be left in "review" status until the change has been verified.

Additional notes (August, 2023)

Issue 2374 has meanwhile clarified that v is required to implicitly convert to the underlying type of the enumeration for 9.5.5 [dcl.init.list] bullet 3.8 to apply. Now, the logic falls through to 9.5.5 [dcl.init.list] bullet 3.9 for the above example, making it well-formed.

CWG 2023-09-15

Class types with conversions to scalar types were not in view when the wording in this bullet was conceived.

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

Change in 9.5.5 [dcl.init.list] bullet 3.8 as follows:

Otherwise, if T is an enumeration with a fixed underlying type (9.8.1 [dcl.enum]) U, the initializer-list has a single element v of scalar type, v can be implicitly converted to U, and the initialization is direct-list-initialization, the object is initialized with the value T(v) (7.6.1.4 [expr.type.conv]); if a narrowing conversion is required to convert v to U, the program is ill-formed.

2638. Improve the example for initializing by initializer list

[Accepted as a DR at the March, 2024 meeting.]

Issue 2137 amended the rules for initialization by initializer list, but neglected to add an example.

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

Change the example in 9.5.5 [dcl.init.list] bullet 3.7 as follows:

struct S {
  S(std::initializer_list<double>); // #1
  S(std::initializer_list<int>);    // #2
  S(std::initializer_list<S>);      // #3
  S();                              // #3#4

  // ...
};
S s1 = { 1.0, 2.0, 3.0 };  // invoke #1
S s2 = { 1, 2, 3 };        // invoke #2
S s3{s2};                  // invoke #3 (not the copy constructor)
S s3s4 = { };              // invoke #3#4

2713. Initialization of reference-to-aggregate from designated initializer list

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

Aggregates can be initialized by a designated initializer list, but references to aggregates cannot, although list-initialization of such with a regular braced-init-list is fine.

Subclause 9.5.5 [dcl.init.list] paragraph 3 specifies:

List-initialization of an object or reference of type T is defined as follows:

• If the braced-init-list contains a designated-initializer-list, T shall be an aggregate class. ...
• ...
• Otherwise, if T is a reference type, a prvalue is generated. The prvalue initializes its result object by copy-list-initialization from the initializer list. The prvalue is then used to direct-initialize the reference. The type of the prvalue is the type referenced by T, unless ...
• ...

Subclause 12.2.4.2.6 [over.ics.list] paragraph 2 specifies:

If the initializer list is a designated-initializer-list, a conversion is only possible if the parameter has an aggregate type that can be initialized from the initializer list according to the rules for aggregate initialization (9.5.2 [dcl.init.aggr]), in which case the implicit conversion sequence is a user-defined conversion sequence whose second standard conversion sequence is an identity conversion.

Proposed resolution (approved by CWG 2023-04-28):

1. Change in 9.5.5 [dcl.init.list] bullet 3.1 as follows:

   • If the braced-init-list contains a designated-initializer-list and T is not a reference type, T shall be an aggregate class. ...
   • ...

2. Change in 9.5.5 [dcl.init.list] bullet 3.9 as follows:

   Otherwise, if the initializer list is not a designated-initializer-list and has a single element of type E and ...

3. Change in 9.5.5 [dcl.init.list] bullet 3.10 as follows:

   [ Example:

     ...
     const B& b2{a};  // error: cannot copy-list-initialize B temporary from A
     struct C { int x; };
     C&& c = { .x = 1 };  // OK
   

   -- end example ]

4. Change in 12.2.4.2.6 [over.ics.list] paragraph 2 as follows:

   If the initializer list is a designated-initializer-list and the parameter is not a reference, a conversion is only possible if the parameter has an aggregate type that can be initialized from the initializer list according to the rules for aggregate initialization (9.5.2 [dcl.init.aggr]), in which case the implicit conversion sequence is a user-defined conversion sequence whose second standard conversion sequence is an identity conversion.

2830. Top-level cv-qualification should be ignored for list-initialization

[Accepted as a DR at the March, 2024 meeting.]

(From editorial issue 3492.)

Subclause 9.5.5 [dcl.init.list] paragraph 3 specifies:

List-initialization of an object or reference of type T is defined as follows:

• ...

Top-level cv-qualifiers should be ignored when comparing T to other types, e.g. in 9.5.5 [dcl.init.list] bullet 3.2.

Proposed resolution (approved by CWG 2024-01-19):

Change in 9.5.5 [dcl.init.list] paragraph 3 as follows:

List-initialization of an object or reference of type cv T is defined as follows:

• ...
• If T is an aggregate class and the initializer list has a single element of type cv cv1 U, where U is T or a class derived from T, the object is initialized from that element (by copy-initialization for copy-list-initialization, or by direct-initialization for direct-list-initialization).
• ...

2864. Narrowing floating-point conversions

[Accepted as a DR at the June, 2024 meeting.]

Consider:

  float f = {1e100};

This is rejected as narrowing on all implementations. Issue 2723 made the example non-narrowing, which seems incorrect on an IEEE platform.

Proposed resolution (approved by CWG 2024-04-19):

Change in 9.5.5 [dcl.init.list] paragraph 7 as follows:

A narrowing conversion is an implicit conversion

• from a floating-point type to an integer type, or
• from a floating-point type T to another floating-point type whose floating-point conversion rank is neither greater than nor equal to that of T, except where the source result of the conversion is a constant expression and the actual either its value after conversion is finite and within the range of values that can be represented (even if it cannot be represented exactly) the conversion did not overflow, or the values before and after the conversion are not finite, or
• from an integer type ...

Additional notes (April, 2024)

According to the proposed wording, since NaNs are not finite, conversion of NaNs is always non-narrowing. However, the payload of the NaN might not be preserved when converting to a smaller floating-point type.

2144. Function/variable declaration ambiguity

[Accepted as a DR at the June, 2024 meeting.]

The following fragment,

  int f() {};

is syntactically ambiguous. It could be either a function-definition followed by an empty-declaration, or it could be a simple-declaration whose init-declarator has the brace-or-equal-initializer {}. The same is true of a variable declaration

  int a {};

since function-definition simply uses the term declarator in its production.

Additional notes (May, 2024)

Issue 2876 introduced a framework to distinguish the parsing. Its resolution was extended to also resolve this issue.

2547. Defaulted comparison operator function for non-classes

[Accepted as a DR at the March, 2024 meeting.]

(See editorial issue 5337.)

Subclause 9.6.2 [dcl.fct.def.default] paragraph 1 specifies:

A function definition whose function-body is of the form = default ; is called an explicitly-defaulted definition. A function that is explicitly defaulted shall

• be a special member function or a comparison operator function (12.4.3 [over.binary]), and
• not have default arguments.

There seem to be no further restrictions on which comparison operator functions are allowed to be defaulted. For example,

  enum E { };
  bool operator==(E, E) = default;  // well-formed?

Subclause 11.10.1 [class.compare.default] paragraph 1 applies only to comparison operator functions "for some class":

A defaulted comparison operator function (12.4.3 [over.binary]) for some class C shall be a non-template function that is

• a non-static const non-volatile member of C having one parameter of type const C& and either no ref-qualifier or the ref-qualifier &, or
• a friend of C having either two parameters of type const C& or two parameters of type C.

Proposed resolution [SUPERSEDED]:

1. Change in 9.6.2 [dcl.fct.def.default] paragraph 1 as follows:

   A function definition whose function-body is of the form = default ; is called an explicitly-defaulted definition. A function that is explicitly defaulted shall

   • be a special member function (11.4.4 [special]) or a comparison operator function (12.4.3 [over.binary], 11.10.1 [class.compare.default]), and
   • not have default arguments (9.3.4.7 [dcl.fct.default]).

2. Change in 11.10.1 [class.compare.default] paragraph 1 as follows:

   A defaulted comparison operator function (12.4.3 [over.binary]) for some class C shall be a non-template function that is

   • a non-static const non-volatile member of some class C having one parameter of type const C& and either no ref-qualifier or the ref-qualifier &, or
   • a friend of some class C having either two parameters of type const C& or two parameters of type C.

   Such a comparison operator function is termed a comparison operator function for class C. A comparison operator function for class C that is defaulted on its first declaration ...

CWG 2023-12-01

A defaulted comparison function for an incomplete class later declared a friend for that class should be made ill-formed.

Proposed resolution (approved by CWG 2023-12-15):

1. Change in 9.6.2 [dcl.fct.def.default] paragraph 1 as follows:

   A function definition whose function-body is of the form = default ; is called an explicitly-defaulted definition. A function that is explicitly defaulted shall

   • be a special member function (11.4.4 [special]) or a comparison operator function (12.4.3 [over.binary], 11.10.1 [class.compare.default]), and
   • not have default arguments (9.3.4.7 [dcl.fct.default]).

2. Change in 11.10.1 [class.compare.default] paragraph 1 as follows:

   A defaulted comparison operator function (12.4.3 [over.binary]) for some class C shall be a non-template function that is

   • is a non-static member or friend of some class C,
   • is defined as defaulted in C or in a context where C is complete, and
   • either has two parameters of type const C& or two parameters of type C, where the implicit object parameter (if any) is considered to be the first parameter.

   Such a comparison operator function is termed a defaulted comparison operator function for class C. Name lookups in the implicit definition (9.6.2 [dcl.fct.def.default]) of a comparison operator function are performed from a context equivalent to its function-body. A definition of a comparison operator as defaulted that appears in a class shall be the first declaration of that function. [ Example:

     struct S;
     bool operator==(S, S) = default;  // error: S is not complete
     struct S {
       friend bool operator==(S, const S&) = default; // error: parameters of different types
     };
     enum E { };
     bool operator==(E, E) = default;  // error: not a member or friend of a class
   

   -- end example ]

2570. Clarify constexpr for defaulted functions

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

After the application of P2448R2, 9.6.2 [dcl.fct.def.default] paragraph 3 reads:

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.

It is unclear that no other such defaulted function is implicitly constexpr.

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

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. [Note: Other defaulted functions are not implicitly constexpr. -- end note ]

2809. An implicit definition does not redeclare a function

[Accepted as a DR at the March, 2024 meeting.]

Subclause 9.6.2 [dcl.fct.def.default] paragraph 5 specifies:

... A user-provided explicitly-defaulted function (i.e., explicitly defaulted after its first declaration) is implicitly defined at the point where it is explicitly defaulted; if such a function is implicitly defined as deleted, the program is ill-formed. A non-user-provided defaulted function (i.e., implicitly declared or explicitly defaulted in the class) that is not defined as deleted is implicitly defined when it is odr-used (6.3 [basic.def.odr]) or needed for constant evaluation (7.7 [expr.const]).

In the first case, there is a second point of declaration for the function, wherever the user wrote the definition. In contrast, there is no redeclaration for the second case, where the function is not user-provided. A note would clarify.

Proposed resolution (approved by CWG 2024-03-20):

Insert a paragraph break before the quoted section and change in 9.6.2 [dcl.fct.def.default] paragraph 5 as follows:

... A function is user-provided if it is user-declared and not explicitly defaulted or deleted on its first declaration. A user-provided explicitly-defaulted function (i.e., explicitly defaulted after its first declaration) is implicitly defined at the point where it is explicitly defaulted; if such a function is implicitly defined as deleted, the program is ill-formed. [Note 1: Declaring a function as defaulted after its first declaration can provide efficient execution and concise definition while enabling a stable binary interface to an evolving code base. —end note] A non-user-provided defaulted function (i.e., implicitly declared or explicitly defaulted in the class) that is not defined as deleted is implicitly defined when it is odr-used (6.3 [basic.def.odr]) or needed for constant evaluation (7.7 [expr.const]). [Note 1: Declaring a function as defaulted after its first declaration can provide efficient execution and concise definition while enabling a stable binary interface to an evolving code base. —end note] [ Note: The implicit definition of a non-user-provided defaulted function does not bind any names. -- end note ]

2754. Using *this in explicit object member functions that are coroutines

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

Subclause 9.6.4 [dcl.fct.def.coroutine] paragraph 4 specifies:

In the following, pi is an lvalue of type Pi , where p1 denotes the object parameter and pi+1 denotes the ith non-object function parameter for a non-static member function, and pi denotes the ith function parameter otherwise. For a non-static member function, q1 is an lvalue that denotes *this; any other qi is an lvalue that denotes the parameter copy corresponding to pi , as described below.

An explicit object member function is a non-static member function, but there is no this.

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

Change in 9.6.4 [dcl.fct.def.coroutine] paragraph 4 as follows:

In the following, pi is an lvalue of type Pi , where p1 denotes the object parameter and pi+1 denotes the ith non-object function parameter for a non-static an implicit object member function, and pi denotes the ith function parameter otherwise. For a non-static an implicit object member function, q1 is an lvalue that denotes *this; any other qi is an lvalue that denotes the parameter copy corresponding to pi, as described below.

2867. Order of initialization for structured bindings

[Accepted as a DR at the June, 2024 meeting.]

Consider:

  auto [a, b] = f(X{});

If X is a tuple-like type, this is transformed to approximately the following:

  auto e = f(X{});
  T1 &a = get<0>(std::move(e));
  T2 &b = get<1>(std::move(e));

However, the sequencing of the initializations of e, a, and b is not specified. Further, the temporary X{} should be destroyed after the initializations of a and b.

Possible resolution [SUPERSEDED]:

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

   A full-expression is

   • an unevaluated operand (7.2.3 [expr.context]),
   • a constant-expression (7.7 [expr.const]),
   • an immediate invocation (7.7 [expr.const]),
   • an init-declarator (9.3 [dcl.decl]) or a mem-initializer (11.9.3 [class.base.init]), including the constituent expressions of the initializer,
   • the initializers for all uniquely-named variables introduced by a structured binding declaration (9.7 [dcl.struct.bind]), including the constituent expressions of all initializers,
   • an invocation of a destructor generated at the end of the lifetime of an object other than a temporary object (6.7.7 [class.temporary]) whose lifetime has not been extended, or
   • an expression that is not a subexpression of another expression and that is not otherwise part of a full-expression.

   ...

2. Change in 9.7 [dcl.struct.bind] paragraph 4 as follows:

   ... Each v_i is the name of an lvalue of type T_i that refers to the object bound to r_i; the referenced type is T_i. The initialization of e is sequenced before the initialization of any r_i. The initialization of r_i is sequenced before the initialization of r_j if i < j.

CWG 2024-05-03

CWG tentatively agreed that all temporaries in a structured binding (including those from default arguments of get invocations) should persist until the semicolon on the declaration as written.

Possible resolution [SUPERSEDED]:

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

   A full-expression is

   • an unevaluated operand (7.2.3 [expr.context]),
   • a constant-expression (7.7 [expr.const]),
   • an immediate invocation (7.7 [expr.const]),
   • an init-declarator (9.3 [dcl.decl]) , an initializer of a structured binding declaration (9.1 [dcl.pre]), or a mem-initializer (11.9.3 [class.base.init]), including the constituent expressions of the initializer,
   • an invocation of a destructor generated at the end of the lifetime of an object other than a temporary object (6.7.7 [class.temporary]) whose lifetime has not been extended, or
   • an expression that is not a subexpression of another expression and that is not otherwise part of a full-expression.

   ...

2. Change in 9.7 [dcl.struct.bind] paragraph 4 as follows:

   ... Each v_i is the name of an lvalue of type T_i that refers to the object bound to r_i; the referenced type is T_i. The initialization of e is sequenced before the initialization of any r_i. The initialization of each r_i is sequenced before the initialization of any r_j where i < j.

3. Append a new paragraph at the end of 9.7 [dcl.struct.bind] as follows:

   ... [ Example: ... The type of the id-expression x is "int", the type of the id-expression y is "const volatile double". -- end example ]

   The initialization of e and of any r_i are sequenced before the destruction of any temporary object introduced by the initializer for e or by the initializers for the r_i. The temporary objects are destroyed in the reverse order of their construction.