Date: | 2025-09-12
Project: | Programming Language C++
Reference: | ISO/IEC 14882:2024
Reply to: | Jens Maurer
| jens.maurer@gmx.net

## C++ Standard Core Language Closed Issues, Revision 118

This document contains the C++ core language issues for which the Committee (J16 + WG21) has decided that no action is required, that is, issues with status "NAD" ("Not A Defect"), "dup" (duplicate), "concepts," and "extension."

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.
- Defect Reports List, which contains the issues that have been categorized by the Committee as Defect Reports, as well as other issues accepted by the Committee, along with their proposed resolutions.
- 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 N5014.

### Issues with "NAD" Status

#### 1067. `[[hiding]]`, using-declarations, and multiple inheritance

Section: _N3225_.7.6.5 [dcl.attr.override] Status: NAD Submitter: Daveed Vandevoorde Date: 2010-03-26

The intent appears to be that the following example is well-formed, even though `D::f(int)` hides `B2::f()`:

        struct B1 { void f(); };
        struct B2 { void f(); };
        struct[[base_check]] D: B1, B2 {
          using B1::f;
          void f(int);
        };

However, this is not reflected in the current wording.

Rationale (November, 2010):

The consensus of the CWG was that the using-declaration does, indeed, hide `B2::f()` and thus `D` should be ill-formed.

#### 167. Deprecating static functions

Section: _N3225_.D.2 [depr.static] Status: NAD Submitter: Darin Adler Date: 8 Sep 1999

_N3225_.D.2 [depr.static] says that declaring namespace-scope objects as `static` is deprecated. Declaring namespace-scope functions as `static` should also be deprecated.

Proposed resolution (10/99): In both 9.9.2.2 [namespace.unnamed] paragraph 2 and _N3225_.D.2 [depr.static] paragraph 1, replace

> when declaring objects in a namespace scope

with

> when declaring entities in a namespace scope

In addition, there are a number of locations in the Standard where use of or reference to `static` should be reconsidered. These include:

- 6.3 [basic.def.odr] paragraph 5,
- 6.7 [basic.link] paragraph 6,
- 6.10.3.2 [basic.start.static] paragraph 4,
- 7.7 [expr.const] paragraph 2,
- 9.2 [dcl.spec] paragraph 2,
- 9.12 [dcl.link] paragraph 7, and
- 9.3.4.5 [dcl.array] paragraph 4.

Rationale (04/00):

This issue, along with issue 174, has been subsumed by issue 223. Until the committee determines the meaning of deprecation, it does not make sense either to extend or reduce the number of features to which it is applied.

#### 174. Undeprecating global static

Section: _N3225_.D.2 [depr.static] Status: NAD Submitter: Lawrence Crowl Date: 25 Oct 1999

The decision to deprecate global static should be reversed.

1. We cannot deprecate static because it is an important part of C and to abandon it would make C++ unnecessarily incompatible with C.
2. Because templates may be instantiated on members of unnamed namespaces, some compilation systems may place such symbols in the global linker space, which could place a significant burden on the linker. Without static, programmers have no mechanism to avoid the burden.

Rationale (04/00):

This issue, along with issue 167, has been subsumed by issue 223. Until the committee determines the meaning of deprecation, it does not make sense either to extend or reduce the number of features to which it is applied.

#### 1150. Inheriting constructors have not been implemented

Section: _N4527_.12.9 [class.inhctor] Status: NAD Submitter: US Date: 2010-08-03
N3092 comment US 65

Inheriting constructors should not be part of C++0x unless they have implementation experience.

Rationale (March, 2011):

The full Committee voted not to remove this feature.

#### 687. `template` keyword with unqualified-ids

Section: _N4567_.5.1.1 [expr.prim.general] Status: NAD Submitter: Mihai Rusu Date: 27 February, 2008

[Addressed with a different approach by paper P0846R0, adopted at the November, 2017 meeting.]

Consider the following:

        namespace N {
            struct A { };
            template<typename T>
            T func(const A&) { return T(); }
        }

        void f() {
            N::A a;
            func<int>(a);    // error
        }

Although argument-dependent lookup would allow `N::func` to be found in this call, the `<` is taken as a less-than operator rather than as the beginning of a template argument list. If the use of the `template` keyword for syntactic disambiguation were permitted for unqualified-ids, this problem could be solved by prefixing the function name with `template`, allowing the template-id to be parsed and argument-dependent lookup to be performed.

Rationale (July, 2009):

This suggestion would need a full proposal and discussion by the EWG before the CWG could consider it.

#### 2134. Objectless references to non-static member functions

Section: _N4567_.5.1.1 [expr.prim.general] Status: NAD Submitter: Aaron Ballman Date: 2015-06-03

Bullet 13.3 of _N4567_.5.1.1 [expr.prim.general] permits only non-static data members to appear without an object expression in an unevaluated operand. There does not appear to be a good reason to exclude non-static member functions from this permission.

Rationale (October, 2015):

Without knowing the type of `this`, overload resolution cannot be performed, and it seems not worth the trouble to allow member functions only in the case where there is no overloading.

#### 596. Replacing an exception object

Section: _N4606_.15.5.2 [except.unexpected] Status: NAD Submitter: Alisdair Meredith Date: 12 September 2006

When a function throws an exception that is not in its exception-specification, `std::unexpected()` is called. According to _N4606_.15.5.2 [except.unexpected] paragraph 2,

> If [`std::unexpected()`] throws or rethrows an exception that the exception-specification does not allow then the following happens: If the exception-specification does not include the class `std::bad_exception` (17.9.4 [bad.exception]) then the function `std::terminate()` is called, otherwise the thrown exception is replaced by an implementation-defined object of the type `std::bad_exception,` and the search for another handler will continue at the call of the function whose exception-specification was violated.

The “replaced by” wording is imprecise and undefined. For example, does this mean that the destructor is called for the existing exception object, or is it simply abandoned? Is the replacement in situ, so that a pointer to the existing exception object will now point to the `std::bad_exception` object?

Mike Miller: The call to `std::unexpected()` is not described as analogous to invoking a handler, but if it were, that would resolve this question; it is clearly specified what happens to the previous exception object when a new exception is thrown from a handler (14.2 [except.throw] paragraph 4).

This approach would also clarify other questions that have been raised regarding the requirements for stack unwinding. For example, 14.6.2 [except.terminate] paragraph 2 says that

> In the situation where no matching handler is found, it is implementation-defined whether or not the stack is unwound before `std::terminate()` is called.

This requirement could be viewed as in conflict with the statement in _N4606_.15.5.2 [except.unexpected] paragraph 1 that

> If a function with an exception-specification throws an exception that is not listed in the exception-specification, the function `std::unexpected()` is called (_N4606_.D.6 [exception.unexpected]) immediately after completing the stack unwinding for the former function.

If it is implementation-defined whether stack unwinding occurs before calling `std::terminate()` and `std::unexpected()` is called only after doing stack unwinding, does that mean that it is implementation-defined whether `std::unexpected()` is called if there is ultimately no handler found?

Again, if invoking `std::unexpected()` were viewed as essentially invoking a handler, the answer to this would be clear, because unwinding occurs before invoking a handler.

Rationale (February, 2017):

The issue is moot after the adoption of document P0003.

#### 2393. Pseudo-destructors and object lifetime

Section: _N4778_.7.6.1.4 [expr.pseudo] Status: NAD Submitter: CWG Date: 2018-11-07

With the changes for issue 2256, extending destruction to apply to objects of scalar type, should invoking a pseudo-destructor end the lifetime of that object?

Rationale (February, 2019):

This question is resolved by paper P0593R4.

#### 156. Name lookup for conversion functions

Section: _N4868_.6.5.6 [basic.lookup.classref] Status: NAD Submitter: Derek Inglis Date: 18 Aug 1999

Paragraph 7 of _N4868_.6.5.6 [basic.lookup.classref] says,

> If the id-expression is a conversion-function-id, its conversion-type-id shall denote the same type in both the context in which the entire postfix-expression occurs and in the context of the class of the object expression (or the class pointed to by the pointer expression).

Does this mean that the following example is ill-formed?

        struct A { operator int(); } a;
        void foo() {
          typedef int T;
          a.operator T(); // 1) error T is not found in the context
    		      // of the class of the object expression?
        }

The second bullet in paragraph 1 of 6.5.5.2 [class.qual] says,

> a conversion-type-id of an operator-function-id is looked up both in the scope of the class and in the context in which the entire postfix-expression occurs and shall refer to the same type in both contexts

How about:

        struct A { typedef int T; operator T(); };
        struct B : A { operator T(); } b;
        void foo() {
          b.A::operator T(); // 2) error T is not found in the context
    			 // of the postfix-expression?
        }

Is this interpretation correct? Or was the intent for this to be an error only if `T` was found in both scopes and referred to different entities?

If the intent was for these to be errors, how do these rules apply to template arguments?

        template <class T1> struct A { operator T1(); }
        template <class T2> struct B : A<T2> {
          operator T2();
          void foo() {
    	T2 a = A<T2>::operator T2(); // 3) error? when instantiated T2 is not
    				     // found in the scope of the class
    	T2 b = ((A<T2>*)this)->operator T2(); // 4) error when instantiated?
          }
        }

(Note bullets 2 and 3 in paragraph 1 of 6.5.5.2 [class.qual] refer to postfix-expression. It would be better to use qualified-id in both cases.)

Erwin Unruh: The intent was that you look in both contexts. If you find it only once, that's the symbol. If you find it in both, both symbols must be "the same" in some respect. (If you don't find it, its an error).

Mike Miller: What's not clear to me in these examples is whether what is being looked up is `T` or `int`. Clearly the `T` has to be looked up somehow, but the "name" of a conversion function clearly involves the base (non-typedefed) type, not typedefs that might be used in a definition or reference (cf 6.1 [basic.pre] paragraph 7 and 11.4.8 [class.conv] paragraph 5) . (This is true even for types that must be written using typedefs because of the limited syntax in conversion-type-ids — e.g., the "name" of the conversion function in the following example

        typedef void (*pf)();
        struct S {
    	operator pf();
        };

is `S::operator void(*)()`, even though you can't write its name directly.)

My guess is that this means that in each scope you look up the type named in the reference and form the canonical operator name; if the name used in the reference isn't found in one or the other scope, the canonical name constructed from the other scope is used. These names must be identical, and the conversion-type-id in the canonical operator name must not denote different types in the two scopes (i.e., the type might not be found in one or the other scope, but if it's found in both, they must be the same type).

I think this is all very vague in the current wording.

Rationale (February, 2021):

This issue was resolved by the resolution of issue 1111.

#### 95. Elaborated type specifiers referencing names declared in friend decls

Section: _N4868_.9.8.2.3 [namespace.memdef] Status: NAD Submitter: John Spicer Date: 9 Feb 1999

A change was introduced into the language that made names first declared in friend declarations "invisible" to normal lookups until such time that the identifier was declared using a non-friend declaration. This is described in _N4868_.9.8.2.3 [namespace.memdef] paragraph 3 and 11.8.4 [class.friend] paragraph 9 (and perhaps other places).

The standard gives examples of how this all works with friend declarations, but there are some cases with nonfriend elaborated type specifiers for which there are no examples, and which might yield surprising results.

The problem is that an elaborated type specifier is sometimes a declaration and sometimes a reference. The meaning of the following code changes depending on whether or not friend class names are injected (visibly) into the enclosing namespace scope.

        struct A;
        struct B;
        namespace N {
            class X {
                friend struct A;
                friend struct B;
            };
            struct A *p;     // N::A with friend injection, ::A without
            struct B;        // always N::B
        }

Is this the desired behavior, or should all elaborated type specifiers (and not just those of the form "class-key identifier;") have the effect of finding previously declared "invisible" names and making them visible?

Mike Miller: That's not how I would categorize the effect of "`struct B;`". That declaration introduces the name "`B`" into namespace `N` in exactly the same fashion as if the friend declaration did not exist. The preceding friend declaration simply stated that, if a class `N::B` were ever defined, it would have friendly access to the members of `N::X`. In other words, the lookups in both "`struct A*`..." and "`struct B;`" ignore the friend declarations.

(The standard is schizophrenic on the issue of whether such friend declarations introduce names into the enclosing namespace. 6.4 [basic.scope] paragraph 4 says,

friend declarations (11.8.4 [class.friend] ) may introduce a (possibly not visible) name into an enclosing name-space

while 6.4.2 [basic.scope.pdecl] paragraph 6 says exactly the opposite:

friend declarations refer to functions or classes that are members of the nearest enclosing namespace, but they do not introduce new names into that namespace (_N4868_.9.8.2.3 [namespace.memdef] ).

Both of these are just notes; the normative text doesn't commit itself either way, just stating that the name is not found until actually declared in the enclosing namespace scope. I prefer the latter description; I think it makes the behavior you're describing a lot clearer and easier to understand.)

John Spicer: The previous declaration of B is not completely ignored though, because certainly changing "friend struct B;" to "friend union B;" would result in an error when B was later redeclared as a struct, wouldn't it?

Bill Gibbons: Right. I think the intent was to model this after the existing rule for local declarations of functions (which dates back to C), where the declaration is introduced into the enclosing scope but the name is not. Getting this right requires being somewhat more rigorous about things like the ODR because there may be declaration clashes even when there are no name clashes. I suspect that the standard gets this right in most places but I would expect there to be a few that are still wrong, in addition to the one Mike pointed out.

Mike Miller: Regarding would result in an error when `B` was later redeclared

I don't see any reason why it should. The restriction that the class-key must agree is found in 9.2.9.5 [dcl.type.elab] and is predicated on having found a matching declaration in a lookup according to 6.5.6 [basic.lookup.elab] . Since a lookup of a name declared only (up to that point) in a friend declaration does not find that name (regardless of whether you subscribe to the "does-not-introduce" or "introduces-invisibly" school of thought), there can't possibly be a mismatch.

I don't think that the Standard's necessarily broken here. There is no requirement that a class declared in a friend declaration ever be defined. Explicitly putting an incompatible declaration into the namespace where that friend class would have been defined is, to me, just making it impossible to define — which is no problem, since it didn't have to be defined anyway. The only error would occur if the same-named but unbefriended class attempted to use the nonexisting grant of friendship, which would result in an access violation.

(BTW, I couldn't find anything in the Standard that forbids defining a class with a mismatched class-key, only using one in an elaborated-type-specifier. Is this a hole that needs to be filled?)

John Spicer: This is what 9.2.9.5 [dcl.type.elab] paragraph 3 says:

The class-key or `enum` keyword present in the elaborated-type-specifier shall agree in kind with the declaration to which the name in the elaborated-type-specifier refers. This rule also applies to the form of elaborated-type-specifier that declares a class-name or `friend` class since it can be construed as referring to the definition of the class. Thus, in any elaborated-type-specifier, the `enum` keyword shall be used to refer to an enumeration (9.8.1 [dcl.enum] ), the `union` class-key shall be used to refer to a union (Clause 11 [class] ), and either the `class` or `struct` class-key shall be used to refer to a class (Clause 11 [class] ) declared using the `class` or `struct` class-key.

The latter part of this paragraph (beginning "This rule also applies...") is somewhat murky to me, but I think it could be interpreted to say that

                class B;
                union B {};

and

                union B {};
                class B;

are both invalid. I think this paragraph is intended to say that. I'm not so sure it actually does say that, though.

Mike Miller: Regarding I think the intent was to model this after the existing rule for local declarations of functions (which dates back to C)

Actually, that's not the C (1989) rule. To quote the Rationale from X3.159-1989:

While it was generally agreed that it is poor practice to take advantage of an external declaration once it had gone out of scope, some argued that a translator had to remember the declaration for checking anyway, so why not acknowledge this? The compromise adopted was to decree essentially that block scope rules apply, but that a conforming implementation need not diagnose a failure to redeclare an external identifier that had gone out of scope (undefined behavior).

Regarding Getting this right requires being somewhat more rigorous

Yes, I think if this is to be made illegal, it would have to be done with the ODR; the name-lookup-based current rules clearly (IMHO) don't apply. (Although to be fair, the [non-normative] note in 6.4 [basic.scope] paragraph 4 sounds as if it expects friend invisible injection to trigger the multiple-declaration provisions of that paragraph; it's just that there's no normative text implementing that expectation.)

Bill Gibbons: Nor does the ODR currently disallow:

        translation unit #1    struct A;

        translation unit #2    union A;

since it only refers to class definitions, not declarations.

But the obvious form of the missing rule (all declarations of a class within a program must have compatible struct/class/union keys) would also answer the original question.

The declarations need not be visible. For example:

        translation unit #1    int f() { return 0; }

        translation unit #2:   void g() {
                                   extern long f();
                               }

is ill-formed even though the second "`f`" is not a visible declaration.

Rationale (10/99): The main issue (differing behavior of standalone and embedded elaborated-type-specifiers) is as the Committee intended. The remaining questions mentioned in the discussion may be addressed in dealing with related issues.

(See also issues 136, 138, 139, 143, 165, and 166.)

#### 165. Definitions of friends and block-scope externs

Section: _N4868_.9.8.2.3 [namespace.memdef] Status: NAD Submitter: Derek Inglis Date: 7 Sep 1999

_N4868_.9.8.2.3 [namespace.memdef] paragraph 2 says,

> Members of a named namespace can also be defined outside that namespace by explicit qualification (6.5.5.3 [namespace.qual] ) of the name being defined, provided that the entity being defined was already declared in the namespace...

It is not clear whether block-scope `extern` declarations and `friend` declarations are sufficient to permit the named entities to be defined outside their namespace. For example,

        namespace NS {
           struct A { friend struct B; };
           void foo() { extern void bar(); }
        }
        struct NS::B { };   // 1) legal?
        void NS::bar() { }  // 2) legal?

Rationale (10/99): Entities whose names are "invisibly injected" into a namespace as a result of `friend` declarations are not "declared" in that namespace until an explicit declaration of the entity appears at namespace scope. Consequently, the definitions in the example are ill-formed.

(See also issues 95, 136, 138, 139, 143, and 166.)

#### 553. Problems with friend allocation and deallocation functions

Section: _N4868_.9.8.2.3 [namespace.memdef] Status: NAD Submitter: Dmitriy Litskalov Date: 16 December 2005

Consider the following example:

        class C {
           public: enum E {};

           friend void* operator new(size_t, E);
           friend void  operator delete(void*, E);
        };

        void foo() {
           C::E e;
           C* ptr = new(e) C();
        }

This code, which is valid in global scope, becomes ill-formed when the class definition is moved into a namespace, and there is no way to make it valid:

        namespace N {
           class C {
              public: enum E {};

              friend void* operator new(size_t, E);
              friend void  operator delete(void*, E);
           };
        }

        void foo() {
           N::C::E e;
           N::C* ptr = new(e) N::C();
        }

The reason for this is that non-member allocation and deallocation functions are required to be members of the global scope (6.8.6.5.2 [basic.stc.dynamic.allocation] paragraph 1, 6.8.6.5.3 [basic.stc.dynamic.deallocation] paragraph 1) , unqualified friend declarations declare names in the innermost enclosing namespace (_N4868_.9.8.2.3 [namespace.memdef] paragraph 3) , and these functions cannot be declared in global scope at a point where the friend declarations could refer to them using qualified-ids because their second parameter is a member of the class and thus can't be named before the class containing the friend declarations is defined.

Possible solutions for this conundrum include invention of some mechanism to allow a friend declaration to designate a namespace scope other than the innermost enclosing namespace in which the friend class or function is to be declared or to relax the innermost enclosing namespace lookup restriction in _N4868_.9.8.2.3 [namespace.memdef] paragraph 3 for friend declarations that nominate allocation and deallocation functions.

Rationale (April, 2006):

The CWG acknowledged that it is not always possible to move code from the global scope into a namespace but felt that this problem was not severe enough to warrant changing the language to accommodate it. Possible solutions include moving the enumeration outside the class or defining member allocation and deallocation functions.

#### 673. Injection of names from elaborated-type-specifiers in `friend` declarations

Section: _N4868_.9.8.2.3 [namespace.memdef] Status: NAD Submitter: Mike Miller Date: 6 February, 2008

_N4868_.9.8.2.3 [namespace.memdef] paragraph 3 is intended to prevent injection of names from `friend` declarations into the containing namespace scope:

> If a `friend` declaration in a non-local class first declares a class or function the friend class or function is a member of the innermost enclosing namespace. The name of the friend is not found by unqualified lookup (6.5.3 [basic.lookup.unqual]) or by qualified lookup (6.5.5 [basic.lookup.qual]) until a matching declaration is provided in that namespace scope (either before or after the class definition granting friendship).

However, this does not address names declared by elaborated-type-specifiers that are part of the `friend` declaration. Are these names intended to be visibly injected? For example, is the following well-formed?

        class A {
            friend class B* f();
        };
        B* bp;    // Is B visible here?

Implementations differ in their treatment of this example: EDG and MSVC++ 8.0 accept it, while g++ 4.1.1 rejects it.

Rationale (July, 2009):

The current specification does not restrict injection of names in elaborated-type-specifiers, and the consensus of the CWG was that no change is needed on this point.

#### 1077. Explicit specializations in non-containing namespaces

Section: _N4868_.9.8.2.3 [namespace.memdef] Status: NAD Submitter: Mike Spertus Date: 2010-06-13

The current wording of _N4868_.9.8.2.3 [namespace.memdef] and 13.9.4 [temp.expl.spec] requires that an explicit specialization be declared either in the same namespace as the template or in an enclosing namespace. It would be convenient to relax that requirement and allow the specialization to be declared in a non-enclosing namespace to which one or more if the template arguments belongs.

Additional note, April, 2015:

See EWG issue 48.

EWG 2022-11-11

This is a feature request, not a defect.

#### 37. When is uncaught_exception() true?

Section: _N5001_.14.6.3 [except.uncaught] Status: NAD Submitter: Daveed Vandevoorde Date: 10 Aug 1998

The term "throw exception" seems to sometimes refer to an expression of the form "`throw` expr" and sometimes just to the "expr" portion thereof.

As a result it is not quite clear to me whether when "`uncaught_exception()`" becomes true: before or after the temporary copy of the value of "expr".

Is there a definite consensus about that?

Rationale: The standard is sufficiently clear; the phrase "to be thrown" indicates that the throw itself (which includes the copy to the temporary object) has not yet begun. The footnote in 14.6.2 [except.terminate] paragraph 1 reinforces this ordering.

See also issue 475.

#### 2034. Deprecating `uncaught_exception()`

Section: _N5001_.14.6.3 [except.uncaught] Status: NAD Submitter: CWG Date: 2014-11-06

With the adoption of paper N4259 specifying the `std::uncaught_exceptions()` function, the `std::uncaught_exception()` function should be deprecated.

Rationale (May, 2015):

This has already been done; see _N4140_.D.9 [depr.uncaught].

#### 449. Consistency in use of hyphen with names of "non" entities

Section: Clause 3 [intro.defs] Status: NAD Submitter: Daveed Vandevoorde Date: 14 Jan 2004

The standard is inconsistent in its use of a hyphen on the following: nontype vs. non-type, non-dependent vs. nondependent, non-deduced vs. nondeduced, and non-template vs. nontemplate. We should pick a preferred form.

Notes from the March 2004 meeting:

If this isn't a purely editorial issue, nothing is. We're referring this to the editor. We prefer the hyphenated forms.

#### 1947. Digit separators following non-octal prefix

Section: 5.13.2 [lex.icon] Status: NAD Submitter: Japan Date: 2014-08-12

(From item JP 03 of the Japanese National Body comments on the C++14 DIS ballot.)

A digit separator is allowed immediately following the prefix for an octal literal but not for a binary or hexadecimal literal. For example, `0'01` is permitted but `0b'01` and `0x'01` are not. This asymmetry makes tools such as automatic code generators more complicated than necessary. The digit separator should be consistently allowed or disallowed immediately following the prefix in all non-decimal integer literals.

Rationale (November, 2014):

CWG felt that the reported asymmetry is not a major difficulty and that it is more natural to think of the leading `0` in an octal literal as part of the numeric value rather than as a separate prefix, as it is with `0b` and `0x`. Consequently there was no consensus for a change to the existing specification.

#### 937. Restrictions on values of template arguments in user-defined literals

Section: 5.13.9 [lex.ext] Status: NAD Submitter: Alisdair Meredith Date: 11 July, 2009

5.13.9 [lex.ext] paragraphs 3-4 state in notes that the arguments to a literal operator template “can only contain characters from the basic source character set.” This restriction does not appear to occur anywhere in normative text, however.

Rationale (July, 2009):

The characters in the template arguments are the characters comprising n, the integer literal, or f, the floating literal. As such, they are constrained by the grammar to be members of the basic character set, and no further normative restriction is needed.

#### 1108. User-defined literals have not been implemented

Section: 5.13.9 [lex.ext] Status: NAD Submitter: US Date: 2010-08-02
N3092 comment US 18

User-defined literals should not be part of C++0x unless they have implementation experience.

Rationale (March, 2011):

The feature has been implemented.

#### 1474. User-defined literals and `<inttypes.h>` format macros

Section: 5.13.9 [lex.ext] Status: NAD Submitter: Richard Smith Date: 2012-03-05

The format macros that are part of `<inttypes.h>` (incorporated into C++11 as `<cinttypes>`) are conventionally written with no whitespace separating them from the rest of the format string, e.g.,

      printf("foo = "PRIu32", bar = "PRIi8"\n", foo, bar);
      printf("baz = "PRIu32"\n", baz);

This usage conflicts with user-defined literals.

Rationale (October, 2012):

CWG felt that whether this form of these macros needed to be supported in C++ should be examined by EWG.

Rationale (February, 2014):

EWG determined that no action should be taken on this issue.

#### 1871. Non-identifier characters in ud-suffix

Section: 5.13.9 [lex.ext] Status: NAD Submitter: Richard Smith Date: 2014-02-17

A ud-suffix is defined in 5.13.9 [lex.ext] as an identifier. This prevents plausible user-defined literals for currency symbols, which are not categorized as identifier characters.

Rationale (June, 2014):

CWG felt that a decision on whether to allow this capability or not should be considered by EWG.

EWG 2022-11-11

This is a request for a new feature, which should be proposed in a paper to EWG. SG16 recommended not adding the feature.

#### 2152. Can an alternative token be used as a ud-suffix?

Section: 5.13.9 [lex.ext] Status: NAD Submitter: David Krauss Date: 2015-06-28

According to the grammar in 5.13.9 [lex.ext], a ud-suffix is an identifier. However, implementations seem to agree that `"x"or"y"` is equivalent to `"xy"or` and not to `true`. Should the Standard permit identifier-like alternative tokens as ud-suffixes?

Rationale (October, 2015):

The identifier in a ud-suffix is required to begin with an underscore, and the identifier-like alternative tokens do not satisfy this requirement.

#### 2423. Typedefs, names, and entities

Section: 6.1 [basic.pre] Status: NAD Submitter: Alisdair Meredith Date: 2019-07-29

According to 6.1 [basic.pre] paragraph 4,

> A name is a use of an identifier (5.11 [lex.name]), operator-function-id (12.4 [over.oper]), literal-operator-id (12.6 [over.literal]), conversion-function-id (11.4.8.3 [class.conv.fct]), or template-id (13.3 [temp.names]) that denotes an entity or label (8.8.6 [stmt.goto], 8.2 [stmt.label]).

Since typedefs are neither entities nor labels, it appears that a typedef-name is not a name.

There is an additional discrepancy regarding alias templates. According to 6.1 [basic.pre] paragraph 3, templates (including, presumably, alias templates) and their specializations are entities. However, the note in 13.3 [temp.names] paragraph 6 says,

> [Note: A simple-template-id that names a class template specialization is a class-name (11.3 [class.name]). Any other simple-template-id that names a type is a typedef-name. —end note]

Thus an alias template specialization both is and is not an entity.

#### 50. Converting pointer to incomplete type to same type

Section: 6.3 [basic.def.odr] Status: NAD Submitter: Steve Adamczyk Date: 13 Oct 1998

In 6.3 [basic.def.odr] paragraph 4 bullet 4, it's presumably the case that a conversion to `T*` requires that `T` be complete only if the conversion is from a different type. One could argue that there is no conversion (and therefore the text is accurate as it stands) if a cast does not change the type of the expression, but it's probably better to be more explicit here.

On the other hand, this text is non-normative (it's in a note).

Rationale (04/99): The relevant normative text makes this clear. Implicit conversion and `static_cast` are defined (in 7.3 [conv] and 7.6.1.9 [expr.static.cast] , respectively) as equivalent to declaration with initialization, which permits pointers to incomplete types, and `dynamic_cast` (7.6.1.7 [expr.dynamic.cast] ) explicitly prohibits pointers to incomplete types.

#### 1110. Incomplete return type should be allowed in `decltype` operand

Section: 6.3 [basic.def.odr] Status: NAD Submitter: DE Date: 2010-08-02
N3092 comment DE 9
N3092 comment US 22

`decltype` applied to a function call expression requires a complete type (7.6.1.3 [expr.call] paragraph 3 and 6.3 [basic.def.odr] paragraph 4), even though `decltype`'s result might be used in a way that does not actually require a complete type. This might cause undesired and excessive template instantiations. Immediately applying `decltype` should not require a complete type, for example, for the return type of a function call.

Additional note (October, 2010):

Another potential consideration in this question is the use of the return type in template argument deduction. If the return type is a specialization of a class template, one would want an error occurring in the instantiation of that specialization to cause a deduction failure, which would argue in favor of requiring the type to be complete. (However, that might also be covered by “when the completeness of the class type affects the semantics of the program” in 13.9.2 [temp.inst] paragraph 1.)

Rationale (November, 2010):

The CWG was persuaded by the SFINAE consideration.

Note:

This issue was raised again at the March, 2011 meeting and paper N3276, implementing this recommendation, was adopted for the FDIS.

#### 1254. odr-use vs template arguments and constexpr functions

Section: 6.3 [basic.def.odr] Status: NAD Submitter: Nikolay Ivchenkov Date: 2011-03-08

The relationship between when an expression is potentially evaluated, especially with respect to contexts requiring constant expressions, and non-type template arguments is not clear and should be clarified. In particular, it seems that these contexts should be potentially-evaluated.

See also issue 1378.

Additional note, January, 2012:

Further discussion indicates that this is not a defect and should be closed as such.

Notes from the February, 2012 meeting:

CWG determined that the current wording is clear enough that an instantiation is required whenever it affects the semantics of the program.

#### 2240. `this` is not odr-used in a constant expression

Section: 6.3 [basic.def.odr] Status: NAD Submitter: Daveed Vandevoorde Date: 2016-03-04

According to 6.3 [basic.def.odr] paragraph 3,

> `this` is odr-used if it appears as a potentially-evaluated expression (including as the result of the implicit transformation in the body of a non-static member function (11.4.3 [class.mfct.non.static])).

This wording does not distinguish between constant and non-constant expressions in determining whether `this` is odr-used or not.

Notes from the April, 2018 teleconference:

Specification of the odr-use of `this` was done to allow determination of whether `this` should be captured by a lambda. Recent changes to determine capture syntactically, rather than by odr-use, have rendered this issue almost moot. However, 6.3 [basic.def.odr] still describes when `this` is odr-used; this specification is no longer necessary and should be removed.

Rationale (February, 2019):

This specification is now used by contracts.

#### 2367. Lambdas in default arguments vs the ODR

Section: 6.3 [basic.def.odr] Status: NAD Submitter: Richard Smith Date: 2017-11-10

According to 6.3 [basic.def.odr] bullet 6.5,

- in each definition of `D`, a default argument used by an (implicit or explicit) function call is treated as if its token sequence were present in the definition of `D`; that is, the default argument is subject to the requirements described in this paragraph (and, if the default argument has subexpressions with default arguments, this requirement applies recursively)

However, this rule is insufficient to handle a case like:

      struct A {
        template<typename T> A(T);
      };
      void f(A a = []{});
      inline void g() {
        f();
      }

This should be an ODR violation, because the call to f() will invoke a different specialization of the constructor template in each translation unit, but it is not, because the rule says this example is equivalent to:

      inline void g() {
       f([]{});
      }

which is not an ODR violation, since the type of the closure object will be the same in every translation unit (9.2.8 [dcl.inline] paragraph 6) ..

Notes from the October, 2018 teleconference:

This will be addressed by work already underway to rework the relationship between lambdas and the ODR.

Rationale (February, 2021):

The resolution of issue 2300 makes clear that this example is an ODR violation.

#### 1433. trailing-return-type and point of declaration

Section: 6.4.2 [basic.scope.pdecl] Status: NAD Submitter: Jason Merrill Date: 2011-12-20

This seems like it should be well-formed:

        template <class T> T list(T x);

        template <class H, class ...T>
        auto list(H h, T ...args) -> decltype(list(args...));

        auto list3 = list(1, 2, 3);

but it isn't, because the second list isn't in scope in its own trailing-return-type; the point of declaration is after the declarator, which includes the trailing-return-type. And since `int` has no associated namespaces, the call in the return type only sees the first list. G++, EDG and Clang all reject the testcase on this basis.

But this seems like a natural pattern for writing variadic function templates, and we could support it by moving the point of declaration to the `->`. This would mean having to deal with a function that only has a placeholder for a return type, but I think we can handle that.

Rationale (February, 2012):

This is a request for an extension to the language and is thus more appropriately addressed by EWG.

EWG 2022-11-11

This is a breaking change whose benefits and trade-offs need to be carefully analyzed.

#### 42. Redefining names from base classes

Section: 6.4.7 [basic.scope.class] Status: NAD Submitter: Steve Clamage Date: 15 Sep 1998

Consider this code:

        struct Base {
            enum { a, b, c, next };
        };

        struct Derived : public Base {
            enum { d = Base::next, e, f, next };
        };

The idea is that the enumerator "next" in each class is the next available value for enumerators in further derived classes.

If we had written

        enum { d = next, e, f, next };

I think we would run afoul of 6.4.7 [basic.scope.class] :

> A name `N` used in a class `S` shall refer to the same declaration in its context and when re-evaluated in the completed scope of `S`. No diagnostic is required for a violation of this rule.

But in the original code, we don't have an unqualified "next" that refers to anything but the current scope. I think the intent was to allow the code, but I don't find the wording clear on on that point.

Is there another section that makes it clear whether the original code is valid? Or am I being obtuse? Or should the quoted section say "An unqualified name N used in a class ..."?

Rationale (04/99): It is sufficiently clear that "name" includes qualified names and hence the usual lookup rules make this legal.

#### 1429. Scope of a member template's template parameter

Section: 6.4.9 [basic.scope.temp] Status: NAD Submitter: James Widman Date: 2011-12-09

Consider:

        struct A {
            struct B { typedef int X; };
        };

        template<class B> struct C : A {
            B::X q; // Ok: A::B.
            struct U { typedef int X; };
            template<class U>
                struct D;
        };

        template<class B>
        template<class U>
        struct C<B>::D {
            typename U::X r; // which U?
        };

        C<int>::D<double> y;

In the definition of `D`, `U` definitely needs to be in scope as soon as it's declared because it might have been used in subsequent template parameter declarations, or it might have been used in the id-expression that names the declared entity — just as `B` is used in `C<B>::D`. (So 6.4.9 [basic.scope.temp] does the right thing for that purpose.)

But it would be nice if the result of lookup did not depend on whether `D`'s body appears lexically inside `C`'s body; currently, we don't seem to have the wording that makes it so.

Rationale (October, 2012):

This example is covered by the wording in 13.8.2 [temp.local] paragraphs 7-8: the template parameter is found.

#### 2078. Name lookup of mem-initilizer-id

Section: 6.5.2 [class.member.lookup] Status: NAD Submitter: Richard Smith Date: 2015-01-31

The name lookup in a base-specifier and a mem-initializer differ in that the former ignores non-type names but the latter does not. When the mem-initializer-id is qualified, this can lead to surprising results:

      struct file_stat : ::stat {    // the class
        file_stat() : ::stat{} {}    // the function
      };

Rationale (May, 2015):

The use of a qualified-id as a mem-initializer-id is sufficiently unusual that it is not worth changing the lookup rules to accommodate it.

#### 2567. Operator lookup ambiguity

Section: 6.5.2 [class.member.lookup] Status: NAD Submitter: Daveed Vandevoorde Date: 2022-04-01

Consider:

      struct B1 {
        bool operator==(B1 const&) const;
      };
      struct B2 {
        bool operator==(B2 const&) const;
      };
      struct D: B1, B2 {} d;
      bool operator==(D const&, D const&);

      auto r = d == d; // ambiguous?

There is implementation divergence in handling this example; some implementations select the non-member operator, others diagnose an ambiguous lookup.

Member name lookup for `operator==` is ambiguous, making the program ill-formed per 6.5.2 [class.member.lookup] paragraph 6:

> The result of the search is the declaration set of S(N, T). If it is an invalid set, the program is ill-formed.

There is no provision for simply failing if the lookup is invoked as part of some larger lookup, as in the case of a lookup for an overloaded operator (12.2.2.3 [over.match.oper] paragraph 3):

> For a unary operator @ with an operand of type cv1 T1, and for a binary operator @ with a left operand of type cv1 T1 and a right operand of type cv2 T2, four sets of candidate functions, designated member candidates, non-member candidates, built-in candidates, and rewritten candidates, are constructed as follows:
> - If T1 is a complete class type or a class currently being defined, the set of member candidates is the result of a search for `operator@` in the scope of T1; otherwise, ....
> - For the operators =, [], or ->, the set of non-member candidates is empty; otherwise, it includes the result of unqualified lookup for `operator@` in the rewritten function call (6.5.3 [basic.lookup.unqual], 6.5.4 [basic.lookup.argdep]), ignoring all member functions. ...
> - For the operator `,`, the unary operator `&`, or the operator `->`, the built-in candidates set is empty. For all other operators, the built-in candidates include all of the candidate operator functions defined in 12.5 [over.built] that ...
> - The rewritten candidate set is determined as follows: ...

It is unclear whether that is intended or desirable.

Suggested resolution:

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

> The result of the search is If the declaration set of S(N, T). If it is an invalid set, the program is ill-formed the result of the search is an empty set; otherwise, the result is that set.

Rationale (CWG 2023-06-17)

Changing the lookup rules to yield an empty set has undesirable effects on non-operator lookup, where fall-back to non-member lookup is actually desired. The intended outcome for the example is as specified (i.e. the program is ill-formed). The example can be addressed by making `operator==` a member of `D`.

#### 192. Name lookup in parameters

Section: 6.5.3 [basic.lookup.unqual] Status: NAD Submitter: Alan Nash Date: 6 Jan 2000

The description of name lookup in the parameter-declaration-clause of member functions in 6.5.3 [basic.lookup.unqual] paragraphs 7-8 is flawed in at least two regards.

First, both paragraphs 7 and 8 apply to the parameter-declaration-clause of a member function definition and give different rules for the lookup. Paragraph 7 applies to names "used in the definition of a class `X` outside of a member function body...," which includes the parameter-declaration-clause of a member function definition, while paragraph 8 applies to names following the function's declarator-id (see the proposed resolution of issue 41), including the parameter-declaration-clause.

Second, paragraph 8 appears to apply to the type names used in the parameter-declaration-clause of a member function defined inside the class definition. That is, it appears to allow the following code, which was not the intent of the Committee:

        struct S {
            void f(I i) { }
            typedef int I;
        };

Additional note, January, 2012:

brace-or-equal-initializers for non-static data members are intended effectively as syntactic sugar for mem-initializers in constructor definitions; the lookup should be the same.

Rationale (February, 2021):

This issue was resolved by the resolution of issue 1352.

#### 231. Visibility of names after using-directives

Section: 6.5.3 [basic.lookup.unqual] Status: NAD Submitter: Jörg Barfurth Date: 31 May 2000

The wording of 6.5.3 [basic.lookup.unqual] paragraph 2 is misleading. It says:

> The declarations from the namespace nominated by a using-directive become visible in a namespace enclosing the using-directive; see 9.9.4 [namespace.udir].

According to 9.9.4 [namespace.udir] paragraph 1, that namespace is

> the nearest enclosing namespace which contains both the using-directive and the nominated namespace.

That would seem to imply the following:

        namespace outer {
            namespace inner {
                int i;
            }
            void f() {
                using namespace inner;
            }
            int j = i;   // inner::i is "visible" in namespace outer
        }

Suggested resolution: Change the first sentence of 6.5.3 [basic.lookup.unqual] paragraph 2 to read:

> The declarations from the namespace nominated by a using-directive become visible in the scope in which the using-directive appears after the using-directive.

Notes from the 4/02 meeting:

After a lot of discussion of possible wording changes, we decided the wording should be left alone. 6.5.3 [basic.lookup.unqual] paragraph 2 is not intended to be a full specification; that's in 9.9.4 [namespace.udir] paragraph 1. See also 6.4.6 [basic.scope.namespace] paragraph 1.

#### 1906. Name lookup in member `friend` declaration

Section: 6.5.3 [basic.lookup.unqual] Status: NAD Submitter: Richard Smith Date: 2014-03-30

According to 6.5.3 [basic.lookup.unqual] paragraph 10,

> In a `friend` declaration naming a member function, a name used in the function declarator and not part of a template-argument in the declarator-id is first looked up in the scope of the member function's class (6.5.2 [class.member.lookup]). If it is not found, or if the name is part of a template-argument in the declarator-id, the look up is as described for unqualified names in the definition of the class granting friendship.

The corresponding specification for non-`friend` declarations in paragraph 8 applies the class-scope lookup only to names that follow the declarator-id. The same should be true in `friend` declarations.

Proposed resolution (February, 2018):

1. Change 6.5.3 [basic.lookup.unqual] paragraph 8 as follows:

> For the members of a class `X`, a name used in a member function body, in a default argument, in a noexcept-specifier, in the brace-or-equal-initializer of a non-static data member (11.4 [class.mem]), or in the definition declaration of a class member outside of the definition of `X`, following the member's declarator-id32, shall be declared in one of the following ways:

> - before its use in the block in which it is used or in an enclosing block (8.4 [stmt.block]) within the body of the member function, or

> - shall be as a member of class `X` or be as a member of a base class of `X` (6.5.2 [class.member.lookup]), or

> - if `X` is a nested class of class `Y` (11.4.12 [class.nest]), shall be a member of `Y`, or shall be a member of a base class of `Y` (this lookup applies in turn to `Y`'s enclosing classes, starting with the innermost enclosing class),33 or

> - if `X` is a local class (11.6 [class.local]) or is a nested class of a local class, before the definition of class `X` in a block enclosing the definition of class `X`, or

> - if `X` is a member of namespace `N`, or is a nested class of a class that is a member of `N`, or is a local class or a nested class within a local class of a function that is a member of `N`, before the use of the name, in namespace `N` or in one of `N`'s enclosing namespaces., or

> - for a friend declaration in a class `Y`, in a scope that would be searched for a name appearing within `Y`.

2. Delete 6.5.3 [basic.lookup.unqual] paragraph 10 and combine its example with that of paragraph 8:

> In a `friend` declaration naming a member function, a name used in the function declarator and not part of a template-argument in the declarator-id is first looked up in the scope of the member function's class (6.5.2 [class.member.lookup]). If it is not found, or if the name is part of a template-argument in the declarator-id, the look up is as described for unqualified names in the definition of the class granting friendship. [Example:

>       struct A {
>         typedef int AT;
>         void f1(AT);
>         void f2(float);
>         template <class T> void f3();
>       };
>       struct B {
>         typedef char AT;
>         typedef float BT;
>         friend void A::f1(AT);     // parameter type is A::AT
>         friend void A::f2(BT);     // parameter type is B::BT
>         friend void A::f3<AT>(); // template argument is B::AT
>       };

> —end example]

Notes from the February, 2018 teleconference:

There was some concern as to whether the added lookup for friend function declarations placed the additional lookups in the correct sequence relative to the existing lookups and whether the new specification reflects any existing practice.

Rationale (March, 2018):

After further discussion, CWG determined that the semantics described in the existing wording were the most appropriate out of the alternatives considered.

#### 2357. Lookup in member function declarations

Section: 6.5.3 [basic.lookup.unqual] Status: NAD Submitter: John Spicer Date: 2017-09-07

Consider an example like the following:

      template <typename T>
      void doit(const T& t, const T& t2) { }

      template <typename T>
      struct Container {
        auto doit(Container<T> &rhs)
        noexcept(noexcept(doit(T{}, T{})))
           -> decltype(doit(T{}, T{}));
      };

      Container<int> c;

This would appear to be ill-formed because the exception specification is a delayed-parse region, where the lookup is in the context of the completed class, while the lookup in the `decltype` in the return type is done immediately. The latter should find the two-parameter version of `doit`, as expected, while the former finds the member, one-parameter version. Current implementations accept the code, however, and it seems unfortunate that the meaning would be different in the two contexts.

Rationale, June, 2018:

The example is ill-formed: the reference to `doit` in the return type would refer to the member function in the completed class, which is ill-formed, no diagnostic required, per 6.4.7 [basic.scope.class] paragraph 2.

#### 91. A union's associated types should include the union itself

Section: 6.5.4 [basic.lookup.argdep] Status: NAD Submitter: John Spicer Date: 2 Feb 1999

When a union is used in argument-dependent lookup, the union's type is not an associated class type. Consequently, code like this will fail to work.

        union U {
            friend void f(U);
        };

        int main() {
            U u;
            f(u);  // error: no matching f — U is not an associated class
        }

Is this an error in the description of unions in argument-dependent lookup?

Also, this section is written as if unions were distinct from classes. So adding unions to the "associated classes" requires either rewriting the section so that "associated classes" can include unions, or changing the term to be more inclusive, e.g. "associated classes and unions" or "associated types".

Jason Merrill: Perhaps in both cases, the standard text was intended to only apply to anonymous unions.

Liam Fitzpatrick: One cannot create expressions of an anonymous union type.

Rationale (04/99): Unions are class types, so the example is well-formed. Although the wording here could be improved, it does not rise to the level of a defect in the Standard.

#### 225. Koenig lookup and fundamental types

Section: 6.5.4 [basic.lookup.argdep] Status: NAD Submitter: Derek Inglis Date: 26 Jan 2000

In discussing issue 197, the question arose as to whether the handling of fundamental types in argument-dependent lookup is actually what is desired. This question needs further discussion.

Rationale (March, 2011):

There does not seem to be sufficient motivation at this point, with an additional eleven years' experience, to make a change.

#### 384. Argument-dependent lookup and operator functions

Section: 6.5.4 [basic.lookup.argdep] Status: NAD Submitter: Herb Sutter Date: 18 Sept 2002

I believe the following code example should unambiguously call the member operator+. Am I right?

      //--- some library header ---
      //
      namespace N1 {
        template<class T> struct Base { };

        template<class T> struct X {
          struct Y : public Base<T> {     // here's a member operator+
            Y operator+( int _Off ) const { return Y(); }
          };

          Y f( unsigned i ) { return Y() + i; } // the "+" in question
        };
      }

      //--- some user code ---
      //
      namespace N2 {
        struct Z { };

        template<typename T>              // here's another operator+
        int* operator+( T , unsigned ) { static int i ; return &i ; }
      }

      int main() {
        N1::X< N2::Z > v;
        v.f( 0 );
      }

My expectation is that 6.5.4 [basic.lookup.argdep] would govern, specifically:

> If the ordinary unqualified lookup of the name finds the declaration of a class member function, the associated namespaces and classes are not considered.

So I think the member should hide the otherwise-better-matching one in the associated namespace. Here's what compilers do:

Agree with me and call the member operator+: Borland 5.5, Comeau 4.3.0.1, EDG 3.0.1, Metrowerks 8.0, MSVC 6.0

Disagree with me and try to call N2::operator+: gcc 2.95.3, 3.1.1, and 3.2; MSVC 7.0

Simple so far, but someone tells me that 12.2.2.3 [over.match.oper] muddies the waters. There, paragraph 10 summarizes that subclause:

> [Note: the lookup rules for operators in expressions are different than the lookup rules for operator function names in a function call, ...

In particular, consider the above call to "Y() + unsigned" and please help me step through 12.2.2.3 [over.match.oper] paragraph 3:

> ... for a binary operator @ with a left operand of a type whose cv-unqualified version is T1 and a right operand of a type whose cv-unqualified version is T2,

OK so far, here @ is +, and T1 is N1::X::Y.

> three sets of candidate functions, designated member candidates, non-member candidates and built-in candidates, are constructed as follows:

[and later are union'd together to get the candidate list]

> If T1 is a class type, the set of member candidates is the result of the qualified lookup of T1::operator@ (over.call.func); otherwise, the set of member candidates is empty.

So there is one member candidate, N1::X::Y::operator+.

> The set of non-member candidates is the result of the unqualified lookup of operator@ in the context of the expression according to the usual rules for name lookup in unqualified function calls (basic.lookup.argdep) except that all member functions are ignored.

*** This is the question: What does that last phrase mean? Does it mean:

a) first apply the usual ADL rules to generate a candidate list, then ignore any member functions in that list (this is what I believe and hope it means, and in particular it means that the presence of a member will suppress names that ADL would otherwise find in the associated namespaces); or

b) something else?

In short, does N2::operator+ make it into the candidate list? I think it shouldn't. Am I right?

John Spicer: I believe that the answer is sort-of "a" above. More specifically, the unqualified lookup consists of a "normal" unqualified lookup and ADL. ADL always deals with only namespace members, so the "ignore members functions" part must affect the normal lookup, which should ignore class members when searching for an operator.

I suspect that the difference between compilers may have to do with details of argument-dependent lookup. In the example given, the argument types are "N1::X<N2::Z>::Y" and "unsigned int". In order for N2::operator+ to be a candidate, N2 must be an associated namespace.

N1::X<N2::Z>::Y is a class type, so 6.5.4 [basic.lookup.argdep] says that its associated classes are its direct and indirect base classes, and its namespaces are the namespaces of those classes. So, its associated namespace is just N1.

6.5.4 [basic.lookup.argdep] also says:

> If T is a template-id, its associated namespaces and classes are the namespace in which the template is defined; for member templates, the member template's class; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which any template template arguments are defined; and the classes in which any member templates used as template template arguments are defined. [Note: non-type template arguments do not contribute to the set of associated namespaces. ]

First of all, there is a problem with the term "is a template-id". template-id is a syntactic constuct and you can't really talk about a type being a template-id. Presumably, this is intended to mean "If T is the type of a class template specialization ...". But does this apply to N1::X<N2::Z>::Y? Y is a class nested within a class template specialization. In addition, its base class is a class template specialization.

I think this raises two issues:

1. Should the enclosing class(es) of a class, and their template argument lists (if any) contribute to the associated classes/namespaces for ADL?
2. Should the template argument lists of base classes contribute to the associated classes/namespaces for ADL?

Notes from the April 2003 meeting:

The ADL rules in the standard sort of look at if they are fully recursive, but in fact they are not; in some cases, enclosing classes and base classes are considered, and in others they are not. Microsoft and g++ did fully-recursive implementations, and EDG and IBM did it the other way. Jon Caves reports that Microsoft saw no noticeable difference (e.g., no complaints from customers internal or external) when they made this change, so we believe that even if the rules are imperfect the way they are in the standard, they are clear and the imperfections are small enough that programmers will not notice them. Given that, it seemed prudent to make no changes and just close this issue.

The template-id issue is spun off as issue 403.

#### 2136. Argument-dependent lookup and initializer lists

Section: 6.5.4 [basic.lookup.argdep] Status: NAD Submitter: Ryou Ezoe Date: 2015-06-10

Argument-dependent lookup does not consider the elements of an initializer list used as an argument. This seems inconsistent:

      namespace NS {
        struct X { } ;
        void f( std::initializer_list<X> ) { }
      }

      int main() {
        NS::X x ;
        // ADL fails to find NS::f
        f( {x,x,x} ) ;

        // OK. ADL finds NS::f
        auto i = {x,x,x} ;
        f( i ) ;

        // Also OK
        f( std::initializer_list<NS::X>{x,x,x} ) ;
      }

Rationale (October, 2015):

Argument-dependent lookup makes sense when the arguments correspond to actual parameters of the function. In the case of an initializer list, however, the elements of the initializer list need not bear any relationship to the actual parameter type of the function; instead, they provide values for aggregate initialization or construction of the object being initialized, and there is no reason to expect that that type will have the same associated namespace as the types of the elements of the initializer list.

#### 2142. Missing definition of associated classes and namespaces

Section: 6.5.4 [basic.lookup.argdep] Status: NAD Submitter: Daniel Krügler Date: 2015-06-13

One would expect to find a definition of the terms “associated class” and “associated namespace” in 6.5.4 [basic.lookup.argdep], but there is none. Note also that “associated class” is used in a different sense in 7.6.10 [expr.eq] bullet 3.6, and that drafting being proposed for other issues also uses the term differently.

Rationale (October, 2015):

CWG felt that the current usage is plain English, not a technical term, and is clear enough.

#### 635. Names of constructors and destructors of templates

Section: 6.5.5.2 [class.qual] Status: NAD Submitter: Martin Sebor Date: 23 May 2007

There is a discrepancy between the syntaxes allowed for defining a constructor and a destructor of a class template. For example:

        template <class> struct S { S(); ~S (); };
        template <class T> S<T>::S<T>() { }        // error
        template <class T> S<T>::~S<T>() { }       // okay

The reason for this is that 6.5.5.2 [class.qual] paragraph 2 says that `S::S` is “considered to name the constructor,” which is not a template and thus cannot accept a template argument list. On the other hand, the second `S` in `S::~S` finds the injected-class-name, which “can be used with or without a template-argument-list” (13.8.2 [temp.local] paragraph 1) and thus satisfies the requirement to name the destructor's class (11.4.7 [class.dtor] paragraph 1).

Would it make sense to allow the template-argument-list in the constructor declaration and thus make the language just a little easier to use?

Rationale (July, 2007):

The CWG noted that the suggested change would be confusing in the case where the class template had both template and non-template constructors.

#### 132. Local types and linkage

Section: 6.7 [basic.link] Status: NAD Submitter: Daveed Vandevoorde Date: 25 June 1999

6.7 [basic.link] paragraph 8 says,

> A name with no linkage (notably, the name of a class or enumeration declared in a local scope (6.4.3 [basic.scope.block] )) shall not be used to declare an entity with linkage.

This wording does not, but should, prohibit use of an unnamed local type in the declaration of an entity with linkage. For example,

        void f() {
            extern struct { } x;  // currently allowed
        }

Proposed resolution: Change the text in 6.7 [basic.link] paragraph 8 from:

> A name with no linkage (notably, the name of a class or enumeration declared in a local scope (6.4.3 [basic.scope.block])) shall not be used to declare an entity with linkage.

to:

> A name with no linkage (notably, the name of a class or enumeration declared in a local scope (6.4.3 [basic.scope.block])) or an unnamed type shall not be used to declare an entity with linkage.

In section 6.7 [basic.link] paragraph 8, add to the example, before the closing brace of function `f`:

> `extern struct {} x; //` ill-formed

Rationale (10/00): The proposed change would have introduced an incompatibility with the C language. For example, the global declaration

        static enum { A, B, C } abc;

represents an idiom that is used in C but would be prohibited under this resolution.

#### 278. External linkage and nameless entities

Section: 6.7 [basic.link] Status: NAD Submitter: Daveed Vandevoorde Date: 12 Apr 2000

It is unclear to what extent entities without names match across translation units. For example,

        struct S {
           int :2;
           enum { a, b, c } x;
           static class {} *p;
        };

If this declaration appears in multiple translation units, are all these members "the same" in each declaration?

A similar question can be asked about non-member declarations:

        // Translation unit 1:
        extern enum { d, e, f } y;

        // Translation unit 2:
        extern enum { d, e, f } y;

        // Translation unit 3:
        enum { d, e, f } y;

Is this valid C++? Is it valid C?

James Kanze: `S::p` cannot be defined, because to do so requires a type specifier and the type cannot be named. `::y` is valid C because C only requires compatible, not identical, types. In C++, it appears that there is a new type in each declaration, so it would not be valid. This differs from `S::x` because the unnamed type is part of a named type — but I don't know where or if the Standard says that.

John Max Skaller: It's not valid C++, because the type is a synthesised, unique name for the enumeration type which differs across translation units, as if:

        extern enum _synth1 { d,e,f} y;
        ..
        extern enum _synth2 { d,e,f} y;

had been written.

However, within a class, the ODR implies the types are the same:

        class X { enum { d } y; };

in two translation units ensures that the type of member `y` is the same: the two `X`'s obey the ODR and so denote the same class, and it follows that there's only one member `y` and one type that it has.

(See also issues 132 and 216.)

Rationale (February, 2021):

The resolution of issue 2300 and paper P2115R0 have resolved these questions.

#### 2230. Linkage of `extern "C"` function in unnamed namespace

Section: 6.7 [basic.link] Status: NAD Submitter: Jonathan Wakely Date: 2016-03-09

Consider:

      namespace {
        extern "C" void f() { }
      }

Does `f` have internal or external linkage? Implementations seem to give `f` external linkage, but the standard prescribes internal linkage per 6.7 [basic.link] paragraph 4.

Rationale (November, 2016):

The specification is as intended.

#### 1879. Inadequate definition of alignment requirement

Section: 6.8.3 [basic.align] Status: NAD Submitter: Richard Smith Date: 2014-02-24

For certain data types on some hardware, a given object can be accessed most efficiently with one alignment but can be successfully accessed if allocated at a less-stringent boundary. Should the Standard specify the minimum or the preferred alignment as the value of the `alignof`?

Rationale (June, 2014):

The existing wording is clear that the result `alignof` is the minimal alignment. If an operator returning the preferred alignment is desired, that request should be addressed to EWG.

#### 234. Reuse of base class subobjects

Section: 6.8.4 [basic.life] Status: NAD Submitter: Bill Wade Date: 28 Jun 2000

6.8.4 [basic.life] and 11.4.7 [class.dtor] discuss explicit management of object lifetime. It seems clear that most object lifetime issues apply to sub-objects (array elements, and data members) as well. The standard supports

         struct X { T t } x;
         T* pt = &x.t;
         pt->~T();
         new(pt) T;

and this kind of behavior is useful in allocators.

However the standard does not seem to prohibit the same operations on base sub-objects.

       struct D: B{ ... } d;
       B* pb = &d;
       pb->~B();
       new(pb) B;

However if `B` and/or `D` have virtual member functions or virtual bases, it is unlikely that this code will result in a well-formed `D` object in current implementations (note that the various lines may be in different functions).

Suggested resolution: 11.4.7 [class.dtor] should be modified so that explicit destruction of base-class sub-objects be made illegal, or legal only under some restrictive conditions.

Rationale (04/01):

Reallocation of a base class subobject is already disallowed by 6.8.4 [basic.life] paragraph 7.

#### 1050. Effects of thread support on object lifetime

Section: 6.8.4 [basic.life] Status: NAD Submitter: Hans Boehm Date: 2010-03-11

6.8.4 [basic.life] was never adjusted for threads. In particular, it describes what may be done with objects in various intervals. In general when the Standard uses words like “during,” it is referring to intervals defined by “sequenced before” ordering. In this context, however, all the specifications need to use the “happens before” ordering.

Suggested resolution:

Add the following at the beginning of 6.8.4 [basic.life]:

> All statements about the ordering of evaluations in this section, using words like “before,” “after,” and “during,” refer to the “happens before” order defined in 6.10.2 [intro.multithread]. [Note: We ignore situations in which evaluations are unordered by “happens before,” since these require a data race (6.10.2 [intro.multithread]), which already results in undefined behavior. —end note]

Rationale (August, 1020):

The text is already in the FCD.

#### 1280. Object reallocation and reference members

Section: 6.8.4 [basic.life] Status: NAD Submitter: Nikolay Ivchenkov Date: 2011-03-27

The restrictions in 6.8.4 [basic.life] paragraph 7 on when the storage for an object containing a reference member can be reused seem overly restrictive.

Rationale (August, 2011):

CWG did not find a persuasive use case for a change to the existing rules.

#### 1285. Trivial destructors and object lifetime

Section: 6.8.4 [basic.life] Status: NAD Submitter: Johannes Schaub Date: 2011-04-02

The Standard is self-contradictory regarding which destructor calls end the lifetime of an object. 6.8.4 [basic.life] paragraph 1 says,

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

> - if `T` is a class type with a non-trivial destructor (11.4.7 [class.dtor]), the destructor call starts, or

> - the storage which the object occupies is reused or released.

i.e., the lifetime of an object of a class type with a trivial destructor persists until its storage is reused or released. However, 11.4.7 [class.dtor] paragraph 15 says,

> Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended (6.8.4 [basic.life]).

implying that invoking any destructor, even a trivial one, ends the lifetime of the associated object. Similarly, 11.9.5 [class.cdtor] paragraph 1 says,

> For an object with a non-trivial destructor, referring to any non-static member or base class of the object after the destructor finishes execution results in undefined behavior.

A similar question arises for pseudo-destructors for non-class types.

Notes from the August, 2011 meeting:

CWG will need a paper exploring this topic before it can act on the issue.

Rationale (February, 2021):

The resolution of issue 2256 makes it clear that the destruction of an object, no matter how accomplished, ends its lifetime.

#### 2665. Replacing a subobject with a complete object

Section: 6.8.4 [basic.life] Status: NAD Submitter: Richard Smith Date: 2022-12-06

Subclause 6.8.4 [basic.life] bullet 8.5 says that o1 is only transparently replaceable by o2 if

> either o1 and o2 are both complete objects, or o1 and o2 are direct subobjects of objects p1 and p2, respectively, and p1 is transparently replaceable by p2.

This disallows most of the intended uses of the transparent replacement rule, including example 3 in 11.5.1 [class.union.general], which is similar to:

      union A { int n; string s; };
      A a;
      // Does not transparently replace A::s subobject, because
      // the created object is a complete object.
      new (&a.s) string("hello");
      string t = a.s;

The rule was changed in response to NB comment US 041 (C++20 CD) in what appears to be an over-reach: US 041 says that a member subobject should not transparently replace an unrelated member subobject, but is silent about complete objects transparently replacing members.

CWG 2023-01-06

Issues 2676 and 2677 were split off from this issue.

Subclause 6.8.2 [intro.object] paragraph 2 specifies that "the created object is a subobject of [the original] containing object" for the example above. This issue is therefore NAD.

#### 967. Exception specification of replacement allocation function

Section: 6.8.6.5 [basic.stc.dynamic] Status: NAD Submitter: Steve Clamage Date: 15 September, 2009

The global allocation functions are implicitly declared in every translation unit with exception-specifications (6.8.6.5 [basic.stc.dynamic] paragraph 2). It is not clear what should happen if a replacement allocation function is declared without an exception-specification. Is that a conflict with the implicitly-declared function (as it would be with explicitly-declared functions, and presumably is if the `<new>` header is included)? Or does the new declaration replace the implicit one, including the lack of an exception-specification? Or does the implicit declaration prevail? (Regardless of the exception-specification or lack thereof, it is presumably undefined behavior for an allocation function to exit with an exception that cannot be caught by a handler of type `std::bad_alloc` (6.8.6.5.2 [basic.stc.dynamic.allocation] paragraph 3).)

Rationale (November, 2014):

The predeclared allocation functions no longer have an exception-specification, so formally this issue is no longer applicable. As noted in the rationale of issue 1948, however, the intent is that the predeclarations are no different from ordinary declarations, so the replacement functions must have compatible exception-specifications.

#### 1948. exception-specification of replacement global `new`

Section: 6.8.6.5 [basic.stc.dynamic] Status: NAD Submitter: Steve Clamage Date: 2014-06-18

Some implementations accept code like

      #include <cstddef> // to get size_t
      void* operator new(std::size_t) noexcept { ... }

This declaration conflicts with the predeclaration of `operator new` with no exception-specification.

See also issue 967.

Rationale (November, 2014):

The specification intentionally makes such replacement functions ill-formed.

#### 2238. Contradictory alignment requirements for allocation

Section: 6.8.6.5.2 [basic.stc.dynamic.allocation] Status: NAD Submitter: Jason Merrill Date: 2016-03-03

Speaking of the value returned by an allocation function, 6.8.6.5.2 [basic.stc.dynamic.allocation] paragraph 2 says,

> The pointer returned shall be suitably aligned so that it can be converted to a pointer of any complete object type with a fundamental alignment requirement

However, the various “Effects” specifications in 17.6.3 [new.delete] have a different formulation:

> ...allocate `size` bytes of storage suitably aligned to represent any object of that size.

These should be reconciled.

Rationale (November, 2016):

The adoption of paper P0035R4 has rendered this issue moot.

#### 117. Timing of destruction of temporaries

Section: 6.8.7 [class.temporary] Status: NAD Submitter: Mike Miller Date: 14 May 1999

6.8.7 [class.temporary] paragraph 4 seems self-contradictory:

> the temporary that holds the result of the expression shall persist until the object's initialization is complete... the temporary is destroyed after it has been copied, before or when the initialization completes.

How can it be destroyed "before the initialization completes" if it is required to "persist until the object's initialization is complete?"

Rationale (04/00):

It was suggested that "before the initialization completes" refers to the case in which some part of the initialization terminates by throwing an exception. In that light, the apparent contradiction does not apply.

#### 1651. Lifetime extension of temporary via reference to subobject

Section: 6.8.7 [class.temporary] Status: NAD Submitter: Richard Smith Date: 2013-04-15

The resolution of issues 616 and 1213, making the result of a member access or subscript expression applied to a prvalue an xvalue, means that binding a reference to such a subobject of a temporary does not extend the temporary's lifetime. 6.8.7 [class.temporary] should be revised to ensure that it does.

Proposed resolution (February, 2014): [SUPERSEDED]

This issue is resolved by the resolution of issue 1299.

Rationale (February, 2019):

This concern is already covered by 6.8.7 [class.temporary] paragraph 6:

> The temporary object to which the reference is bound or the temporary object that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference if...

#### 1695. Lifetime extension via init-capture

Section: 6.8.7 [class.temporary] Status: NAD Submitter: Richard Smith Date: 2013-05-31

If an init-capture binds a const reference to a temporary, is the lifetime of the temporary extended to match that of the lambda? For example,

       struct S { ~S(); };
       const S f();
       auto &&lambda = [&x(f())] () -> auto& { return x; };
       auto &y = lambda(); // ok?

Notes from the September, 2013 meeting:

CWG agreed that there is no lifetime extension in this example.

Rationale (June, 2014):

After further consideration, CWG agreed that this example should extend the lifetime of the temporary (because the notional variable is a reference) and that the existing text is clear enough in this regard.

#### 290. Should memcpy be allowed into a POD with a const member?

Section: 6.9 [basic.types] Status: NAD Submitter: Garry Lancaster Date: 12 Jun 2001

Following the definition in Clause 11 [class] paragraph 4 the following is a valid POD (actually a POD-struct):

        struct test
        {
            const int i;
        };

The legality of PODs with const members is also implied by the text of 7.6.2.8 [expr.new] bullet 15.1, sub-bullet 2 and 11.9.3 [class.base.init] bullet 4.2.

6.9 [basic.types] paragraph 3 states that

> For any POD type `T`, if two pointers to `T` point to distinct objects `obj1` and `obj2`, if the value of `obj1` is copied into `obj2`, using the `memcpy` library function, `obj2` shall subsequently hold the same value as `obj1`.

[Note: this text was changed by TC1, but the essential point stays the same.]

This implies that the following is required to work:

        test obj1 = { 1 };
        test obj2 = { 2 };
        memcpy( &obj2, &obj1, sizeof(test) );

The memcpy of course changes the value of the const member, surely something that shouldn't be allowed.

Suggested resolution:

It is recommended that 6.9 [basic.types] paragraph 3 be reworded to exclude PODs which contain (directly or indirectly) members of const-qualified type.

Rationale (October, 2004):

9.2.9.2 [dcl.type.cv] paragraph 4 already forbids modifying a const member of a POD struct. The prohibition need not be repeated in 6.9 [basic.types].

#### 646. Can a class with a constexpr copy constructor be a literal type?

Section: 6.9 [basic.types] Status: NAD Submitter: Jens Maurer Date: 9 Aug 2007

6.9 [basic.types] paragraph 11 requires that a class type have a trivial copy constructor in order to be classified as a literal type. This seems overly restrictive; presumably having a constexpr copy constructor would suffice. (Note that a trivial copy constructor is a constexpr constructor according to 9.2.6 [dcl.constexpr] paragraph 4.)

Rationale (June, 2008):

A copy constructor takes a reference as its first parameter, thus no user-declared copy constructor can be constexpr.

#### 1334. Layout compatibility and cv-qualification

Section: 6.9 [basic.types] Status: NAD Submitter: Daniel Krügler Date: 2011-06-23

Should cv-qualified and cv-unqualified versions of fundamental types be considered to be layout-compatible types?

Rationale (August, 2011):

The purpose of “layout compatible” types in C++ is for C compatibility with respect to the common initial sequence of structs appearing in unions. However, C requires that corresponding members have compatible types, and compatible types must have the same cv-qualification. Consequently, this issue is not a defect.

#### 627. Values behaving as types

Section: 6.9.2 [basic.fundamental] Status: NAD Submitter: Gennaro Prota Date: 15 March 2007

6.9.2 [basic.fundamental] paragraph 6 states,

> As described below, `bool` values behave as integral types.

This sentence looks definitely out of order: how can a value behave as a type?

Suggested resolution:

Remove the sentence entirely, as it doesn't supply anything that isn't already stated in the following paragraphs and in the referenced section about integral promotion.

Rationale (July, 2007):

This is, at most, an editorial issue with no substantive impact. The suggestion has been forwarded to the project editor for consideration.

#### 1276. Reference to `stdint.h`

Section: 6.9.2 [basic.fundamental] Status: NAD Submitter: Daniel Krügler Date: 2011-03-26

6.9.2 [basic.fundamental] paragraph 5 refers to a C header instead of to its C++ equivalent:

> ...Types `char16_t` and `char32_t` denote distinct types with the same size, signedness, and alignment as `uint_least16_t` and `uint_least32_t`, respectively, in `<stdint.h>`, called the underlying types.

Rationale (August, 2011)

This is an editorial issue that has been transmitted to the project editor.

#### 1448. Integral values of type `bool`

Section: 6.9.2 [basic.fundamental] Status: NAD Submitter: Johannes Schaub Date: 2012-01-19

Although 6.9.2 [basic.fundamental] paragraph 7 classifies `bool` as an integral type, the values of `true` and `false` are not specified — only that the results of converting them to another integral type are `1` and `0`, respectively. This omission leaves unspecified whether `false` is an integral null pointer constant or not.

Rationale (February, 2012):

The resolution of issue 903 makes it clear that `false` is not a null pointer constant.

#### 1040. Memory model issues

Section: 6.10.2 [intro.multithread] Status: NAD Submitter: Paul McKinney Date: 2010-03-03

This issue is for tracking various concerns that are raised in paper N3057.

Rationale (August, 2010):

The paper was voted in in Pittsburgh.

#### 1470. Thread migration

Section: 6.10.2 [intro.multithread] Status: NAD Submitter: Detlef Vollman Date: 2012-02-14

It is not clear from the wording of 6.10.2 [intro.multithread] that different statements in the same function cannot be executed by different threads.

Rationale (September, 2013):

SG-1 determined that the existing wording is clear enough.

#### 1661. Preservation of infinite loops

Section: 6.10.2 [intro.multithread] Status: NAD Submitter: Daniel Krügler Date: 2013-04-15

According to 6.10.2 [intro.multithread] paragraph 24,

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

> - terminate,

> - make a call to a library I/O function,

> - access or modify a volatile object, or

> - perform a synchronization operation or an atomic operation.

> [Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. —end note]

Some programmers find this liberty afforded to implementations to be disadvantageous; see this blog post for a discussion of the subject.

Rationale (October, 2015)

SG1 reaffirms the original intent of this specification.

#### 2954. Simultaneous modifications of an atomic object

Section: 6.10.2.2 [intro.races] Status: NAD Submitter: Jim X Date: 2024-11-08

(From submission #636.)

Subclause 6.10.2.2 [intro.races] paragraph 4 specifies:

> All modifications to a particular atomic object M occur in some particular total order, called the modification order of M. ...

Is the total order a strict total order? If not, modifications may appear to occur simultaneously.

Suggested resolution:

1. Change in 6.10.2.2 [intro.races] paragraph 4 as follows:

   > All modifications to a particular atomic object M occur in some particular strict total order, called the modification order of M. ...

2. Change in 32.5.4 [atomics.order] paragraph 4 as follows:

   > There is a single strict total order S on all memory_order::seq_cst operations, including fences, that satisfies the following constraints. ...

Additional notes (November, 2024)

Forwarded to SG1 and LWG by decision of the CWG chair, via paper issue 2137.

CWG 2024-11-08

If "modifications [...] occur in some particular total order", one can equivalently define a strict or non-strict total order over them, as those are isomorphic. Phrases like "A is earlier than B in the modification order of M" plainly refer to <, not <=.

#### 269. Order of initialization of multiply-defined static data members of class templates

Section: 6.10.3.2 [basic.start.static] Status: NAD Submitter: Andrei Iltchenko Date: 8 Feb 2001

According to 6.3 [basic.def.odr] paragraph 5, it is possible for a static data member of a class template to be defined more than once in a given program provided that each such definition occurs in a different translation unit and the ODR is met.

Now consider the following example:

src1.cpp:

        #include <iostream>

        int  initializer()
        {
           static int   counter;
           return  counter++;
        }

        int   g_data1 = initializer();

        template<class T>
        struct  exp  {
           static int   m_data;
        };
        template<class T>
        int  exp<T>::m_data = initializer();

        int   g_data2 = initializer();
        extern int   g_data3;

        int  main()
        {
           std::cout << exp<char>::m_data << ", " << g_data1 << ", "
    	  << g_data2 << ", " << g_data3 << std::endl;
           return  0;
        }

src2.cpp:

        extern int  initializer();
        int  g_data3 = initializer();

        template<class T>
        struct  exp  {
           static int   m_data;
        };
        template<class T>
        int  exp<T>::m_data = initializer();

        void  func()
        {
          exp<char>::m_data++;
        }

The specialization `exp<char>::m_data` is implicitly instaniated in both translation units, hence (13.9.2 [temp.inst] paragraph 1) its initialization occurs. And for both definitions of `exp<T>::m_data` the ODR is met. According to 6.10.3.2 [basic.start.static] paragraph 1:

> Objects with static storage duration defined in namespace scope in the same translation unit and dynamically initialized shall be initialized in the order in which their definition appears in the translation unit.

But for `exp<T>::m_data` we have two definitions. Does it mean that both `g_data1` and `g_data3` are guaranteed to be dynamically initialized before `exp<char>::m_data`?

Suggested Resolution: Insert the following sentence before the last two sentences of 6.3 [basic.def.odr] paragraph 5:

> In the case of `D` being a static data member of a class template the following shall also hold:

> - for a given (not explicit) specialization of `D` initialized dynamically (6.10.3.2 [basic.start.static]), the accumulated set of objects initialized dynamically in namespace scope before the specialization of `D` shall be the same in every translation unit that contains the definition for this specialization.

Notes from 10/01 meeting:

It was decided that this issue is not linked to issue 270 and that there is no problem, because there is only one instantiation (see 5.2 [lex.phases] paragraph 8).

#### 465. May constructors of global objects call `exit()`?

Section: 6.10.3.2 [basic.start.static] Status: NAD Submitter: Matt Austern Date: 26 Feb 2004

The subject line pretty much says it all. It's a possibility that hadn't ever occurred to me. I don't see any prohibition in the standard, and I also don't think the possibility introduces any logical inconsistencies. The proper behavior, presumably, would be to go through the list of already-constructed objects (not including the current one, since its constructor wouldn't have finished executing) and destroy them in reverse order. Not fundamentally hard, and I'm sure lots of existing implementations already do that.

I'm just not sure whether the standard was intended to support this, or whether it's just that nobody else thought of it either. If the former, then a non-normative note somewhere in 6.10.3.2 [basic.start.static] might be nice.

Rationale (October 2004):

There is nothing in the Standard to indicate that this usage is prohibited, so it must be presumed to be permitted.

#### 1749. Confusing definition for constant initializer

Section: 6.10.3.2 [basic.start.static] Status: NAD Submitter: Daniel Krügler Date: 2013-09-12

According to 6.10.3.2 [basic.start.static] paragraph 2,

> A constant initializer for an object `o` is an expression that is a constant expression, except that it may also invoke `constexpr` constructors for `o` and its subobjects even if those objects are of non-literal class types [Note: such a class may have a non-trivial destructor —end note].

This would be clearer if worded as something like,

> A constant initializer for an object `o` is an expression that would be a constant expression if every `constexpr` constructor invoked for `o` and its subobjects were a constructor for a literal class type.

Rationale (February, 2014):

CWG felt that the existing wording is clear enough.

#### 640. Accessing destroyed local objects of static storage duration

Section: 6.10.3.3 [basic.start.dynamic] Status: NAD Submitter: Howard Hinnant Date: 30 July 2007

6.10.3.3 [basic.start.dynamic] paragraph 2 says,

> If a function contains a local object of static storage duration that has been destroyed and the function is called during the destruction of an object with static storage duration, the program has undefined behavior if the flow of control passes through the definition of the previously destroyed local object.

I would like to turn this behavior from undefined to well-defined behavior for the purpose of achieving a graceful shutdown, especially in a multi-threaded world.

Background: Alexandrescu describes the “phoenix singleton” in Modern C++ Design. This is a class used as a function local static, that will reconstruct itself, and reapply itself to the `atexit` chain, if the program attempts to use it after it is destructed in the `atexit` chain. It achieves this by setting a “destructed flag” in its own state in its destructor. If the object is later accessed (and a member function is called on it), the member function notes the state of the “destructed flag” and does the reconstruction dance. The phoenix singleton pattern was designed to address issues only in single-threaded code where accesses among static objects can have a non-scoped pattern. When we throw in multi-threading, and the possibility that threads can be running after `main` returns, the chances of accessing a destroyed static significantly increase.

The very least that I would like to see happen is to standardize what I believe is existing practice: When an object is destroyed in the `atexit` chain, the memory the object occupied is left in whatever state the destructor put it in. If this can only be reliably done for objects with standard layout, that would be an acceptable compromise. This would allow objects to set “I'm destructed” flags in their state and then do something well-defined if accessed, such as throw an exception.

A possible refinement of this idea is to have the compiler set up a 3-state flag around function-local statics instead of the current 2-state flag:

- Not constructed yet
- Constructed but not destroyed yet
- Destroyed

We have the first two states today. We might choose to add the third state, and if execution passes over a function-local static with “destroyed” state, an exception could be thrown. This would mean that we would not have to guarantee memory stability in destroyed objects of static duration.

This refinement would break phoenix singletons, and is not required for the `~mutex()`/`~condition()` I've described and prototyped. But it might make it easier for Joe Coder to apply this kind of guarantee to his own types.

Rationale (CWG 2023-05-12)

This is an extension that requires a paper targeted at EWG.

#### 71. Incorrect cross reference

Section: Clause 7 [expr] Status: NAD Submitter: Neal Gafter Date: 15 Oct 1998

An operator expression can, according to Clause 7 [expr] paragraph 2, require transformation into function call syntax. The reference in that paragraph is to 12.4 [over.oper] , but it should be to 12.2.2.3 [over.match.oper] .

Rationale (04/99): The subsections 12.4.2 [over.unary] , 12.4.3 [over.binary] , etc. of the referenced section are in fact relevant.

#### 584. Unions and aliasing

Section: 7.2.1 [basic.lval] Status: NAD Submitter: comp.std.c++ Date: 10 June 2006

The C++ standard says in 7.2.1 [basic.lval], in paragraph 15:

- an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union),

Note that it is a literal copy from the C standard, but this is of course not the problem.

In C, union is not defined as an aggregate type. Therefore it is appropriate to say “aggregate or union.” But things changed in C++: aggregate type includes union type now (though not all unions are aggregates), and it becomes clear that the “union” in “aggregate or union” is redundant and should be deleted.

The above cited paragraph could be changed to:

- an aggregate type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate)

Rationale (October, 2006):

As noted in the issue, not all unions are aggregates, but those that are not aggregates still allow aliasing. That part of the specification would be lost with the suggested change.

#### 1026. Cv-qualified non-class rvalues

Section: 7.2.1 [basic.lval] Status: NAD Submitter: Jerry Coffin Date: 2010-02-01

Historically, based on C's treatment, cv-qualification of non-class rvalues has been ignored in C++. With the advent of rvalue references, it's not quite as clear that this is desirable. For example, some implementations are reported to print `const rvalue` for the following program:

    const int bar() {
       return 5;
    }

    void pass_int(int&& i) {
       printf("rvalue\n");
    }

    void pass_int(const int&& i) {
       printf("const rvalue\n");
    }

    int main() {
       pass_int(bar());
    }

Rationale (August, 2010):

The current specification is as intended.

#### 1998. Additional sources of xvalue expressions

Section: 7.2.1 [basic.lval] Status: NAD Submitter: Daveed Vandevoorde Date: 2014-09-08

According to 7.2.1 [basic.lval] paragraph 1,

> An xvalue is the result of certain kinds of expressions involving rvalue references (9.3.4.3 [dcl.ref]).

However, there are now expressions not involving rvalue references whose results are xvalues, e.g., a member access expression in which the left operand is a prvalue.

Rationale (November, 2014):

The cited wording does not preclude other kinds of expressions that result in xvalues. This wording could be expanded editorially if a more extensive coverage is desired.

#### 617. Lvalue-to-rvalue conversions of uninitialized `char` objects

Section: 7.3.2 [conv.lval] Status: NAD Submitter: Alan Stokes Date: 6 February 2007

According to 7.3.2 [conv.lval] paragraph 1, applying the lvalue-to-rvalue conversion to any uninitialized object results in undefined behavior. However, character types are intended to allow any data, including uninitialized objects and padding, to be copied (hence the statements in 6.9.2 [basic.fundamental] paragraph 1 that “For character types, all bits of the object representation participate in the value representation” and in 7.2.1 [basic.lval] paragraph 15 that `char` and `unsigned char` types can alias any object). The lvalue-to-rvalue conversion should be permitted on uninitialized objects of character type without evoking undefined behavior.

Rationale (February, 2021):

The Standard now clearly specifies the handling of indeterminate values for `unsigned char` and `std::byte` types; see 6.8.5 [basic.indet].

#### 303. Integral promotions on bit-fields

Section: 7.3.7 [conv.prom] Status: NAD Submitter: Kiril Avdeiv Date: 24 Jul 2001

Paragraph 3 of section 7.3.7 [conv.prom] contains a statement saying that if a bit-field is larger than int or unsigned int, no integral promotions apply to it. This phrase needs further clarification, as it is hardly possible to fugure out what it means. See below.

Assuming a machine with a size of general-purpose register equal 32 bits (where a byte takes up 8 bits) and a C++ implementation where an int is 32 bits and a long is 64 bits. And the following snippet of code:

        struct ExternalInterface {
          long field1:36, field2:28;
        };
        int main() {
          ExternalInterface  myinstance = { 0x100000001L, 0x12,};
          if(myinstance.field1 < 0x100000002L) { //do something }
        }

Does the standard prohibit the implementation from promoting field1's value into two general purpose registers? And imposes a burden of using shift machine instructions to work with the field's value? What else could that phrase mean?

Either alternative is implementation specific, so I don't understand why the phrase "If the bit-field is larger yet, no integral promotions apply to it" made it to the standard.

Notes from 10/01 meeting:

The standard of course does not dictate what an implementation might do with regard to use of registers or shift instructions in the generated code. The phrase cited means only that a larger bit-field does not undergo integral promotions, and therefore it retains the type with which it was declared (`long` in the above example). The Core Working Group judged that this was sufficiently clear in the standard.

Note that 11.4.10 [class.bit] paragraph 1 indicates that any bits in excess of the size of the underlying type are padding bits and do not participate in the value representation. Therefore the `field1` bit field in the above example is not capable of holding the indicated values, which require more than 32 bits.

#### 566. Conversion of negative floating point values to integer type

Section: 7.3.11 [conv.fpint] Status: NAD Submitter: Seungbeom Kim Date: 13 March 2006

Section 7.3.11 [conv.fpint] paragraph 1 states:

> An rvalue of a floating point type can be converted to an rvalue of an integer type. The conversion truncates; that is, the fractional part is discarded.

Here, the concepts of “truncation” and “fractional part” seem to be used without precise definitions. When -3.14 is converted into an integer, is the truncation toward zero or away from zero? Is the fractional part -0.14 or 0.86? The standard seem to give no clear answer to these.

Suggested resolution:

1. Replace “truncates” with “truncates toward zero.”

2. Replace “the fractional part” with “the fractional part (where that of `x` is defined as `x-floor(x)` for nonnegative `x` and `x-ceiling(x)` for negative `x`);” there should be a better wording for this, or the entire statement “that is, the fractional part is discarded” can be removed, once the meaning of “truncation” becomes unambiguous as above.

Rationale (October, 2006):

The specification is clear enough: “fractional part” refers to the digits following the decimal point, so that -3.14 converted to `int` becomes -3.

#### 2139. Floating-point requirements for integer representation

Section: 7.3.11 [conv.fpint] Status: NAD Submitter: Tony Van Eerd Date: 2015-06-12

There is no normative requirement regarding the ability of floating-point values to represent integer values exactly; however, 7.3.11 [conv.fpint] paragraph 2 appears to implicitly rely on their ability to represent the values 0 and 1:

> If the source type is `bool`, the value `false` is converted to zero and the value `true` is converted to one.

Rationale (October, 2015):

CWG felt that the cited passage should be read as indicating that converting true and false should have the same result as converting 1 and 0 and thus do not imply a requirement that those values be represented exactly.

#### 456. Is initialized const int or const bool variable a null pointer constant?

Section: 7.3.12 [conv.ptr] Status: NAD Submitter: Lloyd Lewins Date: 31 Jan 2004

In the following code, I expect both "null" and "FALSE" to be null pointer constants -- and that the code should compile and output the string "int*" twice to cout:

    #include <iostream>

    using namespace std;

    void foo(int* p)
    {
         cout << "int*" << endl;
    }

    int main(void)
    {
         const int null = 0;
         foo(null);
         const bool FALSE = false;
         foo(FALSE);
    }

ISO/IEC 14882-1998 7.3.12 [conv.ptr] states:

> An integral constant expression rvalue of integer type that evaluates to zero (called a /null pointer constant/) can be converted to a pointer type.

Stroustrup appears to agree with me -- he states (3rd edition page 88):

> In C, it has been popular to define a macro NULL to represent the zero pointer. Because of C++`s tighter type checking, the use of plain 0, rather than any suggested NULL macro, leads to fewer problems. If you feel you must define NULL, use:

>        const int NULL = 0;

However gcc 3.3.1 rejects this code with the errors:

         bug.cc:17: error: invalid conversion from `int' to `int*'
         bug.cc:19: error: cannot convert `const bool' to `int*' for argument `1' to `
             void foo(int*)'

I have reported this as a bug (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13867), but the gcc team states that 4.10 requires that a null pointer constant must be an rvalue -- and no implicit conversion from an lvalue to an rvalue is required (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=396):

> a null pointer constant is an integral constant expression rvalue that evaluates to zero [4.10/1] in this case `null' is an lvalue. The standard does not specify that lvalue->rvalue decay happens here, so `null' is not a null pointer constant.

I disagree with the gcc teams interpretation -- I don't see why 7.2.1 [basic.lval] doesn't apply:

> Whenever an lvalue appears in a context where an rvalue is expected, the lvalue is converted to an rvalue;

The insertion of the word rvalue appears to have occurred during standardization -- it is not present in either Stroustrup 2nd edition or the 3rd edition. Does the committee deliberately intend to exclude an lvalue as a null pointer constant by adding the word rvalue? If so, it leads to the rather bizarre fact that "null" is not a null pointer constant, but "null + 0" is!

Notes from the March 2004 meeting:

We think this is just a bug in gcc. The const variable does get converted to an rvalue in this context. This case is not really any different than cases like

      const int null = 0;
      int i = null;

or

      const int i = 1;
      int a[i];

(which are accepted by gcc). No one would argue that the second lines of those examples are invalid because the variables are lvalues, and yet the conversions to rvalue happen implicitly for the same reason cited above -- the contexts require an rvalue.

#### 794. Base-derived conversion in member type of pointer-to-member conversion

Section: 7.3.13 [conv.mem] Status: NAD Submitter: CH Date: 2009-03-03
N2800 comment CH 1

Currently both implicit (7.3.13 [conv.mem]) and explicit (7.6.1.9 [expr.static.cast]) conversions of pointers to members permit only cases in which the type of the member is the same except for cv-qualification. It would seem reasonable to allow conversions in which one member type is a base class of the other. For example:

        struct B { };
        struct D: B { };
        struct X {
            D d;
        };
        struct Y: X { };
        B Y::* pm = &X::d;  // Currently ill-formed: type of d is D, not B

(See also issue 170.)

EWG 2022-11-11

The change is plausible, but needs a paper to EWG.

#### 795. Dependency of lambdas on `<functional>`

Section: 7.5.6 [expr.prim.lambda] Status: NAD Submitter: UK Date: 3 March, 2009
N2800 comment UK 45

7.5.6 [expr.prim.lambda] paragraph 2 says,

> A closure object behaves as a function object (22.10 [function.objects])...

This linkage to `<functional>` increases the dependency of the language upon the library and is inconsistent with the definition of “freestanding” in 16.4.2.5 [compliance].

Rationale (July, 2009):

The reference to 22.10 [function.objects] appears in a note, not in normative text, and is intended only to clarify the meaning of the term “function object.” The CWG does not believe that this reference creates any dependency on any library facility.

#### 958. Lambdas and `decltype`

Section: 7.5.6 [expr.prim.lambda] Status: NAD Submitter: Jason Merrill Date: 31 August, 2009

The following case is ill-formed:

        int f (int&);
        void* f (const int&);

        int main()
        {
           int i;
           [=] ()-> decltype(f(i)) { return f(i); };
        }

The `decltype(f(i))` is not of the form `decltype((x))`, and also not within the body of the lambda, so the special rewriting rule doesn't apply. So, the call in the decltype selects the first overload, and the call in the body selects the second overload, and there's no conversion from `void*` to `int`, so the return-statement is ill-formed.

This pattern is likely to arise frequently because of the retrictions on deducing the return type from the body of the lambda.

Daveed Vandevoorde: The pattern may be common, but it probably doesn't matter much in practice. It's most likely that overloaded functions that differ only in the cv-qualification of their parameters will have related return types.

Rationale (October, 2009):

The consensus of the CWG was that this is not a sufficiently important problem to warrant changing the existing specification.

#### 1118. Implicit lambda capture via explicit copy constructor

Section: 7.5.6.3 [expr.prim.lambda.capture] Status: NAD Submitter: FI Date: 2010-08-02
N3092 comment FI 19

According to 7.5.6 [expr.prim.lambda] paragraph 21,

> When the lambda-expression is evaluated, the entities that are captured by copy are used to direct-initialize each corresponding non-static data member of the resulting closure object.

This apparently means that if the capture-default is to copy, entities captured by default, implicitly, are copied even in cases where the copy constructors of such entities are explicit. It should be required that such entities be captured explicitly instead.

See also issue 1020.

Rationale (August, 2010):

The behavior is according to the original design and is similar to what would happen if the constructor of the closure object initialized the members for the captured entities using mem-initializers. CWG did not see sufficient motivation to change the design.

#### 1663. Capturing an empty pack expansion

Section: 7.5.6.3 [expr.prim.lambda.capture] Status: NAD Submitter: Michael Wong Date: 2013-04-15
N3690 comment CA 19

The conditions under which a closure class has a conversion function to a pointer-to-function type are given in 7.5.6 [expr.prim.lambda] paragraph 6:

> The closure type for a non-generic lambda-expression with no lambda-capture has a public non-virtual non-explicit const conversion function to pointer to function...

Does this apply to a lambda whose lambda-capture is empty by virtue of being an empty pack expansion? For example, is the following well-formed?

      #include <cstdlib>

      template <typename ...Args>
      void foo(Args ...args) {
        auto xf = [args ...] { };
        std::atexit(xf);
      }

This is likely a violation of the rule in 13.8 [temp.res] paragraph 8,

> If every valid specialization of a variadic template requires an empty template parameter pack, the template is ill-formed, no diagnostic required.

Does this need to be clarified?

Rationale (September, 2013):

The statement in 7.5.6 [expr.prim.lambda] paragraph 6 is a syntactic constraint, not a semantic one. The example has a lambda-capture, regardless of its expansion in a given instantiation. This is consistent with the intent expressed in 13.7.4 [temp.variadic] paragraph 6:

> When N is zero, the instantiation of the expansion produces an empty list. Such an instantiation does not alter the syntactic interpretation of the enclosing construct...

#### 1743. init-captures in nested lambdas

Section: 7.5.6.3 [expr.prim.lambda.capture] Status: NAD Submitter: Faisal Vali Date: 2013-08-30

According to 7.6.1.2 [expr.sub] paragraph 11,

> No entity is captured by an init-capture.

It should be made clearer that a variable, odr-used by an init-capture in a nested lambda, is still captured by the containing lambda as a result of the init-capture.

Rationale (October, 2015):

Subsequent edits have removed the offending phraseXS.

#### 2159. Lambda capture and local `thread_local` variables

Section: 7.5.6.3 [expr.prim.lambda.capture] Status: NAD Submitter: Richard Smith Date: 2015-07-15

Consider the following example:

      void f() {
        thread_local int n = 10;
        std::thread([&] { std::cout << n << std::endl; }).join();
      }

This function prints `0`, because:

1. The lambda does not capture `n`

2. `n` is not initialized on the spawned thread prior to the invocation of the lambda.

Additional note, March, 2016:

SG1 discussed this issue and concluded that the issues should be resolved follows:

1. If the program would result in a capture by reference of a local thread-local variable, then it is ill-formed.

2. If the program has a capture by value of a local thread-local variable, then a copy of the value from the calling thread is captured (and initialized in the calling thread, if necessary).

The rationale for #1 is that, if we allowed capture of local thread-locals, some programmers will have one intuition of what to expect and other programmers will have the opposite intuition. It's better to forbid both interpretations. We don't want to say simply that there is no capture by reference of thread-locals, because simply ignoring the local thread-local might result in name-lookup finding a global variable by the same name, which would be very confusing.

Rationale (March, 2017):

Only automatic variables are captured. A lambda accessing a thread-local variable would be ill-formed.

#### 1555. Language linkage and function type compatibility

Section: 7.6.1.3 [expr.call] Status: NAD Submitter: Daniel Krügler Date: 2012-09-18

Currently function types with different language linkage are not compatible, and 7.6.1.3 [expr.call] paragraph 1 makes it undefined behavior to call a function via a type with a different language linkage. These features are generally not enforced by most current implementations (although some do) between functions with C and C++ language linkage. Should these restrictions be relaxed, perhaps as conditionally-supported behavior?

Rationale (October, 2012):

CWG felt that this language design question would be better considered by EWG.

EWG 2022-11-11

Any changes in this area should be pursued via a paper to EWG.

#### 1525. Array bound inference in temporary array

Section: 7.6.1.4 [expr.type.conv] Status: NAD Submitter: Steve Adamczyk Date: 2012-07-18

Should the determination of array bounds from an initializer, described in 9.5.2 [dcl.init.aggr] paragraph 4, apply to creation of a temporary array using the `T{`expr`}` syntax? E.g., is the following example well-formed?

      typedef int ARR[];
      int* p = ARR{1,2,3};

(See also issues 1300, 1307, and 1326.)

Rationale (October, 2012):

The example is valid, according to the new wording of 9.5.2 [dcl.init.aggr] paragraph 4.

#### 1585. Value category of member access of rvalue reference member

Section: 7.6.1.5 [expr.ref] Status: NAD Submitter: Daniel Krügler Date: 2012-11-13

According to 7.6.1.5 [expr.ref] paragraph 4,

> If `E2` is declared to have type “reference to `T`,” then `E1.E2` is an lvalue...

This applies to rvalue reference types as well as to lvalue reference types, based on the rationale from Clause 7 [expr] paragraph 7 that

> In general... named rvalue references are treated as lvalues and unnamed rvalue references to objects are treated as xvalues...

Since a non-static data member has a name, it would appear most naturally to fall into the lvalue category. This makes sense as well from the perspective that the target of such a reference does not bear any necessary correlation with the value category of the object expression; in particular, an xvalue object might have an rvalue reference member referring to a different object from which it would be an error to move.

On the other hand, rvalue reference members have limited utility and are likely only to occur as the result of template argument deduction in the context of perfect forwarding, such as using a `std::pair` to forward values. In such cases, a `first` or `second` member of rvalue reference type would be most naturally treated as having the same value category as that of the object expression. The utility of this usage may outweigh the safety considerations that shaped the current policy.

Rationale (April, 2013):

The design of rvalue references in the language is complex, and CWG felt that an attempt to change the existing rules to accommodate this case ran the risk of breaking other cases. Treating named rvalue reference members as lvalues, consistently with other named rvalue references, is also safer in that it prevents the inadvertent theft of resources from an object to which such a member refers.

#### 2231. Class member access to static data member template

Section: 7.6.1.5 [expr.ref] Status: NAD Submitter: Faisal Vali Date: 2016-02-18

Consider:

      struct A {
        template<class T> static int X;
      };
      template<class T> int A::X = T{};

      A{}.X<int>; // error
      A::X<int>;  // OK

Implementations seem to reject the class member access, despite 7.6.1.5 [expr.ref] bullet 6.1 stating the contrary.

Rationale (November, 2016):

The specification is as intended.

#### 528. Why are incomplete class types not allowed with `typeid`?

Section: 7.6.1.8 [expr.typeid] Status: NAD Submitter: Dave Abrahams Date: 18 May 2005

7.6.1.8 [expr.typeid] paragraph 4 says,

> When `typeid` is applied to a type-id, the result refers to a `std::type_info` object representing the type of the type-id. If the type of the type-id is a reference type, the result of the `typeid` expression refers to a `std::type_info` object representing the referenced type. If the type of the type-id is a class type or a reference to a class type, the class shall be completely-defined.

I'm wondering whether this is not overly restrictive. I can't think of a reason to require that `T` be completely-defined in `typeid(T)` when `T` is a class type. In fact, several popular compilers enforce that restriction for `typeid(T)`, but not for `typeid(T&)`. Can anyone explain this?

Nathan Sidwell: I think this restriction is so that whenever the compiler has to emit a typeid object of a class type, it knows what the base classes are, and can therefore emit an array of pointers-to-base-class typeids. Such a tree is necessary to implement `dynamic_cast` and exception catching (in a commonly implemented and obvious manner). If the class could be incomplete, the compiler might have to emit a typeid for incomplete `Foo` in one object file and a typeid for complete `Foo` in another object file. The compilation system will then have to make sure that (a) those compare equal and (b) the complete `Foo` gets priority, if that is applicable.

Unfortunately, there is a problem with exceptions that means there still can be a need to emit typeids for incomplete class. Namely one can throw a pointer-to-pointer-to-incomplete. To implement the matching of pointer-to-derived being caught by pointer-to-base, it is necessary for the typeid of a pointer type to contain a pointer to the typeid of the pointed-to type. In order to do the qualification matching on a multi-level pointer type, one has a chain of pointer typeids that can terminate in the typeid of an incomplete type. You cannot simply NULL-terminate the chain, because one must distinguish between different incomplete types.

Dave Abrahams: So if implementations are still required to be able to do it, for all practical purposes, why aren't we letting the user have the benefits?

Notes from the April, 2006 meeting:

There was some concern expressed that this might be difficult under the IA64 ABI. It was also observed that while it is necessary to handle exceptions involving incomplete types, there is no requirement that the RTTI data structures be used for exception handling.

Rationale (2023-05-12)

This is an extension that requires a paper targeted at EWG, investigating any ABI concerns.

#### 2512. `typeid` and incomplete class types

Section: 7.6.1.8 [expr.typeid] Status: NAD Submitter: Jens Maurer Date: 2021-08-19

According to 7.6.1.8 [expr.typeid] paragraphs 2-3,

> 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.8.2 [intro.object]) (that is, the dynamic type) to which the glvalue refers...

> When `typeid` is applied to an expression other than a glvalue of a polymorphic class type, the result refers to a `std::type_info` object representing the static type of the expression.

The status of a glvalue of incomplete class type is not clear from this specification. Since it is not known whether an incomplete class type is polymorphic or not, the existing wording could be read either as giving that case undefined behavior or as falling into paragraph 3 and always returning the static type.

The wording for `dynamic_cast` requires class types to be complete, as does paragraph 4, describing `typeid` applied to a type-id.

Rationale (December, 2021):

The change was already applied via the editorial review process, with approval from CWG at the 2021-08-24 teleconference.

#### 294. Can `static_cast` drop exception specifications?

Section: 7.6.1.9 [expr.static.cast] Status: NAD Submitter: Steve Adamczyk Date: 27 Jun 2001

[Picked up by evolution group at October 2002 meeting.]

Is it okay for a `static_cast` to drop exception specifications?

        void f() throw(int);
        int main () {
          static_cast<void (*)() throw()>(f);  // Okay?
          void (*p)() throw() = f;  // Error
        }

The fact that a `static_cast` is defined, more or less, as an initialization suggests that a check ought to be made.

One tricky point: this is another case where the general rule that the reverse of an implicit cast is allowed as a `static_cast` bites you -- the reverse conversion doesn't drop exception specifications, and so is okay. Perhaps this should be treated like casting away constness.

Mike Miller comments : I don't think that case can arise. According to 14.5 [except.spec],

> An exception-specification shall appear only on a function declarator in a function, pointer, reference, or pointer to member declaration or definition.

We strengthened that in issue 87 (voted to DR status in Copenhagen) to

> An exception-specification shall appear only on a function declarator for a function type, pointer to function type, reference to function type, or pointer to member function type that is the top-level type of a declaration or definition, or on such a type appearing as a parameter or return type in a function declarator.

As I read that, you can't put an exception-specification on the type-id in a static_cast, which means that a static_cast can only weaken, not strengthen, the exception specification.

The core WG discussed this at the 10/01 meeting and agreed.

Note (March, 2008):

The Evolution Working Group recommended closing this issue with no further consideration. See paper J16/07-0033 = WG21 N2173.

#### 2814. Alignment requirement of incomplete class type

Section: 7.6.1.9 [expr.static.cast] Status: NAD Submitter: Janet Cobb Date: 2023-10-20

Consider:

      struct X;       // declared, but not defined

      int i;
      X* p = static_cast<X*>(static_cast<void*>(&i));

Is the value of `p` unspecified per 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”, where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. 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 is unspecified. Otherwise, ...

Is that a case where implementations have to possibly pessimize a use of an undefined class, because a later definition can have the worst possible properties? Such a situation can also occur for pointer-to-members of undefined classes.

CWG 2023-12-15

The resulting pointer value should be unspecified if `T` is incomplete.

CWG 2024-03-18

CWG decided to reverse direction here and to constrain implementations, not programs.

Proposed resolution [SUPERSEDED]:

Change in 7.6.1.9 [expr.static.cast] paragraph 14 and add bullets as follows:

> A prvalue of type “pointer to cv1 void” can be converted to a prvalue of type “pointer to cv2 T”, where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. If the original pointer value represents the address A of a byte in memory `, T` is complete, and A does not satisfy the alignment requirement of T, then the resulting pointer value is unspecified. Otherwise, ...

Possible resolution:

Change in 7.6.1.9 [expr.static.cast] paragraph 14 and add bullets as follows:

> A prvalue of type “pointer to cv1 void” can be converted to a prvalue of type “pointer to cv2 T”, where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. If the original pointer value represents the address A of a byte in memory `, T` is complete anywhere in the program, and A does not satisfy the alignment requirement of T, then the resulting pointer value is unspecified. Otherwise, ...

CWG 2024-06-28

It is understood that a pointer value of type `T*` may point to an object whose type is unrelated to `T`. (Any access through such a pointer value is undefined behavior.) However, C++ maintains the invariant that the address represented by a pointer value of type `T*` is always suitably aligned for a `T`. The rule that is the concern of this issue ensures the invariant holds even when values of type `T*` are obtained by casting, and not by taking the address of an object. For the latter case, the invariant holds because an object cannot exist unless its storage is aligned suitably.

The rule that is the concern of this issue therefore primarily constrains user programs, not implementations. It is unclear which "pessimizations" are expected from casting to a type whose alignment requirements are unknown at the point of the cast. Note that the resulting unspecified pointer value may be an invalid pointer value (6.9.4 [basic.compound]), which is essentially useless. Note also that incomplete class types may have (minimum) alignment requirements, because an alignment-specifier can appear in an elaborated-type-specifier.

Additional notes (January, 2025)

      // Maybe in a different translation unit
      struct X;
      X *f(void *p) { return static_cast<X*>(p); }

      // translation unit boundary
      struct alignas(2) X { char c[2]; } x;
      void h(X *p) {
       // #1
      }

      int main() {
       // Details of q aren't relevant here, the point is simply that this pointer is not properly aligned for an X.
       void *q = &x.c[1];
       X *misaligned = f(q);
       h(misaligned);
      }

Consider the value of `p` at #1. If `p` was obtained by casting, the status quo rule in 7.6.1.9 [expr.static.cast] paragraph 13 says that `p` has an unspecified pointer value if misaligned. That pointer value can be an invalid pointer value (6.9.4 [basic.compound] paragraph 3.4). An lvalue-to-rvalue conversion on an object storing an invalid pointer value is implementation-defined (7.3.2 [conv.lval] paragraph 3.3), and thus might trap. There is no guarantee that invalid pointer values have a predictable bit-pattern.

Effectively, the implementation can assume that `p` is suitably aligned at `p`.

#### 800. Safely-derived pointers and object pointers converted from function pointers

Section: 7.6.1.10 [expr.reinterpret.cast] Status: NAD Submitter: UK Date: 3 March, 2009
N2800 comment UK 57

It is not specified under what conditions an object pointer created by converting a function pointer, as described in 7.6.1.10 [expr.reinterpret.cast] paragraph 8, will be safely-derived, particularly in light of the conditionally-supported, implementation-defined nature of such conversions.

Notes from the March, 2009 meeting:

If this is to be addressed, the result should not be as suggested, i.e., a requirement for implementation documentation appearing only in a note. At the least, such a requirement must be in normative text.

Rationale (July, 2009):

The definition of “safely-derived pointer” is clearly and exclusively formulated in terms of pointers to objects. So no implementation is required to maintain safe pointer derivation through conversion to and from a function-pointer type.

On the other hand, any garbage-collecting implementation is free to treat function pointers the same as object pointers for purposes of collection. This would provide the effect of safe pointer derivation through function-pointer types. An implementation is even free to document this behavior, if it so chooses.

However, converting a pointer to a dynamically-allocated object into a function pointer would be a very strange and almost always pointless and unsafe thing to do. There is no need for the standard to encourage this sort of behavior, even to the extent of adding a note mentioning the possibility.

#### 944. `reinterpret_cast` for all types with the same size and alignment

Section: 7.6.1.10 [expr.reinterpret.cast] Status: NAD Submitter: Miller Date: 15 July, 2009

During the discussion of issue 799, which specified the result of using `reinterpret_cast` to convert an operand to its own type, it was observed that it is probably reasonable to allow `reinterpret_cast` between any two types that have the same size and alignment.

Additional note, April, 2015:

It has been suggested that this question may more properly be the province of EWG, especially in light of discussions during the resolution of issue 330.

Rationale (May, 2015):

CWG agreed that this question should be considered from a language design perspective and is thus being referred to EWG.

Rationale (June, 2021):

EWG resolved to close this issue. The `bit_cast` function addresses some of the use-cases. Supporting other use-cases would need a paper. See vote.

#### 2225. `reinterpret_cast` to same floating-point type

Section: 7.6.1.10 [expr.reinterpret.cast] Status: NAD Submitter: Aaron Ballman Date: 2016-01-14

Consider this inconsistency:

      void func(long l, float f) {
       (void)reinterpret_cast<long *>(&l); // ok
       (void)reinterpret_cast<long>(l); // ok
       (void)reinterpret_cast<float *>(&f); // ok
       (void)reinterpret_cast<float>(f); // ill-formed
      }

Suggested resolution:

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

> ... An expression of integral arithmetic, enumeration, pointer, or pointer-to-member type can be explicitly converted to its own type; such a cast yields the value of its operand.

Rationale (November, 2016):

The specification is as intended.

#### 203. Type of address-of-member expression

Section: 7.6.2.2 [expr.unary.op] Status: NAD Submitter: Lisa Lippincott Date: 8 Feb 2000

7.6.2.2 [expr.unary.op] paragraph 2 indicates that the type of an address-of-member expression reflects the class in which the member was declared rather than the class identified in the nested-name-specifier of the qualified-id. This treatment is unintuitive and can lead to strange code and unexpected results. For instance, in

        struct B { int i; };
        struct D1: B { };
        struct D2: B { };

        int (D1::* pmD1) = &D2::i;   // NOT an error

More seriously, template argument deduction can give surprising results:

        struct A {
           int i;
           virtual void f() = 0;
        };

        struct B : A {
           int j;
           B() : j(5)  {}
           virtual void f();
        };

        struct C : B {
           C() { j = 10; }
        };

        template <class T>
        int DefaultValue( int (T::*m) ) {
           return T().*m;
        }

        ... DefaultValue( &B::i )    // Error: A is abstract
        ... DefaultValue( &C::j )    // returns 5, not 10.

Suggested resolution: 7.6.2.2 [expr.unary.op] should be changed to read,

> If the member is a nonstatic member (perhaps by inheritance) of the class nominated by the nested-name-specifier of the qualified-id having type `T`, the type of the result is "pointer to member of class nested-name-specifier of type `T`."

and the comment in the example should be changed to read,

> `// has type int B::*`

Notes from 04/00 meeting:

The rationale for the current treatment is to permit the widest possible use to be made of a given address-of-member expression. Since a pointer-to-base-member can be implicitly converted to a pointer-to-derived-member, making the type of the expression a pointer-to-base-member allows the result to initialize or be assigned to either a pointer-to-base-member or a pointer-to-derived-member. Accepting this proposal would allow only the latter use.

Additional notes:

Another problematic example has been mentioned:

        class Base {
        public:
          int func() const;
        };

        class Derived : public Base {
        };

        template<class T>
        class Templ {
        public:
          template<class S>
          Templ(S (T::*ptmf)() const);
        };

        void foo()
        {
          Templ<Derived> x(&Derived::func);    // ill-formed
        }

In this example, even though the conversion of `&Derived::func` to `int (Derived::*)() const` is permitted, the initialization of `x` cannot be done because template argument deduction for the constructor fails.

If the suggested resolution were adopted, the amount of code broken by the change might be reduced by adding an implicit conversion from pointer-to-derived-member to pointer-to-base-member for appropriate address-of-member expressions (not for arbitrary pointers to members, of course).

(See also issues 247 and 1121.)

Additional notes (September, 2012):

Tomasz Kamiński pointed out three additional motivating examples:

      struct Very_base { int a; };
      struct Base1 : Very_base {};
      struct Base2 : Very_base {};
      struct Derived : Base1, Base2 {}

      int main() {
        Derived d;
        int Derived:: * a_ptr = &Derived::Base1::a; //error: Very_base ambiguous despite qualification
      };

Also:

      struct Base { int a; };
      struct Derived : Base { int b; };

      template<typename Class, typename Member_type, Member_type Base:: * ptr>
      Member_type get(Class &c) { return c.*ptr; }

      void call(int (*f)(Derived &));

      int main() {
        call(&get<Derived, int, &Derived::b>); // Works correctly
        call(&get<Derived, int, &Derived::a>); // Fails because &Derived::a returns an int Base::*
                                               // and no conversions are applied to pointer to member
                                               // (as specified in 13.4.3 [temp.arg.nontype] paragraph 5)
        call(&get<Base, int, &Derived::a>);    //Template function is instantiated properly but has invalid type
      }

Finally:

      struct Base { int a; };
      struct Derived : private Base {
      public:
        using Base::a; //make a accessible
      };

      int main() {
        Derived d;
        d.a; // valid
        int Derived::* ptr = &Derived::a; // Conversion from int Base::* to int Derived::*
                                          // is ill-formed because the base class is inaccessible
      }

Rationale (October, 2012):

CWG felt that such a change to the existing semantics would be better considered by EWG rather than as a defect.

Additional note, April, 2015:

EWG has determined that the utility of such a change is outweighed by the fact that it would break code. See EWG issue 89.

#### 232. Is indirection through a null pointer undefined behavior?

Section: 7.6.2.2 [expr.unary.op] Status: NAD Submitter: Mike Miller Date: 5 Jun 2000

At least a couple of places in the IS state that indirection through a null pointer produces undefined behavior: 6.10.1 [intro.execution] paragraph 4 gives "dereferencing the null pointer" as an example of undefined behavior, and 9.3.4.3 [dcl.ref] paragraph 4 (in a note) uses this supposedly undefined behavior as justification for the nonexistence of "null references."

However, 7.6.2.2 [expr.unary.op] paragraph 1, which describes the unary "*" operator, does not say that the behavior is undefined if the operand is a null pointer, as one might expect. Furthermore, at least one passage gives dereferencing a null pointer well-defined behavior: 7.6.1.8 [expr.typeid] paragraph 2 says

> If the lvalue 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 the `bad_typeid` exception (17.7.5 [bad.typeid]).

This is inconsistent and should be cleaned up.

Bill Gibbons:

At one point we agreed that dereferencing a null pointer was not undefined; only using the resulting value had undefined behavior.

For example:

        char *p = 0;
        char *q = &*p;

Similarly, dereferencing a pointer to the end of an array should be allowed as long as the value is not used:

        char a[10];
        char *b = &a[10];   // equivalent to "char *b = &*(a+10);"

Both cases come up often enough in real code that they should be allowed.

Mike Miller:

I can see the value in this, but it doesn't seem to be well reflected in the wording of the Standard. For instance, presumably `*p` above would have to be an lvalue in order to be the operand of "`&`", but the definition of "lvalue" in 7.2.1 [basic.lval] paragraph 2 says that "an lvalue refers to an object." What's the object in `*p`? If we were to allow this, we would need to augment the definition to include the result of dereferencing null and one-past-the-end-of-array.

Tom Plum:

Just to add one more recollection of the intent: I was very happy when (I thought) we decided that it was only the attempt to actually fetch a value that creates undefined behavior. The words which (I thought) were intended to clarify that are the first three sentences of the lvalue-to-rvalue conversion, 7.3.2 [conv.lval]:

> An lvalue (7.2.1 [basic.lval]) of a non-function, non-array type `T` can be converted to an rvalue. If `T` is an incomplete type, a program that necessitates this conversion is ill-formed. If the object to which the lvalue refers is not an object of type `T` and is not an object of a type derived from `T`, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior.

In other words, it is only the act of "fetching", of lvalue-to-rvalue conversion, that triggers the ill-formed or undefined behavior. Simply forming the lvalue expression, and then for example taking its address, does not trigger either of those errors. I described this approach to WG14 and it may have been incorporated into C 1999.

Mike Miller:

If we admit the possibility of null lvalues, as Tom is suggesting here, that significantly undercuts the rationale for prohibiting "null references" -- what is a reference, after all, but a named lvalue? If it's okay to create a null lvalue, as long as I don't invoke the lvalue-to-rvalue conversion on it, why shouldn't I be able to capture that null lvalue as a reference, with the same restrictions on its use?

I am not arguing in favor of null references. I don't want them in the language. What I am saying is that we need to think carefully about adopting the permissive approach of saying that it's all right to create null lvalues, as long as you don't use them in certain ways. If we do that, it will be very natural for people to question why they can't pass such an lvalue to a function, as long as the function doesn't do anything that is not permitted on a null lvalue.

If we want to allow `&*(p=0)`, maybe we should change the definition of "`&`" to handle dereferenced null specially, just as `typeid` has special handling, rather than changing the definition of lvalue to include dereferenced nulls, and similarly for the array_end+1 case. It's not as general, but I think it might cause us fewer problems in the long run.

Notes from the October 2003 meeting:

See also issue 315, which deals with the call of a static member function through a null pointer.

We agreed that the approach in the standard seems okay: `p = 0; *p;` is not inherently an error. An lvalue-to-rvalue conversion would give it undefined behavior.

Proposed resolution (October, 2004):

(Note: the resolution of issue 453 also resolves part of this issue.)

1. Add the indicated words to 7.2.1 [basic.lval] paragraph 2:

   > An lvalue refers to an object or function or is an empty lvalue (7.6.2.2 [expr.unary.op]).

2. Add the indicated words to 7.6.2.2 [expr.unary.op] paragraph 1:

   > The unary `*` operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points, if any. If the pointer is a null pointer value (7.3.12 [conv.ptr]) or points one past the last element of an array object (7.6.6 [expr.add]), the result is an empty lvalue and does not refer to any object or function. An empty lvalue is not modifiable. If the type of the expression is “pointer to `T`,” the type of the result is “`T`.” [Note: a pointer to an incomplete type (other than cv void) can be dereferenced. The lvalue thus obtained can be used in limited ways (to initialize a reference, for example); this lvalue must not be converted to an rvalue, see 7.3.2 [conv.lval].—end note]

3. Add the indicated words to 7.3.2 [conv.lval] paragraph 1:

   > If the object to which the lvalue refers is not an object of type `T` and is not an object of a type derived from `T`, or if the object is uninitialized, or if the lvalue is an empty lvalue (7.6.2.2 [expr.unary.op]), a program that necessitates this conversion has undefined behavior.

4. Change 6.10.1 [intro.execution] as indicated:

   > Certain other operations are described in this International Standard as undefined (for example, the effect of dereferencing the null pointer division by zero).

Note (March, 2005):

The 10/2004 resolution interacts with the resolution of issue 73. We added wording to 6.9.4 [basic.compound] paragraph 3 to the effect that a pointer containing the address one past the end of an array is considered to “point to” another object of the same type that might be located there. The 10/2004 resolution now says that it would be undefined behavior to use such a pointer to fetch the value of that object. There is at least the appearance of conflict here; it may be all right, but it at needs to be discussed further.

Notes from the April, 2005 meeting:

The CWG agreed that there is no contradiction between this direction and the resolution of issue 73. However, “not modifiable” is a compile-time concept, while in fact this deals with runtime values and thus should produce undefined behavior instead. Also, there are other contexts in which lvalues can occur, such as the left operand of `.` or `.*`, which should also be restricted. Additional drafting is required.

(See also issue 1102.)

CWG 2023-11-06

There is no consensus to pursue the introduction of empty lvalues, without prejudice to a potential future paper addressed to EWG. The implicit undefined behavior in 7.6.2.2 [expr.unary.op] paragraph 1 is handled in issue 2823.

#### 610. Computing the negative of `0U`

Section: 7.6.2.2 [expr.unary.op] Status: NAD Submitter: comp.std.c++ Date: 21 December 2006

In 7.6.2.2 [expr.unary.op], part of paragraph 7 describes how to compute the negative of an unsigned quantity:

> The negative of an unsigned quantity is computed by subtracting its value from 2n, where n is the number of bits in the promoted operand. The type of the result is the type of the promoted operand.

According to this method, `-0U` will get the value 2n - 0 = 2n, where n is the number of bits in an unsigned int. However, 2n is obviously out of the range of values representable by an unsigned int and thus not the actual value of `-0U`. To get the result, a truncating conversion must be applied.

Rationale (April, 2007):

As noted in the issue description, a “truncating conversion” is needed. This conversion is supplied without need of an explicit mention, however, by the nature of unsigned arithmetic given in 6.9.2 [basic.fundamental] paragraph 4:

> Unsigned integers, declared `unsigned`, shall obey the laws of arithmetic modulo 2n where n is the number of bits in the value representation of that particular size of integer.

#### 1923. Lvalues of type `void`

Section: 7.6.2.2 [expr.unary.op] Status: NAD Submitter: Richard Smith Date: 2014-05-06

There does not seem to be any significant technical obstacle to allowing a `void*` pointer to be dereferenced, and that would avoid having to use weighty circumlocutions when casting to a reference to an object designated by such a pointer.

Rationale (June, 2014):

This request for a language extension should be evaluated by EWG before any action is taken.

EWG 2022-11-11

This is a request for a new feature, which should be proposed in a paper to EWG.

#### 2454. Tail recursion and coroutine symmetric transfer

Section: 7.6.2.4 [expr.await] Status: NAD Submitter: Lewis Baker Date: 2020-02-14

Paper P0913R0 proposed adding support for a symmetric-transfer capability intended to allow coroutines to be recursively resumed without consuming an unbounded amount of stack space. However, the current wording does not required this, only suggesting it in a note in bullet 5.1.1 of 7.6.2.4 [expr.await]. This should be a normative requirement.

Rationale (July, 2020):

This issue is essentially about implementation limits, which are impossible to specify normatively, and it is inappropriate to specify the desired and forbidden implementation techniques in the Standard.

#### 2472. Value categories in await-expressions

Section: 7.6.2.4 [expr.await] Status: NAD Submitter: Daveed Vandevoorde Date: 2021-01-18

According to 7.6.2.4 [expr.await] bullets 3.3 and 3.4,

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

> - ...

> - o is determined by enumerating the applicable `operator co_await` functions for an argument a (12.2.2.3 [over.match.oper]), and choosing the best one through overload resolution (12.2 [over.match]). If overload resolution is ambiguous, the program is ill-formed. If no viable functions are found, o is a. Otherwise, o is a call to the selected function with the argument a. If o would be a prvalue, the temporary materialization conversion (7.3.5 [conv.rval]) is applied.

> - e is an lvalue referring to the result of evaluating the (possibly-converted) o.

> - ...

However, the temporary materialization conversion produces an xvalue, not an lvalue. Should e be a glvalue instead of an lvalue?

Rationale (February, 2021):

The specification is as intended; o is converted to an lvalue if it is an xvalue result of the temporary materialization conversion. e is used in both bullets 3.7 and 3.8; if it were an xvalue instead of an lvalue, the call to `await_suspend` could steal e's resources and leave the call to `await_resume` with a defunct object, which would be undesirable.

#### 1606. `sizeof` closure class

Section: 7.6.2.5 [expr.sizeof] Status: NAD Submitter: John Spicer Date: 2013-01-18

The standard forbids a lambda from appearing in a `sizeof` operand:

> A lambda-expression shall not appear in an unevaluated operand (Clause 7 [expr]).

(7.5.6 [expr.prim.lambda] paragraph 2). However, there appears to be no prohibition of the equivalent usage when a variable or data member has a closure class as its type:

      int main() {
        int i = 1;
        int j = 1;
        auto f = [=]{ return i + j;};
        return sizeof(f);
      }

According to 7.5.6 [expr.prim.lambda] paragraph 3, the size of a closure class is not specified, so that it could vary between translation units or between otherwise link-compatible implementations, which could result in ODR violations if the size is used as a template non-type argument, for example. Should the Standard forbid taking the size of a closure class? Or should this simply be left as an ABI issue, as is done with other size and alignment questions?

Additional note, April, 2013:

It was observed that generic function wrappers like `std::function` rely on the ability to make compile-time decisions based on the size of the function object, and forbidding the application of `sizeof` to closure classes would make that unnecessarily difficult.

Rationale (April, 2013):

CWG agreed that the ODR and portability considerations were not sufficient to outweigh the utility of applying `sizeof` to closure classes as mentioned in the April, 2013 note and that the issues are more appropriately dealt with in an ABI specification.

#### 1678. Naming the type of an array of runtime bound

Section: 7.6.2.5 [expr.sizeof] Status: NAD Submitter: Mike Miller Date: 2013-05-08

According to 7.6.2.5 [expr.sizeof] paragraph 1,

> The `sizeof` operator shall not be applied to an expression that has function or incomplete type, to an enumeration type whose underlying type is not fixed before all its enumerators have been declared, to an array of runtime bound, to the parenthesized name of such types, or to a glvalue that designates a bit-field.

However, it is not possible to name the type of an array of runtime bound, neither by `typedef` nor `decltype`, so the reference to “the parenthesized name of such types” should precede rather than follow “to an array of unknown bound.”

Rationale (September, 2013):

Arrays of runtime bound were moved from the normative specification to a proposed Technical Specification.

#### 1008. Querying the alignment of an object

Section: 7.6.2.6 [expr.alignof] Status: NAD Submitter: Steve Clamage Date: 2009-11-27

The current specification of the `alignof` operator (7.6.2.6 [expr.alignof]) allows it to be applied only to types, not to objects. Since the `align` attribute may be applied to objects, and since existing practice permits querying the alignment of objects, it should be considered whether to allow this in Standard C++ as well.

Additional note, April, 2020:

A survey of current implementations shows that most have already implemented the extension; the example there illustrates one motivation for its use. The principle of least astonishment would suggest that it is surprising for `sizeof` and `alignof` to behave differently in this regard.

Additional note (April, 2022)

This is a request for an extension, which is pursued by paper P2152 (Querying the alignment of an object).

#### 1685. Value category of `noexcept` expression

Section: 7.6.2.7 [expr.unary.noexcept] Status: NAD Submitter: Daniel Krügler Date: 2013-05-16

According to 7.6.2.7 [expr.unary.noexcept] paragraph 2,

> The result of the `noexcept` operator is a constant of type `bool` and is an rvalue.

Obviously, the result should be a prvalue.

(See also issue 1642, which deals with missing specifications of value categories.)

Notes from the September, 2013 meeting:

This issue is being handled editorially and is being placed in "review" status to ensure that the change has been made.

Rationale (February, 2014):

The change has been made editorially.

#### 31. Looking up new/delete

Section: 7.6.2.8 [expr.new] Status: NAD Submitter: Daveed Vandevoorde Date: 23 Jun 1998

Section 11.4.11 [class.free] paragraph 4 says:

> If a delete-expression begins with a unary `::` operator, the deallocation function's name is looked up in global scope. Otherwise, if the delete-expression is used to deallocate a class object whose static type has a virtual destructor, the deallocation function is the one found by the lookup in the definition of the dynamic type's virtual destructor (11.4.7 [class.dtor] ). Otherwise, if the delete-expression is used to deallocate an object of class `T` or array thereof, the static and dynamic types of the object shall be identical and the deallocation function's name is looked up in the scope of `T`. If this lookup fails to find the name, the name is looked up in the global scope. If the result of the lookup is ambiguous or inaccessible, or if the lookup selects a placement deallocation function, the program is ill-formed.

I contrast that with 7.6.2.8 [expr.new] paragraphs 16 and 17:

> 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] ). If the new-expression creates an array of objects of class type, access and ambiguity control are done for the destructor (11.4.7 [class.dtor] ).

> If any part of the object initialization described above terminates by throwing an exception and a suitable deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed, after which the exception continues to propagate in the context of the new-expression. If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed. [Note: This is appropriate when the called allocation function does not allocate memory; otherwise, it is likely to result in a memory leak. ]

I think nothing in the latter paragraphs implies that the deallocation function found is the same as that for a corresponding delete-expression. I suspect that may not have been intended and that the lookup should occur "as if for a delete-expression".

Rationale:

Paragraphs 16 through 18 are sufficiently correct and unambiguous as written.

#### 130. Sequence points and new-expressions

Section: 7.6.2.8 [expr.new] Status: NAD Submitter: Herb Sutter Date: 20 June 1999

Clause 7 [expr] paragraph 4 appears to grant an implementation the right to generate code for a function call like

        f(new T1, new T2)

in the order

- allocate memory for the `T1` object
- allocate memory for the `T2` object
- call the `T1` constructor
- call the `T2` constructor
- call `f`

However, 7.6.2.8 [expr.new] paragraph 17 seems to require the deallocation of the storage for an object only if part of the initialization of that object terminates with an exception. Given the ordering above, this specification would appear to allow the memory for the `T2` object to be leaked if the `T1` constructor throws an exception.

Suggested resolution: either forbid the ordering above or expand the requirement for reclaiming storage to include exceptions thrown in all operations between the allocation and the completion of the constructor.

Rationale (10/99): Even in the "traditional" ordering of the calls to allocation functions and constructors, memory can still leak. For instance, if `T1` were successfully constructed and then the construction of `T2` were terminated by an exception, the memory for `T1` would be lost. Programmers concerned about memory leaks will avoid this kind of construct, so it seems unnecessary to provide special treatment for it to avoid the memory leaks associated with one particular implementation strategy.

#### 473. Block-scope declarations of allocator functions

Section: 7.6.2.8 [expr.new] Status: NAD Submitter: John Spicer Date: 12 Jul 2004

Looking up `operator new` in a new-expression uses a different mechanism from ordinary lookup. According to 7.6.2.8 [expr.new] paragraph 9,

> If the new-expression begins with a unary `::` operator, the allocation function's name is looked up in the global scope. Otherwise, if the allocated type is a class type `T` or array thereof, the allocation function's name is looked up in the scope of `T`. If this lookup fails to find the name, or if the allocated type is not a class type, the allocation function's name is looked up in the global scope.

Note in particular that the scope in which the new-expression occurs is not considered. For example,

        void f() {
            void* operator new(std::size_t, void*);
            int* i = new int;    // okay?
        }

In this example, the implicit reference to `operator new(std::size_t)` finds the global declaration, even though the block-scope declaration of `operator new` with a different signature would hide it from an ordinary reference.

This seems strange; either the block-scope declaration should be ill-formed or it should be found by the lookup.

Notes from October 2004 meeting:

The CWG agreed that the block-scope declaration should not be found by the lookup in a new-expression. It would, however, be found by ordinary lookup if the allocation function were invoked explicitly.

Rationale

The wording correctly reflects the intent; block-scope allocation functions are not found by the special lookup in a new-expression.

#### 1566. Should `new std::initializer_list<T>` be ill-formed?

Section: 7.6.2.8 [expr.new] Status: NAD Submitter: Steve Adamczyk Date: 2012-10-10

A new-expression that creates an object whose type is a specialization of `std::initializer_list` initialized from an initializer list results in undefined behavior if the object survives past the end of the full-expression, when the lifetime of the underlying array object ends. Since such a new-expression is effectively useless, should it be made ill-formed?

Notes from the October, 2012 meeting:

The consensus of CWG was that this usage should be ill-formed.

Rationale (February, 2013):

Because the library emulation of `std::is_constructible` uses unevaluated new-expressions in the implementation, making a `new` of `std::initializer_list` ill-formed would give the wrong results for its constructibility. CWG determined that it would be acceptable to leave diagnosing of actual undefined behavior resulting from such constructs to the discretion of the implementation.

#### 1259. Deleting a POD via a pointer to base

Section: 7.6.2.9 [expr.delete] Status: NAD Submitter: Herb Sutter Date: 2011-03-10

It is currently undefined behavior to delete a derived-class object via a pointer to a base class unless the base class has a virtual destructor. It has been suggesed that this could be allowed for a standard-layout class. If so, presumably the caveats about a deallocation function or non-trivial destructor found in 7.6.2.9 [expr.delete] paragraph 5 that currently apply to incomplete types would need to be extended to apply to the derived class in such cases.

Another objection that was raised is that such a change would make it more difficult to extend C++ in the future to have global deallocation functions that can take the size of the object being deleted as an argument, as is currently possible for member deallocation functions.

Rationale (August, 2011):

The specification is as intended; changes to the restriction would need to be considered in a larger context by EWG.

Additional note, April, 2015:

EWG has decided not to make a change in this area. See EWG issue 99.

#### 2239. Sized deallocation with a trivial destructor

Section: 7.6.2.9 [expr.delete] Status: NAD Submitter: CWG Date: 2016-03-03

According to 7.6.2.9 [expr.delete] paragraph 10, deletion of an array of a class with both sized and non-sized deallocation functions is not required to call the sized version if the destructor is trivial:

> If deallocation function lookup finds both a usual deallocation function with only a pointer parameter and a usual deallocation function with both a pointer parameter and a size parameter, the function to be called is selected as follows:

> - If the type is complete and if, for the second alternative (delete array) only, the operand is a pointer to a class type with a non-trivial destructor or a (possibly multi-dimensional) array thereof, the function with two parameters is selected.

> - Otherwise, it is unspecified which of the two deallocation functions is selected.

However, if only a sized deallocation function is specified as a class-specific deallocation function, it is not clear how the size argument is to be determined if the class has a trivial destructor.

Rationale (November, 2016):

The adoption of paper P0035R4 has rendered this issue moot.

#### 2925. Deleting a pointer to an incomplete enumeration type

Section: 7.6.2.9 [expr.delete] Status: NAD Submitter: Jiang An Date: 2024-08-14

(From submission #597.)

Paper P3144R2 (Deleting a Pointer to an Incomplete Type Should be Ill-formed), approved in June, 2024, only covered deletion of incomplete class types. However, enumeration types can also be incomplete per 9.8.1 [dcl.enum] paragraph 6:

> An enumeration whose underlying type is fixed is an incomplete type until immediately after its enum-base (if any), at which point it becomes a complete type. An enumeration whose underlying type is not fixed is an incomplete type until the closing } of its enum-specifier , at which point it becomes a complete type.

This leads to the following example that ought to be ill-formed as well:

      enum E {
        zero = decltype(delete static_cast<E*>(nullptr), 0){}
      };

Suggested resolution:

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

> If the static type of the object being to be deleted has incomplete class type at the point of deletion, the program is ill-formed.

CWG 2024-09-13

Since an enumeration type can never have a user-declared destructor, there is no risk of introducing undefined behavior that would be prevented by making deletions involving incomplete enumeration types ill-formed. In short, the situation discussed in this issue is harmless and thus lacks rationale to be made ill-formed.

#### 909. Old-style casts with conversion functions

Section: 7.6.3 [expr.cast] Status: NAD Submitter: Daniel Krügler Date: 2 June, 2009

According to 7.6.3 [expr.cast] paragraph 4, one possible interpretation of an old-style cast is as a `static_cast` followed by a `const_cast`. One would therefore expect that the expressions marked #1 and #2 in the following example would have the same validity and meaning:

        struct S {
          operator const int* ();
        };

        void f(S& s)  {
          const_cast<int*>(static_cast<const int*>(s));  // #1
          (int*) s;  // #2
        }

However, a number of implementations issue an error on #2.

Is the intent that `(T*)x` should be interpreted as something like

        const_cast<T*>(static_cast<const volatile T*>(x))

Rationale (July, 2009):

According to the straightforward interpretation of the wording, the example should work. This appears to be just a compiler bug.

#### 1124. Error in description of value category of pointer-to-member expression

Section: 7.6.4 [expr.mptr.oper] Status: NAD Submitter: JP Date: 2010-08-02
N3092 comment JP 2

According to 7.6.4 [expr.mptr.oper] paragraph 6,

> The result of a `.*` expression whose second operand is a pointer to a data member is of the same value category (7.2.1 [basic.lval]) as its first operand.

This is incorrect if the member has a reference type, in which case the result is an lvalue.

Rationale (September, 2010):

There are no pointers to member of reference type; see 9.3.4.4 [dcl.mptr] paragraph 3.

#### 55. Adding/subtracting pointer and enumeration value

Section: 7.6.6 [expr.add] Status: NAD Submitter: Steve Adamczyk Date: 13 Oct 1998

An expression of the form pointer + enum (see paragraph 5) is not given meaning, and ought to be, given that paragraph 2 of this section makes it valid. Presumably, the enum value should be converted to an integral value, and the rest of the processing done on that basis. Perhaps we want to invoke the integral promotions here.

[Should this apply to (pointer - enum) too?]

Rationale (04/99): Paragraph 1 invokes "the usual arithmetic conversions" for operands of enumeration type.

(It was later pointed out that the builtin operator `T* operator+(T*, ptrdiff_t)` (12.5 [over.built] paragraph 13) is selected by overload resolution. Consequently, according to 12.2.2.3 [over.match.oper] paragraph 7, the operand of enumeration type is converted to `ptrdiff_t` before being interpreted according to the rules in 7.6.6 [expr.add] .)

#### 567. Can `size_t` and `ptrdiff_t` be larger than `long`?

Section: 7.6.6 [expr.add] Status: NAD Submitter: Nick MacLaren Date: 14 March 2006

Code that was portable in C90 and C++98 is no longer portable with the introduction of data types longer than `long`; code that could previously cast `size_t` and `ptrdiff_t` to `long` without loss of precision (because `long` was the largest type) can no longer rely on that idiom.

The CWG discussed this during the Berlin (April, 2006) meeting. The general consensus was that this was unavoidable: there are valid reasons for implementations to keep `long` at a size less than that required for address arithmetic.

See paper J16/06-0053 = WG21 N1983, which also suggests the possibility of required diagnostics for problematic cases as an alternative to restricting the size of `size_t` and `ptrdiff_t`.

Rationale (October, 2006):

This is not an area in which the Standard should override the decisions of implementors who wish to maintain the size of `long` for backward compatibility but need a larger `size_t` to deal with expanded address spaces. Also, diagnostics of the sort described are better treated as quality of implementation issues rather than topics for standardization.

#### 1314. Pointer arithmetic within standard-layout objects

Section: 7.6.6 [expr.add] Status: NAD Submitter: Nikolay Ivchenkov Date: 2011-05-06

According to 6.9 [basic.types] paragraph 4,

> 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 6.8.2 [intro.object] paragraph 5,

> An object of trivially copyable or standard-layout type (6.9 [basic.types]) shall occupy contiguous bytes of storage.

Do these passages make pointer arithmetic (7.6.6 [expr.add] paragraph 5) within a standard-layout object well-defined (e.g., for writing one's own version of `memcpy`?

Rationale (August, 2011):

The current wording is sufficiently clear that this usage is permitted.

#### 2548. Array prvalues and additive operators

Section: 7.6.6 [expr.add] Status: NAD Submitter: Andrey Erokhin Date: 2022-03-08 Liaison: EWG

Consider

      int main()
      {
        using IA = int[];
        IA{ 1, 2, 3 } + 0;
      }

This appears to be ill-formed given the current wording, because the operand is already a prvalue, thus 7.2.1 [basic.lval] paragraph 6 does not apply and the array-to-pointer conversion is not applied:

> Whenever a glvalue appears as an operand of an operator that expects 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.

This outcome might be an oversight in the resolution for issue 1232.

See also clang issue 54016.

Proposed resolution [SUPERSEDED]:

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

> The additive operators + and - group left-to-right. The usual arithmetic conversions (7.4 [expr.arith.conv]) are performed for operands of arithmetic or enumeration type. The array-to-pointer conversion (7.3.3 [conv.array]) is applied to an operand of array type.

CWG 2023-07-14

CWG is generally in favor of the proposed resolution, but the interaction with the surrounding text needs to be checked in more detail after a Working Draft reflecting the Varna straw polls has become available.

Additional notes (September, 2023)

It is questionable which use-cases are being addressed by this change. On the other hand, `IA{1,2,3}[1]` already works today (7.2.1 [basic.lval] paragraph 6 and 7.6.1.2 [expr.sub] paragraph 2). However, the latter does cause temporary lifetime extension (6.8.7 [class.temporary] paragraph 6), whereas the near-equivalent `*(IA{1,2,3} + 1)` does not.

Similar to the addition case, indirection through an array prvalue is also not valid today. Consistency seems desirable.

Related vendor tickets: clang, gcc.

Possible resolution (amended 2023-10-09):

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

   > The unary `*` operator performs indirection. The array-to-pointer conversion (7.3.3 [conv.array]) is applied to an operand of array type; the possibly converted 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.

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

   > The unary `+` operator performs promotion. The array-to-pointer conversion (7.3.3 [conv.array]) is applied to an operand of array type; the possibly converted operand of the unary + operator shall be a prvalue of arithmetic, unscoped enumeration, or pointer type and the result is the value of the argument. Integral promotion (7.3.7 [conv.prom]) is performed on integral or enumeration operands. The type of the result is the type of the promoted operand. The operator yields a prvalue of the type of the converted operand; the result is the value of the converted operand.

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

   > The additive operators + and - group left-to-right. 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. Otherwise, if one operand has arithmetic or unscoped enumeration type, integral promotion is applied (7.3.7 [conv.prom]) to that operand. The array-to-pointer conversion (7.3.3 [conv.array]) is applied to an operand of array type. A converted or promoted operand is used in place of the corresponding original operand for the remainder of this section.

4. Change in 7.6.1.2 [expr.sub] paragraph 2 as follows:

   > ... The result of the expression `E1[E2]` is identical (by definition) to that of `*((E1)+(E2))`, except that in the case of an array operand, the result is an lvalue if that operand is an lvalue and an xvalue otherwise.
   > [ Note: The semantics of `E1[E2]` differ from those of `*((E1)+(E2))` also for
   > - lifetime extension of temporaries (6.8.7 [class.temporary]) and
   > - changing the active member of a union via assignment (11.5.1 [class.union.general]).
   > -- end note ]

CWG 2023-09-15 (amended 2023-10-09)

CWG seeks advice from EWG whether support for array prvalue operands should be added for the indirection operator, the unary `+` operator, and the additive operators, along the lines of the wording above. Similar to the `[]` operator, the specification of the indirection operation could be amended to yield an xvalue if the argument is a prvalue. The unary `+` operator is occasionally used to force an array-to-pointer decay.

Forwarded to EWG via paper issue 1633.

Paper P2865R2 seeks to remove the array-to-pointer conversion for the operands of relational operators, wheras this issue suggests adding more applications for the array-to-pointer conversion. These two directions appear not to be in harmony.

EWG 2023-11-07

The lack of support for the corner-case in this issue is not a defect given the direction in P2865 (Remove Deprecated Array Comparisons from C++26).

#### 2087. Left shift of negative value by zero bits

Section: 7.6.7 [expr.shift] Status: NAD Submitter: Mattheus Izvekov Date: 2015-02-16

A shift of zero bits should result in the left operand regardless of its sign. However, the current wording of 7.6.7 [expr.shift] paragraph 2 makes it undefined behavior.

Notes from the February, 2016 meeting:

CWG felt that a reasonable approach might be to define `<<N` as equivalent to multiplying by 2N in all cases; see also the resolution of issue 1457. The resolution of this question should also be coordinated with SG6 and SG12, as well as with WG14.

Rationale (February, 2019):

This issue is resolved by the adoption of paper P1236.

#### 622. Relational comparisons of arbitrary pointers

Section: 7.6.9 [expr.rel] Status: NAD Submitter: Herb Sutter Date: 26 February 2007

The relational operators have unspecified results when comparing pointers that refer to objects that are not members of the same object or elements of the same array (7.6.9 [expr.rel] paragraph 2, second bullet). This restriction (which dates from C89) stems from the desire not to penalize implementations on architectures with segmented memory by forcing them essentially to simulate a flat address space for the purpose of these comparisons. If such an implementation requires that objects and arrays to fit within a single segment, this restriction enables pointer comparison to be done simply by comparing the offset portion of the pointers, which could be much faster than comparing the full pointer values.

The problem with this restriction in C++ is that it forces users of the Standard Library containers to use `less<T*>` instead of the built-in `<` operator to provide a total ordering on pointers, a usage that is inconvenient and error-prone. Can the existing restriction be relaxed in some way to allow the built-in operator to provide a total ordering? (John Spicer pointed out that the actual comparison for a segmented architecture need only supply a total ordering of pointer values, not necessarily the complete linearization of the address space.)

Rationale (April, 2007):

The current specification is clear and was well-motivated. Analysis of whether this restriction is still needed should be done via a paper and discussed in the Evolution Working Group rather than being handled by CWG as an issue/defect.

Additional note, April, 2015:

EWG has decided not to make a change in this area. See EWG issue 91.

#### 1400. Function pointer equality

Section: 7.6.10 [expr.eq] Status: NAD Submitter: Nikolay Ivchenkov Date: 2011-09-30

According to 7.6.10 [expr.eq] paragraph 2, two function pointers only compare equal if they point to the same function. However, as an optimization, implementations are currently aliasing functions that have identical definitions. It is not clear whether the Standard needs to deal explicitly with this optimization or not.

Rationale (February, 2012):

The Standard is clear on the requirements, and implementations are free to optimize within the constraints of the “as-if” rule.

#### 2302. Address comparison between different member subobjects

Section: 7.6.10 [expr.eq] Status: NAD Submitter: Daveed Vandevoorde Date: 2016-04-29

According to 7.6.10 [expr.eq] bullet 2.1,

> Comparing pointers is defined as follows:

> - If one pointer represents the address of a complete object, and another pointer represents the address one past the last element of a different complete object87, the result of the comparison is unspecified.

The use of the term “complete object” is confusing. A complete object is one that is not a subobject of any other object (6.8.2 [intro.object] paragraph 2), so this restriction apparently does not apply to non-static data members. Is the following guaranteed to work?

      struct S {
        int i[2];
        int j[2];
      };

      constexpr bool check1() {
        S s = { { 1, 2 }, { 3, 4 } };
        return &s.i[2] == &s.j[0];
      }

      static_assert(check1(), "Guaranteed?");

In particular, is there a guarantee that there is no padding between nonstatic data members of the same type?

Rationale (July, 2017):

CWG determined that the existing wording is correct: the result of the comparison is implementation-defined, but not unspecified, so the program is well-formed but the assertion is not guaranteed to pass.

#### 2286. Assignment evaluation order

Section: 7.6.19 [expr.assign] Status: NAD Submitter: Jason Merrill Date: 2016-07-06

P0145 caused this situation:

      extern "C" void abort();

      struct A
      {
        int i;
        int data[10000];
      } a;

      A& aref() { a.i++; return a; }
      int main()
      {
        aref() = a;
        if (a.i != 0)
          abort();
      }

Is `a.i` now required to be 0?

A related example is this:

      int b;
      int& bref() { ++b; return b; }
      int main() {
        bref() = b;
        if (b != 0)
          abort();
      }

Here, `b` is required to be 0 after the assignment, because the value computation of the RHS of the assignment is sequenced before any side-effects on the LHS. The difference in guaranteed behavior between class and non-class types is disturbing.

Rationale (April, 2017):

Class copy assignment binds a `const T&`, so the `A` example actually yields `a.i == 1` after the assignment.

#### 97. Use of bool constants in integral constant expressions

Section: 7.7 [expr.const] Status: NAD Submitter: Andy Koenig Date: 18 Feb 1999

Consider:

        int* p = false;         // Well-formed?
        int* q = !1;            // What about this?

>From 6.9.2 [basic.fundamental] paragraph 6: "As described below, `bool` values behave as integral types."

From 7.3.12 [conv.ptr] paragraph 1: "A null pointer constant is an integral constant expression rvalue of integer type that evaluates to zero."

From 7.7 [expr.const] paragraph 1: "An integral constant-expression can involve only literals, enumerators, const variables or static members of integral or enumeration types initialized with constant expressions, ..."

In 5.13.2 [lex.icon] : No mention of `true` or `false` as an integer literal.

From 5.13.7 [lex.bool] : `true` and `false` are Boolean literals.

So the definition of `q` is certainly valid, but the validity of `p` depends on how the sentence in 7.7 [expr.const] is parsed. Does it mean

{literals, enumerators, const variables, or static members} of integral of integral or enumeration types...

Or does it mean

literals (of any type), enumerators, const variables, or {static members of integral or enumeration types}

Or something else?

If the latter, then `(3.0 < 4.0)` is a constant expression, which I don't think we ever wanted. If the former, though, we have the anomalous notion that `true` and `false` are not constant expressions.

Now, you may argue that you shouldn't be allowed to convert `false` to a pointer. But what about this?

        static const bool debugging = false;

        // ...

        int table[debugging? n+1: n];

Whether the definition of table is well-formed hinges on whether `false` is an integral constant expression.

I think that it should be, and that failure to make it so was just an oversight.

Rationale (04/99): A careful reading of 7.7 [expr.const] indicates that all types of literals can appear in integral constant expressions, but floating-point literals must immediately be cast to an integral type.

#### 236. Explicit temporaries and integral constant expressions

Section: 7.7 [expr.const] Status: NAD Submitter: Mike Miller Date: 19 Jul 2000

Does an explicit temporary of an integral type qualify as an integral constant expression? For instance,

        void* p = int();    // well-formed?

It would appear to be, since `int()` is an explicit type conversion according to 7.6.1.4 [expr.type.conv] (at least, it's described in a section entitled "Explicit type conversion") and type conversions to integral types are permitted in integral constant expressions (7.7 [expr.const]). However, this reasoning is somewhat tenuous, and some at least have argued otherwise.

Note (March, 2008):

This issue should be closed as NAD as a result of the rewrite of 7.7 [expr.const] in conjunction with the constexpr proposal.

Rationale (August, 2011):

As given in the preceding note.

#### 487. Operator overloading in constant expressions

Section: 7.7 [expr.const] Status: NAD Submitter: Steve Adamczyk Date: 24 Nov 2004

According to 7.7 [expr.const] paragraph 1,

> In particular, except in `sizeof` expressions, functions, class objects, pointers, or references shall not be used, and assignment, increment, decrement, function-call, or comma operators shall not be used.

Given a case like

        enum E { e };
        int operator+(int, E);
        int i[4 + e];

does this mean that the overloaded `operator+` is not considered (because it can't be called), or is it selected by overload resolution, thus rendering the program ill-formed?

Rationale (April, 2005):

All expressions, including constant expressions, are subject to overload resolution. The example is ill-formed.

#### 807. `typeid` expressions in constant expressions

Section: 7.7 [expr.const] Status: NAD Submitter: UK Date: 3 March, 2009
N2800 comment UK 51

`typeid` expressions can never be constant, whether or not the operand is a polymorphic class type. The result of the expression is a reference, and the `typeinfo` class that the reference refers to is polymorphic, with a virtual destructor - it can never be a literal type.

Rationale (July, 2009):

The intent of this specification was that the address of such a `typeinfo` object could be treated as an address constant and thus usable in constant initialization (contrary to the statement in the comment, the result of `typeid` is an lvalue, not a reference).

#### 1384. `reinterpret_cast` in constant expressions

Section: 7.7 [expr.const] Status: NAD Submitter: Daniel Krügler Date: 2011-08-30

`reinterpret_cast` was forbidden in constant expressions to prevent type-punning operations at compile time. This may have been too strict, as there are uses for the operator that do not involve type punning. For example, a portable implementation of the `addressof` function could be written as a `constexpr` function if `reinterpret_cast` could be used in a constant expression.

Rationale (October, 2012):

Although `reinterpret_cast` was permitted in address constant expressions in C++03, this restriction has been implemented in some compilers and has not proved to break significant amounts of code. CWG deemed that the complications of dealing with pointers whose tpes changed (pointer arithmetic and dereference could not be permitted on such pointers) outweighed the possible utility of relaxing the current restriction.

#### 1407. Integral to `bool` conversion in converted constant expressions

Section: 7.7 [expr.const] Status: NAD Submitter: Richard Smith Date: 2011-10-21

The following example appears to be ill-formed, although current implementations accept it:

      template<bool> struct S { };
      S<0> s;

The reason this is ill-formed is that the non-type template argument is a converted constant expression of type `bool` (see 13.4.3 [temp.arg.nontype] paragraph 5), and the second conversion in the implicit conversion sequence is a boolean conversion, which is not allowed in the conversion for a converted constant expression (see 7.7 [expr.const] paragraph 3) . Conversions in the other direction (from `bool` to integer types) are permitted here, since they're integral promotions.

Rationale (February, 2012):

The analysis is correct, and the example is ill-formed. Implementations that accept it are in error.

#### 1452. Value-initialized objects may be constants

Section: 7.7 [expr.const] Status: NAD Submitter: Richard Smith Date: 2011-12-24

Some classes that would produce a constant when initialized by value-initialization are not considered literal types. For example:

       struct A { int a; };       // non-constexpr default constructor
       struct B : A {};           // non-literal type
       constexpr int i = B().a;   // OK, trivial constructor not called
       constexpr B b = b ();      // error, constexpr object of non-literal type

Additional note (February, 2017):

This is effectively issue 644, which was resolved once, then had its resolution backed out via the resolution of issue 1071 (actual drafting in issue 981).

Rationale (February, 2021):

The adoption of paper P1331R2 (at the July, 2019 meeting) rendered the question in the issue moot, as the requirement that a constexpr constructor initialize all its non-static data members was removed, so the defaulted `B` default constructor is now constexpr.

#### 1540. Use of address constants in constant expressions

Section: 7.7 [expr.const] Status: NAD Submitter: Bjarne Stroustrup Date: 2012-08-16

It appears that the current specification of constant expressions in 7.7 [expr.const] pararaph 2 permits examples like

      constexpr const char* p = "asdf";
      constexpr char ch = p[2];

This seems unnecessarily complicated for both users and implementers. If subscripting were defined directly, rather than in terms of pointer arithmetic and indirection (see issue 1213), we could still support the obvious cases of things like

      constexpr char ch2 = "asdf"[2];

without requiring compilers and users to track the target of address-constant pointers and references.

Rationale (October, 2012):

CWG was comfortable with this implication of the current wording.

#### 1826. `const` floating-point in constant expressions

Section: 7.7 [expr.const] Status: NAD Submitter: Ville Voutilainen Date: 2014-01-04

A `const` integer initialized with a constant can be used in constant expressions, but a `const` floating point variable initialized with a constant cannot. This was intentional, to be compatible with C++03 while encouraging the consistent use of `constexpr`. Some people have found this distinction to be surprising, however.

It was also observed that allowing `const` floating point variables as constant expressions would be an ABI-breaking change, since it would affect lambda capture.

One possibility might be to deprecate the use of `const` integral variables in constant expressions.

Additional note, April, 2015:

EWG requested CWG to allow use of `const` floating-point variables in constant expressions.

Rationale (May, 2015):

CWG felt that the current rules should not be changed and that programmers desiring floating point values to participate in constant expressions should use `constexpr` instead of `const`.

#### 1921. `constexpr` constructors and point of initialization of `const` variables

Section: 7.7 [expr.const] Status: NAD Submitter: Ville Voutilainen Date: 2014-05-02

In an example like

      extern int const x;

      struct A {
        constexpr A () { }
        int value = x;
      };

      int const x = 123;

      constexpr A a;

it is not clear whether the constructor for `A` is well-formed (because the initialization for `x` has not yet been seen) and whether that constant value is used in the initialization of `a`. There is implementation divergence on these questions.

Rationale (June, 2014):

The requirements for a `constexpr` constructor in 9.2.6 [dcl.constexpr] do not require that an initializer be constant at the point of definition, similar to the provision for mutually-recursive `constexpr` functions, which require that at least one of the functions will contain a reference to a not-yet-defined `constexpr` function. Determination of whether an expression is constant or not is made in the context in which the expression appears, by which time the constant value of `x` in the exampe above is known. CWG feels that the current wording is clear enough that the example is well-formed.

#### 1968. Address of `typeid` in constant expressions

Section: 7.7 [expr.const] Status: NAD Submitter: Richard Smith Date: 2014-07-14

There is implementation divergence on the handling of `typeid` in constant expressions, for example:

      static_assert(&typeid(int) == &typeid(int), ""); // #1

According to the current wording, it is unspecified whether two evaluations of the `typeid` operator produce the same result, even though `typeid` can be used in constant expressions as long as its operand is not a glvalue of a polymorphic class type. Of particular concern is the case where `typeid` might be evaluated in different translation units.

Rationale (November, 2014):

Because the result of two separate evaluations of the `typeid` operator are not guaranteed to produce the same result, the comparison in the example is not permitted in a constant expression.

#### 2005. Incorrect `constexpr` reference initialization requirements

Section: 7.7 [expr.const] Status: NAD Submitter: David Krauss Date: 2014-09-18

Consider an example like:

      constexpr int f() { return 5; } // function must be constexpr
      constexpr int && q = f();       // but result is not constant
      constexpr int const & r = 2;    // temporary is still not constant
      int main() {
        q = 11;                       // OK
        const_cast< int & >( r ) = 3; // OK (temporary object is not ROMable)

        constexpr int && z = 7;       // Error? Temporary does not have static storage duration?
      }

A constexpr reference must be initialized by a constant expression (9.2.6 [dcl.constexpr] paragraph 9), yet it may refer to a modifiable temporary object. Such a temporary is guaranteed static initialization, but it's not ROMable.

A non-const constexpr reference initialized with an lvalue expression is useful, because it indicates that the underlying storage of the reference may be statically initialized, or that no underlying storage is required at all.

When the initializer is a temporary, finding its address is trivial. There is no reason to declare any intent the computation of its address. On the other hand, an initial value is provided, and that is also required to be a constant expression, although it's never treated as a constant.

The situation is worse for local constexpr references. The initializer generates a temporary when the declaration is executed. The temporary is a locally scoped, unique object. This renders constexpr meaningless, because although the address computation is trivial, it still must be done dynamically.

C++11 constexpr references required initialization by reference constant expressions, which had to “designate an object with static storage duration or a function” (C++11 7.7 [expr.const] paragraph 3). A temporary with automatic storage duration granted by the reference fails this requirement.

C++14 removes reference constant expressions and the static storage requirement, rendering the program well-defined with an apparently defeated constexpr specifier. (GCC and Clang currently provide the C++11 diagnosis.)

Suggested resolution: a temporary bound to a constexpr reference should itself be constexpr, implying const-qualified type. Forbid binding a constexpr reference to a temporary unless both have static storage duration. (In local scope, the static specifier fixes the issue nicely.)

Rationale (November, 2014):

This issue is already covered by 7.7 [expr.const] paragraph 4, which includes conversions and temporaries in the analysis.

#### 2364. Constant expressions, aggregate initialization, and modifications

Section: 7.7 [expr.const] Status: NAD Submitter: Mike Miller Date: 2017-10-31

There is implementation variance in the treatment of the following example:

      constexpr int f(int x) { return x; }
      int main() {
        struct {
          int x = f(x = 37);
        } constexpr a = { };
      }

Is the assignment to `x` considered to satisfy the requirememts of 7.7 [expr.const] bullet 2.17,

> modification of an object (7.6.19 [expr.assign], 7.6.1.6 [expr.post.incr], 7.6.2.3 [expr.pre.incr]) unless it is applied to a non-volatile lvalue of literal type that refers to a non-volatile object whose lifetime began within the evaluation of `e`;

assuming that `e` is the full-expression encompassing the initialization of `a`?

Notes from the October, 2018 teleconference:

This kind of example was previously ill-formed but it was inadvertently allowed by the change to the “non-vacuous initialization” rule. That rule should be restricted to class and array types, making this example again ill-formed.

Rationale, February, 2021:

The resolution of 2256 makes clear that the lifetime of `x` has not begun because its initialization is not yet complete, so the assignment is undefined behavior and thus ill-formed in a constant expression.

#### 2349. Class/enumeration names vs conditions

Section: Clause 8 [stmt] Status: NAD Submitter: Daveed Vandevoorde Date: 2017-05-04

According to Clause 8 [stmt] paragraph 3,

> A name introduced by a declaration in a condition (either introduced by the decl-specifier-seq or the declarator of the condition) is in scope from its point of declaration until the end of the substatements controlled by the condition. If the name is redeclared in the outermost block of a substatement controlled by the condition, the declaration that redeclares the name is ill-formed.

This does not exempt class and enumeration names, which can ordinarily coexist with non-type names in the same scope (_N4868_.6.4.10 [basic.scope.hiding] paragraph 2) . However, there is implementation variance in the handling of examples like:

       void g() {
         if (int N = 3) {
           struct N { } n; // ill-formed but not diagnosed by some implementations
         }
       }

Should the rule for conditions be updated to allow for this case?

Rationale (April, 2018):

Hiding of tag names by non-type names was added for C compatibility. C does not support conditions, and there was no consensus to extend the tag/non-type hiding rules into contexts where C compatibility is not required.

#### 2344. Redeclaration of names in init-statements

Section: 8.5 [stmt.select] Status: NAD Submitter: John Spicer Date: 2017-04-19

According to Clause 8 [stmt] paragraph 3,

> A name introduced by a declaration in a condition (either introduced by the decl-specifier-seq or the declarator of the condition) is in scope from its point of declaration until the end of the substatements controlled by the condition. If the name is redeclared in the outermost block of a substatement controlled by the condition, the declaration that redeclares the name is ill-formed.

Should there be a similar rule about redeclaring names introduced by init-statements?

Notes from the April, 2018 teleconference:

CWG agreed that such a rule should be added.

Rationale (January, 2019):

The init-statement case is covered by 6.4.3 [basic.scope.block] paragraph 3. These two references should be harmonized and cross-referenced appropriately as an editorial change.

#### 2274. Generic lambda capture vs constexpr if

Section: 8.5.2 [stmt.if] Status: NAD Submitter: Richard Smith Date: 2016-06-20

Consider:

      template<typename Iter> void f(Iter a, Iter b) {
        const int v = 10;
        auto do_something = [&] (auto thing) {
          if constexpr (is_random_access_iterator<Iter> && is_integral<decltype(thing)>)
            *(a + 1) = v;
         };
        do_something(5);
        do_something("foo");
      }

Determining whether `v` is captured requires instantiating the "if constexpr", but that results in a hard error for a statement that will eventually be discarded.

Rationale (February, 2018):

These questions were resolved by the adoption of paper P0588R1 at the November, 2017 meeting.

#### 2348. Non-templated `constexpr if`

Section: 8.5.2 [stmt.if] Status: NAD Submitter: John Spicer Date: 2017-05-01

The effect of `constexpr if` in non-templated code is primarily limited to not requiring definitions for entities that are odr-used in discarded statements. This eliminates a plausible implementation techique of simply skipping the tokens of a discarded statement. Should the Standard allow such an approach? One needed change might be to say that all diagnosable rules become “no diagnostic required” inside discarded statements.

Rationale (April, 2018):

The design was thoroughly discussed before adopting the feature and the current specification was intentionally adopted. Any request for a change should go through the normal EWG process at this point.

#### 1679. Range-based `for` and array of runtime bound

Section: 8.6.5 [stmt.ranged] Status: NAD Submitter: Jason Merrill Date: 2013-05-09

The expansion of a range-based `for` in 8.6.5 [stmt.ranged] paragraph 1 involves a declaration of the form

      auto && __range = range-init;

However, it is not permitted to bind a reference to an array of runtime bound (9.3.4.3 [dcl.ref] paragraph 5), even though it is intended that such arrays can be used in a range-based `for`.

Rationale (September, 2013):

Arrays of runtime bound were moved from the normative specification to a proposed Technical Specification.

#### 467. Jump past initialization of local static variable

Section: 8.10 [stmt.dcl] Status: NAD Submitter: Kerch Holt Date: 31 Mar 2004

When jumping past initialization of a local static variable the value of the static becomes indeterminate. Seems like this behavior should be illegal just as it is for local variables with automatic linkage.

Here is an example:

    struct X {
        X(int i) : x(i) {}
        int x;
    };
    int f(int c) {
        if (c)
            goto ly;    // error here for jumping past next stmt.
        static X a = 1;
    ly:
        return a.x;  // either 1 or 0 depending on implementation.
    }

8.10 [stmt.dcl] P3 should be changed to:

> A program that jumps from a point where a local variable with automatic or static storage duration is not in scope to a point where it is in scope is ill-formed unless the variable has POD type (3.9) and is declared without an initializer (8.5).

This would imply "static X a = 1;" should be flagged as an error. Note that this behavior a may be a "quality of implementation issue" which may be covered in 6.7 P4. Paragraph 4 seems to make the choice of static/dynamic initialization indeterminate. Making this an error and thus determinate seems the correct thing to do since that is what is already required of automatic variables.

Steve Adamczyk: Some version of this may be appropriate, but it's common to have code that is executed only the first time it is reached, and to have an initialization of a static variable inside such a piece of code. In such a case, on executions after the first there is indeed a jump over the declaration, but the static variable is correctly initialized -- it was initialized the first time the routine was called.

      void f() {
        static bool first_time = true;
        if (!first_time) goto after_init;
        static int i = g();
        first_time = false;
      after_init:
        ...
      }

Rationale (October, 2004):

The CWG sees no reason to change this specification. Local static variables are different from automatic variables: automatic variables, if not explicitly initialized, can have indeterminate (“garbage”) values, including trap representations, while local static variables are subject to zero initialization and thus cannot have garbage values.

The latitude granted to implementations regarding performing dynamic initialization of local static objects as if it were static initialization is exactly parallel to namespace scope objects (6.10.3.2 [basic.start.static]), as are the restrictions on programmer assumptions.

#### 2751. Order of destruction for parameters for operator functions

Section: 8.10 [stmt.dcl] Status: NAD Submitter: Richard Smith Date: 2020-06-10 Liaison: EWG

Subclause 8.10 [stmt.dcl] paragraph 2 specifies:

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

Another description of the same rule is in a note in 8.8.1 [stmt.jump.general] paragraph 2:

> [Note 1: On exit from a scope (however accomplished), objects with automatic storage duration (6.8.6.4 [basic.stc.auto]) that have been constructed in that scope are destroyed in the reverse order of their construction. ... —end note]

However, 12.2.2.3 [over.match.oper] paragraph 2 specifies:

> ... Therefore, the operator notation is first transformed to the equivalent function-call notation as summarized in Table 18 (where @ denotes one of the operators covered in the specified subclause). However, the operands are sequenced in the order prescribed for the built-in operator (7.6 [expr.compound]).

For `operator+=` (for example), 7.6.19 [expr.assign] paragraph 1 requires:

> ... The right operand is sequenced before the left operand. ...

Now, consider an ABI with callee-cleanup and this example:

      void operator<<(A, B);
      void operator+=(A, B);
      void (*p)(A, B) = cond ? &operator<< : &operator+=;

In `A() << B()`, `A()` is sequenced before `B()`. In `A() += B()`, `B() is sequenced before A()`. For an ABI with callee-cleanup, this means that `operator<<` must destroy the `B` parameter before the `A` parameter, and `operator+=` must destroy the `A` parameter before the `B` parameter.

But this means we have a problem emitting a call to `p(A(), B())`: no order of parameter initialization guarantees that parameters are destroyed in reverse construction order.

A possible implementation strategy would be to emit a second definition of `operator+=` with the opposite parameter destruction order that is used when naming the function `operator+=`, e.g. when taking the address or using function call notation (as opposed to using operator notation).

Another alternative is to relax the rules about destruction of parameters in the reverse order of construction for the case of binary operator functions and `operator new` and `operator delete`.

Additional notes (June, 2023)

Forwarded to EWG via paper issue 1583, per decision of the CWG chair, to either affirm the intent of the rules (requiring a more involved implementation strategy as outlined above) or agree on a relaxation of the rules for the order of destruction of parameters.

EWG 2023-11-07

Not a defect; the suggested implementation strategy is viable.

#### 435. Change "declararation or definition" to "declaration"

Section: 9.1 [dcl.pre] Status: NAD Submitter: Jens Maurer Date: 27 Oct 2003

Because a definition is also a declaration, it might make sense to change uses of "declaration or definition" to simply "declaration".

Notes from the March 2004 meeting:

Jens Maurer prepared drafting for this issue, but we find ourselves reluctant to actually make the changes. Though correct, they seemed more likely to be misread than the existing wording.

Proposed resolution:

Remove in Clause 3 [intro.defs] “parameter” the indicated words:

> an object or reference declared as part of a function declaration or definition, or in the catch clause of an exception handler, that acquires a value on entry to the function or handler; ...

Remove in 13.2 [temp.param] paragraph 10 the indicated words:

> The set of default template-arguments available for use with a template declaration or definition is obtained by merging the default arguments from the definition (if in scope) and all declarations in scope in the same way default function arguments are (...).

Remove in 13.8 [temp.res] paragraph 2 the indicated words:

> A name used in a template declaration or definition and that is dependent on a template-parameter is assumed not to name a type unless the applicable name lookup finds a type name or the name is qualified by the keyword `typename`.

Remove in 13.8.4.1 [temp.point] paragraph 1 the indicated words:

> Otherwise, the point of instantiation for such a specialization immediately follows the namespace scope declaration or definition that refers to the specialization.

Remove in 13.8.4.1 [temp.point] paragraph 3 the indicated words:

> Otherwise, the point of instantiation for such a specialization immediately precedes the namespace scope declaration or definition that refers to the specialization.

Remove in 13.9.4 [temp.expl.spec] paragraph 21 the indicated words:

> Default function arguments shall not be specified in a declaration or a definition for one of the following explicit specializations:
> - ...
> [Note: default function arguments may be specified in the declaration or definition of a member function of a class template specialization that is explicitly specialized. ]

Remove in 13.10.3.6 [temp.deduct.type] paragraph 18 the indicated words:

> [Note: a default template-argument cannot be specified in a function template declaration or definition; ...]

Remove in 16.4.3.2 [using.headers] paragraph 3 the indicated words:

> A translation unit shall include a header only outside of any external declaration or definition, and shall include the header lexically before the first reference to any of the entities it declares or first defines in that translation unit.

Rationale (October, 2004):

CWG felt that readers might misunderstand “declaration” as meaning “non-definition declaration.”

#### 1325. Omitted declarator in `friend` declarations

Section: 9.1 [dcl.pre] Status: NAD Submitter: Johannes Schaub Date: 2011-05-27

According to 9.1 [dcl.pre] paragraph 3,

> In a simple-declaration, the optional init-declarator-list can be omitted only when declaring a class (Clause 11 [class]) or enumeration (9.8.1 [dcl.enum]), that is, when the decl-specifier-seq contains either a class-specifier, an elaborated-type-specifier with a class-key (11.3 [class.name]), or an enum-specifier.

This does not allow for the new simplified `friend` declaration syntax (11.8.4 [class.friend] paragraph 3), which permits the forms

`friend` simple-type-specifier `;`
`friend` typename-specifier `;`

Rationale (May, 2014):

The `friend` specifier can only appear in a member-declaration, which contains a member-declarator-list, not an init-declarator-list.

#### 2288. Contradictory optionality in simple-declaration

Section: 9.1 [dcl.pre] Status: NAD Submitter: Gabriel Dos Reis Date: 2016-07-12

Subclause 9.1 [dcl.pre] paragraph 1 defines simple-declaration as:

>     simple-declaration :
>         decl-specifier-seq init-declarator-listopt ;
>         attribute-specifier-seq decl-specifier-seq init-declarator-list ;
>         ...

However, 9.1 [dcl.pre] paragraph 2 then refers to a simple-declaration using a different producction:

> A simple-declaration or nodeclspec-function-declaration of the form

>         attribute-specifier-seqopt decl-specifier-seqopt init-declarator-listopt ;

> is divided into three parts...

It appears that the latter redefines the grammar non-terminal simple-declaration in an inconsistent way.

Rationale (April, 2017):

The unification of the “in the form” pattern is confusing, so the question was based on a misunderstanding of the text.

#### 154. Anonymous unions in unnamed namespaces

Section: 9.2.2 [dcl.stc] Status: NAD Submitter: Greg Comeau Date: 9 Aug 1999

11.5 [class.union] paragraph 3 implies that anonymous unions in unnamed namespaces need not be declared `static` (it only places that restriction on anonymous unions "declared in a named namespace or in the global namespace").

However, 9.2.2 [dcl.stc] paragraph 1 says that "global anonymous unions... shall be declared `static`." This could be read as prohibiting anonymous unions in unnamed namespaces, which are the preferred alternative to the deprecated use of static.

Rationale (10/99): An anonymous union in an unnamed namespace is not "a global anonymous union," i.e., it is not a member of the global namespace.

#### 2050. Consolidate specification of linkage

Section: 9.2.2 [dcl.stc] Status: NAD Submitter: Alisdair Meredith Date: 2014-11-26

9.2.2 [dcl.stc] paragraph 7 seems out of place in the current organization of the Standard:

> The linkages implied by successive declarations for a given entity shall agree. That is, within a given scope, each declaration declaring the same variable name or the same overloading of a function name shall imply the same linkage. Each function in a given set of overloaded functions can have a different linkage, however. [Example:...

The preceding two paragraphs on `static` and `extern` simply defer to 6.7 [basic.link] to describe their interaction with linkage, so it seems appropriate for this paragraph to move there as well so that all the information on linkage is in one place.

Rationale (May, 2015):

The material in 6.7 [basic.link] deals with linkage concepts, while 9.2.2 [dcl.stc] is concerned with the syntactic constructs in a program that result in the linkages described in 6.7 [basic.link]. CWG felt that the referenced paragraph falls more into the latter category than the former.

#### 376. Class "definition" versus class "declaration"

Section: 9.2.3 [dcl.fct.spec] Status: NAD Submitter: Randy Maddox Date: 28 August 2002

In 9.2.3 [dcl.fct.spec], para. 3, the following sentence

> A function defined within a class definition is an inline function.

should, if I am not mistaken, instead be:

> A function defined within a class declaration is an inline function."

Notes from October 2002 meeting:

This is not a defect. Though there is a long history, going back to the ARM, of use of the term "class declaration" to mean the definition of the class, we believe "class definition" is clearer. We have opened issue 379 to deal with changing all other uses of "class declaration" to "class definition" where appropriate.

#### 412. Can a replacement allocation function be inline?

Section: 9.2.3 [dcl.fct.spec] Status: NAD Submitter: Matt Austern Date: 23 Apr 2003

A customer reports that when he attempts to replace `::operator new` with a user-defined function, the standard library calls the default function by preference if the user-defined function is inline. I believe that our compiler is correct, and that such a replacement function isn't allowed to be inline, but I'm not sure there's sufficiently explicit language in the standard.

In general, of course, the definition of an inline function must be present in every translation unit where the function is called. (9.2.3 [dcl.fct.spec], par 4) It could be argued that this requirement doesn't quite address replacement functions: what we're dealing with is the odd case where we've already got one definition and the user is supplying a different one. I'd like to see something specifically addressing the case of a replacement function.

So what do we have? I see discussion of requirement for a replacement `::operator new` in three places: 16.4.5.6 [replacement.functions], 17.6.3.2 [new.delete.single] par 2, and 6.8.6.5 [basic.stc.dynamic] par 2-3. I don't see anything explicitly saying that the replacement function may not be inline. The closest I can find is 17.6.3.2 [new.delete.single] par 2, which says that "a C++ program may define a function with this function signature that displaces the default version defined by the C++ Standard library". One might argue that "with this function signature" rules out inline, but that strikes me as a slight stretch.

Have I missed anything?

Andrew Koenig: I think you've turned up a problem in 9.2.3 [dcl.fct.spec] paragraph 4. Consider:

      // Translation unit 1
      #include <iostream>

      extern void foo(void (*)());

      inline void bar() {
        std::cout << "Hello, world!" << std::endl;
      }

      int main() {
        foo(bar);
      }

      // Translation unit 2
      void foo(void (*f)()) { (*f)(); }

Are you really trying to tell me that this program is ill-formed because the definition of bar is not available in translation unit 2?

I think not. The actual words in 9.2.3 [dcl.fct.spec] par 4 are

> An inline function shall be defined in every translation unit in which it is used...

and I think at in this context, ``used'' should be interpreted to mean that foo is used only in translation unit 1, where it is converted to a value of type void(*)().

Notes from October 2003 meeting:

We don't think Andy Koenig's comment requires any action; "used" is already defined appropriately.

We agree that this replacement should not be allowed, but we think it's a library issue (in the rules for allowed replacements). Forwarded to library group; it's issue 404 on the library issues list.

#### 422. Is a typedef redeclaration allowed with a template type that might be the same?

Section: 9.2.4 [dcl.typedef] Status: NAD Submitter: Steve Adamczyk Date: 18 June 2003

Is the following valid?

      template <class T> void f(T) {
        typedef int x;
        typedef T x;
      }
      int main() {
        f(1);
      }

There is an instantiation where the function is valid. Is an implementation allowed to issue an error on the template declaration because the types on the typedef are not the same (9.2.4 [dcl.typedef])?

How about

      typedef T x;
      typedef T2 x;

?

It can be argued that these cases should be allowed because they aren't necessarily wrong, but it can also be argued that there's no reason to write things like the first case above, and if such a case appears it's more likely to be a mistake than some kind of intentional test that int and T are the same type.

Notes from the October 2003 meeting:

We believe that all these cases should be allowed, and that errors should be required only when an instance of the template is generated. The current standard wording does not seem to disallow such cases, so no change is required.

#### 1964. opaque-enum-declaration in alias-declaration?

Section: 9.2.4 [dcl.typedef] Status: NAD Submitter: Fedor Sergeev Date: 2014-07-07

The grammar does not allow for a declaration of the form

      using T = enum class E : int;

However, it is widely accepted by current implementations. Should the rules be changed to accommodate this usage?

Rationale (November, 2014):

A type-id is intended as a reference to a type, but the opaque enumeration syntax is intended as a declaration, not a reference like an elaborated-type-specifier, so the current rules are as intended.

#### 1316. `constexpr` function requirements and class scope

Section: 9.2.6 [dcl.constexpr] Status: NAD Submitter: Jason Merrill Date: 2011-0512

A `constexpr` function is required to have literal argument and return types. Consider an example like:

      template <class T> struct B {
        constexpr B(T) { }
      };

      struct A {
        B<A> b;
      };

Whether `B(A)` is `constexpr` depends on whether `A` is literal, which depends on whether `B<A>` is literal, which depends on whether `B(A)` is `constexpr`.

Rationale (August, 2011):

The requirements apply to definitions, not declarations.

#### 1637. Recursion in `constexpr` template default constructor

Section: 9.2.6 [dcl.constexpr] Status: NAD Submitter: Daveed Vandevoorde Date: 2013-03-11

Consider the following example:

      struct A {
        template <class T> constexpr void* f(T) { return nullptr; }
        A* ap = (A*)f(A());
        template <class ...T> constexpr A() {}
      };

A default constructor template instance would recurse infinitely via the member initializer for `A::ap`. However, since it's a template, by 9.2.6 [dcl.constexpr] paragraph 6, that would just mean that the instance shouldn't be treated as `constexpr`.

Is an implementation really expected to handle that? In effect, we have to try to evaluate the expression and if that fails, nullify the `constexpr`-ness of the `A::A<>()` instance, and re-examine the initializer with the new understanding of that instance?

Rationale (April, 2013):

In the cited example, the constructor is `constexpr`; it simply cannot be used in a constant expression. The error would be detected at the time of such a use.

#### 1688. Volatile `constexpr` variables

Section: 9.2.6 [dcl.constexpr] Status: NAD Submitter: Daniel Krügler Date: 2013-05-18

There does not appear to be language in the current wording stating that `constexpr` cannot be applied to a variable of volatile-qualified type. Also, the wording in 7.7 [expr.const] paragraph 2 referring to “a non-volatile object defined with `constexpr`” might lead one to infer that the combination is permitted but that such a variable cannot appear in a constant expression. What is the intent?

Rationale (September, 2013):

The combination is intentionally permitted and could be used in some circumstances to force constant initialization.

#### 1745. `thread_local constexpr` variable

Section: 9.2.6 [dcl.constexpr] Status: NAD Submitter: John Spicer Date: 2013-09-05

Neither 9.2.6 [dcl.constexpr] nor 9.2.2 [dcl.stc] forbids combining the `thread_local` and `constexpr` specifiers in the declaration of a variable. Should this combination be permitted?

Rationale (January, 2014):

Such an object could have mutable subobjects. The `constexpr` specifier guarantees static initialization.

#### 2117. Explicit specializations and `constexpr` function templates

Section: 9.2.6 [dcl.constexpr] Status: NAD Submitter: Faisal Vali Date: 2015-04-26

[ The paragraph in question was removed by P2448R2, adopted at the July, 2022 meeting. ]

According to 9.2.6 [dcl.constexpr] paragraph 6,

> If no specialization of the template would satisfy the requirements for a constexpr function or constexpr constructor when considered as a non-template function or constructor, the template is ill-formed; no diagnostic required.

This should say “instantiated template specialization” instead of just “specialization” to clarify that an explicit specialization is not in view here.

#### 2217. `constexpr` constructors for non-literal types

Section: 9.2.6 [dcl.constexpr] Status: NAD Submitter: Daveed Vandevoorde Date: 2015-12-21

Given an example like:

      struct S {
        constexpr S(): i(42) {  }
        ~S();
        int i;
      };
      double x[S().i];  // Error

such a `constexpr` constructor is completely useless, but there doesn't appear to be anything in the current wording making it ill-formed. Should it be?

Rationale (November, 2016):

Such constructors can be useful for guaranteeing static initialization of namespace-scope objects.

#### 643. Use of `decltype` in a class member-specification

Section: 9.2.9.3 [dcl.type.simple] Status: NAD Submitter: Alisdair Meredith Date: 8 Aug 2007

11.4 [class.mem] paragraph 2 says,

> A class is considered a completely-defined object type (6.9 [basic.types]) (or complete type) at the closing `}` of the class-specifier. Within the class member-specification, the class is regarded as complete within function bodies, default arguments, and exception-specifications (including such things in nested classes). Otherwise it is regarded as incomplete within its own class member-specification.

In particular, the return type of a member function is not listed as a context in which the class type is considered complete; instead, that case is handled as an exception to the general rule in 9.3.4.6 [dcl.fct] paragraph 6 requiring a complete type in the definition of a function:

> The type of a parameter or the return type for a function definition shall not be an incomplete class type (possibly cv-qualified) unless the function definition is nested within the member-specification for that class (including definitions in nested classes defined within the class).

These rules have implications for the use of `decltype`. (The following examples use the not-yet-accepted syntax for specifying the return type of a function after its declarator, but the questions apply to the current syntax as well.) Consider:

        struct deduced {
          int test() { return 0; }
          auto eval( deduced& d )->decltype( d.test() ) {
            return d.test();
          }
        };

7.6.1.5 [expr.ref] paragraph 1 requires that the class type of the object or pointer expression in a class member access expression be complete, so this usage is ill-formed.

A related issue is the use of `this` in a `decltype` specifier:

        struct last_one {
          int test() { return 0; }
          auto eval()->decltype( this->test() ) {
            return test();
          }
        };

_N4868_.11.4.3.2 [class.this] paragraph 1 allows use of `this` only in the body of a non-static member function, and the return type is not part of the function-body.

Do we want to change the rules to allow these kinds of `decltype` expressions?

Rationale (February, 2008):

In the other cases where a class type is considered complete within the definition of the class, it is possible to defer handling the construct until the end of the definition. That is not possible for types, as the type may be needed immediately in subsequent declarations.

It was also noted that the primary utility of `decltype` is in generic contexts; within a single class definition, other mechanisms are possible (e.g., use of a member typedef in both the declaration of the operand of the `decltype` and to replace the `decltype` itself).

#### 669. Confusing specification of the meaning of `decltype`

Section: 9.2.9.3 [dcl.type.simple] Status: NAD Submitter: Vera Lychagina Date: 17 December 2007

The first bullet of 9.2.9.3 [dcl.type.simple] paragraph 4 says,

- if `e` is an id-expression or a class member access (7.6.1.5 [expr.ref]), `decltype(e)` is the type of the entity named by `e`.

There are two clarifications to this specification that would assist the reader. First, it would be useful to have a note highlighting the point that a parenthesized expression is neither an id-expression nor a member access expression.

Second, the phrase “the type of the entity named by `e`” is unclear as to whether cv-qualification in the object or pointer expression is or is not part of that type. Rephrasing this to read, “the declared type of the entity,” or adding “(ignoring any cv-qualification in the object expression or pointer expression),” would clarify the intent.

Rationale (February, 2008):

The text is clear enough. In particular, both of these points are illustrated in the last two lines of the example contrasting `decltype(a->x)` and `decltype((a->x))`: in the former, the expression has no parentheses, thus satisfying the requirements of the first bullet and yielding the declared type of `A::x`, while the second has parentheses, falling into the third bullet and picking up the `const` from the object expression in the member access.

#### 706. Use of `auto` with rvalue references

Section: 9.2.9.7 [dcl.spec.auto] Status: NAD Submitter: Jonathan Caves Date: 1 Aug, 2008

Because type deduction for the `auto` specifier is described in 9.2.9.7 [dcl.spec.auto] paragraph 6 as equivalent to the deduction that occurs in a call to a function template, the adjustment of the argument type from `A` to `A&` specified in 13.10.3.2 [temp.deduct.call] paragraph 3 is performed when the initializer is an lvalue. As a result, in the following example, `ra` has the type `A&` and not, as might be expected, `A&&`:

        class A { };

        void f() {
           A a;
           auto&& ra = a;
        }

It is unclear whether this is surprising enough, and potentially widely-enough used, to warrant making an exception to the current rules to handle this case differently.

Rationale (September, 2008):

It is important that the deduction rules be the same in the function and `auto` cases. The result of this example might be surprising, but maintaining a consistent model for deduction is more important.

#### 1564. Template argument deduction from an initializer list

Section: 9.2.9.7 [dcl.spec.auto] Status: NAD Submitter: Faisal Vali Date: 2012-10-09

An initializer list is treated differently in deducing the type of an `auto` specifier and in a function call. In 9.2.9.7 [dcl.spec.auto] paragraph 6, an initializer list is given special treatment so that `auto` is deduced as a specialization of `std::initializer_list`:

> Once the type of a declarator-id has been determined according to 9.3.4 [dcl.meaning], the type of the declared variable using the declarator-id is determined from the type of its initializer using the rules for template argument deduction. Let `T` be the type that has been determined for a variable identifier `d`. Obtain `P` from `T` by replacing the occurrences of `auto` with either a new invented type template parameter `U` or, if the initializer is a braced-init-list (9.5.5 [dcl.init.list]), with `std::initializer_list<U>`. The type deduced for the variable `d` is then the deduced `A` determined using the rules of template argument deduction from a function call (13.10.3.2 [temp.deduct.call]), where `P` is a function template parameter type and the initializer for `d` is the corresponding argument.

In a function call, however, an initializer-list argument is a non-deduced context:

> Template argument deduction is done by comparing each function template parameter type (call it `P`) with the type of the corresponding argument of the call (call it `A`) as described below. If removing references and cv-qualifiers from `P` gives `std::initializer_list<P'>` for some P' and the argument is an initializer list (9.5.5 [dcl.init.list]), then deduction is performed instead for each element of the initializer list, taking P' as a function template parameter type and the initializer element as its argument. Otherwise, an initializer list argument causes the parameter to be considered a non-deduced context (13.10.3.6 [temp.deduct.type]). [Example:

>       template<class T> void f(std::initializer_list<T>);
>       f({1,2,3});          // T deduced to int
>       f({1,"asdf"});       // error: T deduced to both int and const char*

>       template<class T> void g(T);
>       g({1,2,3});          // error: no argument deduced for T

This seems inconsistent, but it is not clear in which direction the inconsistency should be resolved. The use of an initializer list in a range-based `for` is an argument in favor of the 9.2.9.7 [dcl.spec.auto] treatment, but the utility of this deduction in other contexts is not apparent.

Rationale (October, 2012):

CWG felt that this language design question would be better considered by EWG.

Additional note, April, 2015:

EWG has decided not to make a change in this area. See EWG issue 109.

#### 1725. Trailing return type with nested function declarator

Section: 9.2.9.7 [dcl.spec.auto] Status: NAD Submitter: Richard Smith Date: 2013-08-01

The treatment of a declaration like the following is not clear:

       auto (*f())() -> int; // #1

9.3.4.6 [dcl.fct] paragraph 2 appears to require determining the type of the nested declarator

       auto (*f()); // #2

which, because it does not have a trailing-return-type, would be ill-formed by (C++11) 9.2.9.7 [dcl.spec.auto]. (In C++14, an `auto` return type without a trailing-return-type is, of course, permitted.)

Rationale (September, 2013):

The intent of the C++11 wording is that the requirement for a trailing return type applies only at the top level of the declarator to which `auto` applies, not to each possible recursive stage in the declarator processing. Also, as noted, the issue becomes moot with the changes enabling return type deduction.

#### 1957. `decltype(auto)` with direct-list-initialization

Section: 9.2.9.7 [dcl.spec.auto] Status: NAD Submitter: Vinny Romano Date: 2014-06-30

Paper N3922 changed the rules for deduction from a braced-init-list containing a single expression in a direct-initialization context. Should a corresponding change be made for `decltype(auto)`? E.g.,

      auto x8a = { 1 };           // decltype(x8a) is std::initializer_list<int>
      decltype(auto) x8d = { 1 }; // ill-formed, a braced-init-list is not an expression
      auto x9a{ 1 };              // decltype(x9a) is int
      decltype(auto) x9d{ 1 };    // decltype(x9d) is int

See also issue 1467, which also effectively ignores braces around a single expression, this change would be parallel to that one, even though the primary motivation for `delctype(auto)` is in the return type of a forwarding function, where direct-initialization does not apply.

Rationale (November, 2014):

CWG felt that this was a question of language design and thus more properly dealt with by EWG.

EWG 2022-11-11

This is a request for a new feature, which should be proposed in a paper to EWG.

#### 2060. Deduced return type for explicit specialization

Section: 9.2.9.7 [dcl.spec.auto] Status: NAD Submitter: John Spicer Date: 2014-12-15

The Standard does not indicate whether an explicit specialization of a function template can have a deduced return type. It seems a bit too much to require parsing the entire function body in order to tell which template is being specialized. In extreme cases, that could mean deferring access checks for the entire body of the function.

Rationale (May, 2015):

An explicit specialization with a deduced return type can only match a template declared with a deduced return type, so the actual return type is not needed in order to match the explicit specialization with the template being specialized.

#### 2453. Deduced return types and coroutine lambdas

Section: 9.2.9.7.1 [dcl.spec.auto.general] Status: NAD Submitter: Lewis Baker Date: 2020-02-14

According to 9.2.9.7.1 [dcl.spec.auto.general] paragraph 15,

> A function declared with a return type that uses a placeholder type shall not be a coroutine (9.6.4 [dcl.fct.def.coroutine]).

This should also apply to coroutine lambdas.

Rationale (July, 2020):

No change is needed. The restriction applies to functions, and the lambda's `operator()` is a function.

#### 736. Is the `&` ref-qualifier needed?

Section: 9.3 [dcl.decl] Status: NAD Submitter: Alberto Ganesh Barbati Date: 16 October, 2008

Do we really need the `&` ref-qualifier? We could get the same behavior without it if we relaxed the restriction on ref-qualified and non-ref-qualified overloads in the same set:

with the `&` ref-qualifier | without the `&` ref-qualifier
        struct S {
          void f();
        };
        struct S {
          void f();
        };
        struct S {
          void f() &;
        };
        struct S {
          void f();
          void f() && = delete;
        };
        struct S {
          void f() &&;
        };
        struct S {
          void f() &&;
        };
        struct S {
          void f() &;
          void f() &&;
        };
        struct S {
          void f();
          void f() &&;
        };

The main objection I can see to this change is that we would lose the notational convenience of the `&` ref-qualifier, which would need to be replaced by a pair of declarations. We might overcome this by still allowing a single `&` on a function (although it would not be a ref-qualifier) as a synonym to a non-ref-qualified declaration plus a deleted ref-qualified declaration.

The biggest asymmetry between the implicit object parameter and regular parameters is not in reference binding but in type deduction. Consider:

        template <class R, class C, class A> void f(R (C::*p)(A));

With these members:

        struct S {
           void mv(std::string);
           void mr(std::string&);
           void ml(std::string&&);
        };

then

        f(&S::mv); // deduces A = string
        f(&S::mr); // deduces A = string&
        f(&S::ml); // deduces A = string&&

On the other hand, with these members:

        struct S {
           void mv(std::string);
           void mr(std::string) &;
           void ml(std::string) &&
        };

then

      f(&S::mv); // deduces C = S
      f(&S::mr); // illegal
      f(&S::ml); // illegal

To make template `f` work with any pointer to member function, I need three overloads of `f`. Add cv-qualifiers and it's twelve overloads!

And then there is the interaction with concepts. Consider this type:

        struct Value {
            Value& operator=(const Value&) &;
        };

Is it, say, `Regular`? If so, will the following compile, and what is the outcome?

        template <Regular T> void f() {
          T() = T();
        }

        void g() {
          f<Value>();
        }

If `Value` is not `Regular`, that is a good motivation to avoid ever using `&` ref-qualifiers on `operator=` (and probably on any member functions).

If `Value` is `Regular`, then either `f<Value>()` doesn't compile, violating one of the principal motivations for concepts, or it calls `Value::operator=` on an rvalue, which was explicitly prohibited.

Rationale, March, 2009:

The CWG did not feel that the suggested change was a signficant improvement over the existing specification.

#### 2036. Refactoring parameters-and-qualifiers

Section: 9.3 [dcl.decl] Status: NAD Submitter: Jonathan Caves Date: 2014-11-05

The production for parameters-and-qualifiers is long and will be even longer with the changes for the Transactional Memory TS. It might be beneficial to refactor it into more manageable chunks.

Rationale (May, 2015):

CWG felt that recent changes to the grammar are sufficient.

#### 333. Ambiguous use of "declaration" in disambiguation section

Section: 9.3.3 [dcl.ambig.res] Status: NAD Submitter: Michiel Salters Date: 14 Jan 2002

In deciding whether a construct is an object declaration or a function declaration, 9.3.3 [dcl.ambig.res] contains the following gem: "In that context, the choice is between a function declaration [...] and an object declaration [...] Just as for the ambiguities mentioned in 8.11 [stmt.ambig], the resolution is to consider any construct that could possibly be a declaration a declaration."

To what declaration do the last two "declarations" refer? Object, function, or (following from the syntax) possibly parameter declarations?

Notes from the 4/02 meeting:

This is not a defect. Section 9.3.3 [dcl.ambig.res] reads:

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

The wording "any construct" in the last sentence is not limited to top-level constructs. In particular, the function declaration encloses a parameter declaration, whereas the object declaration encloses an expression. Therefore, in case of ambiguity between these two cases, the declaration is parsed as a function declaration.

#### 340. Unclear wording in disambiguation section

Section: 9.3.3 [dcl.ambig.res] Status: NAD Submitter: Bart v Ingen Schenau Date: 27 Feb 2002

Consider the following program:

      struct Point
      {
        Point(int){}
      };
      struct Lattice
      {
        Lattice(Point, Point, int){}
      };
      int main(void)
      {
        int a, b;
        Lattice latt(Point(a), Point(b), 3);   /* Line X */
      }

The problem concerns the line marked `/* Line X */`, which is an ambiguous declarations for either an object or a function. The clause that governs this ambiguity is 9.3.3 [dcl.ambig.res] paragraph 1, and reads:

> The ambiguity arising from the similarity between a function-style cast and a declaration mentioned in 8.11 [stmt.ambig] can also occur in the context of a declaration. In that context, the choice is between a function declaration with a redundant set of parentheses around a parameter name and an object declaration with a function-style cast as the initializer. Just as for the ambiguities mentioned in 8.11 [stmt.ambig], the resolution is to consider any construct that could possibly be a declaration a declaration. [Note: a declaration can be explicitly disambiguated by a nonfunction-style cast, by a `=` to indicate initialization or by removing the redundant parentheses around the parameter name. ]

Based on this clause there are two possible interpretations of the declaration in line X:

1. The declaration of latt declares a function with a return value of the type Lattice and taking three arguments. The type of the first two arguments is Point and each of these arguments is followed by a parameter name in redundant parentheses. The type of the third argument can not be determined, because it is a literal. This will result in a syntax error.
2. The declaration of latt declares an object, because the other option (a function declaration) would result in a syntax error.

Note that the last sentence before the "[Note:" is not much help, because both options are declarations.

Steve Adamczyk: a number of people replied to this posting on comp.std.c++ saying that they did not see a problem. The original poster replied:

I can't do anything but agree with your argumentation. So there is only one correct interpretation of 9.3.3 [dcl.ambig.res] paragraph 1, but I have to say that with some rewording, the clause can be made a lot clearer, like stating explicitly that the entire declaration must be taken into account and that function declarations are preferred over object declarations.

I would like to suggest the following as replacement for the current 9.3.3 [dcl.ambig.res] paragraph 1:

> The ambiguity arising from the similarity between a functionstyle cast and a declaration mentioned in 8.11 [stmt.ambig] can also occur in the context of a declaration. In that context, the choice is between a function declaration with a redundant set of parentheses around a parameter name and an object declaration with a function-style cast as the initializer. The resolution is to consider any construct that could possibly be a function declaration a function declaration. [Note: To disambiguate, the whole declaration might have to be examined to determine if it is an object or a function declaration.] [Note: a declaration can be explicitly disambiguated by a nonfunction-style cast, by a `=` to indicate initialization or by removing the redundant parentheses around the parameter name. ]

Notes from the 4/02 meeting:

The working group felt that the current wording is clear enough.

#### 1867. Function/expression ambiguity with qualified parameter name

Section: 9.3.3 [dcl.ambig.res] Status: NAD Submitter: Richard Smith Date: 2014-02-12

In an example like,

      namespace N { enum E { X }; }
      struct S { S(N::E); };
      S s(S(N::X));

the last line disambiguates as an (ill-formed) function declaration, because the restriction requiring unqualified parameter names is semantic, not syntactic. Should the language be changed to use the presence of a qualified-id in this case as disambiguation? There is implementation divergence in the handling of this example.

Rationale (June, 2014):

CWG noted that the grammar change to allow disambiguation based on the parameter name being qualified is large, so the cost outweighs the relatively small benefit for disambiguating this particular corner case.

#### 1970. Ambiguity resolution for `(T())*x`

Section: 9.3.3 [dcl.ambig.res] Status: NAD Submitter: Richard Smith Date: 2014-07-15

The disambiguation of a fragment like

      (T())*x

where `T` is a type and `x` is a variable, is unclear. Is it a cast to type `T()` of the expression `*x`, or is it a binary operator `*` multiplying a value-initialized `T` by `x`? Current implementations treat it as the former, which is not helpful since the specified type is a function type and thus always ill-formed.

Rationale (November, 2014):

According to 9.3.3 [dcl.ambig.res], `T()` is to be taken as a function type, so the cast interpretation is correct, and one of the examples in this section is very nearly exactly this case.

#### 504. Should use of a variable in its own initializer require a diagnostic?

Section: 9.3.4.3 [dcl.ref] Status: NAD Submitter: Bjarne Stroustrup Date: 14 Apr 2005

Split off from issue 453.

It is in general not possible to determine at compile time whether a reference is used before it is initialized. Nevertheless, there is some sentiment to require a diagnostic in the obvious cases that can be detected at compile time, such as the name of a reference appearing in its own initializer. The resolution of issue 453 originally made such uses ill-formed, but the CWG decided that this question should be a separate issue.

Rationale (October, 2005):

The CWG felt that this error was not likely to arise very often in practice. Implementations can warn about such constructs, and the resolution for issue 453 makes executing such code undefined behavior; that seemed to address the situation adequately.

Note (February, 2006):

Recent discussions have suggested that undefined behavior be reduced. One possibility (broadening the scope of this issue to include object declarations as well as references) was to require a diagnostic if the initializer uses the value, but not just the address, of the object or reference being declared:

        int i = i;        // Ill-formed, diagnostic required
        void* p = &p;     // Okay

Rationale (2023-05-12)

This is an extension whose detailed specification requires a paper targeted at EWG. Some implementations warn about the situation in question.

#### 478. May a function parameter be an array of an abstract class type?

Section: 9.3.4.5 [dcl.array] Status: NAD Submitter: Steve Adamczyk Date: 28 Sep 2004

Consider the following example:

        struct S {
          virtual void v() = 0;
        };

        void f(S sa[10]);     // permitted?

9.3.4.5 [dcl.array] paragraph 1 says that a declaration like that of `sa` is ill-formed:

> `T` is called the array element type; this type shall not be a reference type, the (possibly cv-qualified) type `void`, a function type or an abstract class type.

On the other hand, 9.3.4.6 [dcl.fct] paragraph 3 says that the type of `sa` is adjusted to `S*`, which would be permitted:

> The type of each parameter is determined from its own decl-specifier-seq and declarator. After determining the type of each parameter, any parameter of type “array of `T`” or “function returning `T`” is adjusted to be “pointer to `T`” or “pointer to function returning `T`,” respectively.

It is not clear whether the parameter adjustment trumps the prohibition on declaring an array of an abstract class type or not. Implementations differ in this respect: EDG 2.4.2 and MSVC++ 7.1 reject the example, while g++ 3.3.3 and Sun Workshop 8 accept it.

Rationale (April, 2005):

The prohibition in 9.3.4.5 [dcl.array] is absolute and does not allow for exceptions. Even though such a type in a parameter declaration would decay to an allowed type, the prohibition applies to the type before the decay.

This interpretation is consistent with the resolution of issue 337, which causes template type deduction to fail if such types are deduced. It was also observed that pointer arithmetic on pointers to abstract classes is very likely to fail, and the fact that the programmer used array notation to declare the pointer type is a strong indication that he/she expected to use subscripting.

#### 1222. Unnecessary restriction on `auto` array types

Section: 9.3.4.5 [dcl.array] Status: NAD Submitter: Michael Wong Date: 2010-11-08

According to 9.3.4.5 [dcl.array] paragraph 1,

> In a declaration `T D` where `D` has the form

> `D1 [` constant-expressionopt `]` attribute-specifieropt

> and the type of the identifier in the declaration `T D1` is “derived-declarator-type-list `T`”, then the type of the identifier of `D` is an array type; if the type of the identifier of `D` contains the `auto` type-specifier, the program is ill-formed.

This has the effect of prohibiting a declaration like

        int v[1];
        auto (*p)[1] = &v;

This restriction is unnecessary and presumably unintentional.

Note also that the statement that “the type of the identifier of `D` is an array type” is incorrect when the nested declarator is not simply a declarator-id. A similar problem exists in the wording of 9.5.4 [dcl.init.ref] paragraph 3 for function types.

Rationale (March, 2011):

The functionality of the `auto` specifier was intentionally restricted to simple cases; supporting complex declarators like this was explicitly discussed and rejected when the feature was adopted.

#### 1761. Runtime check on size of automatic array

Section: 9.3.4.5 [dcl.array] Status: NAD Submitter: USA Date: 2013-09-23
N3690 comment US 10

The runtime check for violating the maximum size of a stack-based array object is ill-advised. Many implementations cannot easily determine the available stack space, and checking against a fixed limit is not helpful.

Proposed resolution (September, 2013):

Change 9.3.4.5 [dcl.array] paragraph 1 as follows:

> ...The expression is erroneous if:

> - its value before converting...

> - its value is such that the size of the allocated object would exceed the implementation-defined limit for the maximum size of an object (Annex Clause Annex B [implimits]);

> - ...

> ...If the expression is erroneous, an exception of a type that would match a handler (14.4 [except.handle]) of type `std::bad_array_length` (_N3690_.18.6.2.2 [bad.array.length]) is thrown [Footnote: Implementations are encouraged also to throw such an exception if the size of the object would exceed the remaining stack space. —end footnote].

This resolution also resolves issue 1675.

#### 1768. Zero-element array of runtime bound

Section: 9.3.4.5 [dcl.array] Status: NAD Submitter: USA Date: 2013-09-24
N3690 comment US 9

C-style variable-length arrays (which have been widely implemented as extensions to C++) permit a zero-length array. Similarly, arrays created by new-expressions can have a length of zero. Forbidding zero-length arrays of runtime bound is a gratuitous incompatibility.

Proposed resolution (September, 2013):

1. Change 9.3.4.5 [dcl.array] paragraph 1 as follows:

> ...The expression is erroneous if:

> - its value before converting to `std::size_t` or, in the case of an expression of class type, before application of the second standard conversion (12.2.4.2.3 [over.ics.user]) is less than or equal to zero;

> - ...

> If the expression, after converting to `std::size_t`, is a core constant expression and the expression is erroneous or its value is zero, the program is ill-formed. If the expression... `std::bad_array_length` (_N3690_.18.6.2.2 [bad.array.length]) is thrown. An object of array type If `N` is zero, an object of array type has no elements. Otherwise, it contains a contiguously allocated non-empty set of `N` subobjects of type `T`. The type...

Rationale (February, 2014):

The specification was removed from the WP and moved into a Technical Specification.

#### 18. f(TYPE) where TYPE is void should be allowed

Section: 9.3.4.6 [dcl.fct] Status: NAD Submitter: unknown Date: unknown

9.3.4.6 [dcl.fct] paragraph 2 says:

> If the parameter-declaration-clause is empty, the function takes no arguments. The parameter list `(void)` is equivalent to the empty parameter list.

Can a typedef to void be used instead of the type void in the parameter list?

Rationale: The IS is already clear that this is not allowed.

#### 1389. Recursive reference in trailing-return-type

Section: 9.3.4.6 [dcl.fct] Status: NAD Submitter: Daniel Krügler Date: 2011-09-04

There doesn't appear to be an explicit prohibition of a function declaration of the form

        auto f() -> decltype(f());

Presumably there should be.

Rationale (February, 2012):

As noted in issue 1433, the point of declaration of the function name is after the complete declarator, i.e., after the trailing return type, so the recursion posited in this issue cannot occur.

#### 66. Visibility of default args vs overloads added after using-declaration

Section: 9.3.4.7 [dcl.fct.default] Status: NAD Submitter: Mike Miller Date: 6 Oct 1998

Paragraph 9 of says that extra default arguments added after a using-declaration but before a call are usable in the call, while 9.10 [namespace.udecl] paragraph 9 says that extra function overloads are not. This seems inconsistent, especially given the similarity of default arguments and overloads.

Rationale (10/99): The Standard accurately reflects the intent of the Committee.

#### 1443. Default arguments and non-static data members

Section: 9.3.4.7 [dcl.fct.default] Status: NAD Submitter: Jason Merrill Date: 2012-01-13

Consider:

        struct A {
           int i;
           A() { void foo(int=i); }
        };

It's not clear whether that is well-formed or not. It uses `this`, which might be thought of as a kind of parameter or local variable, which would make the default argument ill-formed. On the other hand, there doesn't seem to be a good reason to ban the code, either.

Rationale (February, 2012):

9.3.4.7 [dcl.fct.default] paragraphs 8-9 should be interpreted as making the example ill-formed.

#### 1339. Parenthesized braced-init-list and arrays

Section: 9.5 [dcl.init] Status: NAD Submitter: Jason Merrill Date: 2011-08-03

The resolution of issue 1214 makes it ill-formed to use an initializer of the form `({...})` with a variable of a non-class type. This can cause problems with a mem-initializer of the form

      constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}

If `pthread_cond_t` is an array, `PTHREAD_COND_INITIALIZER` will be a braced-init-list and the mem-initializer will be ill-formed.

Rationale (August, 2011):

A non-static data member initializer can be used in this case.

#### 1434. Parenthesized braced-init-list

Section: 9.5 [dcl.init] Status: NAD Submitter: Daniel Krügler Date: 2011-12-21

The semantics of a parenthesized braced-init-list are not clear, whether appearing as a mem-initializer or standalone.

Rationale (February, 2012):

CWG feels that the semantics are sufficiently clear without any changes to the current wording.

#### 1578. Value-initialization of aggregates

Section: 9.5 [dcl.init] Status: NAD Submitter: Alisdair Meredith Date: 2012-10-21

The resolution of issue 1301 changed the status of `T{}`, where `T` is an aggregate, from being value-initialization to being aggregate initialization. This change breaks the description of `DefaultConstructible` in 16.4.4.2 [utility.arg.requirements] Table 19. LWG has opened an issue for this (2170) but would like CWG to consider a core approach that would categorize `T{}` as value initialization, even when `T` is an aggregate.

Rationale (April, 2013):

There is a distinction in the core language between aggregate initialization and value initialization. For example, a class with a deleted default constructor can be list-initialized via aggregate initialization but not value-initialized.

#### 2709. Parenthesized initialization of reference-to-aggregate

Section: 9.5.1 [dcl.init.general] Status: NAD Submitter: Mike Miller Date: 2023-03-14 Liaison: EWG

Paper P0960R3 enabled initialization of aggregates (including arrays) from parenthesized expression lists. The rather similar case of initializating a reference to an aggregate was not addressed. For example:

      const int (&ra)[2](1,2);

There is no evidence in 9.5.1 [dcl.init.general] paragraph 16 that such support is intended, nor does 9.5.4 [dcl.init.ref] paragraph 5 admit an initializer other than a (single) expression for a reference.

There is implementation divergence: gcc accepts, others reject. Also, the parenthesized aggregate initialization paper P0960R3 apparently originally envisioned a textual transformation to a braced-init-list, which presumably would have permitted the example. It is not clear whether the reference case was intentionally or accidentially dropped during the multiple revisions of the paper.

Additional notes (March, 2023)

Forwarded to EWG for consideration via cplusplus/papers#1494 by decision of the CWG chair.

EWG 2023-05-11

It was noted that an attempt to initialize a reference-to-class type using a parenthesized expression-list is also ill-formed even if the class has a suitable constructor. Since parenthesized aggregate initialization was modeled after a constructor invocation for aspects such as temporary lifetimes, the status quo seems consistent in that regard.

#### 1097. Aggregate initialization of function parameters

Section: 9.5.2 [dcl.init.aggr] Status: NAD Submitter: Daniel Krügler Date: 2010-07-29

The current wording of the WP allows aggregate initialization of parameters in function calls. For example, 12.2.4.2.6 [over.ics.list] paragraph 4 reads:

> Otherwise, if the parameter has an aggregate type which can be initialized from the initializer list according to the rules for aggregate initialization (9.5.2 [dcl.init.aggr]), the implicit conversion sequence is a user-defined conversion sequence. [Example:

>       struct A {
>         int m1;
>         double m2;
>       };

>       void f(A);
>       f( {'a', 'b'} );  // OK: f(A(int,double)) user-defined conversion
>       f( {1.0} );       // error: narrowing

> —end example]

The rules for aggregate initialization in 9.5.2 [dcl.init.aggr] paragraph 11 allow braces to be elided in the initializer

> In a declaration of the form

>       T x = { a };

It is not clear whether this phrasing should be interpreted as allowing brace elision only in a simple-declaration and thus not in a function argument or whether this restriction is inadvertent and should be removed.

Rationale (November, 2010):

The restriction is intentional. Support for aggregate initialization is principally intended for legacy code and C compatibility, not for code written using the new facilities of the language.

#### 1497. Aggregate initialization with parenthesized string literal

Section: 9.5.2 [dcl.init.aggr] Status: NAD Submitter: Daveed Vandevoorde Date: 2012-04-25

Existing practice appears to be to allow C++03-style aggregate initialization from a parenthesized string literal, e.g.,

      struct S {
        char arr[4];
      } s = {("abc")};

This should be standardized, to allow examples like

      struct S {
        char arr[4];
      };
      void f(S);
      void g() {
        f({("abc")});
      }

Rationale (October, 2012):

CWG agreed that this is already permitted by virtue of _N4567_.5.1.1 [expr.prim.general] paragraph 6.

#### 1985. Unknown bound array member with brace-or-equal-initializer

Section: 9.5.2 [dcl.init.aggr] Status: NAD Submitter: Hubert Tong Date: 2014-08-09

The correct interpretation of an example like the following is not clear:

      struct A {
        int x[] = { 0 };
      };

Should the initializer be considered as implicitly determining the omitted array bound?

Rationale (November, 2014):

The requirement for determining an omitted bound in an aggregate is that it be “initialized” (9.5.5 [dcl.init.list] paragraph 4); since the brace-or-equal-initializer might, in fact, be ignored in some or all uses of the class, it should not be considered as definitively initializing the member and thus does not determine the array bound. Clarification of this intent could be done editorially, but CWG felt that no normative change was required.

#### 2408. Temporaries and previously-initialized elements in aggregate initialization

Section: 9.5.2 [dcl.init.aggr] Status: NAD Submitter: Daveed Vandevoorde Date: 2019-03-13

There is implementation divergence with respect to an example like:

      constexpr int f(int &r) { r *= 9; return r - 12; }
      struct A { int &&temporary; int x; int y; };

      constexpr A a1 = { 6, f(a1.temporary), a1.temporary }; // #1

Some implementations accept this code and others say that `a1.temporary` is not a constant expression in the initializer at #1.

Rationale (July, 2019)

The example is valid; the constant evaluation is the entire initialization `constexpr A a1`, thus the temporary bound to `a1.temporary` started its lifetime within the constant evaluation.

#### 434. Unclear suppression of standard conversions while binding reference to lvalue

Section: 9.5.4 [dcl.init.ref] Status: NAD Submitter: Bronek Kozicki Date: 14 September 2003

In section 9.5.4 [dcl.init.ref], paragraph 5, there is following note:

> Note: the usual lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are not needed, and therefore are suppressed, when such direct bindings to lvalues are done.

I believe that this note is misleading. There should be either:

- no note, and leave this issue to be explained in section 4 only
- explicit list of all suppressed conversions (including pointer qualification conversion, as covered in section 4.4)
- reminder that result of all standard conversions is never an lvalue, thus these conversions are suppressed when binding reference to lvalue

The problem:

1. under current wording it's unclear if following code is legal, or not:

       int main()
       {
         const int ci = 10;
         int * pi = NULL;
         const int * & rpci = pi;
         rpci = &ci;
         *pi = 12; // circumvent constness of "ci"
       }

2. it is also unclear what behaviour should following program expose:

       int main()
       {
         int * pi = NULL;
         const int * const & rcpci = pi; // 1
         int i = 0;
         pi = &i; // 2
         if (pi == rcpci)
           std::cout << "bound to lvalue" << std::endl;
         else
           std::cout << "bound to temporary rvalue" << std::endl;
       }

There has been discussion on this issue on comp.lang.c++.moderated month ago, see http://groups.google.pl/groups?threadm=9bed99bb.0308041153.1c79e882%40posting.google.com and there seems to be some confusion about it. I understand that note is not normative, but apparently even some compiler writers are misled (try above code snippets on few different compilers, and using different compilation options - notably GCC 3.2.3 with -Wall -pedantic), thus it should be cleared up.

My proposal is to change wording of discussed note to:

> Note: result of every standard conversion is never an lvalue, and therefore all standard conversions (clause 4) are suppressed, when such direct bindings to lvalues are done.

Rationale (April, 2005):

As acknowledged in the description of the issue, the referenced text is only a note and has no normative impact. Furthermore, the examples cited do not involve the conversions mentioned in the note, and the normative text is already sufficiently clear that the types in the examples are not reference-compatible.

#### 1058. Reference binding of incompatible array types

Section: 9.5.4 [dcl.init.ref] Status: NAD Submitter: Johannes Schaub Date: 2010-03-20

According to the logic in 9.5.4 [dcl.init.ref] paragraph 5, the following example should create a temporary array and bind the reference to that temporary:

        const char (&p)[10] = "123";

That is presumably not intended (issue 450 calls a similar outcome for rvalue arrays “implausible”). Current implementations reject this example.

Rationale (August, 2010):

The Standard does not describe initialization of array temporaries, so a program that requires such is ill-formed.

Note (October, 2010):

Although in general an object of array type cannot be initialized from another object of array type, there is special provision in 9.5.3 [dcl.init.string] for doing so when the source object is a string literal, as in this example. The issue is thus being reopened for further consideration in this light.

Notes from the November, 2010 meeting:

The CWG agreed that the current wording appears to permit this example but still felt that array temporaries are undesirable. Wording should be added to disallow this usage.

Proposed resolution (November, 2010):

Change 9.5.4 [dcl.init.ref] paragraph 5 as follows:

- ...

- If the initializer expression is a string literal (5.13.5 [lex.string]), the program is ill-formed.

- Otherwise, a temporary of type...

(See also issue 1232, which argues in favor of allowing array temporaries.)

Rationale (March, 2011):

In consideration of the arguments made in issue 1232, CWG agreed to allow array temporaries and there is thus no reason to prohibit them in this case.

#### 1263. Mismatch between rvalue reference binding and overload resolution

Section: 9.5.4 [dcl.init.ref] Status: NAD Submitter: Johannes Schaub Date: 2011-03-18

#### 1650. Class prvalues in reference initialization

Section: 9.5.4 [dcl.init.ref] Status: NAD Submitter: Michael Wong Date: 2013-04-15

As described in the “additional note, January, 2012” in issue 1287, questions were raised regarding the treatment of class prvalues in the original proposed resolution and the proposed resolution was revised (February, 2012) to address those concerns. The revised resolution raised its own set of concerns with regard to slicing and performance, however, and the issue was moved back to "review" status to allow further discussion.

At the April, 2013 meeting, it was decided to proceed with the original resolution of issue 1287 and split off the concerns regarding class prvalues into this issue.

Notes from the September, 2013 meeting:

The resolution for issue 1604 results in indirect binding to a subobject and will no longer cause slicing.

Rationale (November, 2013):

CWG determined that, in light of the resolution of issue 1604, no further change was necessary.

#### 2111. Array temporaries in reference binding

Section: 9.5.4 [dcl.init.ref] Status: NAD Submitter: Vinny Romano Date: 2015-04-02

The current wording of the Standard appears to permit code like

      void f(const char (&)[10]);
      void g() {
        f("123");
        f({'a','b','c','\0'});
      }

creating a temporary array of ten elements and binding the parameter reference to it. This is controversial and should be reconsidered. (See issues 1058 and 1232.)

Rationale (March, 2016):

Whether to support creating a temporary array in such cases is a question of language design and thus should be considered by EWG.

EWG 2022-11-11

The intent is adequately expressed in the specification.

#### 982. Initialization with an empty initializer list

Section: 9.5.5 [dcl.init.list] Status: NAD Submitter: Daniel Krügler Date: 17 October, 2009

The exposition of list initialization using an array in 9.5.5 [dcl.init.list] paragraph 4 raises the question of whether an empty initializer list is permitted, as declaration of an array with a zero bound is ill-formed.

Rationale (October, 2009):

The description is intended as an aid to understanding the concepts, not as a literal transformation that is performed. An implementation is permitted to allocate a zero-length array, even if such as array cannot be decclared (e.g., via a new-expression).

#### 1078. Narrowing and the usual arithmetic conversions

Section: 9.5.5 [dcl.init.list] Status: NAD Submitter: Jason Merrill Date: 2010-06-14

Consider the example,

        struct A { char c; };
        void f (char d) {
           A a = { d + 1 };
        }

This code is now ill-formed because of the narrowing conversion from the `int` result type of the addition, not because of any real narrowing. This seems like an embarrassment for C++0x. It would be better not to get an error about any arithmetic involving non-constant operands just because it might overflow with some values.

Rationale (November, 2010):

The CWG agreed that this behavior is unfortunate but felt that it would be too difficult to formulate a satisfactory set of rules for handling complex expressions correctly for a small gain in utility (the user can simply add a cast in order to avoid the error).

#### 1379. Is `std::initializer_list` an aggregate?

Section: 9.5.5 [dcl.init.list] Status: NAD Submitter: Daniel Krügler Date: 2011-08-21

The Standard does not specify whether `std::initializer_list` may be an aggregate or not. Strictly speaking, the order of the bullets in 9.5.5 [dcl.init.list] paragraph 3 depends on the answer. The existence of a constructor declaration in 17.11 [support.initlist] suggests that it is not an aggregate but does not say so definitively.

Rationale (February, 2012):

The presence of the constructor declaration in 17.11 [support.initlist] is sufficient to establish that `std::initializer_list` is not an aggregate.

#### 1419. Evaluation order in aggregate initialization

Section: 9.5.5 [dcl.init.list] Status: NAD Submitter: Jason Merrill Date: 2011-11-22

Issue 1030 clarified that elements of an initializer-list are evaluated in the order they are written, but does that also apply to implied expressions? That is, given:

        struct A { A(); ~A(); };
        struct B { B(int, const A& = A()); ~B(); };
        struct C { B b1, b2; };
        int main() { C{1,2}; }

Do we know that the first `B` is constructed before the second `A`? I suppose that's what we want, even though it complicates exception region nesting since the `A`s need to live longer than the `B` subobject cleanups.

Rationale (October, 2012):

Because this is an expression, not a declaration, the `A`s live until the end of the full-expression.

#### 1421. Full expressions and aggregate initialization

Section: 9.5.5 [dcl.init.list] Status: NAD Submitter: Jason Merrill Date: 2011-12-03

Dealing with aggregate-initialized temporaries has been a bit of a headache because unlike aggregate initialization of variables, each element initialization is not a full-expression, so various things behave differently because they are in the context of initializing a temporary.

This can either be inconsistent with aggregate initialization of a variable (in which each element is a full-expression) or inconsistent with list-initialization via constructor (in which each element is a subexpression).

Rationale (October, 2012):

The rules are acceptable as written; declaration and expression contexts are different.

#### 1461. Narrowing conversions to bit-fields

Section: 9.5.5 [dcl.init.list] Status: NAD Submitter: Richard Corden Date: 2012-02-08

The definition of a “narrowing conversion” in 9.5.5 [dcl.init.list] paragraph 7 is couched in terms of the type of the target. A conversion to a too-small bit-field should presumably also be categorized as a narrowing conversion. (See also issue 1449.)

Additional note (August, 2012):

It was observed that the proposed narrowing error, unlike in other contexts, cannot be circumvented by adding a cast. The only way to avoid a narrowing error would be to avoid using the brace syntax or to mask the value to an appropriate width. Even the latter approach could conceivably require an implementation to track the maximum number of bits needed by operations applied on top of the masked value, unless the masking were required to be at the top level of the initializer expression.

Rationale (October, 2012):

CWG felt that this was more of a language design question and would be better considered by EWG.

Rationale (February, 2014):

EWG determined that no action should be taken on this issue.

#### 1501. Nested braces in list-initialization

Section: 9.5.5 [dcl.init.list] Status: NAD Submitter: Steve Adamczyk Date: 2012-05-04

The specification of list-initialization in 9.5.5 [dcl.init.list] paragraph 3 has a bullet that reads,

> Otherwise, if the initializer list has a single element of type `E` and either `T` is not a reference type or its referenced type is reference-related to `E`, the object or reference is initialized from that element

It is not clear what is meant by being “ initialized from the element.” If one assumes that it means “go back to 9.5 [dcl.init] and follow the logic ladder there with the element,” the logical result is that an initializer for a scalar could be arbitrarily deeply nested in braces, with each trip through the 9.5 [dcl.init] / 9.5.5 [dcl.init.list] recursion peeling off one layer. Presumably that is not intended.

Rationale (October, 2012):

The wording “a single element of type `E`” excludes the case of a nested braced initializer, because such an element has no type.

#### 1565. Copy elision and lifetime of `initializer_list` underlying array

Section: 9.5.5 [dcl.init.list] Status: NAD Submitter: Steve Adamczyk Date: 2012-10-10

If an `initializer_list` object is copied and the copy is elided, is the lifetime of the underlying array object extended? E.g.,

      void f() {
        std::initializer_list<int> L =
            std::initializer_list<int>{1, 2, 3}; // Lifetime of array extended?
      }

The current wording is not clear.

(See also issue 1299.)

Notes from the October, 2012 meeting:

The consensus of CWG was that the behavior should be the same, regardless of whether the copy is elided or not.

Rationale (November, 2016):

With the adoption of paper P0135R1, there is no longer any copy in this example to be elided.

#### 1864. List-initialization of array objects

Section: 9.5.5 [dcl.init.list] Status: NAD Submitter: Alisdair Meredith Date: 2014-02-15

The resolution of issue 1467 now allows for initialization of aggregate classes from an object of the same type. Similar treatment should be afforded to array aggregates.

Notes from the June, 2014 meeting:

This is a request for extended language facilities and thus should be evaluated by EWG.

EWG 2022-11-11

This is a request for a new feature that should be proposed in a paper to EWG.

#### 1984. Lossless narrowing conversions

Section: 9.5.5 [dcl.init.list] Status: NAD Submitter: Hubert Tong Date: 2014-08-13

According to 9.5.5 [dcl.init.list] bullet 7.3, an implicit conversion

> from an integer type or unscoped enumeration type to a floating-point type, except where the source is a constant expression and the actual value after conversion will fit into the target type and will produce the original value when converted back to the original type

is a narrowing conversion. There does not seem to be a good reason why a conversion from, for example, an unsigned char value to a floating point value should be considered to be narrowing, since floating point types should be able represent all the values.

Rationale (November, 2014):

CWG felt that type-based (in contrast to value-based) restrictions such as this should not depend on the platform-specific characteristics of the type, so the general rule should apply.

#### 1574. Explicitly-defaulted `constexpr` functions in wrapper templates

Section: 9.6.2 [dcl.fct.def.default] Status: NAD Submitter: Daniel Krügler Date: 2012-10-16

According to 9.6.2 [dcl.fct.def.default] paragraph 2,

> An explicitly-defaulted function may be declared `constexpr` only if it would have been implicitly declared as `constexpr`...

This is relevant for wrapper functions like

      template<class T> struct wrap {
        T t;
        constexpr wrap() = default;
        constexpr wrap(const wrap&) = default;
      };

It is not clear how the new wording for `constexpr` member functions of class templates in the proposed resolution issue 1358 affects this:

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

Rationale (April, 2013):

The specification is as intended. The defaulted constructor will be `constexpr` if it can be, so it should not be explicitly declared `constexpr` in order to avoid the problems mentioned.

#### 1217. Are deleted functions implicitly `noexcept`?

Section: 9.6.3 [dcl.fct.def.delete] Status: NAD Submitter: Daniel Krügler Date: 2010-11-10

It would seem intuitively that a deleted function cannot throw an exception, but 9.6.3 [dcl.fct.def.delete] does not mention that. This could conceivably be useful in SFINAE contexts.

Rationale (November, 2010):

Any reference to a deleted function is ill-formed, so it doesn't really matter whether they are `noexcept` or not.

#### 2308. Structured bindings and lambda capture

Section: 9.7 [dcl.struct.bind] Status: NAD Submitter: Richard Smith Date: 2016-07-23

Whether or not structured bindings can be captured by a lambda and, if so, with what semantics, is unclear from the current wording.

Rationale (March, 2018):

Paper P0588R1, adopted at the October, 2017 meeting, answers the question by explicitly prohibiting such captures.

#### 893. Brace syntax for enumerator-definitions

Section: 9.8.1 [dcl.enum] Status: NAD Submitter: Alisdair Meredith Date: 8 May, 2009

Although in most contexts “`=` expression” can be replaced by “`{` expression `}`”, enumerator-definitions accept only the “`=`” form. This could be surprising.

Additional note (October, 2009):

The Committee may wish to consider default arguments in this light as well.

Rationale (August, 2010):

This suggestion was considered and rejected by EWG.

#### 1317. Unnamed scoped enumerations

Section: 9.8.1 [dcl.enum] Status: NAD Submitter: John Spicer Date: 2011-05-12

The text of 9.8.1 [dcl.enum] paragraph 2 explicitly forbids unnamed scoped enumerations:

> The optional identifier shall not be omitted in the declaration of a scoped enumeration.

There does not appear to be a good rationale for this restriction since a typedef name can be used to name the enumerators. It is also inconsistent with similar constructs. For example,

        typedef enum class { e } E;
        E x = E::e;

is ill-formed, but

        typedef struct { enum { s }; } S;
        int y = S::s;

is well-formed.

Rationale (August, 2011):

The use of typedef names for linkage purposes is intended for C compatibility and should not be extended to features that are not part of the C subset of C++.

#### 1917. decltype-qualified enumeration names

Section: 9.8.1 [dcl.enum] Status: NAD Submitter: Daveed Vandevoorde Date: 2014-04-25

9.3.4 [dcl.meaning] paragraph 1 and Clause 11 [class] paragraph 11 prohibit decltype-qualified declarators and class names, respectively. There is no such prohibition in 9.8.1 [dcl.enum] for enumeration names. Presumably that is an oversight that should be rectified.

Rationale (February, 2021):

The resolution of issue 2156 includes the required prohibition.

#### 311. Using qualified name to reopen nested namespace

Section: 9.9.2 [namespace.def] Status: NAD Submitter: Bjarne Stroustrup Date: 18 Sep 2001

I received an inquiry/complaint that you cannot re-open a namespace using a qualified name. For example, the following program is ok, but if you uncomment the commented lines you get an error:

    namespace A {
        namespace N {
    	int a;
        }
        int b;
        namespace M {
    	int c;
        }
    }

    //namespace A::N {
    //    int d;
    //}

    namespace A {
        namespace M {
            int e;
        }
    }

    int main()
    {
        A::N::a = 1;
        A::b = 2;
        A::M::c = 3;
    //  A::N::d = 4;
        A::M::e = 5;
    }

Andrew Koenig: There's a name lookup issue lurking here. For example:

        int x;

        namespace A {
    	int x;
    	namespace N {
    	   int y;
    	};
        }

        namespace A::N {
            int* y = &x;  // which x?
        }

Jonathan Caves: I would assume that any rule would state that:

    namespace A::B {

would be equivalent to:

    namespace A {
       namespace B {

so in your example 'x' would resolve to A::x

BTW: we have received lots of bug reports about this "oversight".

Lawrence Crowl: Even worse is

        int x;
        namespace A {
          int x;
        }
        namespace B {
          int x;
          namespace ::A {
             int* y = &x;
          }
        }

I really don't think that the benefits of qualified names here is worth the cost.

Notes from April 2003 meeting:

We're closing this because it's on the Evolution working group list.

#### 1976. Ambiguity of namespace-aliases

Section: 9.9.3 [namespace.alias] Status: NAD Submitter: Richard Smith Date: 2014-07-20

Current implementations reject an example like:

      namespace X { int n; }
      namespace A = X;
      namespace { namespace A = X; }
      int k = A::n;

This seems curious, since a similar example with using-declarations or with alias-declarations is valid.

Rationale (November, 2014):

The current wording of the Standard makes this example ambiguous, and CWG did not find the similarities mentioned compelling enough to warrant a change.

#### 109. Allowing `::template` in using-declarations

Section: 9.10 [namespace.udecl] Status: NAD Submitter: Daveed Vandevoorde Date: 6 Apr 1999

Daveed Vandevoorde : While reading Core issue 11 I thought it implied the following possibility:

        template<typename T>
        struct B {
           template<int> void f(int);
        };

        template<typename T>
        struct D: B<T> {
           using B<T>::template f;
           void g() { this->f<1>(0); } // OK, f is a template
        };

However, the grammar for a using-declaration reads:

`using typenameopt ::opt nested-name-specifier unqualified-id ;`

and nested-name-specifier never ends in "`template`".

Is that intentional?

Bill Gibbons :

It certainly appears to be, since we have:

qualified-id:

`::opt nested-name-specifier templateopt unqualified-id`

so it would be easier to specify using-declaration as:

`using typenameopt qualified-id ;`

if the "`template`" keyword were allowed. There was a discussion about whether a dependent name specified in a using-declaration could be given an "is a type" attribute through the `typename` keyword; the decision was to allow this. But I don't recall if the "is a template" attribute was discussed.

Rationale (04/99): Any semantics associated with the `template` keyword in using-declarations should be considered an extension.

Notes from the April 2003 meeting:

See also issues 96 and 11.

We decided to make no change and to close this issue as not-a-defect. This is not needed functionality; the example above, for example, can be written with `->template`. This issue has been on the issues list for years as an extension, and there has been no clamor for it.

It was also noted that knowing that something is a template is not enough; there's still the issue of knowing whether it is a class or function template.

Additional note (February, 2011):

This issue is being reopened for further consideration after additional discussion; see messages 18492 through 18499. It was noted that, in addition to the workaround described above for the member function template case, the new alias template facility provides a workaround for the member class template case: instead of

        using T::template X;  // ill-formed

for a class template member `X` of base class `T`, one could write

        template<U> using X = typename T::template X<U>;

Rationale (March, 2011):

There was insufficient motivation for a change at this point.

#### 169. template-ids in using-declarations

Section: 9.10 [namespace.udecl] Status: NAD Submitter: Valentin Bonnard Date: 16 Sep 1999

9.10 [namespace.udecl]s ays,

> A using-declaration shall not name a template-id.

It is not clear whether this prohibition applies to the entity for which the using-declaration is a synonym or to any name that appears in the using-declaration. For example, is the following code well-formed?

        template <typename T>
        struct base {
    	void bar ();
        };

        struct der : base<int>
        {
    	using base<int>::bar; // ill-formed ?
        };

Rationale (10/99): 9.10 [namespace.udecl] paragraph 1 says, "A using-declaration introduces a name..." It is the name that is thus introduced that cannot be a template-id.

#### 1960. Visibility of entity named in class-scope using-declaration

Section: 9.10 [namespace.udecl] Status: NAD Submitter: Hubert Tong Date: 2014-07-04

According to 9.10 [namespace.udecl] paragraph 17,

> The base class members mentioned by a using-declaration shall be visible in the scope of at least one of the direct base classes of the class where the using-declaration is specified.

The rationale for this restriction is not clear and should be reconsidered.

Rationale (November, 2014):

The rule was introduced because the hiding of a base class member by an intermediate derived class is potentially intentional and should not be capable of circumvention by a using-declaration in a derived class. The consensus of CWG preferred not to change the restriction.

Additional note (November, 2020):

The changes in P1787R6, adopted at the November, 2020 meeting, removes the quoted wording, affirming the rationale in a different manner.

#### 461. Make `asm` conditionally-supported

Section: 9.11 [dcl.asm] Status: NAD Submitter: Clark Nelson Date: 24 May 2004

Now that the concept of "conditionally-supported" is available (see N1564), perhaps `asm` should not be required of every implementation.

Rationale (October, 2004):

This is covered in paper N1627. We would like to keep `asm` as a keyword for all implementations, however, to enhance portability by preventing programmers from inadvertently using it as an identifier.

#### 13. extern "C" for Parameters of Function Templates

Section: 9.12 [dcl.link] Status: NAD Submitter: John Spicer Date: unknown

[Picked up by evolution group at October 2002 meeting.]

How can we write a function template, or member function of a class template that takes a C linkage function as a parameter when the function type depends on one of the template parameter types?

        extern "C" void f(int);
        void g(char);

        template <class T> struct A {
            A(void (*fp)(T));
        };

        A<char> a1(g);  // okay
        A<int> a2(f);   // error

Another variant of the same problem is:

        extern "C" void f(int);
        void g(char);

        template <class T> void h( void (*fp)(T) );

        int main() {
            h(g);  // okay
            h(f);  // error
        }

Suggested resolution: (John Spicer)

Somehow permit a language linkage to be specified as part of a function parameter declaration. i.e.

        template <class T> struct A {
            A( extern "C" void (*fp)(T) );
        };

        template <class T> void h( extern "C" void (*fp)(T) );

Suggested resolution: (Bill Gibbons)

The whole area of linkage needs revisiting. Declaring calling convention as a storage class was incorrect to begin with; it should be a function qualifier, as in:

        void f( void (*pf)(int) c_linkage );

instead of the suggested:

        void f( extern "C" void (*pf)(int) );

I would like to keep calling convention on the "next round" issues list, including the alternative of using function qualifiers.

And to that end, I suggest that the use of linkage specifiers to specify calling convention be deprecated - which would make any use of linkage specifiers in a parameter declaration deprecated.

Martin Sebor: 9.12 [dcl.link], paragraph 4 says that "A linkage-specification shall occur only in namespace scope..." I'm wondering why this restriction is necessary since it prevents, among other things, the use of the functions defined `<cmath>` in generic code that involves function objects. For example, the program below is ill-formed since `std::pointer_to_binary_function<>` takes a pointer to a function with extern "C++" linkage which is incompatible with the type of the `double` overload of `std::pow`.

Relaxing the restriction to allow linkage specification in declarations of typedefs in class scope would allow `std::pointer_to_binary_function<>` ctor to be overloaded on both types (i.e., extern "C" and extern "C++"). An alternative would be to allow for the linkage specification to be deduced along with the type.

        #include <cmath>
        #include <functional>
        #include <numeric>

        int main () {
          double a[] = { 1, 2, 3 };
          return std::accumulate (a, a + 3, 2.0,
            std::pointer_to_binary_function<double, double, double>(std::pow));
        }

Rationale (February, 2014):

EWG determined that no action should be taken on this issue.

#### 14. extern "C" functions and declarations in different namespaces

Section: 9.12 [dcl.link] Status: NAD Submitter: Erwin Unruh Date: unknown

Issue 1

9.12 [dcl.link] paragraph 6 says the following:

extern "C" functions in multiple namespaces refer to the same function.

Is this only for linkage purposes or for both name look up and linkage purposes:

        extern "C" int f(void);
        namespace A {
             extern "C" int f(void);
        };
        using namespace A;

        int i = f(); // Ok because only one function f() or
                     // ill-formed

For name lookup, both declarations of f are visible and overloading cannot distinguish between them. Has the compiler to check that these functions are really the same function or is the program in error?

Rationale: These are the same function for all purposes.

Issue 2

A similar question may arise with typedefs:

        // vendor A
        typedef unsigned int size_t;
        // vendor B
        namespace std {
                typedef unsigned int size_t;
        }
        using namespace std;
        size_t something(); // error?

Is this valid because the typedef `size_t` refers to the same type in both namespaces?

Rationale (04/99): In 9.9.4 [namespace.udir] paragraph 4:

> If name lookup finds a declaration for a name in two different namespaces, and the declarations do not declare the same entity and do not declare functions, the use of the name is ill-formed.

The term entity applied to typedefs refers to the underlying type or class (6.1 [basic.pre] paragraph 3); therefore both declarations of `size_t` declare the same entity and the above example is well-formed.

#### 107. Linkage of operator functions

Section: 9.12 [dcl.link] Status: NAD Submitter: Stephen Clamage Date: 21 Apr 1999

[Picked up by evolution group at October 2002 meeting.]

Steve Clamage: I can't find anything in the standard that prohibits a language linkage on an operator function. For example:

>     extern "C" int operator+(MyInt, MyInt) { ... }

Clearly it is a bad idea, you could have only one `operator+` with "C" linkage in the entire program, and you can't call the function from C code.

Mike Miller: Well, you can't name an operator function in C code, but if the arguments are compatible (e.g., not references), you can call it from C code via a pointer. In fact, because the language linkage is part of the function type, you couldn't pass the address of an operator function into C code unless you could declare the function to be extern "C".

Fergus Henderson: In the general case, for linkage to languages other than C, this could well make perfect sense.

Steve Clamage:

But is it disallowed (as opposed to being stupid), and if so, where in the standard does it say so?

Mike Miller: I don't believe there's a restriction. Whether that is because of the (rather feeble) justification of being able to call an operator from C code via a pointer, or whether it was simply overlooked, I don't know.

Fergus Henderson: I don't think it is disallowed. I also don't think there is any need to explicitly disallow it.

Steve Clamage: I don't think the standard is clear enough on this point. I'd like to see a clarification.

I think either of these two clarifications would be appropriate:

1. A linkage specification on an operator function is ill-formed.
2. A linkage specification on an operator function is well-formed, but the semantics (e.g. name mangling) are implementation-defined. In addition, the rule about multiple functions with the same name having "C" linkage applies.

        extern "C" T operator+(T,T); // ok
        extern "C" T operator-(T,T); // ok
        extern "C" U operator-(U);   // error, two extern "C" operator-

Mike Miller: I think the point here is that something like

        extern "xyzzy" bool operator<(S&,S&)

could well make sense, if language xyzzy is sufficiently compatible with C++, and the one-function rule only applies to extern "C", not to other language linkages. Given that it might make sense to have general language linkages for operators, is it worthwhile to make an exception to the general rule by saying that you can have any language linkage on an operator function except "C" linkage? I don't like exceptions to general rules unless they're very well motivated, and I don't see sufficient motivation to make one here.

Certainly this capability isn't very useful. There are lots of things in C++ that aren't very useful but just weren't worth special-casing out of the language. I think this falls into the same category.

Mike Ball: I DON'T want to forbid operator functions within an extern "C". Rather I want to add operator functions to that sentence in paragraph 4 of 9.12 [dcl.link] which reads

> A C language linkage is ignored for the names of class members and the member function type of class member functions.

My reason is simple: C linkage makes a total hash of scope. Any "C" functions declared with the same name in any namespace scope are the same function. In other words, namespaces are totally ignored.

This provision was added in toward the end of the standardization process, and was, I thought, primarily to make it possible to put the C library in namespace `std`. Otherwise, it seems an unwarrented attack on the very concept of scope. We (wisely) didn't force this on static member functions, since it would essentially promote them to the global scope.

Now I think that programmers think of operator functions as essentially part of a class. At least for one very common design pattern they are treated as part of the class interface. This pattern is the reason we invented Koenig lookup for operator functions.

What happens when such a class definition is included, deliberately or not, in an extern "C" declaration? The member operators continue to work, but the non-member operators can suddenly get strange and hard to understand messages. Quite possibly, they get the messages only when combined with other classes in other compilation units. You can argue that the programmer shouldn't put the class header in a linkage delaration in the first place, but I can still find books that recommend putting `extern "C"' around entire header files, so it's going to happen.

I think that including operator functions in the general exclusion from extern "C" doesn't remove a capability, rather it ensurs a capability that programmers already think they have.

Rationale (10/00):

The benefits of creating an exception for operator functions were outweighed by the complexity of adding another special case to the rules.

Note (March, 2008):

The Evolution Working Group recommended closing this issue with no further consideration. See paper J16/07-0033 = WG21 N2173.

#### 168. C linkage for static member functions

Section: 9.12 [dcl.link] Status: NAD Submitter: Darin Adler Date: 9 Sep 1999

[Picked up by evolution group at October 2002 meeting.]

9.12 [dcl.link] paragraph 4 says,

> A C language linkage is ignored for the names of class members and the member function types of class member functions.

This makes good sense, since C linkage names typically aren't compatible with the naming used for member functions at link time, nor is C language linkage function type necessarily compatible with the calling convention for passing `this` to a non-static member function.

But C language linkage type (not name) for a static member function is invaluable for a common programming idiom. When calling a C function that takes a pointer to a function, it's common to use a private static member function as a "trampoline" which retrieves an object reference (perhaps by casting) and then calls a non-static private member function. If a static member function can't have a type with C language linkage, then a global or friend function must be used instead. These alternatives expose more of a class's implementation than a static member function; either the friend function itself is visible at namespace scope alongside the class definition or the private member function must be made public so it can be called by a non-friend function.

Suggested Resolution: Change the sentence cited above to:

> A C language linkage is ignored for the names of class members and the member function types of non-static class member functions.

The example need not be changed because it doesn't involve a static member function.

The following workaround accomplishes the goal of not exposing the class's implementation, but at the cost of significant superstructure and obfuscation:

        // foo.h
        extern "C" typedef int c_func(int);
        typedef int cpp_func(int);
        class foo
        {
        private:
          c_func* GetCallback();
          static int Callback(int);
        };

        // foo.cpp
        #include "foo.h"

        // A local pointer to the static member that will handle the callback.
        static cpp_func* cpp_callback=0;

        // The C function that will actually get registered.
        extern "C" int CFunk(int i)
        {
          return cpp_callback(i);
        }

        c_func* foo::GetCallback()
        {
          cpp_callback = &Callback;    // Only needs to be done once.
          return &CFunk;
        }

Rationale (10/99): The Standard correctly reflects the intent of the Committee.

Note (March, 2008):

The Evolution Working Group recommended closing this issue with no further consideration. See paper J16/07-0033 = WG21 N2173.

#### 358. Namespaces and extern "C"

Section: 9.12 [dcl.link] Status: NAD Submitter: Steve Clamage Date: 28 May 2002

Is this code valid:

      extern "C" void f();

      namespace N
      {
        int var;
        extern "C" void f(){ var = 10; }
      }

The two declarations of f refer to the same external function, but is this a valid way to declare and define f?

And is the definition of f considered to be in namespace N or in the global namespace?

Notes from October 2002 meeting:

Yes, this example is valid. See 9.12 [dcl.link] paragraph 6, which contains a similar example with the definition in the global namespace instead. There is only one f, so the question of whether the definition is in the global namespace or the namespace N is not meaningful. The same function is found by name lookup whether it is found from the declaration in namespace N or the declaration in the global namespace, or both (9.9.4 [namespace.udir] paragraph 4) .

#### 1703. Language linkage of names of functions with internal linkage

Section: 9.12 [dcl.link] Status: NAD Submitter: Richard Smith Date: 2013-06-17

Issue 4 separated the concepts of language linkage for names and language linkage for types; since the names of functions with internal linkage are not visible outside their (C++) translation unit, there is no need to restrict overloading of extern "C" functions with internal linkage, e.g.,

      extern "C" {
        static void f();
        static void f(int);
      }

although the types of such functions still have C language linkage and thus can be called via a function pointer from C code.

The change permitting such overloading, however, has not been widely implemented since the resolution of issue 4, leading some to suggest that the unnecessary restriction on function overloading of such functions should be reimposed.

If it is decided to keep the resolution of issue 4, 9.12 [dcl.link] paragraph 6 should be clarified:

> At most one function with a particular name can have C language linkage.

Presumably this was overlooked in implementing the intent of the resolution for the issue and is a likely explanation for the reason it is not more widely implemented.

Rationale (September, 2013):

There was no consensus in CWG for a change to the current rules. 9.12 [dcl.link] paragraph 6 should be read as applying to the C language linkage of the name, not the function type.

#### 1869. `thread_local` vs linkage-specifications

Section: 9.12 [dcl.link] Status: NAD Submitter: Richard Smith Date: 2014-02-14

According to 9.12 [dcl.link] paragraph 7,

> A declaration directly contained in a linkage-specification is treated as if it contains the `extern` specifier (9.2.2 [dcl.stc]) for the purpose of determining the linkage of the declared name and whether it is a definition. Such a declaration shall not specify a storage class.

This prohibits a declaration like

      extern "C++" thread_local int n;

Should this be changed?

Rationale (June, 2014):

This restriction is the same for `static` and simply requires that the braced form of linkage-specification be used.

#### 1323. Nonexistent nonterminal in alignment-specifier grammar

Section: 9.13.1 [dcl.attr.grammar] Status: NAD Submitter: Alisdair Meredith Date: 2011-05-19

The grammar for alignment-specifier in 9.13.1 [dcl.attr.grammar] paragraph 1 is:

alignment-specifier:

`alignas (` type-id `...`opt `)`
`alignas (` alignment-expression `...`opt `)`

There is no such nonterminal as alignment-expression; it should be assignment-expression instead.

Rationale (August, 2011)

This is an editorial issue that has been transmitted to the project editor.

#### 2279. Multiple attribute-specifiers in one attribute-list

Section: 9.13.1 [dcl.attr.grammar] Status: NAD Submitter: Richard Smith Date: 2016-06-27

P0028R4 contains this example:

      [[ using CC: opt(1), debug ]] void f() {} // Same as [[ CC::opt(1), CC::debug ]] void f() {}
      [[ using CC: opt(1)]][[ CC::debug ]] void g() {} // Okay (same effect as above).

However, there appears to be no normative justification for the claim that these two attribute-lists have the same effect.

Rationale (February, 2017):

The effects of such attributes are implementation-defined.

#### 2388. Applicability of contract-attribute-specifiers

Section: 9.13.1 [dcl.attr.grammar] Status: NAD Submitter: Aaron Ballman Date: 2018-10-24

According to 9.13.1 [dcl.attr.grammar] paragraph 5,

> Each attribute-specifier-seq is said to appertain to some entity or statement, identified by the syntactic context where it appears ( Clause 8 [stmt], 9.1 [dcl.pre], 9.3 [dcl.decl]). If an attribute-specifier-seq that appertains to some entity or statement contains an attribute or alignment-specifier that is not allowed to apply to that entity or statement, the program is ill-formed.

This does not, but presumably should, mention contract-attribute-specifiers.

Proposed resolution (March, 2019):

Change 9.13.1 [dcl.attr.grammar] paragraph 5 as follows:

> Each attribute-specifier-seq is said to appertain to some entity or statement, identified by the syntactic context where it appears (Clause 8 [stmt], 9.1 [dcl.pre], 9.3 [dcl.decl]). If an attribute-specifier-seq that appertains to some entity or statement contains an attribute, contract-attribute-specifier, or alignment-specifier that is not allowed to apply to that entity or statement, the program is ill-formed. If an attribute-specifier-seq appertains to a friend declaration (11.8.4 [class.friend]), that declaration shall be a definition. No attribute-specifier-seq shall appertain to an explicit instantiation (13.9.3 [temp.explicit]).

Rationale (July, 2019):

With the adoption of paper P1823R0, removing contracts from C++20, this issue is moot.

#### 1627. Agreement of dependent `alignas` specifiers

Section: 9.13.2 [dcl.align] Status: NAD Submitter: Richard Smith Date: 2013-02-22

Although 9.13.2 [dcl.align] paragraph 6 requires that all declarations of a given entity must have the same alignment, enforcing that requirement for class templates would require instantiating all declarations of the template, a process not otherwise needed. For example:

       template<int M, int N> struct alignas(M) X;
       template<int M, int N> struct alignas(N) X {};

The same problem would presumably afflict any attribute applied to a class template.

Rationale (April, 2013):

9.13.2 [dcl.align] paragraph 6 requires that the alignments be “equivalent,” which in a dependent context is specified by 13.7.7.2 [temp.over.link] paragraph 5. The expressions in this example are not equivalent.

#### 836. `[[noreturn]]` applied to function types

Section: 9.13.10 [dcl.attr.noreturn] Status: NAD Submitter: Joseph Myers Date: 7 March, 2009

The `[[noreturn]]` attribute, as specified in 9.13.10 [dcl.attr.noreturn], applies to function declarations and is not integrated with the type system. This is incompatible with existing practice (as in gcc) and should be reconsidered.

Rationale (July, 2009):

The CWG reaffirmed the previous decisions not to have attributes apply to types and did not believe that the benefits were sufficient for this case to make an exception to the general rule.

#### 1132. Keyword vs attribute for `noreturn`

Section: 9.13.10 [dcl.attr.noreturn] Status: NAD Submitter: GB Date: 2010-08-02
N3092 comment GB 32

C has rejected the notion of attributes, and introduced the noreturn facility as a keyword. To continue writing clean, portable code we should replace the `[[noreturn]]` attribute with a `noreturn` keyword, following the usual convention that while C obfuscates new keywords with _Capital and adds a macro to map to the comfortable spelling, C++ simply adopts the all-lowercase spelling.

Rationale (August, 2010):

CWG felt that an attribute was a more appropriate representation for this feature.

#### 2527. Non-class potentially-overlapping objects

Section: 9.13.11 [dcl.attr.nouniqueaddr] Status: NAD Submitter: Jiang An Date: 2022-01-29

The definition of a “potentially-overlapping subobject” in 6.8.2 [intro.object] paragraph 7 does not exclude non-class subobjects; in particular, 9.13.11 [dcl.attr.nouniqueaddr] makes no restrictions on the types of members declared with the `no_unique_address` attribute. It is not clear that a potentially-overlapping scalar member or array of scalar elements is useful. Should there be a restriction on the type of potentially-overlapping subjects?

CWG 2022-11-11

Restricting the type of a potentially-overlapping subobject would make it difficult to use `no_unique_address` on a subobject of dependent type, which may be a non-class type in some, but not all, specializations. Compilers can warn about non-sensical uses in non-dependent contexts.

#### 1141. Non-static data member initializers have not been implemented

Section: 11.4 [class.mem] Status: NAD Submitter: US Date: 2010-08-02
N3092 comment US 51

Non-static data member initializers should not be part of C++0x unless they have implementation experience.

Notes from the August, 2010 meeting:

The C++/CLI dialect has a very similar feature that has been implemented.

Rationale (March, 2011):

The full Committee voted not to remove this feature.

#### 1341. Bit-field initializers

Section: 11.4 [class.mem] Status: NAD Submitter: James Widman Date: 2011-08-10

The grammar for member-declarator (11.4 [class.mem]) does not, but should, allow for a brace-or-equal-initializer on a bit-field declarator.

Rationale (October, 2015):

Such a change would introduce a new syntactic ambiguity. CWG also felt uncomfortable with a construct that is visually

      expression = expression

not being an assignment expression.

#### 2208. static_assert-declaration does not declare a member

Section: 11.4 [class.mem] Status: NAD Submitter: Stephan Bergmann Date: 2015-12-02

[Detailed description pending.]

Rationale (November, 2016):

The reported issue is no longer relevant to the current working paper.

#### 2510. noexcept-specifier of friend function vs class completeness

Section: 11.4.1 [class.mem.general] Status: NAD Submitter: John Spicer Date: 2021-10-26

According to 11.4.1 [class.mem.general] paragraph 7, a noexcept-specifier is a complete-class context. This raises an issue when the function is a friend function; for example, consider:

      using T = int;
      struct B {
        friend void g(B b) noexcept(sizeof(b.m) >= 4) { }
        T m = T();
      };
      int main() {
        B b;
        g(b);
      }

For friend declarations you need to be able to decide at the point of declaration whether it matches a prior declaration, and you can't do that if you treat the noexcept-specifier as a complete-class context.

There is implementation divergence in the treatment of this example.

Notes from the December, 2021 teleconference:

CWG questioned why the declaration matching couldn't be deferred until the end of the class.

CWG 2022-11-10

CWG believes that, in general, a "when needed" approach to parsing complete-class contexts is superior. In the present case, the existing wording clearly requires that the noexcept-specifier be delayed-parsed, which implies that matching the declaration of a friend function to declarations at namespace scope is also delayed.

#### 1005. Qualified name resolution in member functions of class templates

Section: 11.4.3 [class.mfct.non.static] Status: NAD Submitter: Doug Gregor Date: 2009-11-19

It's not clear how lookup of a non-dependent qualified name should be handled in a non-static member function of a class template. For example,

        struct A {
          int f(int);
          static int f(double);
        };

        struct B {};

        template<typename T> struct C : T {
          void g() {
            A::f(0);
          }
        };

The call to `A::f` inside `C::g()` appears non-dependent, so one might expect that it would be bound at template definition time to `A::f(double)`. However, the resolution for issue 515 changed 11.4.3 [class.mfct.non.static] paragraph 3 to transform an id-expression to a member access expression using `(*this).` if lookup resolves the name to a non-static member of any class, making the reference dependent. The result is that if `C` is instantiated with `A`, `A::f(int)` is called; if `C` is instantiated with `B`, the call is ill-formed (the call is transformed to `(*this).A::f(0)`, and there is no `A` subobject in `C<B>`). Both these results seem unintuitive.

(See also issue 1017.)

Notes from the November, 2010 meeting:

The CWG agreed that the resolution of issue 515 was ill-advised and should be reversed.

Rationale (March, 2011):

The analysis is incorrect; whether the reference is dependent or not, overload resolution chooses `A::f(int)` because of the rules in 12.2.2.2.2 [over.call.func] paragraph 3 dealing with contrived objects for static member functions.

#### 1143. Move semantics for `*this` have not been implemented

Section: 11.4.3 [class.mfct.non.static] Status: NAD Submitter: US Date: 2010-08-02
N3092 comment US 53

Move semantics for `*this` should not be part of C++0x unless they have implementation experience.

Rationale (March, 2011):

The full Committee voted not to remove this feature.

#### 819. Access control and deleted implicitly-declared special member functions

Section: 11.4.4 [special] Status: NAD Submitter: US Date: 3 March, 2009
N2800 comment US 50

An implicitly-declared special member function is defined as deleted (11.4.5 [class.ctor] paragraph 5, 11.4.7 [class.dtor] paragraph 3, 11.4.5.3 [class.copy.ctor] paragraphs 5 and 10) if any of the corresponding functions it would call from base classes is inaccessible. This is inconsistent with the treatment of access control in overload resolution and template argument deduction, where accessibility is ignored (but may result in an ill-formed program). This should be made consistent.

Rationale (July, 2009):

The current treatment is sufficiently useful to warrant the inconsistency with the other handling of access control. In particular, it enables such cases to be detected by SFINAE.

#### 1427. Default constructor and deleted or inaccessible destructors

Section: 11.4.5 [class.ctor] Status: NAD Submitter: Daniel Krügler Date: 2011-12-08

The list of causes for a defaulted default constructor to be defined as deleted, given in 11.4.5 [class.ctor] paragraph 5, should have a case for subobjects of a type with a destructor that is deleted or inaccessible from the defaulted constructor.

Rationale (January, 2012):

The supposedly-missing text is actually already present.

#### 26. Copy constructors and default arguments

Section: 11.4.5.3 [class.copy.ctor] Status: NAD Submitter: Daveed Vandevoorde Date: 22 Sep 1997

The working paper is quite explicit about

        struct X {
             X(X, X const& = X());
        };

being illegal (because of the chicken & egg problem wrt copying.)

Shouldn't it be as explicit about the following?

        struct Y {
            Y(Y const&, Y = Y());
        };

Rationale: There is no need for additional wording. This example leads to a program which either fails to compile (due to resource limits on recursive inlining) or fails to run (due to unterminated recursion). In either case the implementation may generate an error when the program is compiled.

#### 111. Copy constructors and cv-qualifiers

Section: 11.4.5.3 [class.copy.ctor] Status: NAD Submitter: Jack Rouse Date: 4 May 1999

Jack Rouse: In 11.4.5.3 [class.copy.ctor] paragraph 8, the standard includes the following about the copying of class subobjects in such a constructor:

- if the subobject is of class type, the copy constructor for the class is used;

But there can be multiple copy constructors declared by the user with differing cv-qualifiers on the source parameter. I would assume overload resolution would be used in such cases. If so then the passage above seems insufficient.

Mike Miller: I'm more concerned about 11.4.5.3 [class.copy.ctor] paragraph 7, which lists the situations in which an implicitly-defined copy constructor can render a program ill-formed. Inaccessible and ambiguous copy constructors are listed, but not a copy constructor with a cv-qualification mismatch. These two paragraphs taken together could be read as requiring the calling of a copy constructor with a non-const reference parameter for a const data member.

Proposed Resolution (November, 2006):

This issue is resolved by the proposed resolution for issue 535.

Rationale (August, 2011):

These concerns have been addressed by other changes.

#### 356. Wording of behavior of generated copy constructor for scalar members

Section: 11.4.5.3 [class.copy.ctor] Status: NAD Submitter: Steve Clamage Date: 25 May 2002

Section 11.4.5.3 [class.copy.ctor] paragraph 8 says the compiler-generated copy constructor copies scalar elements via the built-in assignment operator. Seems inconsistent. Why not the built-in initialization?

Notes from October 2002 meeting:

The Core Working Group believes this should not be changed. The standard already mentions built-in operators and the assignment operator does clearly define what must be done for scalar types. There is currently no concept of built-in initialization.

#### 992. Inheriting explicitness

Section: 11.4.5.3 [class.copy.ctor] Status: NAD Submitter: Lawrence Crowl Date: 24 October, 2009

Paper N2987 suggests that an implicitly-declared copy or move constructor should be explicit if the corresponding constructor of any of its subobjects is explicit. During the discussion at the October, 2009 meeting, the CWG deemed this a separable question from the major emphasis of that paper, and this issue was opened as a placeholder for that discussion.

See also issue 1051.

Rationale (November, 2010):

The CWG did not see a correlation between the explicitness of a base class constructor and that of an implicitly-declared derived class constructor.

#### 1084. Conditions for a deleted move function

Section: 11.4.5.3 [class.copy.ctor] Status: NAD Submitter: Jason Merrill Date: 2010-06-22

11.4.5.3 [class.copy.ctor] paragraph 12 says that a defaulted move constructor is defined as deleted if the class has a non-static data member or direct or virtual base class with a type that does not have a move constructor and is not trivially copyable. This seems more strict than is necessary; the subobject need not be trivially copyable, it should be enough for the selected constructor not to throw. In any case, the wording should be phrased in terms of the function selected by overload resolution rather than properties of the subobject type, and similarly for move assignment.

Rationale (November, 2010):

The CWG felt that the current specification was consistent and not overly problematic; users can add their own move constructor if needed.

#### 1731. `is_trivially_`X and definitions of special member functions

Section: 11.4.5.3 [class.copy.ctor] Status: NAD Submitter: James Widman Date: 2013-08-07

Consider an example like,

      struct A {
        A() = default;
        A(A&) = default;
        A(const A&) = default;
      };
      static_assert(!__is_trivially_copyable(A),"");

      struct B {
        A a;
        B() = default;
        B(const B&) = default;
      };
      static_assert(__is_trivially_copyable(B),"");

      struct C {
        mutable A a;
        C() = default;
        C(const C&) = default;
      };
      static_assert(!__is_trivially_copyable(C),"");

Presumably, all `static_assert()` conditions above are desired to evaluate `true`. Implementations diverge on this.

To decide whether a class is trivially copyable (Clause 11 [class] paragraph 6) , we need to see whether it has a non-trivial copy constructor. So eventually we hit 11.4.5.3 [class.copy.ctor] paragraph 12:

> A copy/move constructor for class `X` is trivial if it is not user-provided, its declared parameter type is the same as if it had been implicitly declared, and if

> - class `X` has no virtual functions (11.7.3 [class.virtual]) and no virtual base classes (11.7.2 [class.mi]), and

> - the constructor selected to copy/move each direct base class subobject is trivial, and

> - for each non-static data member of `X` that is of class type (or array thereof), the constructor selected to copy/move that member is trivial;

> otherwise the copy/move constructor is non-trivial.

which seem to imply that the copy constructor needs to have been implicitly defined before we consider this rule. But copy ctors are not odr-used in this example, so they're not implicitly-defined (paragraph 13).

The same considerations apply to copy/move assignment operators.

It might be sufficient to clarify this specification by replacing “selected to” with “that would be selected to.”

Rationale (September, 2013):

CWG felt that the existing wording was clear enough.

#### 1831. Explicitly vs implicitly deleted move constructors

Section: 11.4.5.3 [class.copy.ctor] Status: NAD Submitter: Vinny Romano Date: 2014-01-13

According to 11.4.5.3 [class.copy.ctor] paragraph 11,

> A defaulted move constructor that is defined as deleted is ignored by overload resolution (12.2 [over.match], 12.3 [over.over]). [Note: A deleted move constructor would otherwise interfere with initialization from an rvalue which can use the copy constructor instead. —end note]

Limiting this provision to defaulted move constructors introduces an unfortunate distinction between implicitly and explicitly deleted move constructors. For example, given

      #include <iostream>
      #include <memory>
      using namespace std;

      struct Expl {
        Expl() = default;
        Expl(const Expl &) {
          cout << " Expl(const Expl &)" << endl;
       }
       Expl(Expl &&) = delete;
      };

      struct Impl : Expl {
        Impl() = default;
        Impl(const Impl &) {
          cout << " Impl(const Impl &)" << endl;
        }
        Impl(Impl &&) = default;
      };

      struct Moveable {
        Moveable() { }
        Moveable(const Moveable &) {
          cout << " Moveable(const Moveable &)" << endl;
        }
        Moveable(Moveable &&) {
          cout << " Moveable(Moveable &&)" << endl;
        }
      };

      template<typename T> struct Container {
        Moveable moveable[2];
        T t;
      };

      int main() {
        cout << "Expl:" << endl;
        Container<Expl> c1(move(Container<Expl>()));
        cout << "Impl:" << endl;
        Container<Impl> c2(move(Container<Impl>()));
      }

The output of this program is

      Expl:
       Moveable(const Moveable &)
       Moveable(const Moveable &)
       Expl(const Expl &)
      Impl:
       Moveable(Moveable &&)
       Moveable(Moveable &&)
       Impl(const Impl &)

Should the specification be changed to allow overload resolution to ignore all deleted move constructors instead of only the defaulted ones?

From one perspective, at least, the principal reason to delete a move constructor explicitly is to elicit an error if a move is attempted, and such a change would violate that intent. On the other hand, minimizing the difference between explicit default and implicit default seems like an important goal.

Rationale (February, 2014):

The specification is as intended.

#### 1928. Triviality of deleted special member functions

Section: 11.4.5.3 [class.copy.ctor] Status: NAD Submitter: Richard Smith Date: 2014-05-15

The current wording of the Standard does not make clear whether a special member function that is defaulted and implicitly deleted is trivial. Triviality is visible in various ways that don't involve invoking the function, such as determining whether a type is trivially copyable and determining the result of various type traits. It also factors into some ABI specifications.

(See also issue 1734.)

Notes from the June, 2014 meeting:

CWG felt that deleted functions should be trivial. See also issue 1590.

Additional note, November, 2014:

See paper N4148.

Additional note, October, 2015:

Moved from "extension" status to "open" to allow consideration by CWG. See the additional discussion in issue 1734 for further details. See also issue 1496.

Rationale (October, 2015):

CWG feels that the triviality of a deleted function should be irrelevant. Any cases in which the triviality of a deleted function is observable should be amended to remove that dependency.

#### 2132. Deprecated default generated copy constructors

Section: 11.4.5.3 [class.copy.ctor] Status: NAD Submitter: Nico Josuttis Date: 2015-05-28

EWG has indicated that they are not currently in favor of removing the implicitly declared defaulted copy constructors and assignment operators that are deprecated in 11.4.5.3 [class.copy.ctor] paragraphs 7 and 18. Should this deprecation be removed?

EWG 2022-11-11

EWG expressed no interest to remove the deprecation.

#### 444. Overriding and the generated copy assignment operator

Section: 11.4.6 [class.copy.assign] Status: NAD Submitter: Kerch Holt Date: 26 Nov 2003

EDG (and g++, for that matter) picks the explicit copy assignment operator, which we think is wrong in this case:

    #include <stdio.h>
    struct D;   // fwd declaration
    struct B {
        D& operator=(D&);
    };
    struct D : B {
        D() {}
        D(int ii) { s = ii; }
        using B::operator=;
        int s;
    };
    int main() {
        D od, od1(10);
        od = od1; // implicit D::operator=(D&) called, not BASE::operator=(D&)
    }
    D& B::operator=(D& d) {
        printf("B::operator called\n");
        return d;
    }

If you look at 11.4.5.3 [class.copy.ctor] paragraph 10 it explicitly states that in such a case the "using B::operator=" will not be considered.

Steve Adamczyk: The fact that the operator= you declared is (D&) and not (const D&) is fooling you. As the standard says, the operator= introduced by the using-declaration does not suppress the generation of the implicit operator=. However, the generated operator= has the (const D&) signature, so it does not hide B::operator=; it overloads it.

Kerch Holt: I'm not sure this is correct. Going by 12.8 P10 first paragraph we think that the other form "operator=(D&)" is generated because the two conditions mentioned were not met in this case. 1) there is no direct base with a "const [volatile] B&" or "B" operator 2) And no member has a operator= either. This implies the implicit operator is "operator=(D&)". So, if that is the case the "hiding" should happen.

Also, in the last paragraph it seems to state that operators brought in from "using", no matter what the parameter is, are always hidden.

Steve Adamczyk: Not really. I think this section is pretty clear about the fact that the implicit copy assignment operator is generated. The question is whether it hides or overloads the one imported by the using-declaration.

Notes from the March 2004 meeting:

(a) Class B does get an implicitly-generated `operator=(const B&)`; (b) the using-declaration brings in two `operator=` functions from B, the explicitly-declared one and the implicitly-generated one; (c) those two functions overload with the implicitly-generated `operator=(const D&)` in the derived class, rather than being hidden by the derived-class function, because it does not match either of their signatures; (d) overload resolution picks the explicitly-declared function from the base class because it's the best match in this case. We think the standard wording says this clearly enough.

#### 574. Definition of “copy assignment operator”

Section: 11.4.6 [class.copy.assign] Status: NAD Submitter: Steve Adamczyk Date: 15 April 2006

Is the following a “copy assignment operator?”

        struct A {
            const A& operator=(const A&) volatile;
        };

11.4.5.3 [class.copy.ctor] paragraph 9 doesn't say one way or the other whether cv-qualifiers on the function are allowed. (A similar question applies to the `const` case, but I avoided that example because it seems so wrong one tends to jump to a conclusion before seeing what the standard says.)

Since the point of the definition of “copy assignment operator” is to control whether the compiler generates a default version if the user doesn’t, I suspect the correct answer is that neither `const` nor `volatile` cv-qualification on `operator=` should be allowed for a “copy assignment operator.” A user can write an `operator=` like that, but it doesn't affect whether the compiler generates the default one.

Proposed Resolution (November, 2006):

Change 11.4.5.3 [class.copy.ctor] paragraph 9 as follows:

> A user-declared copy assignment operator `X::operator=` is a non-static non-template non-volatile non-const member function of class `X` with exactly one parameter of type `X`, `X&`, `const X&`, `volatile X&` or `const volatile X&`.

[Drafting note: If a user-declared volatile `operator=` prevented the implicit declaration of the copy assignment operator, all assignments for objects of the given class (even to non-volatile objects) would pay the penalty for volatile write accesses in the user-declared `operator=`, despite not needing it.]

Additional note (December, 2008):

The proposed resolution addresses only cv-qualified assignment operators and is silent on ref-qualified versions. However, it would seem that the spirit of the resolution would indicate that a ref-qualified assignment operator would not be considered a copy assignment operator.

There appears to be an emerging idiom that relies on the idea that providing an lvalue-only assignment operator would prevent assignment to rvalues:

        struct A {
          A& operator=(const A&) &; // disable assignemt to rvalue
        };

The resolution should also be reconsidered in light of the use of a const-qualified assignment operator as part of the implementation of a proxy class, where the proxy object itself is constant and should not be changed, but the copy assignment operator would apply to the object to which the proxy object refers.

Rationale (March, 2009):

It was decided that cv-qualified and ref-qualified assignment operators should be considered copy assignment operators if they have the required parameter type.

#### 733. Reference qualification of copy assignment operators

Section: 11.4.6 [class.copy.assign] Status: NAD Submitter: Alberto Ganesh Barbati Date: 9 October, 2008

For increased regularity between built-in types and class types, the copy assignment operator can be qualified with `&`, preventing assignment to an rvalue. The LWG is making that change in the Standard Library. It would seem a good idea to make a similar change, where possible, in the specification of implicitly-declared assignment operators. This would be the case when all subobjects of class type have a non-deleted copy assignment operator that is `&`-qualified.

Rationale (July, 2009):

The LWG decided not to add reference qualifiers in the library, which reduces the motivation for making this change to implicit assignment operators.

See also LWG issue 941 and paper N2819.

#### 1085. Move assignment operators and virtual bases

Section: 11.4.6 [class.copy.assign] Status: NAD Submitter: Jason Merrill Date: 2010-06-22

In 11.4.5.3 [class.copy.ctor] paragraph 25, a move assignment operator is defined as deleted if it has any direct or indirect virtual base class. This could be relaxed to apply only if a virtual base is derived from more than once in the DAG.

Rationale (August, 2010):

CWG felt that there was insufficient motivation to change this at this time.

#### 2415. using-declarations vs copy assignment operators

Section: 11.4.6 [class.copy.assign] Status: NAD Submitter: Mike Miller Date: 2019-05-29

It is not clear whether a using-declaration naming an assignment operator from a base class can be considered to declare a copy assignment operator or not. For example:

      struct A;

      struct B {
        constexpr A & operator= (const A &);
      };

      struct A : B {
        using B::operator=;
      } a { a = a };

There is implementation divergence on the treatment of this code: should the using-declaration suppress or conflict with the implicit declaration of `A::operator=`?

Rationale (June, 2019):

This question is addressed explicitly by 9.10 [namespace.udecl] paragraph 4:

> If a constructor or assignment operator brought from a base class into a derived class has the signature of a copy/move constructor or assignment operator for the derived class (11.4.5.3 [class.copy.ctor], 11.4.6 [class.copy.assign]), the using-declaration does not by itself suppress the implicit declaration of the derived class member; the member from the base class is hidden or overridden by the implicitly-declared copy/move constructor or assignment operator of the derived class, as described below.

#### 1586. Naming a destructor via `decltype`

Section: 11.4.7 [class.dtor] Status: NAD Submitter: Steve Clamage Date: 2012-11-14

Use of a decltype-specifier to name a destructor in an explicit destructor call is explicitly permitted in 11.4.7 [class.dtor] paragraph 13. However, the most straightforward attempt to do so, e.g.,

      p->~decltype(*p)()

does not work, because `*p` is an lvalue and thus `decltype(*p)` is a reference type, not a class type. Even simply eliminating the reference is not sufficient, because `p` could be a pointer to a cv-qualified class type.

Either the provision for decltype-specifiers in explicit destructor calls should be removed or the specification should be expanded to allow reference and cv-qualified types to be considered as “denot[ing] the destructor's class type.”

Notes from the April, 2013 meeting:

CWG favored replacing the existing syntax with something more flexible, for example, `p->~auto()`. This new syntax would also apply to pseudo destructors.

Rationale (November, 2013):

CWG felt that the suggested change should be considered by EWG before the issue is resolved.

Additional note, April, 2015:

EWG has decided not to make a change in this area. See EWG issue 112.

#### 1783. Why are virtual destructors non-trivial?

Section: 11.4.7 [class.dtor] Status: NAD Submitter: Jeffrey Yasskin Date: 2013-09-26

According to 11.4.7 [class.dtor] paragraph 5,

> A destructor is trivial if it is not user-provided and if:

> - the destructor is not `virtual`,

> - ...

It is not clear why this restriction is needed, and it should be removed if it is not needed.

Rationale (February, 2014):

A trivial destructor is known to perform no actions and thus need not be invoked. A virtual destructor, however, might be member of a base class of an unknown derived class; it must therefore be called virtually in case an overriding virtual function performs some actions.

#### 395. Conversion operator template syntax

Section: 11.4.8.3 [class.conv.fct] Status: NAD Submitter: Daveed Vandevoorde Date: 18 Dec 2002

A posting in comp.lang.c++.moderated prompted me to try the following code:

      struct S {
        template<typename T, int N> (&operator T())[N];
      };

The goal is to have a (deducible) conversion operator template to a reference-to-array type.

This is accepted by several front ends (g++, EDG), but I now believe that 11.4.8.3 [class.conv.fct] paragraph 1 actually prohibits this. The issue here is that we do in fact specify (part of) a return type.

OTOH, I think it is legitimate to expect that this is expressible in the language (preferably not using the syntax above ;-). Maybe we should extend the syntax to allow the following alternative?

      struct S {
        template<typename T, int N> operator (T(&)[N])();
      };

Eric Niebler: If the syntax is extended to support this, similar constructs should also be considered. For instance, I can't for the life of me figure out how to write a conversion member function template to return a member function pointer. It could be useful if you were defining a null_t type. This is probably due to my own ignorance, but getting the syntax right is tricky.

Eg.

      struct null_t {
        // null object pointer. works.
        template<typename T> operator T*() const { return 0; }
        // null member pointer. works.
        template<typename T,typename U> operator T U::*() const { return 0; }
        // null member fn ptr.  doesn't work (with Comeau online).  my error?
        template<typename T,typename U> operator T (U::*)()() const { return 0; }
      };

Martin Sebor: Intriguing question. I have no idea how to do it in a single declaration but splitting it up into two steps seems to work:

      struct null_t {
        template <class T, class U>
        struct ptr_mem_fun_t {
          typedef T (U::*type)();
        };

        template <class T, class U>
        operator typename ptr_mem_fun_t<T, U>::type () const {
          return 0;
        }
      };

Note: In the April 2003 meeting, the core working group noticed that the above doesn't actually work.

Note (June, 2010):

It has been suggested that template aliases effectively address this issue. In particular, an identity alias like

        template<typename T> using id = T;

provides the necessary syntactic sugar to be able to specify types with trailing declarator elements as a conversion-type-id. For example, the two cases discussed above could be written as:

        struct S {
            template<typename T, int N>
              operator id<T[N]>&();
            template<typename T, typename U>
              operator id<T (U::*)()>() const;
        };

This issue should thus be closed as now NAD.

Rationale (August, 2011):

As given in the preceding note.

#### 315. Is call of static member function through null pointer undefined?

Section: 11.4.9.2 [class.static.mfct] Status: NAD Submitter: Jason Merrill Date: 7 Oct 2001

Another instance to consider is that of invoking a member function from a null pointer:

      struct A { void f () { } };
      int main ()
      {
        A* ap = 0;
        ap->f ();
      }

Which is explicitly noted as undefined in 11.4.3 [class.mfct.non.static], even though one could argue that since `f()` is empty, there is no lvalue->rvalue conversion.

If `f` is static, however, there seems to be no such rule, and the call is only undefined if the dereference implicit in the `->` operator is undefined. IMO it should be.

Incidentally, another thing that ought to be cleaned up is the inconsistent use of "indirection" and "dereference". We should pick one. (This terminology issue has been broken out as issue 342.)

This is related to issue 232.

Rationale (October 2003):

We agreed the example should be allowed. `p->f()` is rewritten as `(*p).f()` according to 7.6.1.5 [expr.ref]. `*p` is not an error when `p` is null unless the lvalue is converted to an rvalue (7.3.2 [conv.lval]), which it isn't here.

Additional notes (June, 2024)

Issue 2823 represents the current language rules; the example has undefined behavior.

#### 902. In-class initialization of non-constant static data members

Section: 11.4.9.3 [class.static.data] Status: NAD Submitter: Daniel Krügler Date: 21 May, 2009

The current wording of 11.4.9.3 [class.static.data] only allows a static data member to be initialized within the class definition if it is `const`. This restriction should be removed.

Rationale (July, 2009):

The consensus of the CWG was that there is insufficient motivation for such a change. A non-const static data member must still be defined outside the class if it is used, and the value of such a member cannot be used in a constant expression, unlike a constant static data member, so there is no real advantage to putting the initializer inside the class definition instead of in the definition of the static data member. The apparent parallel with non-static data member initialization is also not compelling; for example, the initializer for a non-static data member can contain forward references to members declared later in the class, while the same is not true of static data member initializers.

#### 1272. Implicit definition of static data member of const literal type

Section: 11.4.9.3 [class.static.data] Status: NAD Submitter: Nikolay Ivchenkov Date: 2011-03-18

The Standard requires that a const static data member that is initialized in the class definition must still be defined in namespace scope if it is odr-used. This seems unnecessary.

Rationale (August, 2011):

This is a request for an extension.

Additional note, April, 2015:

EWG has decided not to make a change in this area. See EWG issue 100.

#### 1987. `constexpr` static data members across translation units

Section: 11.4.9.3 [class.static.data] Status: NAD Submitter: Richard Smith Date: 2014-08-22

Given an example like

      struct X {
        static constexpr const char *p = "foo";
      };
      static const char *q = X::p;

if this appears in more than one translation unit, must the value of `q` be the same in each? The implication of the one-definition rule would be that it must be, but current implementations do not give that result.

Rationale (November, 2014):

The interpretation is correct and the implementations are incorrect.

#### 2375. Multiple redeclarations of `constexpr` static data members

Section: 11.4.9.3 [class.static.data] Status: NAD Submitter: Mike Miller Date: 2018-02-21

According to 11.4.9.3 [class.static.data] paragraph 3,

> An inline static data member may be defined in the class definition and may specify a brace-or-equal-initializer. If the member is declared with the `constexpr` specifier, it may be redeclared in namespace scope with no initializer (this usage is deprecated; see _N4778_.D.4 [depr.static_constexpr]).

The out-of-class declaration of a static data member was formerly a definition and thus limited to occurring only once. This limitation was lost when the in-class declaration of inline static data members became the definition; the current specification has no apparent prohibition against multiple out-of-class declarations of a `constexpr` static data member. Should the restriction be reinstated?

Rationale (November, 2018):

Current implementations support this usage and it does not appear to cause any problems.

#### 347. Use of derived class name in defining base class nested class

Section: 11.4.12 [class.nest] Status: NAD Submitter: Jason Shirk Date: 21 March 2002

11.4.2 [class.mfct] paragraph 5 says this about member functions defined lexically outside the class:

> the member function name shall be qualified by its class name using the :: operator

11.4.9.3 [class.static.data] paragraph 2 says this about static data members:

> In the definition at namespace scope, the name of the static data member shall be qualified by its class name using the :: operator

I would have expected similar wording in 11.4.12 [class.nest] paragraph 3 for nested classes. Without such wording, the following seems to be legal (and is allowed by all the compilers I have):

      struct base {
        struct nested;
      };

      struct derived : base {};
      struct derived::nested {};

Is this just an oversight, or is there some rationale for this behavior?

Rationale (July, 2008):

The wording in Clause 11 [class] paragraph 10 (added by the resolution of issue 284, which was approved after this issue was raised) makes the example ill-formed:

> If a class-head contains a nested-name-specifier, the class-specifier shall refer to a class that was previously declared directly in the class or namespace to which the nested-name-specifier refers (i.e., neither inherited nor introduced by a using-declaration), and the class-specifier shall appear in a namespace enclosing the previous declaration.

#### 359. Type definition in anonymous union

Section: 11.5 [class.union] Status: NAD Submitter: Al Grant Date: 31 May 2002

Is this legal? Should it be?

      struct E {
        union {
          struct { int x; } s;
        } v;
      };

One compiler faults a type definition (i.e. of the anonymous struct) since it is in an anonymous union [11.5 [class.union] paragraph 2: "The member-specification of an anonymous union shall only define non-static data members."].

I would suggest that compiler B is correctly interpreting the standard but that this is a defect in the standard. There is no reason to disallow definition of anonymous structs.

Furthermore, is it really necessary to disallow definition of named types in anonymous unions in general, as long as the types do not need fully qualified names for external linkage? Why should this be illegal?

      struct E {
        union {
          typedef int Int;
          struct X { X *next; Int n; } list;
        } v;
      };

Notes from October 2002 meeting:

There was agreement that the standard says such declarations are invalid; therefore this must be considered as an extension. There was general feeling that this extension would not be too useful, though Jason Merrill was sympathetic to the argument. It was also agreed that if this were to be changed it would require careful wording so as not to allow too many cases.

Note (March, 2008):

The Evolution Working Group recommended closing this issue with no further consideration. See paper J16/07-0033 = WG21 N2173.

#### 512. Union members with user-declared non-default constructors

Section: 11.5 [class.union] Status: NAD Submitter: Alisdair Meredith Date: 19 Mar 2005

Can a member of a union be of a class that has a user-declared non-default constructor? The restrictions on union membership in 11.5 [class.union] paragraph 1 only mention default and copy constructors:

> An object of a class with a non-trivial default constructor (11.4.5 [class.ctor]), a non-trivial copy constructor (11.4.5.3 [class.copy.ctor]), a non-trivial destructor (11.4.7 [class.dtor]), or a non-trivial copy assignment operator (12.4.3.2 [over.assign], 11.4.5.3 [class.copy.ctor]) cannot be a member of a union...

(11.4.5 [class.ctor] paragraph 11 does say, “a non-trivial constructor,” but it's not clear whether that was intended to refer only to default and copy constructors or to any user-declared constructor. For example, 6.8.7 [class.temporary] paragraph 3 also speaks of a “non-trivial constructor,” but the cross-references there make it clear that only default and copy constructors are in view.)

Note (March, 2008):

This issue was resolved by the adoption of paper J16/08-0054 = WG21 N2544 (“Unrestricted Unions”) at the Bellevue meeting.

Rationale (August, 2011):

As given in the preceding note.

#### 1714. odr-use of `this` from a local class

Section: 11.6 [class.local] Status: NAD Submitter: David Krauss Date: 2013-07-10

According to 11.6 [class.local] paragraph 1,

> Declarations in a local class shall not odr-use (6.3 [basic.def.odr]) a variable with automatic storage duration from an enclosing scope.

This restriction should apply as well to the `this` pointer when the class is local to a non-static member function.

Rationale (January, 2014):

The restrictions in _N4567_.5.1.1 [expr.prim.general] limiting the locations in which `this` may appear already prevent uses of the containing member function's `this` where the local class's `this` does not hide it.

#### 2119. Disambiguation of multi-level covariant return type

Section: 11.7.3 [class.virtual] Status: NAD Submitter: David Majnemer Date: 2015-05-05

In an example like

      struct W {};
      struct X : W {};
      struct Y : W {};
      struct Z : X, Y {}; // Z has two W subobjects

      struct A {
        virtual W *f();
      };
      struct B : A {
        virtual X *f();
      };
      struct C : B {
        virtual Z *f();   // C::f overrides A::f and B::f
      };

it is not clear whether the return type of `C::f()` satisfies the requirement of 11.7.3 [class.virtual] bullet 7.2 that the return type in the base class of the function be an unambiguous base of the return type in the derived class. Should the conversion from `Z*` to `X*` in overriding `B::f()` be considered to disambiguate the conversion from `Z*` to `W*` in overriding `A::f()`? There is implementation divergence on this question.

Rationale (May, 2015):

CWG determined that the current wording of the Standard is correct: `C::f()` overrides both `B::f()` and `A::f()`, and the latter overriding is ill-formed because of the ambiguity.

#### 230. Calls to pure virtual functions

Section: 11.7.4 [class.abstract] Status: NAD Submitter: Jim Hill Date: 4 May 2000

According to 11.7.4 [class.abstract] paragraph 6,

> Member functions can be called from a constructor (or destructor) of an abstract class; the effect of making a virtual call (11.7.3 [class.virtual]) to a pure virtual function directly or indirectly for the object being created (or destroyed) from such a constructor (or destructor) is undefined.

This prohibition is unnecessarily restrictive. It should not apply to cases in which the pure virtual function has been defined.

Currently the "pure" specifier for a virtual member function has two meanings that need not be related:

1. A pure virtual function need not be defined.
2. A pure virtual function must be overridden in any concrete derived class.

The prohibition of virtual calls to pure virtual functions arises from the first meaning and unnecessarily penalizes those who only need the second.

For example, consider a scenario such as the following. A class `B` is defined containing a (non-pure) virtual function `f` that provides some initialization and is thus called from the base class constructor. As time passes, a number of classes are derived from `B` and it is noticed that each needs to override `f`, so it is decided to make `B::f` pure to enforce this convention while still leaving the original definition of `B::f` to perform its needed initialization. However, the act of making `B::f` pure means that every reference to `f` that might occur during the execution of one of `B`'s constructors must be tracked down and edited to be a qualified reference to `B::f`. This process is tedious and error-prone: needed edits might be overlooked, and calls that actually should be virtual when the containing function is called other than during construction/destruction might be incorrectly changed.

Suggested resolution: Allow virtual calls to pure virtual functions if the function has been defined.

Rationale (February, 2012):

In light of the nontrivial implementation issues such a change would raise, as well as the fact that this restriction has been accepted into the C++ design lexicon for many years, CWG decided not to make a change at this point. Further consideration, if any, should occur within EWG.

Rationale (February, 2014):

EWG determined that no action should be taken on this issue.

#### 1420. Abstract final classes

Section: 11.7.4 [class.abstract] Status: NAD Submitter: Richard Smith Date: 2011-11-30

An abstract class is permitted to be a final class. Such classes are very nearly useless and should probably be made ill-formed.

Rationale (February, 2012):

Such classes could be used for static members and for access control. CWG saw no need to prohibit them.

#### 7. Can a class with a private virtual base class be derived from?

Section: 11.8.3 [class.access.base] Status: NAD Submitter: Jason Merrill Date: unknown

        class Foo { public: Foo() {}  ~Foo() {} };
        class A : virtual private Foo { public: A() {}  ~A() {} };
        class Bar : public A { public: Bar() {}  ~Bar() {} };

`~Bar()` calls `~Foo()`, which is ill-formed due to access violation, right? (`Bar`'s constructor has the same problem since it needs to call `Foo`'s constructor.) There seems to be some disagreement among compilers. Sun, IBM and g++ reject the testcase, EDG and HP accept it. Perhaps this case should be clarified by a note in the draft.

In short, it looks like a class with a virtual private base can't be derived from.

Rationale: This is what was intended.

#### 17. Footnote 99 should discuss the naming class when describing members that can be accessed from friends

Section: 11.8.3 [class.access.base] Status: NAD Submitter: unknown Date: unknown

Footnote 98 says:

> As specified previously in 11.8 [class.access] , private members of a base class remain inaccessible even to derived classes unless friend declarations within the base class declaration are used to grant access explicitly.

This footnote does not fit with the algorithm provided in 11.8.3 [class.access.base] paragraph 4 because it does not take into account the naming class concept introduced in this paragraph.

(See also paper J16/99-0002 = WG21 N1179.)

Rationale (10/99): The footnote should be read as referring to immediately-derived classes, and is accurate in that context.

#### 471. Conflicting inherited access specifications

Section: 11.8.3 [class.access.base] Status: NAD Submitter: Mike Miller Date: 14 Jun 2004

The Standard does not appear to specify how to handle cases in which conflicting access specifications for a member are inherited from different base classes. For example,

        struct A {
        public:
          int i;
        };
        struct B : virtual public A {
        protected:
          using A::i;
        };
        struct C : virtual public A, public B {
          // "i" is protected from B, public from A
        };

This question affects both the existing wording of 11.8.3 [class.access.base] paragraph 4 (“m as a member of N is public ... m as a member of N is private ... m as a member of N is protected”) and the proposed wording for issue 385 (“when a nonstatic data member or nonstatic member function is a protected member of its naming class”).

One possible definition of “is public” would be something like, “if any visible declaration of the entity has public access.” One could also plausibly define the access of `m` in `N` to be the minimum of all the visible declarations, or even an error if the visible declarations are inconsistent.

11.8.3 [class.access.base] paragraph 1 describes the access of inherited members, so a clarifying statement resolving this issue might plausibly be inserted at the end of that paragraph.

Proposed resolution (October, 2004):

Add the following text as a new paragraph after 11.8.3 [class.access.base] paragraph 1:

> If a given base class can be reached along more than one path through a derived class's sub-object lattice (11.7.2 [class.mi]), a member of that base class could have different accessibility in the derived class along different paths. In such cases, the most permissive access prevails. [Example:

>         struct B { static int i; };
>         class I: protected B { };
>         class D1: public B, public I { };
>         class D2: public I, private B { };

> `i` is accessible as a public member of `D1` and as a protected member of `D2`. —end example]

Rationale (03/2005): This question is already covered, in almost identical words, in 11.8.7 [class.paths].

#### 2030. Access of injected-class-name with template arguments

Section: 11.8.3 [class.access.base] Status: NAD Submitter: Mike Miller Date: 2014-10-27

Consider the following example:

      template <typename T> struct S1 { };
      struct S2 : private S1<int> { };
      struct S3 : S2 {
        void f() {
          S1<int> s1;   // #1
        }
      };

The reference in #1 to `S1` finds the injected-class-name of `S1<int>`, which is private in `S2` and thus inaccessible in `S3`. However, there is implementation divergence on the treatment of this reference, with many accepting the declaration without error, presumably because of the use of the name in a template-id. Should the Standard give special treatment to this usage?

Rationale (November, 2014):

The specification is as intended, and the example is ill-formed.

#### 209. Must friend declaration names be accessible?

Section: 11.8.4 [class.friend] Status: NAD Submitter: Judy Ward Date: 1 Mar 2000

11.8.4 [class.friend], paragraph 7, says

> A name nominated by a friend declaration shall be accessible in the scope of the class containing the friend declaration.

Does that mean the following should be illegal?

        class A { void f(); };
        class B { friend void A::f(); }; // Error: A::f not accessible from B

I discussed this with Bjarne in email, and he thinks it was an editorial error and this was not the committee's intention. The paragraph seems to have been added in the pre-Kona (24 Sept 1996) mailing, and I could not find anything in the previous meeting's (Stockholm) mailings which led me to believe this was intentional. The only compiler vendor which I think currently implements it is the latest release (2.43) of the EDG front end.

Proposed resolution (10/00):

Remove the first sentence of 11.8.4 [class.friend], paragraph 7.

Rationale (04/01):

After the 10/00 vote to accept this issue as a DR with the proposed resolution, it was noted that the first two sentences of 11.8 [class.access] paragraph 3 cause the proposed change to have no effect:

> Access control is applied uniformly to all names, whether the names are referred to from declarations or expressions. [Note: access control applies to names nominated by `friend` declarations (11.8.4 [class.friend]) and using-declarations (9.10 [namespace.udecl]). ]

In addition to the obvious editing to the text of the note, an exception to the blanket statement in the first sentence would also be required. However, discussion during the 04/01 meeting failed to produce consensus on exactly which names in the `friend` declaration should be exempted from the requirements of access control.

One possibility would be that only the name nominated as `friend` should be exempt. However, that approach would make it impossible to name a function as a friend if it used private types in its parameters or return type. Another suggestion was to ignore access for every name used in a `friend` declaration. That approach raised a question about access within the body of a `friend` function defined inline in the class body — the body is part of the declaration of a function, but references within the body of a `friend` function should still be subject to the usual access controls.

Other possibilities were raised, such as allowing the declaration of a `friend` member function if the declaration were permissible in its containing class, or taking the union of the access within the befriending class and the befriended entity. However, these suggestions would have been complex and difficult to specify correctly.

Ultimately it was decided that the original perceived defect was not sufficiently serious as to warrant the degree of complexity required to resolve it satisfactorily and the issue was consequently declared not to be a defect. It was observed that most of the problems involved with the current state of affairs result from inability to declare a particular member function as a `friend`; in such cases, an easy workaround is simply to befriend the entire class rather than the specific member function.

#### 445. Wording issue on friend declarations

Section: 11.8.4 [class.friend] Status: NAD Submitter: Risto Lankinen Date: 5 Dec 2003

Thus says the section 11.8.4 [class.friend]/7 in ISO 14882 C++ standard:

> A name nominated by a friend declaration shall be accessible in the scope of the class containing the friend declaration.

The obvious intention of this is to allow a friend declaration to specify a function (or nested class, enum, etc.) that is declared "private" or "protected" in its enclosing class. However, literal interpretation seems to allow a broader access to the befriended function by the whole class that is declaring the friendship.

If the rule were interpreted literally as it is currently written, this would compile (when it, of course, shouldn't be allowed at all):

    class C
    {
    private:
      static void f();
    };

    class D
    {
      friend void C::f();  // A name nominated by friend declaration...

      D()
      {
       C::f();  // ... shall be accessible in scope of class declaring friendship
      }
    };

Suggested fix is to reword "in the scope of the class containing the friend declaration" to exclude all other references from the scope of the declaring class, except the friend-declaration itself.

Notes from the March 2004 meeting:

We considered this and concluded that the standard is clear enough.

#### 501. Visibility of friend declarations within the befriending class

Section: 11.8.4 [class.friend] Status: NAD Submitter: Gabriel Dos Reis Date: 25 Jan 2005

I just received a query from a user of why line #1 in the following snippet is ill-formed:

        void g(int (*)(int));

        template<class T>
        class A {
           friend int f(int) { return 0; }

           void h() {
               g(f);          // #1
           }
        };

I believe that the special invisibility rule about friends is too complicated and makes life too complicated, especially considering that friends in templates are not templates, nor can they be conveniently rewritten with a “first declare at the namespace scope” rule. I can understand the rules when they make programming easier or prevent some obvious “silly” mistakes; but that does not seem to be the case here.

John Spicer: See two papers that discuss this issue: N0878 by Bill Gibbons, which ultimately gave rise to our current rules, and N0913 by me as an alternative to N0878.

Rationale (April, 2005):

The Standard is clear and consistent; this rule is the result of an explicit decision by the Committee.

#### 585. Friend template template parameters

Section: 11.8.4 [class.friend] Status: NAD Submitter: James Widman Date: 15 June 2006

After the adoption of the wording for extended friend declarations, we now have this new paragraph in 11.8.4 [class.friend]:

> A `friend` declaration that does not declare a function shall have one of the following forms:

> `friend` elaborated-type-specifier `;`
> `friend` simple-type-specifier `;`
> `friend` typename-specifier `;`

But what about friend class templates? Should the following examples compile in C++0x?

        template< template <class> class T >
             struct A{ friend T; };

        template< class > struct C;
        struct B{ friend C; };

Proposed resolution (June, 2008):

Change 11.8.4 [class.friend] paragraph 3 as follows:

> A `friend` declaration that does not declare a function shall have one of the following forms:

> `friend` elaborated-type-specifier `;`

> `friend` simple-type-specifier `;`

> `friend` typename-specifier `;`

> `friend` `::`opt nested-name-specifieropt template-name `;`

> `friend` identifier `;`

> In the last alternative, the identifier shall name a template template-parameter. [Note: a `friend` declaration may be the declaration in a template-declaration (Clause 13 [temp], 13.7.5 [temp.friend]). —end note] If the type specifier in a `friend` declaration designates a (possibly cv-qualified) class type or a class template, that class or template is declared as a friend; otherwise, the `friend` declaration is ignored. [Example:...

Rationale (September, 2008):

The proposed extension is not needed. The template case can be handled simply by providing a template header:

        template <typename T> friend class X<T>;

#### 718. Non-class, non-function friend declarations

Section: 11.8.4 [class.friend] Status: NAD Submitter: John Spicer Date: 18 September, 2008 Liaison: EWG

With the change from a scope-based to an entity-based definition of friendship (see issues 372 and 580), it could well make sense to grant friendship to enumerations and variables, for example:

        enum E: int;
        class C {
          static const int i = 5;  // Private
          friend E;
          friend int x;
        };
        enum E { e = C::i; };      // OK: E is a friend
        int x = C::i;              // OK: x is a friend

According to the current wording of 11.8.4 [class.friend] paragraph 3, the friend declaration of `E` is well-formed but ignored, while the friend declaration of `x` is ill-formed.

Additional notes (February, 2023)

Forwarding to EWG for review of this extension, per decision of the CWG chair. See cplusplus/papers#1466.

EWG 2023-05-11

This is an extension that needs a well-motivated paper to EWG.

#### 1833. `friend` declarations naming implicitly-declared member functions

Section: 11.8.4 [class.friend] Status: NAD Submitter: Richard Smith Date: 2014-01-13

It appears that naming an implicitly-declared member function in a friend declaration requires the full set of decorations to be specified. For example,

      struct A { };
      struct B { friend constexpr A::A() noexcept; };

There is implementation variation regarding the enforcement of this requirement, however. Should the Standard provide default treatment for such cases, allowing the simpler

        friend A::A();

?

Additional note, April, 2015:

EWG has decided not to make a change in this area.

#### 2363. Opaque enumeration friend declarations

Section: 11.8.4 [class.friend] Status: NAD Submitter: Mike Miller Date: 2017-10-26

According to 11.8.4 [class.friend] paragraph 3,

> A friend declaration that does not declare a function shall have one of the following forms:

> `friend` elaborated-type-specifier `;`
> `friend` simple-type-specifier `;`
> `friend` typename-specifier `;`

However, many implementations accept

      friend enum E;

even though that form is explicitly not allowed by 9.2.9.5 [dcl.type.elab] paragraph 1 (which only permits class-key and not enum-key in `friend` declarations). Some implementations also accept opaque enumeration declarations like

      friend enum E : int;

The latter form could plausibly be used in an example like:

      class C {
        constexpr static int priv = 15;
        friend enum class my_constants;
      };
      enum class my_constants {
        pub = C::priv;                // OK because of friend decl
      };

(See also issue 2131.)

Notes from the October, 2018 teleconference:

The suggested plausible use for the feature would require additional wording, because the effect of friendship is currently only described for classes and functions, not for enumerations. There does not appear to be a demand for the change.

#### 19. Clarify protected member access

Section: 11.8.5 [class.protected] Status: NAD Submitter: unknown Date: unknown

11.8.5 [class.protected] paragraph 1 says:

> When a friend or a member function of a derived class references a protected nonstatic member of a base class, an access check applies in addition to ...

Instead of saying "references a protected nonstatic member of a base class", shouldn't this be rewritten to use the concept of naming class as 11.8.3 [class.access.base] paragraph 4 does?

Rationale (04/99): This rule is orthogonal to the specification in 11.8.3 [class.access.base] paragraph 4.

#### 1007. Protected access and pointers to members

Section: 11.8.5 [class.protected] Status: NAD Submitter: Johannes Schaub Date: 2009-11-24

The restrictions on protected access in 11.8.5 [class.protected] apply only to forming pointers to members and to member access expressions. It should be considered whether to extend these restrictions to pointer-to-member expressions as well. For example,

       struct base {
           protected: int x;
       };

       struct derived : base {
           void foo(base* b) {
              b->x = 123; // not ok
              (b->*(&derived::x)) = 123; // ok?!
           }
       };

Rationale (August, 2010):

Access applies to use of names, so the check must be done at the point at which the pointer-to-member is formed. It is not possible to tell from the pointer to member at runtime what the access was.

#### 363. Initialization of class from self

Section: 11.9.2 [class.expl.init] Status: NAD Submitter: Sergey P. Derevyago Date: 11 July 2002

Is the following code well-formed?

     struct A { /* */ };

     int main()
     {
      A a=a;
     }

Note, that { int a=a; } is pretty legal.

And if so, what is the semantics of the self-initialization of UDT? For example

     #include <stdio.h>

     struct A {
            A()           { printf("A::A() %p\n",            this);     }
            A(const A& a) { printf("A::A(const A&) %p %p\n", this, &a); }
            ~A()          { printf("A::~A() %p\n",           this);     }
     };

     int main()
     {
      A a=a;
     }

can be compiled and prints:

    A::A(const A&) 0253FDD8 0253FDD8
    A::~A() 0253FDD8

(on some implementations).

Notes from October 2002 meeting:

6.8.4 [basic.life] paragraph 6 indicates that the references here are valid. It's permitted to take the address of a class object before it is fully initialized, and it's permitted to pass it as an argument to a reference parameter as long as the reference can bind directly. Except for the failure to cast the pointers to `void *` for the `%p` in the `printf`s, these examples are standard-conforming.

#### 1641. Assignment in member initializer

Section: 11.9.3 [class.base.init] Status: NAD Submitter: John Spicer Date: 2013-03-15

There appears to be no prohibition of assignments in member initializer expressions (neither mem-initializers nor brace-or-equal-initializers):

      struct A {
        int x;
        int y = x = 37;
      };

This seems surprising. Should it be allowed?

Rationale (April, 2013):

CWG saw no problems with the example. It did note, however, that the assignment to `x` is not an initialization, so `x` would not be considered to have been initialized by this example.

#### 2135. mem-initializers for virtual bases of abstract classes

Section: 11.9.3 [class.base.init] Status: NAD Submitter: Vinny Romano Date: 2015-06-06

According to 11.9.3 [class.base.init] paragraph 7,

> A mem-initializer where the mem-initializer-id denotes a virtual base class is ignored during execution of a constructor of any class that is not the most derived class.

Presumably “ignored” here means that there will be no runtime effect but that semantic restrictions such as access checking and the ODR must still be applied, but this is not completely clear.

Rationale (October, 2015):

The fact that “ignored” applies only to runtime effects is indicated by the phrase “during execution” in the existing wording. This seems clear enough.

#### 2204. Naming delegated constructors

Section: 11.9.3 [class.base.init] Status: NAD Submitter: Hubert Tong Date: 2015-11-25

11.9.3 [class.base.init] paragraph 3 singles out base classes when indicating the allowance of typedefs, etc. for the naming of types in a mem-initializer-list. It appears that the omission of the class of the constructor is unintentional.

Rationale (November, 2016):

There was no actual issue; the question was based on a misunderstanding of the current specification.

#### 307. Initialization of a virtual base class subobject

Section: 11.9.5 [class.cdtor] Status: NAD Submitter: Andrei Iltchenko Date: 31 Aug 2001

The second paragraph of section 11.9.5 [class.cdtor] contains the following text:

> To explicitly or implicitly convert a pointer (an lvalue) referring to an object of class X to a pointer (reference) to a direct or indirect base class B of X, the construction of X and the construction of all of its direct or indirect bases that directly or indirectly derive from B shall have started and the destruction of these classes shall not have completed, otherwise the conversion results in undefined behavior.

Now suppose we have the following piece of code:

        struct  a  {
           a() :  m_a_data(0)  {   }
           a(const a& rhsa) :  m_a_data(rhsa.m_a_data)  {   }
           int   m_a_data;
        };

        struct  b :  virtual a  {
           b() :  m_b_data(0)  {   }
           b(const b& rhsb) :  a(rhsb),  m_b_data(rhsb.m_b_data)  {   }
           int   m_b_data;
        };

        struct  c :  b  {
           c() :  m_c_data(0)  {   }
           c(const c& rhsc) :  a(rhsc),// Undefined behaviour when constru-
                                       // cting an object of type 'c'
                               b(rhsc),  m_c_data(rhsc.m_c_data)  {   }
           int   m_c_data;
        };

        int  main()
        {   c   ac1,   ac2(ac1);   }

The problem with the above snippet is that when the value '`ac2`' is being created and its construction gets started, `c`'s copy constructor has first to initialize the virtual base class subobject '`a`'. Which requires that the lvalue expression '`rhsc`' be converted to the type of the parameter of `a`'s copy constructor, which is 'const a&'. According to the wording quoted above, this can be done without undefined behaviour if and only if `b`'s construction has already started, which is not possible since '`a`', being a virtual base class, has to be initialized first by a constructor of the most derived object (11.9.3 [class.base.init]).

The issue could in some cases be alleviated when '`c`' has a user-defined copy constuctor. The constructor could default-initialize its '`a`' subobject and then initialize `a`'s members as needed taking advantage of the latitude given in paragraph 2 of 11.9.3 [class.base.init].

But if '`c`' ends up having the implicitly-defined copy constuctor, there's no way to evade undefined behaviour.

        struct  c :  b  {
           c() :  m_c_data(0)  {   }
           int   m_c_data;
        };

        int  main()
        {   c   ac1,   ac2(ac1);   }

Paragraph 8 of 11.4.5.3 [class.copy.ctor] states

> The implicitly-defined copy constructor for class X performs a memberwise copy of its subobjects. The order of copying is the same as the order of initialization of bases and members in a user-defined constructor (see 11.9.3 [class.base.init]). Each subobject is copied in the manner appropriate to its type:
> - if the subobject is of class type, the copy constructor for the class is used;

Which effectively means that the implicitly-defined copy constructor for '`c`' will have to initialize its '`a`' base class subobject first and that must be done with `a`'s copy constructor, which will always require a conversion of an lvalue expression of type '`const c`' to an lvalue of type '`const a&`'. The situation would be the same if all the three classes shown had implicitly-defined copy constructors.

Suggested resolution:

Prepend to paragraph 2 of 11.9.5 [class.cdtor] the following:

> Unless the conversion happens in a mem-initializer whose mem-initializer-id designates a virtual base class of X, to explicitly or implicitly convert ...

Notes from the 10/01 meeting:

There is no problem in this example. `ac1` is fully initialized before it is used in the initialization of `ac2`.

#### 6. Should the optimization that allows a class object to alias another object also allow the case of a parameter in an inline function to alias its argument?

Section: 11.9.6 [class.copy.elision] Status: NAD Submitter: unknown Date: unknown

[Picked up by evolution group at October 2002 meeting.]

(See also paper J16/99-0005 = WG21 N1182.)

At the London meeting, 11.4.5.3 [class.copy.ctor] paragraph 31 was changed to limit the optimization described to only the following cases:

- the source is a temporary object
- the return value optimization

One other case was deemed desirable as well:

- aliasing a parameter in an inline function call to the function call argument.

However, there are cases when this aliasing was deemed undesirable and, at the London meeting, the committee was not able to clearly delimit which cases should be allowed and which ones should be prohibited.

Can we find an appropriate description for the desired cases?

Rationale (04/99): The absence of this optimization does not constitute a defect in the Standard, although the proposed resolution in the paper should be considered when the Standard is revised.

Note (March, 2008):

The Evolution Working Group has accepted the intent of this issue and referred it to CWG for action (not for C++0x). See paper J16/07-0033 = WG21 N2173.

Notes from the June, 2008 meeting:

The CWG decided to take no action on this issue until an interested party produces a paper with analysis and a proposal.

Rationale (2023-05-12):

This is an extension that needs a paper targeted at EWG.

#### 2125. Copy elision and comma operator

Section: 11.9.6 [class.copy.elision] Status: NAD Submitter: Vinny Romano Date: 2015-05-06

Currently, 11.4.5.3 [class.copy.ctor] paragraphs 31-32 apply only to the name of a local variable in determining whether a return expression is a candidate for copy elision or move construction. Would it make sense to extend that to include the right operand of a comma operator?

EWG 2022-11-11

This is a request for a new feature, which should be proposed in a paper to EWG.

#### 102. Operator lookup rules do not work well with parts of the library

Section: 12.2.2.3 [over.match.oper] Status: NAD Submitter: Herb Sutter Date: 15 Oct 1998

The following example does not work as one might expect:

        namespace N { class C {}; }
        int operator +(int i, N::C) { return i+1; }

        #include <numeric>
        int main() {
            N::C a[10];
            std::accumulate(a, a+10, 0);
        }

According to 6.5.3 [basic.lookup.unqual] paragraph 6, I would expect that the "+" call inside `std::accumulate` would find the global `operator+`. Is this true, or am I missing a rule? Clearly, the `operator+` would be found by Koenig lookup if it were in namespace `N`.

Daveed Vandevoorde: But doesn't unqualified lookup of the `operator+` in the definition of `std::accumulate` proceed in the namespace where the implicit specialization is generated; i.e., in namespace `std`?

In that case, you may find a non-empty overload set for `operator+` in namespace `std` and the surrounding (global) namespace is no longer considered?

Nathan Myers: Indeed, `<string>` defines `operator+`, as do `<complex>`, `<valarray>`, and `<iterator>`. Any of these might hide the global operator.

Herb Sutter: These examples fail for the same reason:

        struct Value { int i; };

        typedef map<int, Value > CMap;
        typedef CMap::value_type CPair;

        ostream & operator<< ( ostream &os, const CPair &cp )
          { return os << cp.first << "/" << cp.second.i; }

        int main() {
          CMap courseMap;
          copy( courseMap.begin(), courseMap.end(),
                ostream_iterator<CPair>( cout, "\n" ) );
        }

        template<class T, class S>
        ostream& operator<< (ostream& out, pair<T,S> pr)
          { return out << pr.first << " : " << pr.second << endl; }

        int main() {
          map <int, string> pl;
          copy( pl.begin(), pl.end(),
                ostream_iterator <places_t::value_type>( cout, "\n" ) );
        }

This technique (copying from a map to another container or stream) should work. If it really cannot be made to work, that would seem broken to me. The reason is does not work is that `copy` and `pair` are in namespace `std` and the name lookup rules do not permit the global `operator<<` to be found because the other `operator<<`'s in namespace `std` hide the global operator. (Aside: FWIW, I think most programmers don't realize that a typedef like `CPair` is actually in namespace `std`, and not the global namespace.)

Bill Gibbons: It looks like part of this problem is that the library is referring to names which it requires the client to declare in the global namespace (the operator names) while also declaring those names in namespace `std`. This would be considered very poor design for plain function names; but the operator names are special.

There is a related case in the lookup of operator conversion functions. The declaration of a conversion function in a derived class does not hide any conversion functions in a base class unless they convert to the same type. Should the same thing be done for the lookup of operator function names, e.g. should an operator name in the global namespace be visible in namespace `std` unless there is a matching declaration in `std`?

Because the operator function names are fixed, it it much more likely that a declaration in an inner namespace will accidentally hide a declaration in an outer namespace, and the two declarations are much less likely to interfere with each other if they are both visible.

The lookup rules for operator names (when used implicitly) are already quite different from those for ordinary function names. It might be worthwhile to add one more special case.

Mike Ball : The original SGI proposal said that non-transitive points of instantiation were also considered. Why, when, and by whom was it added?

Rationale (10/99): This appears to be mainly a program design issue. Furthermore, any attempt to address it in the core language would be beyond the scope of what can be done in a Technical Corrigendum.

#### 423. Can a conversion be done on the left operand of a compound assignment?

Section: 12.2.2.3 [over.match.oper] Status: NAD Submitter: Gennaro Prota Date: 19 Jun 2003

Is the following well-formed?

      template <typename T>
      class test
      {
      public:
        operator T& (){ return m_i; }
      private:
        T m_i;
      };
      int main()
      {
        test<int*> t2;
        t2 += 1;  // Allowed?
      }

Is it possible that by "assignment operators" (12.2.2.3 [over.match.oper] paragraph 4) only the built-in candidates for operator= (i.e. excluding +=, *=, etc.) were meant? On one hand the plural ("operators") seems to imply that all the assignment operators are considered. OTOH, there has already been a core DR (221) about a missing distinction between "assignment operator" and "compound assignment operators". Is there a similar defect here?

Steve Adamczyk: The standard is ambiguous. However, I think the ARM was fairly clear about "assignment operators" meaning only "=", and I find that Cfront 3.0.1 accepts the test case (with typename changed to class). I don't know whether that's good or bad, but it's at least a precedent. Given the change of Core Issue 221, if we do nothing further conversions are valid on += and therefore this case is valid.

Note that "`t2++;`" is unquestionably valid, so one could also argue for the status quo (post-221) on the basis of consistency.

Notes from the October 2003 meeting:

We believe the example is well-formed, and no change other than that in issue 221 is needed.

#### 1228. Copy-list-initialization and `explicit` constructors

Section: 12.2.2.8 [over.match.list] Status: NAD Submitter: Daniel Krügler Date: 2010-12-03

The rules for selecting candidate functions in copy-list-initialization (12.2.2.8 [over.match.list]) differ from those of regular copy-initialization (12.2.2.5 [over.match.copy]): the latter specify that only the converting (non-`explicit`) constructors are considered, while the former include all constructors but state that the program is ill-formed if an `explicit` constructor is selected by overload resolution. This is counterintuitive and can lead to surprising results. For example, the call to the function object `p` in the following example is ambiguous because the `explicit` constructor is a candidate for the initialization of the operator's parameter:

        struct MyList {
          explicit MyStore(int initialCapacity);
        };

        struct MyInt {
          MyInt(int i);
        };

        struct Printer {
          void operator()(MyStore const& s);
          void operator()(MyInt const& i);
        };

        void f() {
          Printer p;
          p({23});
        }

Rationale (March, 2011):

The current rules are as intended.

#### 2377. Explicit copy constructor vs function viability

Section: 12.2.3 [over.match.viable] Status: NAD Submitter: Xiang Fan Date: 2018-06-05

According to 12.2.3 [over.match.viable] paragraph 4,

> Third, for `F` to be a viable function, there shall exist for each argument an implicit conversion sequence (12.2.4.2 [over.best.ics]) that converts that argument to the corresponding parameter of `F`. If the parameter has reference type, the implicit conversion sequence includes the operation of binding the reference, and the fact that an lvalue reference to non-`const` cannot be bound to an rvalue and that an rvalue reference cannot be bound to an lvalue can affect the viability of the function (see 12.2.4.2.5 [over.ics.ref]).

The description of an implicit conversion sequence in 12.2.4.2 [over.best.ics] paragraph 6 only discusses the relationship of the types. For example, for a class type, it says,

> When the parameter has a class type and the argument expression has the same type, the implicit conversion sequence is an identity conversion.

This ignores whether the conversion can actually be performed, considering `explicit` qualification of constructors and conversion functions. There is implementation divergence in the handling of an example like:

      template<typename T> void f(T);
      template<typename T> void f(const T &);

      struct Woof {
        explicit Woof() = default;
        explicit Woof(const Woof&) = default;
        explicit Woof(Woof&&) = default;
        Woof& operator=(const Woof&) = default;
        Woof& operator=(Woof&&) = default;
      };

      int main() {
        const Woof cw{};
        f(cw);
      }

If `f(Woof)` is viable, the call is ambiguous, even though calling `f(Woof)` would be ill-formed because of the explicit copy constructor.

This seems to be consistent with the general approach described in 12.2.4.2 [over.best.ics] paragraph 2, even though explicitness is not explicitly mentioned:

> Implicit conversion sequences are concerned only with the type, cv-qualification, and value category of the argument and how these are converted to match the corresponding properties of the parameter. Other properties, such as the lifetime, storage class, alignment, accessibility of the argument, whether the argument is a bit-field, and whether a function is deleted (9.6.3 [dcl.fct.def.delete]), are ignored. So, although an implicit conversion sequence can be defined for a given argument-parameter pair, the conversion from the argument to the parameter might still be ill-formed in the final analysis.

Rationale (November, 2018):

The intent is that the example should be ambiguous. As an editorial matter, the “such as” and “so” remarks should be turned into notes.

#### 455. Partial ordering and non-deduced arguments

Section: 12.2.4 [over.match.best] Status: NAD Submitter: Rani Sharoni Date: 19 Jan 2004

It's not clear how overloading and partial ordering handle non-deduced pairs of corresponding arguments. For example:

    template<typename T>
    struct A { typedef char* type; };

    template<typename T> char* f1(T, typename A<T>::type);  // #1
    template<typename T> long* f1(T*, typename A<T>::type*); // #2

    long* p1 = f1(p1, 0); // #3

I thought that #3 is ambiguous but different compilers disagree on that. Comeau C/C++ 4.3.3 (EDG 3.0.3) accepted the code, GCC 3.2 and BCC 5.5 selected #1 while VC7.1+ yields ambiguity.

I intuitively thought that the second pair should prevent overloading from triggering partial ordering since both arguments are non-deduced and has different types - (char*, char**). Just like in the following:

    template<typename T> char* f2(T, char*);   // #3
    template<typename T> long* f2(T*, char**); // #4

    long* p2 = f2(p2, 0); // #5

In this case all the compilers I checked found #5 to be ambiguous. The standard and DR 214 is not clear about how partial ordering handle such cases.

I think that overloading should not trigger partial ordering (in step 12.2.4 [over.match.best]/1/5) if some candidates have non-deduced pairs with different (specialized) types. In this stage the arguments are already adjusted so no need to mention it (i.e. array to pointer). In case that one of the arguments is non-deuced then partial ordering should only consider the type from the specialization:

    template<typename T> struct B { typedef T type; };

    template<typename T> char* f3(T, T);                   // #7
    template<typename T> long* f3(T, typename B<T>::type); // #8

    char* p3 = f3(p3, p3); // #9

According to my reasoning #9 should yield ambiguity since second pair is (T, long*). The second type (i.e. long*) was taken from the specialization candidate of #8. EDG and GCC accepted the code. VC and BCC found an ambiguity.

John Spicer: There may (or may not) be an issue concerning whether nondeduced contexts are handled properly in the partial ordering rules. In general, I think nondeduced contexts work, but we should walk through some examples to make sure we think they work properly.

Rani's description of the problem suggests that he believes that partial ordering is done on the specialized types. This is not correct. Partial ordering is done on the templates themselves, independent of type information from the specialization.

Notes from October 2004 meeting:

John Spicer will investigate further to see if any action is required.

(See also issue 885.)

CWG 2022-11-11

The second function parameter contains template parameters not deducible in its context, thus that parameter does not contribute to partial ordering. There is no implementation divergence. Close as NAD.

#### 2304. Incomplete type vs overload resolution

Section: 12.2.4.2 [over.best.ics] Status: NAD Submitter: John Spicer Date: 2016-07-05

It is not clear whether the current treatment of an example like the following is what we want:

      template<typename T> void foo(T, int);
      template<typename T> void foo(T&, ...);
      struct Q;
      void fn1(Q &data_vectors) { foo(data_vectors, 0); }

According to 12.2.4.2 [over.best.ics] paragraph 8,

> If no conversions are required to match an argument to a parameter type, the implicit conversion sequence is the standard conversion sequence consisting of the identity conversion (12.2.4.2.2 [over.ics.scs]).

This would select the first overload and then fail in attempting to call it because of the incomplete type. On the other hand, it is ill-formed to define or call a function with an incomplete parameter type, although it can be declared, so it might be reasonable to take completeness of the parameter type into consideration for SFINAE purposes. 13.10.3 [temp.deduct] bullet 8.11 says,

> [Note: Type deduction may fail for the following reasons:

> - ...

> - Attempting to create a function type in which a parameter type or the return type is an abstract class type (11.7.4 [class.abstract]).

If a definition of `Q` were available, we would need to instantiate it to see if it is abstract.

It would seem reasonable for an incomplete type to be invalid as well. That would be consistent with the other rules and general desire not to select functions you can't call based on the template argument types.

Rationale (July, 2017):

CWG determined that no change was needed.

#### 243. Weighting of conversion functions in direct-initialization

Section: 12.2.4.2.3 [over.ics.user] Status: NAD Submitter: Steve Adamczyk Date: 5 Sep 2000

There is a moderately serious problem with the definition of overload resolution. Consider this example:

        struct B;
        struct A {
            A(B);
        };
        struct B {
            operator A();
        } b;
        int main() {
            (void)A(b);
        }

This is pretty much the definition of "ambiguous," right? You want to convert a `B` to an `A`, and there are two equally good ways of doing that: a constructor of `A` that takes a `B`, and a conversion function of `B` that returns an `A`.

What we discover when we trace this through the standard, unfortunately, is that the constructor is favored over the conversion function. The definition of direct-initialization (the parenthesized form) of a class considers only constructors of that class. In this case, the constructors are the `A(B)` constructor and the (implicitly-generated) `A(const A&)` copy constructor. Here's how they are ranked on the argument match:

`A(B)` | exact match (need a `B`, have a `B`)
`A(const A&)` | user-defined conversion (`B::operator A` used to convert `B` to `A`)

In other words, the conversion function does get considered, but it's operating with, in effect, a handicap of one user defined conversion. To put that a different way, this problem is a problem of weighting, not a problem that certain conversion paths are not considered.

I believe the reason that the standard's approach doesn't yield the "intuitive" result is that programmers expect copy constructor elision to be done whenever reasonable, so the intuitive cost of using the conversion function in the example above is simply the cost of the conversion function, not the cost of the conversion function plus the cost of the copy constructor (which is what the standard counts).

Suggested resolution:

In a direct-initialization overload resolution case, if the candidate function being called is a copy constructor and its argument (after any implicit conversions) is a temporary that is the return value of a conversion function, and the temporary can be optimized away, the cost of the argument match for the copy constructor should be considered to be the cost of the argument match on the conversion function argument.

Notes from 10/01 meeting:

It turns out that there is existing practice both ways on this issue, so it's not clear that it is "broken". There is some reason to feel that something that looks like a "constructor call" should call a constructor if possible, rather than a conversion function. The CWG decided to leave it alone.

#### 1950. Restructuring description of ranks of conversion sequences

Section: 12.2.4.3 [over.ics.rank] Status: NAD Submitter: Richard Smith Date: 2014-06-18

The structure of 12.2.3 [over.match.viable] paragraph 3 is of the form

- `X` is better than `Y` if

- condition 1, or, if not that,

- condition 2, or, if not that,

- ...

It would be better to de-bullet this description, define the conditions, and then say, “`X` is better than `Y` if condition 1, condition 2, ...” This would also avoid the awkward “or, if not that,” phrasing.

Rationale (November, 2014):

CWG expressed a preference for the existing structure of this paragraph over the suggested rewrite. The change from “or, if not that,” to “otherwise” can be handled editorially, if desired.

#### 2524. Distinguishing user-defined conversion sequences by ref-qualifier

Section: 12.2.4.3 [over.ics.rank] Status: NAD Submitter: Hani Deek Date: 2021-09-09

Consider the following example:

      struct S  {
          operator int() const & { return 0; }
          operator char() && { return 0; }
      };

      void foo(int) {}
      void foo(char) {}

      int main() {
        foo(S{}); //OK, calls foo(char)
      }

Here, the ICS for each function is a user-defined conversion involving the same user-defined conversion function, `operator char() &&`, because of 12.2.4.3 [over.ics.rank] bullet 3.2.3:

> `S1` and `S2` include reference bindings (9.5.4 [dcl.init.ref]) and neither refers to an implicit object parameter of a non-static member function declared without a ref-qualifier, and `S1` binds an rvalue reference to an rvalue and `S2` binds an lvalue reference

`foo(int)` is a promotion, while `foo(char)` is an exact match, so the latter is chosen.

Replacing `int` and `char` in this example with non-interconvertible types results in a different outcome:

      class A{};
      class B{};

      struct S {
        operator A() const & { return A{}; }
        operator B() && { return B{}; }
      };

      void foo(A) {}
      void foo(B) {}

      int main() {
        foo(S{}); //error: call to foo is ambiguous
      }

Here, only one of the two user-defined conversion operators is viable for each overload. Consequently, 12.2.4.3 [over.ics.rank] bullet 3.3,

> User-defined conversion sequence `U1` is a better conversion sequence than another user-defined conversion sequence `U2` if they contain the same user-defined conversion function or constructor or they initialize the same class in an aggregate initialization and in either case the second standard conversion sequence of `U1` is better than the second standard conversion sequence of `U2`.

does not apply, unlike the earlier case, because different user-defined conversion functions appear in each conversion sequence and thus the sequences are indistinghishable.

This seems inconsistent.

Suggested resolution:

Change 12.2.4.3 [over.ics.rank] bullet 3.3 as follows:

> - User-defined conversion sequence `U1` is a better conversion sequence than another user-defined conversion sequence `U2` if

> - the initial standard conversion sequence of `U1` is better than the initial standard conversion sequence of `U2`, or

> - they contain the same user-defined conversion function or constructor or they initialize the same class in an aggregate initialization and in either case the second standard conversion sequence of `U1` is better than the second standard conversion sequence of `U2`.

CWG 2022-11-11

This is an extension that is best addressed by a paper to EWG.

#### 61. Address of static member function "`&p->f`"

Section: 12.3 [over.over] Status: NAD Submitter: Steve Adamczyk Date: 13 Oct 1998

Can `p->f`, where `f` refers to a set of overloaded functions all of which are static member functions, be used as an expression in an address-of-overloaded-function context? A strict reading of this section suggests "no", because "`p->f`" is not the name of an overloaded function (it's an expression). I'm happy with that, but the core group should decide and should add an example to document the decision, whichever way it goes.

Rationale (10/99): The "strict reading" correctly reflects the intent of the Committee, for the reason given, and no clarification is required.

#### 247. Pointer-to-member casts and function overload resolution

Section: 12.3 [over.over] Status: NAD Submitter: Martin Sebor Date: 22 Sep 2000

It is unclear whether the following code is well-formed or not:

        class A { };

        struct B : public A
        {
    	void foo ();
    	void foo (int);
        };

        int main ()
        {
    	void (A::*f)() = (void (A::*)())&B::foo;
        }

12.3 [over.over] paragraph 1 says,

> The function selected is the one whose type matches the target type required in the context. The target can be
> - ...
> - an explicit type conversion (7.6.1.4 [expr.type.conv], 7.6.1.9 [expr.static.cast], 7.6.3 [expr.cast]).

This would appear to make the program ill-formed, since the type in the cast is different from that of either interpretation of the address-of-member expression (its class is `A`, while the class of the address-of-member expression is `B`)

However, 12.3 [over.over] paragraph 3 says,

> Nonstatic member functions match targets of type "pointer-to-member-function;" the function type of the pointer to member is used to select the member function from the set of overloaded member functions.

The class of which a function is a member is not part of the "function type" (9.3.4.6 [dcl.fct] paragraph 4). Paragraph 4 is thus either a misuse of the phrase "function type," a contradiction of paragraph 1, or an explanation of what "matching the target type" means in the context of a pointer-to-member target. By the latter interpretation, the example is well-formed and `B::foo()` is selected.

Bill Gibbons: I think this is an accident due to vague wording. I think the intent was

> The function selected is the one which will make the effect of the cast be that of the identity conversion.

Mike Miller: The "identity conversion" reading seems to me to be overly restrictive. It would lead to the following:

        struct B {
            void f();
            void f(int);
        };
        struct D: B { };
        void (D::* p1)() = &D::f;                  // ill-formed
        void (D::* p2)() = (void (B::*)()) &D::f;  // okay

I would find the need for an explicit cast here surprising, since the downcast is a standard conversion and since the declaration of `p1` certainly has enough information to disambiguate the overload set. (See also issue 203.)

Bill Gibbons: There is an interesting situation with using-declarations. If a base class member function is present in the overload set in a derived class due to a using-declaration, it is treated as if it were a derived class member function for purposes of overload resolution in a call (12.2.2 [over.match.funcs] paragraph 4):

> For non-conversion functions introduced by a using-declaration into a derived class, the function is considered to be a member of the derived class for the purpose of defining the type of the implicit object parameter

There is no corresponding rule for casts. Such a rule would be practical, but if the base class member function were selected it would not have the same class as that specified in the cast. Since base-to-derived pointer to member conversions are implicit conversions, it would seem reasonable to perform this conversion implicitly in this case, so that the result of the cast has the right type. The usual ambiguity and access restrictions on the base-to-derived conversion would not apply since they do not apply to calling through the using-declaration either.

On the other hand, if there is no special case for this, we end up with the bizarre case:

        struct A {
            void foo();
        };
        struct B : A {
            using A::foo;
            void foo(int);
        }
        int main() {
            // Works because "B::foo" contains A::foo() in its overload set.
            (void (A::*)())&B::foo;
            // Does not work because "B::foo(int)" does not match the cast.
            (void (A::*)(int))&B::foo;
        }

I think the standard should be clarified by either:

- Adding a note to 12.3 [over.over] saying that using-declarations do not participate in this kind of overload resolution; or

- Modifying 12.3 [over.over] saying that using-declarations are treated as members of the derived class for matching purposes, and if selected, the resulting pointer to member is implicitly converted to the derived type with no access or ambiguity errors. (The using-declaration itself has already addressed both of these areas.)

Rationale (10/00): The cited example is well-formed. The function type, ignoring the class specification, is used to select the matching function from the overload set as specified in 12.3 [over.over] paragraph 3. If the target type is supplied by an explicit cast, as here, the conversion is then performed on the selected pointer-to-member value, with the usual restrictions on what can and cannot be done with the converted value (7.6.1.9 [expr.static.cast] paragraph 9, 7.6.1.10 [expr.reinterpret.cast] paragraph 9).

#### 27. Overload ambiguities for builtin ?: prototypes

Section: 12.5 [over.built] Status: NAD Submitter: Jason Merrill Date: 25 Sep 1997

I understand that the lvalue-to-rvalue conversion was removed in London. I generally agree with this, but it means that `?:` needs to be fixed:

Given:

        bool test;
        Integer a, b;
        test ? a : b;

What builtin do we use? The candidates are

        operator ?:(bool, const Integer &, const Integer &)
        operator ?:(bool, Integer, Integer)

which are both perfect matches.

(Not a problem in the C++11 FDIS, but misleading.)

Rationale: The description of the conditional operator in 7.6.16 [expr.cond] handles the lvalue case before the prototype is considered.

#### 728. Restrictions on local classes

Section: Clause 13 [temp] Status: NAD Submitter: Faisal Vali Date: 5 October, 2008

Now that the restriction against local classes being used as template arguments has been lifted, they are more useful, yet they are still crippled. For some reason or oversight, the restriction against local classes being templates or having member templates was not lifted. Allowing local classes to have member templates facilitates generic programming (the reason for lifting the other restriction), especially when it comes to the visitor-pattern (see the `boost::variant` documentation and the following example) as implemented in boost and the `boost::MPL` library (since functors have to be template classes in mpl, and higher-order functors have to have member templates to be useful). A local class with a member template would allow this desirable solution:

        #include <boost/variant.hpp>
        int main() {
          struct times_two_generic: public boost::static_visitor<> {
            template <typename T> void operator()(T& operand) const {
                operand += operand;
            }
          };

          std::vector<boost::variant<int, std::string>> vec;
          vec.push_back(21);
          vec.push_back("hello ");

          times_two_generic visitor;
          std::for_each(vec.begin(), vec.end(), boost::apply_visitor(visitor));
        }

Is there any compelling reason not to allow this code? Is there any compelling reason not to allow local classes to be templates, have friends, or be able to define their static data members at function scope? Wouldn't this symmetry amongst local and non-local classes make the language more appealing and less embarrassing?

Rationale (June, 2021):

EWG resolved to pursue this topic with paper P2044. It is no longer tracked as a core issue. See vote.

#### 822. Additional contexts for template aliases

Section: Clause 13 [temp] Status: NAD Submitter: UK Date: 3 March, 2009
N2800 comment UK 117

It would be nice to allow template alias within a function scope, and possibly a scoped concept map. As these affect name lookup and resolution, rather than defining new callable code, they are not seen to present the same problems that prevented class and function templates in the past.

Rationale (July, 2009):

This suggestion needs a paper and discussion in EWG before CWG can consider it.

Additional note, April, 2015:

EWG has decided not to make a change in this area. See EWG issue 95.

#### 1303. C language linkage for template with internal linkage

Section: Clause 13 [temp] Status: NAD Submitter: Johannes Schaub Date: 2011-04-23

There doesn't seem to be a good reason for prohibiting C language linkage for function templates with internal linkage, and that could be useful in implementations where the calling convention of a function is determined by its language linkage.

Rationale (August, 2011):

The specification is as desired.

#### 1179. Cv-qualification of non-type template parameters

Section: 13.2 [temp.param] Status: NAD Submitter: Daniel Krügler Date: 2010-08-19

Given an example like

        template<const int I> struct S {
            decltype(I) m;
        };

what is the type of `m`? 13.2 [temp.param] paragraph 5 is clear on the question:

> The top-level cv-qualifiers on the template-parameter are ignored when determining its type.

It's not clear that this is the desired outcome, however, particularly in light of the resolution of issue 1130. (This does not make any difference for the current language, as a non-type template parameter is a prvalue and non-class prvalues are never cv-qualified. It would have an impact, however, if a future revision of the language were to allow literal class types as non-type template parameters, so if a change is needed, it might be a good idea to do it now.)

Rationale (November, 2010):

As noted, the treatment of cv-qualification of the type of non-type template parameters is irrelevant because they are currently always non-class prvalues. If the language is extended to allow literal class types, a change to the handling of cv-qualification would be upwardly compatible, so nothing needs to be done now.

#### 1319. Error in pack expansion example

Section: 13.2 [temp.param] Status: NAD Submitter: Mike Miller Date: 2011-05-17

The example in 13.2 [temp.param] paragraph 15 contains the line

        template<T... Values> apply { };   // Values is a non-type template parameter pack
                                           // and a pack expansion

This should presumably be `struct apply` or some such.

Rationale (August, 2011)

This is an editorial issue that has been transmitted to the project editor.

#### 1643. Default arguments for template parameter packs

Section: 13.2 [temp.param] Status: NAD Submitter: Vinny Romano Date: 2013-03-17

Although 13.2 [temp.param] paragraph 9 forbids default arguments for template parameter packs, allowing them would make some program patterns easier to write. Should this restriction be removed?

Rationale (April, 2013):

CWG felt that removing the restriction was an extension best considered by EWG.

Additional note, April, 2015:

See EWG issue 15.

EWG 2022-11-11

This is a request for a possibly desirable feature, which should be proposed in a paper to EWG.

#### 1904. Default template arguments for members of class templates

Section: 13.2 [temp.param] Status: NAD Submitter: John Spicer Date: 2014-03-27

According to 13.2 [temp.param] paragraph 9,

> A default template-argument shall not be specified in the template-parameter-lists of the definition of a member of a class template that appears outside of the member's class.

This presumably is intended to apply to the parameters of the containing class template, not to the parameters of a member template, but the wording should be clarified. (Default arguments are permitted for a template member of a non-template class, and there does not appear to be a good rationale for treating members of a class template differently in this regard.)

Rationale (June, 2014):

CWG felt that the existing wording os clear enough.

#### 2178. Substitution of dependent template arguments in default template arguments

Section: 13.2 [temp.param] Status: NAD Submitter: Richard Smith Date: 2015-10-06

Consider the following example:

       template<typename T, T V, int n = sizeof(V)> using X = int[n];
       template<typename T> void f(X<T, 0>*) {}
       void g() { f<char>(0); }

Current implementations get confused here because they substitute `V=0` into the default argument of `X` before knowing the type `T` and end up with `f` having type `void (int (*)[sizeof(0)])`, that is, the array bound does not depend on `T`. It's not clear what should happen here.

Rationale (March, 2016):

There is no problem with the specification, only with the implementations; the default argument for `n` is dependent because `V` has a dependent type.

#### 2383. Variadic member functions of variadic class templates

Section: 13.2 [temp.param] Status: NAD Submitter: Daveed Vandevoorde Date: 2018-07-18

The intended treatment of an example like the following is not clear:

      template<class ...Types> struct Tuple_ { // _VARIADIC_TEMPLATE
        template<Types ...T> int f() {
          return sizeof...(Types);
        }
      };

      int main() {
        Tuple_<char,int> a;
        int b = a.f();
      }

According to 13.2 [temp.param] paragraph 19,

> If a template-parameter is a type-parameter with an ellipsis prior to its optional identifier or is a parameter-declaration that declares a pack (9.3.4.6 [dcl.fct]), then the template-parameter is a template parameter pack (13.7.4 [temp.variadic]). A template parameter pack that is a parameter-declaration whose type contains one or more unexpanded packs is a pack expansion. Similarly, a template parameter pack that is a type-parameter with a template-parameter-list containing one or more unexpanded packs is a pack expansion. A template parameter pack that is a pack expansion shall not expand a template parameter pack declared in the same template-parameter-list.

with the following example:

      template <class... T>
        struct value_holder {
          template <T... Values> struct apply { }; // Values is a non-type template parameter pack
      };                                           // and a pack expansion

There is implementation divergence on the treatment of the example, with some rejecting it on the basis that the arguments for `Tuple_::f` cannot be deduced, while others accept it.

Rationale (December, 2018):

The example is ill-formed because the packs have different sizes: `Types` has 2, `T` has 0 (from the call).

#### 552. Use of `typename` in the type in a non-type parameter-declaration

Section: 13.3 [temp.names] Status: NAD Submitter: Andre Morozov Date: 15 December 2005

The discussion in of the use of `typename` with a qualified-id in a template parameter-declaration in 13.3 [temp.names] paragraph 2 is confusing:

> `typename` followed by an unqualified-id names a template type parameter. `typename` followed by a qualified-id denotes the type in a non-type parameter-declaration.

This rule would be clearer if the unqualified-id case were described in terms of resolving the ambiguity of declaring a template parameter name versus referring to a type-name from the enclosing scope, and if the qualified-id case referred to the use of the `typename` keyword with dependent types in 13.8 [temp.res]. An example would also be helpful.

Rationale (April, 2006):

The CWG felt that the wording was already clear enough.

#### 440. Allow implicit pointer-to-member conversion on nontype template argument

Section: 13.4 [temp.arg] Status: NAD Submitter: David Abrahams Date: 13 Nov 2003

None of my compilers accept this, which surprised me a little. Is the base-to-derived member function conversion considered to be a runtime-only thing?

      template <class D>
      struct B
      {
          template <class X> void f(X) {}
          template <class X, void (D::*)(X) = &B<D>::f<X> >
          struct row {};
      };
      struct D : B<D>
      {
          void g(int);
          row<int,&D::g> r1;
          row<char*> r2;
      };

John Spicer: This is not among the permitted conversions listed in 14.3.

I'm not sure there is a terribly good reason for that. Some of the template argument rules for external entities were made conservatively because of concerns about issues of mangling template argument names.

David Abrahams: I'd really like to see that restriction loosened. It is a serious inconvenience because there appears to be no way to supply a usable default in this case. Zero would be an OK default if I could use the function pointer's equality to zero as a compile-time switch to choose an empty function implementation:

      template <bool x> struct tag {};

      template <class D>
      struct B
      {
          template <class X> void f(X) {}

          template <class X, void (D::*pmf)(X) = 0 >
          struct row {
              void h() { h(tag<(pmf == 0)>(), pmf); }
              void h(tag<1>, ...) {}
              void h(tag<0>, void (D::*q)(X)) { /*something*/}
          };
      };

      struct D : B<D>
      {
          void g(int);
          row<int,&D::g> r1;
          row<char*> r2;
      };

But there appears to be no way to get that effect either. The result is that you end up doing something like:

          template <class X, void (D::*pmf)(X) = 0 >
          struct row {
              void h() { if (pmf) /*something*/ }
          };

which invariably makes compilers warn that you're switching on a constant expression.

Additional notes (February, 2023)

Even the following simple case fails on all major implementations:

      struct B { void f(); };
      struct D : B {};

      template<void (D::*)()>
      int g();

      int x = g<&D::f>();

Subclause 7.7 [expr.const] paragraph 12 is unambiguous that the code is ill-formed, but that seems unfortunate.

CWG 2023-06-15

CWG noted that the derived-to-base conversion is also not allowed for arguments for non-type template parameters. Permitting such conversions is an extension, not a defect.

#### 114. Virtual overriding by template member function specializations

Section: 13.7.3 [temp.mem] Status: NAD Submitter: Bill Gibbons Date: 7 May 1999

According to 13.7.3 [temp.mem] paragraph 4,

> A specialization of a member function template does not override a virtual function from a base class.

Bill Gibbons: I think that's sufficiently surprising behavior that it should be ill-formed instead.

As I recall, the main reason why a member function template cannot be virtual is that you can't easily construct reasonable vtables for an infinite set of functions. That doesn't apply to overrides.

Another problem is that you don't know that a specialization overrides until the specialization exists:

        struct A {
            virtual void f(int);
        };
        struct B : A {
            template<class T> void f(T);  // does this override?
        };

But this could be handled by saying:

- If deduction using the type of an overridable function in a base class succeeds, the template is implicitly specialized to provide the override.
- If this yields more than one override for a function, the program is ill-formed.
- If a specialization due to explicit template arguments creates an override that did not previously exist, the program is ill-formed. (Or alternatively, it is not an override.)

The last case might only involve non-deducible contexts, e.g.

        template<int I> struct X;
        struct A {
            virtual void f(A<5>);
        };
        struct B : A {
            template<int I, int J> void f(A<I+J>);  // does not overrride
        };

        void g(B *b) {
            X<t> x;
            b->f<3,2>(x);  // specialization B::f(A<5>) makes program ill-formed
        }

So I think there are reasonable semantics. But is it useful?

If not, I think the creation of a specialization that would have been an override had it been declared in the class should be an error.

Daveed Vandevoorde: There is real code out there that is written with this rule in mind. Changing the standard on them would not be good form, IMO.

Mike Ball: Also, if you allow template functions to be specialized outside of the class you introduce yet another non-obvious ordering constraint.

Please don't make such a change after the fact.

John Spicer: This is the result of an explicit committee decision. The reason for this rule is that it is too easy to unwittingly override a function from a base class, which was probably not what was intended when the template was written. Overriding should be a conscious decision by the class writer, not something done accidentally by a template.

Rationale (10/99): The Standard correctly reflects the intent of the Committee.

Notes from October 2002 meeting:

This was reopened because of a discussion while reviewing possible extensions.

Notes from April 2003 meeting:

This was discussed again, and the consensus was that we did not want to make a change, and in particular we did not want to make it an error and risk breaking existing code.

#### 1002. Pack expansion for function arguments

Section: 13.7.4 [temp.variadic] Status: NAD Submitter: Daniel Krügler Date: 2009-11-16

The list of contexts in which pack expansions can occur, in 13.7.4 [temp.variadic] paragraph 4, does not include a function call, in spite of the comments in the example there that assume that a function call is such a context.

Rationale (August, 2010):

initializer-list, mentioned in 13.7.4 [temp.variadic], is used in the argument list of a function call.

#### 1519. Conflicting default and variadic constructors

Section: 13.7.4 [temp.variadic] Status: NAD Submitter: Ville Voutilainen Date: 2012-07-09

A specialization of a variadic function template can produce the same function signature as a non-variadic one; in particular, a class can end up with multiple default constructors if a pack expansion is empty. It would be helpful if such a specialization could be suppressed so that the non-variadic function were preferred.

Rationale (October, 2012):

It can be argued that this is not a defect in the language but simply something that must be considered by the programmer: if the default constructor and the empty-pack-expansion constructor do the same thing, the default constructor is superfluous, while if they do different things there may be a logic error in one or the other. EWG should resolve the policy question of whether this situation should receive special treatment in the language to make it well-formed.

Rationale (February, 2014):

EWG determined that no action should be taken on this issue. There is an existing workaround for the problem, and it will also be addressed by the Concepts Lite proposal.

#### 47. Template friend issues

Section: 13.7.5 [temp.friend] Status: NAD Submitter: John H. Spicer Date: 7 Nov 1997

Issue 1

Paragraph 1 says that a friend of a class template can be a template. Paragraph 2 says: A friend template may be declared within a non-template class. A friend function template may be defined within a non-template class.

I'm not sure what this wording implies about friend template definitions within template classes. The rules for class templates and normal classes should be the same: a function template can be declared or defined, but a class template can only be declared in a friend declaration.

Issue 2

Paragraph 4 says: When a function is defined in a friend function declaration in a class template, the function is defined when the class template is first instantiated. I take it that this was intended to mean that a function that is defined in a class template is not defined until the first instantiation. I think this should say that a function that is defined in a class template is defined each time the class is instantiated. This means that a function that is defined in a class template must depend on all of the template parameters of the class template, otherwise multiple definition errors could occur during instantiations. If we don't have a rule like this, compilers would have to compare the definitions of functions to see whether they are the same or not. For example:

        template <class T> struct A {
                friend int f() { return sizeof(T); }
        };

        A<int> ai;
        A<long> ac;

I hope we would all agree that this program is ill-formed, even if long and int have the same size.

From Bill Gibbons:

[1] That sounds right.

[2] Whenever possible, I try to treat instantiated class templates as if they were ordinary classes with funny names. If you write:

        struct A_int {
            friend int f() { return sizeof(int); }
        };
        struct A_long {
            friend int f() { return sizeof(long); }
        };

it is a redefinition (which is not allowed) and an ODR violation. And if you write:

        template <class T, class U> struct A {
                    friend int f() { return sizeof(U); }
        };

        A<int,float> ai;
        A<long,float> ac;

the corresponding non-template code would be:

        struct A_int_float {
            friend int f() { return sizeof(float); }
        };
        struct A_long_float {
            friend int f() { return sizeof(float); }
        };

then the two definitions of "`f`" are identical so there is no ODR violation, but it is still a redefinition. I think this is just an editorial clarification.

Rationale (04/99): The first sub-issue reflects wording that was changed to address the concern before the IS was issued. A close and careful reading of the Standard already leads to the conclusion that the example in the second sub-issue is ill-formed, so no change is needed.

#### 1545. `friend` function templates defined in class templates

Section: 13.7.5 [temp.friend] Status: NAD Submitter: Daniel Krügler Date: 2012-08-25

The status of an example like the following is not clear:

       template<class> struct x {
         template<class T>
         friend bool operator==(x<T>, x<T>) { return false; }
      };

      int main() {
        x<int> x1;
        x<double> x2;
        x1 == x1;
        x2 == x2;
      }

Such a `friend` definition is permitted by 13.7.5 [temp.friend] paragraph 2:

> A friend function template may be defined within a class or class template...

Paragraph 4 appears to be related, but deals only with friend functions, not friend function templates:

> When a function is defined in a friend function declaration in a class template, the function is instantiated when the function is odr-used. The same restrictions on multiple declarations and definitions that apply to non-template function declarations and definitions also apply to these implicit definitions.

Rationale (February, 2021):

The resolution of issue 2174 deleted the paragraph in question and makes clear the treatment of friend function templates.

#### 2306. Nested friend templates of class templates

Section: 13.7.5 [temp.friend] Status: NAD Submitter: John Spicer Date: 2016-07-17

The current wording is not clear how to declare that a nested class template of a class template is a friend of its containing template. For example, is

      template <class T> struct C {
        template <bool b> class Foo;
        template <bool b> friend class Foo;
      };

correct, or should it be

      template <class T> struct C {
        template <bool b> class Foo;
        template <class X> template <bool b> friend class C<X>::Foo;
      };

Rationale (June, 2018)

The submitter asked that the issue be withdrawn.

#### 229. Partial specialization of function templates

Section: 13.7.6 [temp.spec.partial] Status: NAD Submitter: Dave Abrahams Date: 1 Apr 2000

Library issue 225 poses the following questions:

1. How can a 3rd party library implementor (lib1) write a version of a standard algorithm which is specialized to work with his own class template?
2. How can another library implementor (lib2) write a generic algorithm which will take advantage of the specialized algorithm in lib1?

For example, a programmer might want to provide a version of `std::swap` that would be used for any specialization of a particular class template. It is possible to do that for specific types, but not for all specializations of a template.

The problem is due to the fact that programmers are forbidden to add overloads to namespace `std`, although specializations are permitted. One suggested solution would be to allow partial specialization of function templates, analogous to partial specialization of class templates.

Library issue 225 contains a detailed proposal for adding partial specialization of function templates (not reproduced here in the interest of space and avoiding multiple-copy problems). This Core issue is being opened to provide for discussion of the proposal within the core language working group.

Notes from 10/00 meeting:

A major concern over the idea of partial specialization of function templates is that function templates can be overloaded, unlike class templates. Simply naming the function template in the specialization, as is done for class specialization, is not adequate to identify the template being specialized.

In view of this problem, the library working group is exploring the other alternative, permitting overloads to be added to functions in namespace `std`, as long as certain restrictions (to be determined) are satisfied.

(See also documents N1295 and N1296 and issue 285.)

Notes from 10/01 meeting:

The Core Working Group decided to ask the Library Working Group for guidance on whether this feature is still needed to resolve a library issue. The answer at present is "we don't know."

Rationale (October, 2004):

The Core Working Group decided that the Evolution Working Group is the appropriate forum in which to explore the desirability and form of this feature.

Note (March, 2008):

The Evolution Working Group recommended closing this issue with no further consideration. See paper J16/07-0033 = WG21 N2173.

#### 1754. Declaration of partial specialization of static data member template

Section: 13.7.6 [temp.spec.partial] Status: NAD Submitter: Richard Smith Date: 2013-09-19

There does not appear to be a way to declare (not define) a partial specialization of a static data member template outside its class. The rule for explicit specializations (13.9.4 [temp.expl.spec] paragraph 13) is that the presence or absence of an initializer determines whether the explicit specialization is a definition or not. Applying this rule to the partial specialization case, however, would conflict with being able to provide an initializer on the declaration within the class.

Do we need to support declaring partial specializations of static data member templates outside their class?

Rationale (February, 2014):

CWG felt that this issue is more appropriately considered by EWG.

Additional note, April, 2015:

EWG has decided not to make a change in this area. See EWG issue 132.

#### 1577. Unnecessary restrictions on partial specializations

Section: 13.7.6.1 [temp.spec.partial.general] Status: NAD Submitter: Jeremiah Wilcox Date: 2012-10-19

One of the restrictions on partial specializations found in 13.7.6.1 [temp.spec.partial.general] paragraph 9 is:

> The template parameter list of a specialization shall not contain default template argument values. [Footnote: There is no way in which they could be used. —end footnote]

The rationale for this restriction is incorrect, since default template argument values can be used to trigger SFINAE and thus control whether a particular partial specialization is used. An example of this use is:

        template <typename T> struct a;
        template <typename T,
             typename = typename std::enable_if<some property>::type>
        struct a<std::vector<T>> { ... };

which is forbidden by this point. Note also that an example like

        template <typename T> struct b;
        template <typename T,
             typename = typename std::enable_if<some property>::type>
        struct b<T> { ... };

is likely forbidden by the previous bullet:

> The argument list of the specialization shall not be identical to the implicit argument list of the primary template.

This restriction may also need to be weakened.

Rationale (April, 2013)

CWG felt that consideration of these suggestions was more appropriately done by EWG.

Additional note, April, 2015:

EWG has decided not to make a change in this area. See EWG issue 110.

#### 1644. Equivalent exception-specifications in function template declarations

Section: 13.7.7.2 [temp.over.link] Status: NAD Submitter: Richard Smith Date: 2013-03-17

Although 14.5 [except.spec] paragraph 3 says,

> Two exception-specifications are compatible if:

> - ...

> - both have the form `noexcept(`constant-expression`)` and the constant-expressions are equivalent, or

> - ...

it is not clear whether “equivalent” in this context should be taken as a reference to the definition of equivalent given in 13.7.7.2 [temp.over.link] paragraph 5:

> Two expressions involving template parameters are considered equivalent if two function definitions containing the expressions would satisfy the one definition rule (6.3 [basic.def.odr]), except that the tokens used to name the template parameters may differ as long as a token used to name a template parameter in one expression is replaced by another token that names the same template parameter in the other expression.

since the context there is expressions that appear in function template parameters and return types.

There is implementation variance on this question.

Rationale (February, 2021):

The text in question no longer appears in the Standard.

#### 23. Some questions regarding partial ordering of function templates

Section: 13.7.7.3 [temp.func.order] Status: NAD Submitter: unknown Date: unknown

Issue 1:

13.7.7.3 [temp.func.order] paragraph 2 says:

> Given two overloaded function templates, whether one is more specialized than another can be determined by transforming each template in turn and using argument deduction (13.10.3 [temp.deduct] ) to compare it to the other.

13.10.3 [temp.deduct] now has 4 subsections describing argument deduction in different situations. I think this paragraph should point to a subsection of 13.10.3 [temp.deduct] .

Rationale:

This is not a defect; it is not necessary to pinpoint cross-references to this level of detail.

Issue 2:

13.7.7.3 [temp.func.order] paragraph 4 says:

> Using the transformed function parameter list, perform argument deduction against the other function template. The transformed template is at least as specialized as the other if, and only if, the deduction succeeds and the deduced parameter types are an exact match (so the deduction does not rely on implicit conversions).

In "the deduced parameter types are an exact match", the terms exact match do not make it clear what happens when a type T is compared to the reference type T&. Is that an exact match?

Issue 3:

13.7.7.3 [temp.func.order] paragraph 5 says:

> A template is more specialized than another if, and only if, it is at least as specialized as the other template and that template is not at least as specialized as the first.

What happens in this case:

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

For the first function template, there is no type deduction for the second parameter. So the rules in this clause seem to imply that the second function template will be chosen.

Rationale:

This is not a defect; the standard unambiguously makes the above example ill-formed due to ambiguity.

Additional note (April, 2011):

These points appear to have been addressed by previous resolutions, so presumably the issue is now NAD.

Rationale (August, 2011):

As given in the preceding note.

#### 1520. Alias template specialization vs pack expansion

Section: 13.7.8 [temp.alias] Status: NAD Submitter: Eric Niebler Date: 2012-07-09

The relative order of template parameter pack expansion and alias template substitution is not clear in the current wording. For example, in

      template<typename T> using Int = int;

      template<typename ...Ts> struct S {
        typedef S<Int<Ts>...> other;
      };

it is not clear whether `int` is substituted for `Int<Ts>` first, leaving the ellipsis with no parameter pack to expand, or whether the pack expansion is to be applied first, producing a list of specializations of `Int<T>`.

(See also issue 1558.)

Rationale (October, 2012):

The latter interpretation (a list of specializations) is the correct interpretation; a parameter pack can't be substituted into anything, including an alias template specialization. CWG felt that this is clear enough in the current wording.

#### 560. Use of the `typename` keyword in return types

Section: 13.8 [temp.res] Status: NAD Submitter: Greg Comeau Date: 11 February 2006

Consider the following example:

        template <class T> struct Outer {
            struct Inner {
                Inner* self();
            };
        };
        template <class T> Outer<T>::Inner*
            Outer<T>::Inner::self() { return this; }

According to 13.8 [temp.res] paragraph 3 (before the salient wording was inadvertently removed, see issue 559),

> A qualified-id that refers to a type and in which the nested-name-specifier depends on a template-parameter (13.8.3 [temp.dep]) but does not refer to a member of the current instantiation (13.8.3.2 [temp.dep.type]) shall be prefixed by the keyword `typename` to indicate that the qualified-id denotes a type, forming a typename-specifier.

Because `Outer<T>::Inner` is a member of the current instantiation, the Standard does not currently require that it be prefixed with `typename` when it is used in the return type of the definition of the `self()` member function. However, it is difficult to parse this definition correctly without knowing that the return type is, in fact, a type, which is what the `typename` keyword is for. Should the Standard be changed to require `typename` in such contexts?

Rationale (February, 2021):

The current wording of 13.8.1 [temp.res.general] bullet 5.2.1 makes clear that the `typename` keyword is not required for the given example.

#### 1162. Dependent elaborated-type-specifiers in non-deduced contexts

Section: 13.8 [temp.res] Status: NAD Submitter: CA Date: 2010-08-03
N3092 comment CA 6

The following appears to be well-formed, with templates `foo()` being distinct since any type `T` will produce an invalid type for the second parameter for at least one `foo()` when `T` is replaced within the non-deduced context:

        template <typename T>
          bool *foo(T *, enum T::u_type * = 0) { return 0; }
        template <typename T>
          char *foo(T *, struct T::u_type * = 0) { return 0; }
        struct A { enum u_type { I }; };
        int main(void) { foo((A*)0); }

In particular, while determining the signature for the function templates `foo()`, an elaborated-type-specifier qualifies as part of the decl-specifier-seq under 9.3.4.6 [dcl.fct] paragraph 5 in determining the type of a parameter in the parameter-type-list (absent additional wording). Also, the return type is included in the signature of a function template.

Implementations do not appear to support this case and the ability to do so brings little value since type traits such as `is_enum` and `is_class` cannot be defined using this and equivalent functionality can be achieved using the aforementioned type traits.

Rationale (August, 2010):

The specification is as intended; compilers should handle cases like these.

#### 1483. Non-dependent static_assert-declarations

Section: 13.8 [temp.res] Status: NAD Submitter: Mike Miller Date: 2012-03-23

Recently a customer sent us code of the form,

      template<typename T> void f();
      template<> void f<int>() { }
      template<typename T> void f() {
        static_assert(false, "f() instantiated with non-int type.");
      }

The intent, obviously, was to do compile-time diagnosis of specializations of the template that were not supported, and code of this form is supported by at least some implementations. However, the current wording of 13.8 [temp.res] paragraph 8, appears to invalidate this approach:

> If no valid specialization can be generated for a template, and that template is not instantiated, the template is ill-formed, no diagnostic required.

In this example, the `static_assert` will fail for every generated specialization of `f()`, so an implementation can issue the error, regardless of whether `f()` is ever instantiated with a non-`int` type or not.

A relatively straightforward but somewhat ugly workaround is to define a template like

      template<typename> struct always_false {
        static const bool val = false;
      };

and replace the use of `false` in the `static_assert` with `always_false<T>::val`, making the `static_assert` dependent.

Considering the fact that a non-dependent static_assert-declaration in a template is otherwise pretty useless, however, it might be worth considering whether to support this usage somehow, especially in light of the fact that it is supported by some implementations, perhaps by treating static_assert-declarations as always dependent, even if the condition is not otherwise dependent.

Rationale (October, 2012):

Although this usage is supported by some implementations and used in some libraries, CWG felt that `=delete` is the appropriate mechanism for making a function template or member function of a class template unavailable for specialization.

#### 1547. `typename` keyword in alias-declarations

Section: 13.8 [temp.res] Status: NAD Submitter: Daniel Krügler Date: 2012-09-01

Given that the type-id in an alias-declaration is unambiguously a type, is there a reason to require the `typename` keyword for dependent types appearing there? In other contexts where a dependent name can only be a type (e.g., in a base-specifier), the keyword can/must be omitted.

Rationale (October, 2012):

CWG felt that having a simple rule (advising use of `typename` with all dependent nested types wherever syntactically permitted) was more important than reducing the number of contexts in which the requirement applied.

#### 1785. Conflicting diagnostic requirements for template definitions

Section: 13.8 [temp.res] Status: NAD Submitter: CWG Date: 2013-09-28

According to 13.8 [temp.res] paragraph 8,

> No diagnostic shall be issued for a template for which a valid specialization can be generated.

One sentence later, it says,

> If every valid specialization of a variadic template requires an empty template parameter pack, the template is ill-formed, no diagnostic required.

This appears to be a contradiction: in the latter case, there is postulated to exist a “valid” specialization (with an empty pack expansion), for which a diagnostic might or might not be issued. The first quoted sentence, however, forbids issuing a diagnostic for a template that has at least one valid specialization.

Rationale (February, 2017):

The text in question was revised editorially and the issue is now moot.

#### 1974. Redundant specification of non-type typename-specifier

Section: 13.8 [temp.res] Status: NAD Submitter: Hubert Tong Date: 2014-07-17

Paragraphs 3-4 of 13.8 [temp.res] read, in part,

> When a qualified-id is intended to refer to a type that is not a member of the current instantiation (13.8.3.2 [temp.dep.type]) and its nested-name-specifier refers to a dependent type, it shall be prefixed by the keyword `typename`, forming a typename-specifier. If the qualified-id in a typename-specifier does not denote a type, the program is ill-formed.

> If a specialization of a template is instantiated for a set of template-arguments such that the qualified-id prefixed by typename does not denote a type, the specialization is ill-formed.

The former requirement is intended to apply to the definition and the latter to an instantiation of a template, but that intent is not completely clear, leading to the perception that they are redundant.

Rationale (February, 2021):

The specification, now found in 13.8.1 [temp.res.general], particularly in bullet 8.5, is clearer in this regard.

#### 316. Injected-class-name of template used as template template parameter

Section: 13.8.2 [temp.local] Status: NAD Submitter: Jason Merrill Date: 14 Oct 2001

A gcc hacker recently sent in a patch to make the compiler give an error on code like this:

      template <template <typename> class T> struct A { };

      template <typename U> struct B
      {
        A<B> *p;
      };

presumably because the DR from issue 176 says that we decide whether or not B is to be treated as a template depending on whether a template-argument-list is supplied. I think this is a drafting oversight, and that B should also be treated as a template when passed as a template template parameter. The discussion in the issue list only talks about making the name usable both as a class and as a template.

John Spicer: This case was explicitly discussed and it was agreed that to use the injected name as a template template parameter you need to use the non-injected name.

A (possibly unstated) rule that I've understood about template arguments is that the form of the argument (type/nontype/template) is based only on the argument and not on the kind of template parameter. An example is that "`int()`" is always "function taking no arguments returning int" and never a convoluted way of saying zero.

In a similar way, we now decide whether or not something is a template based only on the form of the argument.

I think this rule is important for two kinds of cases. The first case involves explicit arguments of function templates:

      template <template <typename> class T> void f(){} // #1
      template <class T> void f(){}  // #2

      template <typename U> struct B {
    	void g() {
    		f<B>();
    	}
      };

      int main() {
    	B<int> b;
    	b.g();
      }

With the current rules, this uses B as a type argument to template #2.

The second case involves the use of a class template for which the template parameter list is unknown at the point where the argument list is scanned:

      template <class T> void f(){}

      template <typename U> struct B {
    	void g() {
    		f< U::template X<B> >();  // what is B?
    	}
      };

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

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

      int main() {
    	B<Z1> b1;
    	b1.g();

    	B<Z2> b2;
    	b2.g();
      }

If B could be used as a template name we would be unable to decide how to treat B at the point that it was scanned in the template argument list.

So, I think it is not an oversight and that it should be left the way it is.

Notes from the 4/02 meeting:

It was agreed that this is Not a Defect.

#### 459. Hiding of template parameters by base class members

Section: 13.8.2 [temp.local] Status: NAD Submitter: Daveed Vandevoorde Date: 2 Feb 2004

Currently, member of nondependent base classes hide references to template parameters in the definition of a derived class template.

Consider the following example:

       class B {
          typedef void *It;    // (1)
          // ...
        };

        class M: B {};

        template<typename> X {};

        template<typename It> struct S   // (2)
            : M, X<It> {   // (3)
          S(It, It);   // (4)
          // ...
        };

As the C++ language currently stands, the name "It" in line (3) refers to the template parameter declared in line (2), but the name "It" in line (4) refers to the typedef in the private base class (declared in line (1)).

This situation is both unintuitive and a hindrance to sound software engineering. (See also the Usenet discussion at http://tinyurl.com/32q8d .) Among other things, it implies that the private section of a base class may change the meaning of the derived class, and (unlike other cases where such things happen) there is no way for the writer of the derived class to defend the code against such intrusion (e.g., by using a qualified name).

Changing this can break code that is valid today. However, such code would have to:

1. name a template parameter and not use it after the opening brace, and
2. use that same name to access a base-class name within the braces.

I personally have no qualms breaking such a program.

It has been suggested to make situations like these ill-formed. That solution is unattractive however because it still leaves the writer of a derived class template without defense against accidental name conflicts with base members. (Although at least the problem would be guaranteed to be caught at compile time.) Instead, since just about everyone's intuition agrees, I would like to see the rules changed to make class template parameters hide members of the same name in a base class.

See also issue 458.

Notes from the March 2004 meeting:

We have some sympathy for a change, but the current rules fall straightforwardly out of the lookup rules, so they're not “wrong.” Making private members invisible also would solve this problem. We'd be willing to look at a paper proposing that.

Additional discussion (April, 2005):

John Spicer: Base class members are more-or-less treated as members of the class, [so] it is only natural that the base [member] would hide the template parameter.

Daveed Vandevoorde: Are base class members really “more or less” members of the class from a lookup perspective? After all, derived class members can hide base class members of the same name. So there is some pretty definite boundary between those two sets of names. IMO, the template parameters should either sit between those two sets, or they should (for lookup purposes) be treated as members of the class they parameterize (I cannot think of a practical difference between those two formulations).

John Spicer: How is [hiding template parameters] different from the fact that namespace members can be hidden by private parts of a base class? The addition of `int C` to `N::A` breaks the code in namespace `M` in this example:

        namespace N {
           class A {
        private:
             int C;
           };
        }

        namespace M {
           typedef int C;
           class B : public N::A {
             void f() {
                 C c;
             }
           };
        }

Daveed Vandevoorde: C++ has a mechanism in place to handle such situations: qualified names. There is no such mechanism in place for template parameters.

Nathan Myers: What I see as obviously incorrect ... is simply that a name defined right where I can see it, and directly attached to the textual scope of `B`'s class body, is ignored in favor of something found in some other file. I don't care that `C1` is defined in `A`, I have a `C1` right here that I have chosen to use. If I want `A::C1`, I can say so.

I doubt you'll find any regular C++ coder who doesn't find the standard behavior bizarre. If the meaning of any code is changed by fixing this behavior, the overwhelming majority of cases will be mysterious bugs magically fixed.

John Spicer: I have not heard complaints that this is actually a cause of problems in real user code. Where is the evidence that the status quo is actually causing problems?

In this example, the `T2` that is found is the one from the base class. I would argue that this is natural because base class members are found as part of the lookup in class `B`:

        struct A {
                 typedef int T2;
        };
        template <class T2> struct B : public A {
                 typedef int T1;
                 T1 t1;
                 T2 t2;
        };

This rule that base class members hide template parameters was formalized about a dozen years ago because it fell out of the principle that base class members should be found at the same stage of lookup as derived class members, and that to do otherwise would be surprising.

Gabriel Dos Reis: The bottom line is that:

1. the proposed change is a silent change of meaning;
2. the proposed change does not make the language any more regular; the current behavior is consistent with everything else, however “surprising” that might be;
3. the proposed change does have its own downsides.

Unless presented with real major programming problems the current rules exhibit, I do not think the simple rule “scopes nest” needs a change that silently mutates program meaning.

Mike Miller: The rationale for the current specification is really very simple:

1. “Unless redeclared in the derived class, members of a base class are also considered to be members of the derived class.” (11.7 [class.derived] paragraph 2)
2. In class scope, members hide nonmembers.

That's it. Because template parameters are not members, they are hidden by member names (whether inherited or not). I don't find that “bizarre,” or even particularly surprising.

I believe these rules are straightforward and consistent, so I would be opposed to changing them. However, I am not unsympathetic toward Daveed's concern about name hijacking from base classes. How about a rule that would make a program ill-formed if a direct or inherited member hides a template parameter?

Unless this problem is a lot more prevalent than I've heard so far, I would not want to change the lookup rules; making this kind of collision a diagnosable error, however, would prevent hijacking without changing the lookup rules.

Erwin Unruh: I have a different approach that is consistent and changes the interpretation of the questionable code. At present lookup is done in this sequence:

block scope
derived class scope
base class scope
template parameters
namespace scope

If we change this order to

template parameters
block scope
derived class scope
base class scope
namespace scope

it is still consistent in that no lookup is placed between the base class and the derived class. However, it introduces another inconsistency: now scopes do not nest the same way as curly braces nest — but base classes are already inconsistent this way.

Nathan Myers: This looks entirely satisfactory. If even this seems like too big a change, it would suffice to say that finding a different name by this search order makes the program ill-formed. Of course, a compiler might issue only a portability warning in that case and use the name found Erwin's way, anyhow.

Gabriel Dos Reis: It is a simple fact, even without templates, that a writer of a derived class cannot protect himself against declaration changes in the base class.

Richard Corden: If a change is to be made, then making it ill-formed is better than just changing the lookup rules.

        struct B
        {
          typedef int T;
          virtual void bar (T const & );
        };

        template <typename T>
        struct D : public B
        {
          virtual void bar (T const & );
        };

        template class D<float>;

I think changing the semantics of the above code silently would result in very difficult-to-find problems.

Mike Miller: Another case that may need to be considered in deciding on Erwin's suggestion or the “ill-formed” alternative is the treatment of `friend` declarations described in 6.5.3 [basic.lookup.unqual] paragraph 10:

        struct A {
            typedef int T;
            void f(T);
        };
        template<typename T> struct B {
            friend void A::f(T);  // Currently T is A::T
        };

Notes from the October, 2005 meeting:

The CWG decided not to consider a change to the existing rules at this time without a paper exploring the issue in more detail.

CWG 2023-12-01

CWG has no consensus to pursue a change in this area, without prejudice to a potential future paper addressed to EWG.

#### 544. Base class lookup in explicit specialization

Section: 13.8.3 [temp.dep] Status: NAD Submitter: John Spicer Date: 01 November 2005

There is some question as to whether 13.8.3 [temp.dep] paragraph 3 applies to the definition of an explicitly-specialized member of a class template:

> In the definition of a class template or a member of a class template, if a base class of the class template depends on a template-parameter, the base class scope is not examined during unqualified name lookup either at the point of definition of the class template or member or during an instantiation of the class template or member.

Consider an example like the following:

        template <class T>
        struct A {
         void foo() {}
        };

        template <class T>
        struct B: A<T> {
         int bar();
        };

        int foo() { return 0; }

        template <>
        int B<int>::bar() { return foo(); }

        int main() {
         return B<int>().bar();
        }

Does `foo` in the definition of `B<int>::bar()` refer to `::foo()` or to `A<int>::foo()`?

Rationale (April, 2006):

An explicitly-specialized member of a class template is not, in fact, a member of a class template but a member of a particular specialization of that template. The special treatment of lookup vis-a-vis dependent base classes in 13.8.3 [temp.dep] thus does not apply, and base class members are found by unqualified name lookup.

#### 1281. Virtual and dependent base classes

Section: 13.8.3.2 [temp.dep.type] Status: NAD Submitter: Johannes Schaub Date: 2011-03-28

Consider the following example:

      struct A {
       virtual void f() { /* base */ }
      };

      struct B : virtual A {
       virtual void f() { /* derived */ }
      };

      template<typename T>
      struct C : virtual A, T {
       void g() {
        this->f();
       }
      };

      int main() {
       C<B> c;
       c.g();
      }

This is reasonable C++03 code that is invalidated by the resolution of issue 1043. In the presence of virtual non-dependent base classes and other dependent base classes, one cannot rely on something being found for real when doing the lookup in the instantiation context (therefore, one cannot know whether a "typename" is actually valid or not, without knowing all dependent base classes).

Rationale (August, 2011):

This example is not sufficient motivation to revisit the outcome of issue 1043. `((T*)this)->f()` can be used to allow lookup in a dependent base.

#### 1289. Can an alias template name the current instantiation?

Section: 13.8.3.2 [temp.dep.type] Status: NAD Submitter: James Widman Date: 2011-04-06

It does not appear to be possible to use the name of an alias template (without a template argument list) to refer to the current instantiation.

Rationale (August, 2011):

The rules are as intended.

#### 1905. Dependent types and injected-class-names

Section: 13.8.3.2 [temp.dep.type] Status: NAD Submitter: Johannes Schaub Date: 2014-03-29

According to 13.8.2 [temp.local] paragraph 1, when the injected-class-name of a class template is not followed by a template-argument-list or otherwise used as a template-name,

> it is equivalent to the template-name followed by the template-parameters of the class template enclosed in `<>`.

This use of the template-parameters of the class template should make the injected-class-name a dependent type; however, the definition of dependent types in 13.8.3.2 [temp.dep.type] paragraph 8 applies to the injected-class-name only when it appears in a simple-template-id. An additional case is needed for the bare injected-class-name.

Rationale (June, 2014):

The fact that the use of the bare injected-class-name is described as “equivalent” to the simple-template-id is sufficiently clear regarding its status that no additional entry is needed in the list of dependent types.

#### 334. Is a comma-expression dependent if its first operand is?

Section: 13.8.3.3 [temp.dep.expr] Status: NAD Submitter: John Spicer Date: 10 Jan 2002

Is the comma expression in the following dependent?

      template <class T> static void f(T)
      {
      }
      template <class T> void g(T)
      {
        f((T::x, 0));
      }
      struct A {
        static int x;
      };
      void h()
      {
        g(A());
      }

According to the standard, it is, because 13.8.3.3 [temp.dep.expr] says that an expression is dependent if any of its sub-expressions is dependent, but there is a question about whether the language should say something different. The type and value of the expression are not really dependent, and similar cases (like casting `T::x` to `int`) are not dependent.

Mark Mitchell: If the first operand is dependent, how do we know it does not have an overloaded comma operator?

Rationale (October, 2004):

CWG agreed that such comma expressions are and ought to be dependent, for the reason expressed in Mark Mitchell's comment.

#### 34. Argument dependent lookup and points of instantiation

Section: 13.9.2 [temp.inst] Status: NAD Submitter: Daveed Vandevoorde Date: 15 Jul 1998

Does Koenig lookup create a point of instantiation for class types? I.e., if I say:

        TT<int> *p;
        f(p);

The namespaces and classes associated with `p` are those associated with the type pointed to, i.e., `TT<int>`. However, to determine those I need to know `TT<int>` bases and its friends, which requires instantiation.

Or should this be special cased for templates?

Rationale: The standard already specifies that this creates a point of instantiation.

#### 489. Must member function templates be instantiated during overload resolution?

Section: 13.9.2 [temp.inst] Status: NAD Submitter: Daveed Vandevoorde Date: 24 Nov 2004

A related question to that raised in issue 488 is whether member function templates must be instantiated if the compiler can determine that they will not be needed by the function selected by overload resolution. That is explicitly specified for class templates in 13.9.2 [temp.inst] paragraph 5:

> If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place.

Should the same be true for member function templates? In the example from issue 488,

        struct S {
            template <typename T> S(const T&);
        };
        void f(const S&);
        void f(int);
        void g() {
            enum E { e };
            f(e);    // ill-formed?
        }

a compiler could conceivably determine that `f(int)` would be selected by overload resolution (because it involves only an integral promotion, while the alternative requires a user-defined conversion) without instantiating the declaration of the `S` constructor. Should the compiler have that freedom?

Rationale (April, 2005):

In order for this question to come up, there would need to be a “gap” between the the normal rules and the rules for template argument deduction failure. The resolution for issue 488 will close the only such gap of which the CWG is aware. The issue can be reopened if other such cases turn up.

#### 2655. Instantiation of default arguments in lambda-expressions

Section: 13.9.2 [temp.inst] Status: NAD Submitter: Tom Honermann Date: 2022-08-16

Subclause 7.5.6.2 [expr.prim.lambda.closure] paragraph 2 specifies:

> The closure type is declared in the smallest block scope, class scope, or namespace scope that contains the corresponding lambda-expression.

This means the closure type is a local class if the lambda-expression appears at function scope. A note in 13.9.2 [temp.inst] paragraph 2 claims that default arguments inside local classes are not separately instantiated:

> [Note 3: Within a template declaration, a local class (11.6 [class.local]) or enumeration and the members of a local class are never considered to be entities that can be separately instantiated (this includes their default arguments, noexcept-specifier s, and non-static data member initializers, if any, but not their type-constraints or requires-clauses). As a result, the dependent names are looked up, the semantic constraints are checked, and any templates used are instantiated as part of the instantiation of the entity within which the local class or enumeration is declared. —end note]

However, 13.9.2 [temp.inst] paragraph 3 is not in harmony with the note:

> The implicit instantiation of a class template specialization does not cause the implicit instantiation of default arguments or noexcept-specifier s of the class member functions.

Example:

      template<typename T>
      void ft() {
       [](T p = T::value) {}; // error even though the lambda is never called
      }
      template void ft<int>();

Even for a lambda declared at namespace scope is an unused default argument instantiated by major implementations:

      template<typename T>
      using ta = decltype([](T p = T::value) { // error
    	     return p;
    	    });
      auto g = ta<int>{}(0);

CWG 2023-11-11

The behavior is as intended. Note that 13.9.2 [temp.inst] paragraph 3 applies to a class template specialization and its member functions. The examples do not involve class templates, but merely templated classes.

#### 2893. Instantiations in discarded `if constexpr` substatements

Section: 13.9.2 [temp.inst] Status: NAD Submitter: Jan Schultke Date: 2024-05-09

(From submission #535.)

Consider:

      void g() {
        auto f = [](auto s) {
          s.x = 0;
        };
        if constexpr (false) {
          f(0);   // well-formed?
        }
      }

Note that the lambda has a deduced return type, yet per the current wording, `f` is not instantiated here.

Possible resolution:

Add a new paragraph before 13.9.2 [temp.inst] paragraph 9 as follows:

> The existence of a definition of a function is considered to affect the semantics of the program if the function is named by an expression (6.3 [basic.def.odr]) and the function's declared return type is a placeholder type (9.2.9.7 [dcl.spec.auto]). [ Example:

>       void g() {
>         auto f = [](auto s) {
>           s.x = 0;  // #1
>         };
>         if constexpr (false) {
>           f(0);     // error at #1: type int has no member named x
>         }
>       }

> -- end example ]

> If the function selected by overload resolution (12.2 [over.match]) can be determined without ...

CWG 2024-06-14

The original example involving a deduced return type of the lambda is ill-formed, because the semantics of the program are affected by its return type, and thus an instantion is required (13.9.2 [temp.inst] paragraph 5): If the lambda returned a class type with a private destructor, the program would be ill-formed.

The modified example with a `void` return type of the lambda is well-formed; clang's implementation divergence is believed to be a bug.

As a side note, odr-use is not affected by discarded statements; just some of the effects of odr-use do not materialize (6.3 [basic.def.odr] paragraph 12).

#### 46. Explicit instantiation of member templates

Section: 13.9.3 [temp.explicit] Status: NAD Submitter: John H. Spicer Date: 28 Jan 1998

Is the second explicit instantiation below well-formed?

        template <class T> struct A {
            template <class T2> void f(T2){}
        };

        template void A<int>::f(char); // okay

        template template void A<int>::f(float); // ?

Since multiple "`template<>`" clauses are permitted in an explicit specialization, it might follow that multiple "`template`" keywords should also be permitted in an explicit instantiation. Are multiple "`template`" keywords not allowed in an explicit instantiation? The grammar permits it, but the grammar permits lots of stuff far weirder than that. My opinion is that, in the absence of explicit wording permitting that kind of usage (as is present for explicit specializations) that such usage is not permitted for explicit instantiations.

Rationale (04/99): The Standard does not describe the meaining of multiple `template` keywords in this context, so the example should be considered as resulting in undefined behavior according to Clause 3 [intro.defs] “undefined behavior.”

#### 1045. Requiring explicit instantiation declarations

Section: 13.9.3 [temp.explicit] Status: NAD Submitter: Doug Gregor Date: 2010-03-05

The current language specification allows suppression of implicit instantiations of templates via an explicit instantiation declaration; if all uses of a particular specialization follow an explicit instantiation declaration for that specialization, and there is one explicit instantiation definition in the program, there will be only a single copy of that instance. However, the Standard does not require the presence of an explicit instantiation declaration prior to use, so implementations must still be prepared (using weak symbols, for example) to handle multiple copies of the instance at link time. This can be a significant overhead, particularly in shared libraries where weak symbols must be resolved at load time. Requiring the presence of an explicit instantiation declaration in every translation unit in which the specialization is used would allow the compiler to emit strong symbols for the explicit instantiation definition and reduce the overhead.

On the other hand, the current definition allows use of multiple independent libraries with explicit instantiation directives of the same specializations (from a common third-party library, for instance), as well as incremental migration of libraries to use of explicit instantiation declarations rather than requiring all libraries to be updated at once.

Rationale (August, 2010):

CWG prefers the current specification.

#### 1163. `extern template` prevents inlining functions not marked `inline`

Section: 13.9.3 [temp.explicit] Status: NAD Submitter: US Date: 2010-08-03
N3092 comment US 76

According to 13.9.3 [temp.explicit] paragraph 9,

> Except for inline functions and class template specializations, explicit instantiation declarations have the effect of suppressing the implicit instantiation of the entity to which they refer.

This means that an implementation cannot do inline expansion of an `extern template` function or member function, because that would require its instantiation. As a result, adding an explicit instantiation declaration can affect performance, even though the user only intended to suppress out-of-line copies of functions.

Rationale (August, 2010):

If implementations are allowed to do speculative instantiation for the purpose of inlining, there could be silent changes of meaning depending on whether the instantiation is done or not.

#### 2161. Explicit instantiation declaration and “preceding initialization”

Section: 13.9.3 [temp.explicit] Status: NAD Submitter: Hubert Tong Date: 2015-07-22

Consider the following example:

      template <typename T> extern const decltype(sizeof 0) Sz = sizeof(T);
      extern template const decltype(sizeof 0) Sz<int>;

      constexpr decltype(sizeof 0) x = Sz<int>;

C++14 allows this, exempting “const variables of literal type" from the effects of an explicit instantiation declaration:

> Except for inline functions, declarations with types deduced from their initializer or return value (9.2.9.7 [dcl.spec.auto]), const variables of literal types, variables of reference types, and class template specializations, explicit instantiation declarations have the effect of suppressing the implicit instantiation of the entity to which they refer. [Note: The intent is that an inline function that is the subject of an explicit instantiation declaration will still be implicitly instantiated when odr-used (6.3 [basic.def.odr]) so that the body can be considered for inlining, but that no out-of-line copy of the inline function would be generated in the translation unit. —end note]

Should there be a DR against C++11 for the similar case of a static data member of a class template?

Rationale (October, 2015):

CWG agreed that this was a defect in C++11, but it is addressed in C++14.

#### 2270. Non-inline functions and explicit instantiation declarations

Section: 13.9.3 [temp.explicit] Status: NAD Submitter: Richard Smith Date: 2016-06-10

Consider:

      template <class F> F foo() { return 1; }
      template <class F> struct S { F foo() { return 1; } };
      extern template int foo<int>();
      extern template struct S<int>;
      int bar() { return foo<int>() + S<int>().foo(); }

An implementation is permitted to instantiate (and thus locally inline) `S<int>::foo`, but not `S<int>`, because 13.9.2 [temp.inst] paragraph 10 states:

> Except for inline functions, declarations with types deduced from their initializer or return value (9.2.9.7 [dcl.spec.auto]), const variables of literal types, variables of reference types, and class template specializations, explicit instantiation declarations have the effect of suppressing the implicit instantiation of the entity to which they refer.

Additional note (February, 2022):

The paragraph in question was removed by P1815R2 (Translation-unit-local entities) (adopted 2020-02).

EWG 2022-11-11

Any change would require a paper.

#### 3. The template compilation model rules render some explicit specialization declarations not visible during instantiation

Section: 13.9.4 [temp.expl.spec] Status: NAD Submitter: Bill Gibbons Date: unknown

[N1065 issue 1.19] An explicit specialization declaration may not be visible during instantiation under the template compilation model rules, even though its existence must be known to perform the instantiation correctly. For example:

translation unit #1

          template<class T> struct A { };
          export template<class T> void f(T) { A<T> a; }

translation unit #2

          template<class T> struct A { };
          template<> struct A<int> { }; // not visible during instantiation
          template<class T> void f(T);
          void g() { f(1); }

Rationale: This issue was addressed in the C++11 FDIS and should have been closed.

#### 88. Specialization of member constant templates

Section: 13.9.4 [temp.expl.spec] Status: NAD Submitter: Jason Merrill Date: 20 Jan 1999

Is this valid C++? The question is whether a member constant can be specialized. My inclination is to say no.

        template <class T> struct A {
            static const T i = 0;
        };

        template<> const int A<int>::i = 42;

        int main () {
            return A<int>::i;
        }

John Spicer: This is ill-formed because 11.4.9.3 [class.static.data] paragraph 4 prohibits an initializer on a definition of a static data member for which an initializer was provided in the class.

The program would be valid if the initializer were removed from the specialization.

Daveed Vandevoorde: Or at least, the specialized member should not be allowed in constant-expressions.

Bill Gibbons: Alternatively, the use of a member constant within the definition could be treated the same as the use of "sizeof(member class`)`". For example:

        template <class T> struct A {
            static const T i = 1;
            struct B { char b[100]; };
            char x[sizeof(B)];     // specialization can affect array size
            char y[i];             // specialization can affect array size
        };

        template<> const int A<int>::i = 42;
        template<> struct A<int>::B { char z[200] };

        int main () {
            A<int> a;
            return sizeof(a.x)   // 200  (unspecialized value is 100)
                 + sizeof(a.y);  // 42   (unspecialized value is 1)
        }

For the member template case, the array size "`sizeof(B)`" cannot be evaluated until the template is instantiated because `B` might be specialized. Similarly, the array size "`i`" cannot be evaluated until the template is instantiated.

Rationale (10/99): The Standard is already sufficiently clear on this question.

#### 182. Access checking on explicit specializations

Section: 13.9.4 [temp.expl.spec] Status: NAD Submitter: John Spicer Date: 8 Nov 1999

John Spicer: Certain access checks are suppressed on explicit instantiations. 13.9.3 [temp.explicit] paragraph 8 says:

> The usual access checking rules do not apply to names used to specify explicit instantiations. [Note: In particular, the template arguments and names used in the function declarator (including parameter types, return types and exception specifications) may be private types or objects which would normally not be accessible and the template may be a member template or member function which would not normally be accessible. ]

I was surprised that similar wording does not exist (that I could find) for explicit specializations. I believe that the two cases should be handled equivalently in the example below (i.e., that the specialization should be permitted).

        template <class T> struct C {
        void f();
        void g();
        };

        template <class T> void C<T>::f(){}
        template <class T> void C<T>::g(){}

        class A {
        class B {};
        void f();
        };

        template void C<A::B>::f();    // okay
        template <> void C<A::B>::g(); // error - A::B inaccessible

        void A::f() {
        C<B> cb;
        cb.f();
        }

Mike Miller: According to the note in 13.4 [temp.arg] paragraph 3,

> if the name of a template-argument is accessible at the point where it is used as a template-argument, there is no further access restriction in the resulting instantiation where the corresponding template-parameter name is used.

(Is this specified anywhere in the normative text? Should it be?)

In the absence of text to the contrary, this blanket permission apparently applies to explicitly-specialized templates as well as to implicitly-generated ones (is that right?). If so, I don't see any reason that an explicit instantiation should be treated differently from an explicit specialization, even though the latter involves new program text and the former is just a placement instruction to the implementation.

Proposed Resolution (4/02):

In 13.9.3 [temp.explicit] delete paragraph 8:

> The usual access checking rules do not apply to names used to specify explicit instantiations. [Note: In particular, the template arguments and names used in the function declarator (including parameter types, return types and exception specifications) may be private types or objects which would normally not be accessible and the template may be a member template or member function which would not normally be accessible. ]

In 13.9 [temp.spec] add the paragraph deleted above as paragraph 7 with the changes highlighted below:

> The usual access checking rules do not apply to names used to specify explicit instantiations or explicit specializations. [Note: In particular, t The template arguments and names used in the function declarator (including parameter types, return types and exception specifications) may be private types or objects which would normally not be accessible and the template may be a member template or member function which would not normally be accessible. ]

Rationale (October 2002):

We reconsidered this and decided that the difference between the two cases (explicit specialization and explicit instantiation) is appropriate. The access rules are sometimes bent when necessary to allow naming something, as in an explicit instantiation, but explicit specialization requires not only naming the entity but also providing a definition somewhere.

#### 285. Identifying a function template being specialized

Section: 13.9.4 [temp.expl.spec] Status: NAD Submitter: Erwin Unruh Date: 01 May 2001

The Standard does not describe how to handle an example like the following:

        template <class T> int f(T, int);
        template <class T> int f(int, T);

        template<> int f<int>(int, int) { /*...*/ }

It is impossible to determine which of the function templates is being specialized. This problem is related to the discussion of issue 229, in which one of the objections raised against partial specialization of function templates is that it is not possible to determine which template is being specialized.

Notes from 10/01 meeting:

It was decided that while this is true, it's not a problem. You can't call such functions anyway; the call would be ambiguous.

#### 1727. Type of a specialization of a variable template

Section: 13.9.4 [temp.expl.spec] Status: NAD Submitter: Larisse Voufo Date: 2013-08-05

It is not clear whether there is any necessary relationship between the type specified in a primary variable template declaration and the type in an explicit or partial specialization. For example:

      template<typename T> T var = T();
      template<> char var<char> = 'a';           // #1.
      template<typename T> T* var<T> = new T();  // #2.
      template<> float var<int> = 1.5;           // #3.

Rationale (September, 2013):

CWG affirmed that there is no required relationship between the type of the template and the type of a partial or explicit specialization of that template.

#### 1792. Incorrect example of explicit specialization of member enumeration

Section: 13.9.4 [temp.expl.spec] Status: NAD Submitter: John Spicer Date: 2013-10-01

The example in 13.9.4 [temp.expl.spec] paragraph 6 reads, in part,

      template<class T> struct A {
        enum E : T;
        enum class S : T;
      };
      template<> enum A<int>::E : int { eint };         // OK
      template<> enum class A<int>::S : int { sint };   // OK
      template<class T> enum A<T>::E : T { eT };
      template<class T> enum class A<T>::S : T { sT };
      template<> enum A<char>::E : int { echar };       // ill-formed, A<char>::E was instantiated
                                                        // when A<char> was instantiated
      template<> enum class A<char>::S : int { schar }; // OK

The `int` enum-base in the last two lines appears to be incorrect; the reference to `A<char>` in the nested-name-specifier will have instantiated the declarations of `E` and `S` with an enum-base of `char`, and the explicit specializations must agree.

Rationale (February, 2014):

The problem was fixed editorially in N3797.

#### 1876. Preventing explicit specialization

Section: 13.9.4 [temp.expl.spec] Status: NAD Submitter: John Spicer Date: 2014-02-19

A desire has been expressed for a mechanism to prevent explicitly specializing a given class template, in particular `std::initializer_list` and perhaps some others in the standard library. It is not clear whether simply adding a prohibition to the description of the templates in the library clauses would be sufficient or whether a core language mechanism is required.

Rationale (June, 2014):

This request for a new language feature should be considered by EWG before any action is taken.

EWG 2022-11-11

The library clauses already prohibit user specializations of standard library templates. This is a request for new feature, which should be proposed in a paper to EWG.

#### 2138. Explicit member specialization vs implicit instantiation

Section: 13.9.4 [temp.expl.spec] Status: NAD Submitter: Richard Smith Date: 2015-06-11

It is not clear whether the following common practice is valid by the current rules:

       // foo.h
       template<typename T> struct X {
        int f(); // never defined
       };

       // foo.cc
       #include "foo.h"
       template<> int X<int>::f() { return 123; }

       // main.cc
       #include "foo.h"
       int main() { return X<int>().f(); }

Relevant rules include Clause 13 [temp] paragraph 6,

> A function template, member function of a class template, variable template, or static data member of a class template shall be defined in every translation unit in which it is implicitly instantiated (13.9.2 [temp.inst]) unless the corresponding specialization is explicitly instantiated (13.9.3 [temp.explicit]) in some translation unit; no diagnostic is required.

13.9.2 [temp.inst] paragraph 2,

> Unless a member of a class template or a member template has been explicitly instantiated or explicitly specialized, the specialization of the member is implicitly instantiated when the specialization is referenced in a context that requires the member definition to exist...

and 13.9.4 [temp.expl.spec] paragraph 6:

> If a template, a member template or a member of a class template is explicitly specialized then that specialization shall be declared before the first use of that specialization that would cause an implicit instantiation to take place, in every translation unit in which such a use occurs; no diagnostic is required. If the program does not provide a definition for an explicit specialization and either the specialization is used in a way that would cause an implicit instantiation to take place or the member is a virtual member function, the program is ill-formed, no diagnostic required. An implicit instantiation is never generated for an explicit specialization that is declared but not defined.

The intent appears to be that the reference in `main.cc` violates two rules: it implicitly instantiates something for which no definition is provided and that is not explicitly instantiated elsewhere, and it also causes an implicit instantiation of something explicitly specialized in another translation unit without a declaration of the explicit specialization.

Rationale (March, 2016):

As stated in the analysis, the intent is for the example to be ill-formed, no diagnostic required.

#### 1386. Explicitly-specified partial argument list with multiple parameter packs

Section: 13.10.2 [temp.arg.explicit] Status: NAD Submitter: James Widman Date: 2011-09-01

Given

        template<class T, class U> struct A { };
        template<class... T, class ... U> void f( A<T,U>...p);

        void g() {
            f<int>(
                A<int,unsigned>(),
                A<short,unsigned short>()
                );
        }

I would expect this to work, but all the recent compilers I tried reject it, indicating deduction failure.

Rationale (April, 2013):

This is well-formed.

#### 1982. Deduction extending parameter pack

Section: 13.10.2 [temp.arg.explicit] Status: NAD Submitter: Filip Roséen Date: 2014-08-09

According to 13.10.2 [temp.arg.explicit] paragraph 9,

> Template argument deduction can extend the sequence of template arguments corresponding to a template parameter pack, even when the sequence contains explicitly specified template arguments.

However, it is not clear how to handle an example like:

      template<class...> struct Z {
        Z (int);
      };

      template<class... Ts> void f (Z<Ts...>);

      int main () {
        f<void, void> (0);
      }

Rationale (November, 2014):

CWG was not convinced that such cases are sufficiently useful to warrant the additional complexity in the rules required to support them.

#### 2200. Conversions in template argument deduction

Section: 13.10.2 [temp.arg.explicit] Status: NAD Submitter: Vinny Romano Date: 2015-11-14

Consider:

      struct S
      {
       operator int();
      };

      template<int N>
      void f(const int (&)[N]);

      int main()
      {
       S s;
       f<2>({s, s}); // #1
       f({s, s});  // #2
      }

Since the array element type is not deduced, implicit conversions ought to be permitted in #2 but other implementations disagree. Is there a compelling reason to disallow them?

For comparison:

      #include <initializer_list>

      struct S
      {
       operator int();
      };

      template<typename T>
      void f(std::initializer_list<T>);

      int main()
      {
       S s;
       f<int>({s, s});
      }

Because T is not deduced, implicit conversions are allowed, and the number of elements in the underlying temporary array is determined from the number of elements in the initializer list. It seems that the intention of issue 1591 was to allow the underlying temporary array to be deduced directly, so the fact that the array bounds are deduced in the case above shouldn't inhibit implicit conversions.

Rationale (November, 2016):

Although there is an argument to be made for the suggested direction, the current rule is simple and easy to explain, so there was no consensus for a change.

#### 297. Which template does an explicit specialization specialize?

Section: 13.10.3 [temp.deduct] Status: NAD Submitter: Andrei Iltchenko Date: 7 Jul 2001

Andrei Iltchenko points out that the standard has no wording that defines how to determine which template is specialized by an explicit specialization of a function template. He suggests "template argument deduction in such cases proceeds in the same way as when taking the address of a function template, which is described in 13.10.3.3 [temp.deduct.funcaddr]."

John Spicer points out that the same problem exists for all similar declarations, i.e., friend declarations and explicit instantiation directives. Finding a corresponding placement `operator delete` may have a similar problem.

John Spicer: There are two aspects of "determining which template" is referred to by a declaration: determining the function template associated with the named specialization, and determining the values of the template arguments of the specialization.

        template <class T> void f(T);  #1
        template <class T> void f(T*); #2
        template <> void f(int*);

In other words, which `f` is being specialized (#1 or #2)? And then, what are the deduced template arguments?

13.7.7.3 [temp.func.order] does say that partial ordering is done in contexts such as this. Is this sufficient, or do we need to say more about the selection of the function template to be selected?

13.10.3 [temp.deduct] probably needs a new section to cover argument deduction for cases like this.

Rationale (February, 2021):

The missing specification was added by C++11; see 13.10.3.7 [temp.deduct.decl].

#### 662. Forming a pointer to a reference type

Section: 13.10.3 [temp.deduct] Status: NAD Submitter: Alisdair Meredith Date: 28 November 2007

The Standard currently specifies (9.2.4 [dcl.typedef] paragraph 9, 13.4.2 [temp.arg.type] paragraph 4) that an attempt to create a reference to a reference (via a typedef or template type parameter) is effectively ignored. The same is not true of an attempt to form a pointer to a reference; that is, assuming that `T` is specified to be a reference type,

        template <typename T> void f(T t) {
            T& tr = t;   // OK
            T* tp = &t;  // error
        }

It would be more consistent to allow pointers to references to collapse in the same way that references to references do.

Rationale (February, 2008):

In the absence of a compelling need, the CWG felt that it was better not to change the existing rules. Allowing this case could cause a quiet change to the meaning of a program, because attempting to create a pointer to a reference type is currently a deduction failure.

Additional discussion (May, 2009):

Consider the following slightly extended version of the example above:

        template <typename T> void f(T t) {
            T& tr = t;   // OK
            T* tp = &t;  // error
            auto * ap = &t; // OK!
        }

This means that a template that expects a reference type will need to use `auto` just to work around the failure to collapse pointer-to-reference types. The result might, in fact, be subtly different with `auto`, as well, in case there is an overloaded `operator&` function that doesn't return exactly `T*`. This contradicts one of the main goals of C++0x, to make it simpler, more consistent, and easier to teach.

Rationale (July, 2009):

The CWG reaffirmed its early decision. In general, templates will need to be written differently for reference and non-reference type parameters. Also, the Standard library provides a facility, `std::remove_reference`, that can be used easily for such cases.

#### 1273. Accessibility and function signatures

Section: 13.10.3 [temp.deduct] Status: NAD Submitter: Jason Merrill Date: 2011-03-24

With the resolution of issue 1170, which takes access into account in template argument deduction, it is now possible to have instantiation-dependent expressions (see issue 1172) that do not directly involve a template parameter. For example:

      template <class T> struct C;

      class A
      {
        int i;
        friend struct C<int>;
      } a;

      class B
      {
        int i;
        friend struct C<float>;
      } b;

      template <class T>
      struct C
      {
        template <class U> decltype (a.i) f() { } // #1
        template <class U> decltype (b.i) f() { } // #2
      };

      int main()
      {
        C<int>().f<int>();   // calls #1
        C<float>().f<float>(); // calls #2
      }

Rationale (August, 2011):

The specification is as intended. To the extent that there is an issue here, it is covered by issue 1172.

#### 1546. Errors in function template default arguments

Section: 13.10.3 [temp.deduct] Status: NAD Submitter: Jason Merrill Date: 2012-08-27

Given an example like

      template <class T> void f (T, int = T());
      template <class T> auto g(T t) -> decltype (f(t));
      void g(int);

      struct A { A(int); operator int(); };

      int main() {
        g(A(42));
      }

it seems that since the default argument is treated as a separate template, its ill-formedness causes a hard error, rather than a substitution failure for `g`. Is this what we want?

Rationale (October, 2012):

CWG felt that this was acceptable; also, there is discussion in EWG regarding changes to the SFINAE rules that could affect this case.

#### 99. Partial ordering, references and cv-qualifiers

Section: 13.10.3.2 [temp.deduct.call] Status: NAD Submitter: Mike Miller Date: 5 Mar 1999

Consider:

        template <class T> void f(T&);
        template <class T> void f(const T&);
        void m() {
            const int p = 0;
            f(p);
        }

Some compilers treat this as ambiguous; others prefer `f(const T&)`. The question turns out to revolve around whether 13.10.3.2 [temp.deduct.call] paragraph 2 says what it ought to regarding the removal of cv-qualifiers and reference modifiers from template function parameters in doing type deduction.

John Spicer: The partial ordering rules as originally proposed specified that, for purposes of comparing parameter types, you remove a top level reference, and after having done that you remove top level qualifiers. This is not what is actually in the IS however. The IS says that you remove top level qualifiers and then top level references.

The original rules were intended to prefer `f(A<T>)` over `f(const T&)`.

Rationale (10/99): The Standard correctly reflects the intent of the Committee.

(October 2002) This is resolved by issue 214.

#### 1014. Overload resolution between `const T&` and `T&&`

Section: 13.10.3.2 [temp.deduct.call] Status: NAD Submitter: Steve Adamczyk Date: 2009-12-17

In the following example,

        template<typename T> void f(const T&);  // #1
        template<typename T> void f(T&&);       // #2
        void g() {
            const int x = 5;
            f(x);
        }

the call `f(x)` is ambiguous by the current rules. For #1, `T` is deduced as `int`, giving

        f<int>(const int&)

For #2, because of the special case for `T&&` in 13.10.3.2 [temp.deduct.call] paragraph 3, `T` is deduced as `const int&`; application of the reference-collapsing rules in 9.3.4.3 [dcl.ref] paragraph 6 to the substituted parameter type yields

        f<const int&>(const int&)

These are indistinguishable in overload resolution, resulting in an ambiguity. It's not clear how this might be addressed.

Rationale (August, 2010):

The two functions are distinguished by partial ordering, so the call is not actually ambiguous.

#### 1671. Unclear rules for deduction with cv-qualification

Section: 13.10.3.2 [temp.deduct.call] Status: NAD Submitter: Steve Clamage Date: 2013-04-26

1. Simple pointer:

Template argument: `const T*`
Actual argument: `char*`
We deduce `T` to be `char`, and by compatibility of cv-qualifiers, this deduction works.

Now suppose that (somehow) we deduced `T` to be `const char`. We fold the resulting `const const char*` into `const char*`, and again the deduction works. Does the standard disallow this deduction? The reason for this question is in the next example.

2. Pointer to member:

Template argument: `const T A<T>::*`, where `A` is a class template
Actual argument: `char A<const char>::*`
Compilers reject this case, because if we deduce the first `T` to be `char`, we cannot match `A<T>::*`. But suppose we look first at the second `T`, deducing it to be `const char`. Then we get `const char A<const char>::*`, which is OK. Alternatively, as in the hypothetical case in example 1, suppose we deduce the first `T` to be `const char`, again we get a match.

Arbitrarily adding extra cv-qualifiers in looking for a match, or trying different matching orders to find one that works, seems wrong. But are these approaches disallowed?

For completeness, here is a code example:

      template <typename Q>
      struct A {
        int i;
      };

      template <typename T>
      void foo(const T A<T>::*) { }

      int main() {
        A<const int> a;
        int A<const int>::*p = &A<const int>::i;
        foo(p);  // rejected by all compilers, but why?
      }

Rationale (September, 2013):

There are no rules that would result in deducing `const char` in the specified example.

#### 1700. Does the special rvalue-reference deduction apply to alias templates?

Section: 13.10.3.2 [temp.deduct.call] Status: NAD Submitter: Daveed Vandevoorde Date: 2013-06-14

An rvalue reference type involving a template parameter receives special treatment in template argument deduction in 13.10.3.2 [temp.deduct.call] paragraph 3:

> If `P` is an rvalue reference to a cv-unqualified template parameter and the argument is an lvalue, the type “lvalue reference to `A`” is used in place of `A` for type deduction.

Does this rule apply when the parameter type involves an alias template instead of using a template parameter directly? For example:

        template<class T> using RR = T&&;

        template<class T> struct X {};
        template<class T> struct X<T&&>; // Leave incomplete to possibly trigger an error

        template<class T> void g(RR<T> p) {
          X<decltype(p)> x;
        }

        int main() {
          int x = 2;
          g(x);
        }

There is implementation variance on the treatment of this example.

Additional note (October, 2013):

It was observed that the type of the parameter would be the same whether written as `T&&` or as `RR<T>`, which would require that deduction be performed the same, regardless of how the type was written.

Rationale (September, 2013):

Because the types of the function parameters are the same, regardless of whether written directly or via an alias template, deduction must be handled the same way in both cases.

#### 885. Partial ordering of function templates with unordered parameter pairs

Section: 13.10.3.5 [temp.deduct.partial] Status: NAD Submitter: Mike Miller Date: 1 May, 2009

Consider the following example:

        template <typename T> void f(T** p, void (*)());  // #1
        template <typename T> void f(T* p, void (&)());   // #2
        void x();
        void g(int** p) {
          f(p, x);    // #3
        }

The question is whether the call at #3 is ambiguous or not.

The synthesized declarations for overload resolution are:

        void f<int>(int**, void(*)());   // From #1
        void f<int*>(int**, void(&)());  // From #2

Neither of these is a better match on the basis of conversion sequences (the function-to-pointer conversion and the reference binding have “exact match” rank), and both are function template specializations, so the tiebreaker in 12.2.4 [over.match.best] paragraph 1 comes down to whether #1 is more specialized than #2 or vice versa.

The determination of whether one of these templates is more specialized than the other is done (as described in 13.7.7.3 [temp.func.order]) by synthesizing a type for the template parameter of each function template (call them `@1` and `@2`, respectively), substituting that synthesized type for each occurrence of the template parameter in the function type of the template, and then performing deduction on each pair of corresponding function parameters as described in 13.10.3.5 [temp.deduct.partial].

For the first function parameter, #1 is more specialized: deduction succeeds with `P=T*` and `A=@1**`, giving `T=@1*`, but it fails with `P=T**` and `A=@2*`. For the second parameter, deduction fails in both directions, with `P=void(*)()` and `A=void()` as well as with `P=void()` and `A=void(*)()` (the reference is dropped from both the parameter and argument types, as described in 13.10.3.5 [temp.deduct.partial] paragraph 5). This means that neither parameter type is at least as specialized as the other (paragraph 8).

According to 13.10.3.5 [temp.deduct.partial] paragraph 10,

> If for each type being considered a given template is at least as specialized for all types and more specialized for some set of types and the other template is not more specialized for any types or is not at least as specialized for any types, then the given template is more specialized than the other template. Otherwise, neither template is more specialized than the other.

According to this rule, #1 is not more specialized than #2 because it is not “at least as specialized” for the second parameter type, so the call at #3 is ambiguous.

Results vary among implementations, with some rejecting the call as ambiguous and others resolving it to #1.

Would it be better to say that a function template F1 is more specialized than F2 if at least one of F1's types is more specialized than the corresponding F2 type and none of F2's types is more specialized than the corresponding F1 type? That would be simpler and, for examples like this, arguably more intuitive. The rationale for this change would be that if, for a given parameter pair, neither is more specialized than the other, then that parameter pair simply says nothing about whether one of the templates is more specialized than the other, rather than indicating that the templates cannot be ordered.

(See also issue 455.)

Rationale (October, 2009):

The consensus of the CWG is that this issue, in which corresponding parameters cannot be compared but the functions are equivalent in terms of overload resolution, arises so infrequently in practice that no change is warranted at this time.

#### 2350. Forwarding references and deduction guides

Section: 13.10.3.5 [temp.deduct.partial] Status: NAD Submitter: Barry Revzin Date: 2017-06-03

Consider an example like:

      template<typename T>
      struct A {
        A(const T&);        // #1
        A(T&&);             // #2
      };

      template<typename U>
      A(U&&)->A<double>;    // #3

      int main(){
        int i =0;
        const int ci =0;

        A a1(0);
        A a2(i);
        A a3(ci);
      }

This example is covered by 13.10.3.5 [temp.deduct.partial] paragraph 9:

> If, for a given type, deduction succeeds in both directions (i.e., the types are identical after the transformations above) and both P and A were reference types (before being replaced with the type referred to above):

> - if the type from the argument template was an lvalue reference and the type from the parameter template was not, the parameter type is not considered to be at least as specialized as the argument type; otherwise,

> - if the type from the argument template is more cv-qualified than the type from the parameter template (as described above), the parameter type is not considered to be at least as specialized as the argument type.

For `a2(i)`, the deduction guide is the best match, so this is an `A<double>`.

For `a3(ci)`, the first bullet applies, which prefers #1 to #3 since #1 comes from an lvalue reference and #3 does not, resulting in an `A<int>`.

For `a1(0)`, the case is not covered by partial ordering, so 12.2.4 [over.match.best] bullet 1.10 applies and prefers #3 to #2, which is again an `A<double>`.

It seems inconsistent to prefer #1 to #3 (`T const &` to `U&&`), but to prefer #3 to #2 (`U&&` to `T&&`). Should the rules be expanded to basically prefer any non-forwarding-reference to a forwarding reference?

Rationale (June, 2018):

There was no consensus to make a change at this point; the behavior is as intended.

#### 469. Const template specializations and reference arguments

Section: 13.10.3.6 [temp.deduct.type] Status: NAD Submitter: Matt Austern Date: 19 Mar 2004

Consider the following:

    	template <typename T> struct X {};  // #1
    	template <typename T> struct X<const T>; //#2
    	template struct X<int&>; //#3

Which specialization are we instantiating in #3? The "obvious" answer is #1, because "int&" doesn't have a top level cv-qualification. However, there's also an argument saying that we should actually be instantiating #2. The argument is: int& can be taken as a match for either one (top-level cv-qualifiers are ignored on references, so they're equally good), and given two equally good matches we must choose the more specialized one.

Is this a valid argument? If so, is this behavior intentional?

John Spicer: I don't see the rationale for any choice other than #1. While it is true that if you attempt to apply const to a reference type it just gets dropped, that is very different from saying that a reference type is acceptable where a const-qualified type is required.

If the type matched both templates, the const one would be more specialized, but "int&" does not match "const T".

Nathan Sidwell: thanks for bringing this one to the committee. However this is resolved, I'd like clarification on the followup questions in the gcc bug report regarding deduced and non-deduced contexts and function templates. Here're those questions for y'all,

    template <typename T> void Foo (T *); // #1
    template <typename T> void Foo (T const *); // #2
    void Baz ();
    Foo (Baz); // which?

    template <typename T> T const *Foo (T *); // #1
    void Baz ();
    Foo (Baz); // well formed?

    template <typename T> void Foo (T *, T const * = 0);
    void Baz ();
    Foo (Baz); // well formed?

BTW, I didn't go trying to break things, I implemented the cv-qualifier ignoring requirements and fell over this. I could find nothing in the standard saying 'don't do this ignoring during deduction'.

#### 586. Default template-arguments and template argument deduction

Section: 13.10.3.6 [temp.deduct.type] Status: NAD Submitter: James Widman Date: 20 June 2006

Issue 226 removed the original prohibition on default template-arguments for function templates. However, the note in 13.10.3.6 [temp.deduct.type] paragraph 19 still reflects that prohibition. It should be revised or removed.

Rationale (February, 2010):

The problematic note was removed as a by-product of the changes for variadic templates, document N2284.

#### 1371. Deduction from `T&&` in return types

Section: 13.10.3.6 [temp.deduct.type] Status: NAD Submitter: Michael Wong Date: 2011-08-15

The special rule in 13.10.3.6 [temp.deduct.type] paragraph 10 for handling `T&&` in template argument deduction applies only to function parameters. It also needs to apply to function return types (including for conversion function templates, 13.10.3.4 [temp.deduct.conv]).

Rationale (February, 2012):

The specification is as intended: the special treatment of lvalue arguments in deduction is to make “perfect forwarding” work and should not be applied in other contexts.

#### 947. Deducing type template arguments from default function arguments

Section: 13.10.4 [temp.over] Status: NAD Submitter: Dave Abrahams Date: 27 July, 2009

It would be useful to be able to deduce the type of a function template argument from a corresponding default function argument expression, for example:

        template <class T> int f(T = 0);
        int x = f();

A more realistic use case would be

        template <class T, class U>
        int f(T x, U y = pair<T, T>());

Ideally one would also like

        template <class T, class U>
        int f(T x, U y = g(x));

These capabilities are part of the Boost parameter library, so there should not be issues of implementability.

Rationale (February, 2014):

EWG determined that no action should be taken on this issue.

#### 211. Constructors should not be allowed to return normally after an exception

Section: Clause 14 [except] Status: NAD Submitter: Bruce Mellows Date: 8 Mar 2000

The grammar should be changed so that constructor function-try-blocks must end with a throw-expression.

Rationale (04/00):

No change is needed. It is already the case that flowing off the end of a function-try-block of a constructor rethrows the exception, and `return` statements are prohibited in constructor function-try-blocks (14.4 [except.handle] paragraphs 15-16.

#### 104. Destroying the exception temp when no handler is found

Section: 14.2 [except.throw] Status: NAD Submitter: Jonathan Schilling Date: 21 Mar 1999

Questions regarding when a throw-expression temporary object is destroyed.

Section 14.2 [except.throw] paragraph 4 describes when the temporary is destroyed when a handler is found. But what if no handler is found:

        struct A {
            A() { printf ("A() \n"); }
            A(const A&) { printf ("A(const A&)\n"); }
            ~A() { printf ("~A() \n"); }
        };

        void t() { exit(0); }

        int main() {
            std::set_terminate(t);
            throw A();
        }

Does `A::~A()` ever execute here? (Or, in case two constructions are done, are there two destructions done?) Is it implementation-defined, analogously to whether the stack is unwound before `terminate()` is called (14.4 [except.handle] paragraph 9) ?

Or what if an exception specification is violated? There are several different scenarios here:

        int glob = 0; // or 1 or 2 or 3

        struct A {
            A() { printf ("A() \n"); }
            A(const A&) { printf ("A(const A&)\n"); }
            ~A() { printf ("~A() \n"); }
        };

        void u() {
            switch (glob) {
            case 0:  exit(0);
            case 1:  throw "ok";
            case 2:  throw 17;
            default: throw;
            }
        }

        void foo() throw(const char*, std::bad_exception) {
            throw A();
        }

        int main() {
            std::set_unexpected(u);
            try {
                foo();
            }
            catch (const char*) { printf("in handler 1\n"); }
            catch (std::bad_exception) { printf("in handler 2\n"); }
        }

The case where `u()` exits is presumably similar to the `terminate()` case. But in the cases where the program goes on, `A::~A()` should be called for the thrown object at some point. But where does this happen? The standard doesn't really say. Since an exception is defined to be "finished" when the `unexpected()` function exits, it seems to me that is where `A::~A()` should be called — in this case, as the throws of new (or what will become new) exceptions are made out of `u()`. Does this make sense?

Rationale (10/99): Neither `std::exit(int)` nor `std::abort()` destroys temporary objects, so the exception temporary is not destroyed when no handler is found. The original exception object is destroyed when it is replaced by an `unexpected()` handler. The Standard is sufficiently clear on these points.

#### 1667. Function exiting via exception called by destructor during unwinding

Section: 14.2 [except.throw] Status: NAD Submitter: Ryou Ezoe Date: 2013-04-25

According to 14.2 [except.throw] paragraph 7,

> If the exception handling mechanism, after completing the initialization of the exception object but before the activation of a handler for the exception, calls a function that exits via an exception, `std::terminate` is called (14.6.2 [except.terminate]).

This could be read as indicating that the following example results in calling `std::terminate`:

      // function that exits via an exception
      void f() {
        // std::uncaught_exception() returns true here
        throw 0;
      }

      struct X {
        ~X() {
      // calls a function that exits via an exception
          try { f(); }
          catch( ... ) { }
        }
      };

      int main() {
        try {
          X x;
          throw 0; // calls X's destructor while exception is still uncaught.
        }
        catch( ... ) { }
      }

This seems undesirable, and current implementations do not call `std::terminate`. Presumably the intention is that the cited text only applies to functions that are called directly by the exception handling mechanism, which is not true of `f()` in this example, but this could be stated more clearly.

Rationale (September, 2013):

The intent of the wording in 14.2 [except.throw] paragraph 7 is to call `std::terminate` if an exception is propagated into the exception-handling mechanism; “If the exception handling mechanism... calls a function that exits via an exception” is thus intended to refer to functions that are directly called by the exception handling mechanism. In the given example, `f()` is not called by the exception handling mechanism, it is called by `X::~X()`. The exception handling mechanism calls `X::~X()`, but it does not exit via an exception, so `std::terminate` should not be called.

#### 1624. Destruction of union members with member initializers

Section: 14.3 [except.ctor] Status: NAD Submitter: Vinny Romano Date: 2013-02-15

According to 14.3 [except.ctor] paragraph 2,

> An object of any storage duration whose initialization or destruction is terminated by an exception will have destructors executed for all of its fully constructed subobjects (excluding the variant members of a union-like class)...

The restriction for variant members does not appear to be necessary when there is a mem-initializer or non-static data member initializer for a union member, as that determines which union member is active during the execution of the constructor.

Rationale (April, 2013):

Although the active member in a member union is determined by an initializer, it could change during the execution of the constructor's compound=statement.

#### 2209. Destruction of constructed array elements

Section: 14.3 [except.ctor] Status: NAD Submitter: Robert Haberlach Date: 2015-12-03

[Detailed description pending.]

Rationale (November, 2016):

The reported issue is no longer relevant after the adoption of paper P0490R0 at the November, 2016 meeting.

#### 2210. Principal/target constructor confusion

Section: 14.3 [except.ctor] Status: NAD Submitter: Robert Haberlach Date: 2015-12-06

[Detailed description pending.]

Rationale (November, 2016):

The reported issue is no longer relevant after the adoption of paper P0490R0 at the November, 2016 meeting.

#### 308. Catching exceptions with ambiguous base classes

Section: 14.4 [except.handle] Status: NAD Submitter: Sergey P. Derevyago Date: 04 Sep 2001

14.4 [except.handle] paragraph 3 contains the following text:

> A handler is a match for a throw-expression with an object of type E if
> - The handler is of type cv T or cv T& and E and T are the same type (ignoring the top-level cv- qualifiers), or
> - the handler is of type cv T or cv T& and T is an unambiguous public base class of E, or
> - the handler is of type cv1 T* cv2 and E is a pointer type that can be converted to the type of the handler by either or both of
>   - a standard pointer conversion (7.3.12 [conv.ptr]) not involving conversions to pointers to private or protected or ambiguous classes
>   - a qualification conversion

I propose to alter this text to allow to catch exceptions with ambiguous public base classes by some of the public subobjects. I'm really sure that if someone writes:

        try {
            // ...
        }
        catch (Matherr& m) {
            // ...
        }

he really wants to catch all `Matherrs` rather than to allow some of the `Matherrs` to escape:

        class SomeMatherr : public Matherr { /* */ };
        struct TrickyBase1 : public SomeMatherr { /* */ };
        struct TrickyBase2 : public SomeMatherr { /* */ };
        struct TrickyMatherr : public TrickyBase1, TrickyBase2 { /* */ };

According to the standard `TrickyMatherr` will leak through the catch `(Matherr& m)` clause. For example:

        #include <stdio.h>

        struct B {};
        struct B1 : B {};
        struct B2 : B {};
        struct D : B1, B2 {};  // D() has two B() subobjects

        void f() { throw D(); }

        int main()
        {
         try { f(); }
         catch (B& b) { puts("B&"); }  // passed
         catch (D& d) { puts("D&"); }  // really works _after_ B&!!!
        }

Also I see one more possible solution: to forbid objects with ambiguous base classes to be "exceptional objects" (for example Borland C++ goes this way) but it seems to be unnecessary restrictive.

Notes from the 10/01 meeting:

The Core Working Group did not feel this was a significant problem. Catching either of the ambiguous base classes would be surprising, and giving an error on throwing an object that has an ambiguous base class would break existing code.

#### 593. Falling off the end of a destructor's function-try-block handler

Section: 14.4 [except.handle] Status: NAD Submitter: Alisdair Meredith Date: 30 August 2006

If control reaches the end of handler in a destructor's function-try-block, the exception is rethrown (14.4 [except.handle] paragraph 15). Because of the danger of destructors that throw exceptions, would it be better to treat this case as an implicit `return;` statement, as in a function body? There could be a transitional period, perhaps using conditionally-supported behavior or the like, before mandating the change.

Rationale (October, 2006):

The CWG felt that the current behavior is clearly specified and reflects the intention of the Committee at the time the rules were adopted. Possible changes to these rules should be pursued through the Evolution Working Group.

#### 346. Typo in 15.4

Section: 14.5 [except.spec] Status: NAD Submitter: Lois Goldthwaite Date: 18 March 2002

14.5 [except.spec] paragraph 13 contains the following text. I believe 'implicitLY' marked below should be replaced with 'implicit.'

> An implicitly declared special member function (11.4.4 [special]) shall have an exception-specification. If f is an implicitly declared default constructor, copy constructor, destructor, or copy assignment operator, its implicit exception-specification specifies the type-id T if and only if T is allowed by the exception-specification of a function directly invoked by f's implicitly definition; f shall allow all exceptions if any function it directly invokes allows all exceptions, and f shall allow no exceptions if every function it directly invokes allows no exceptions. [Example:

>         struct A {
>             A();
>             A(const A&) throw();
>             ~A() throw(X);
>         };
>         struct B {
>             B() throw();
>             B(const B&) throw();
>             ~B() throw(Y);
>         };
>         struct D : public A, public B {
>                 //  Implicit declaration of  D::D();
>                 //  Implicit declaration of  D::D(const   D&)   throw();
>                 //  Implicit declaration of  D::~D()   throw   (X,Y);
>         };

> Furthermore, if A::~A() or B::~B() were virtual, D::~D() would not be as restrictive as that of A::~A, and the program would be ill-formed since a function that overrides a virtual function from a base class shall have an exception-specification at least as restrictive as that in the base class. ]

The example code shows structs whose destructors have exception specifications which throw certain types. There is no defect here, but it doesn't sit well with our general advice elsewhere that destructors should not throw. I wish I could think of some other way to illustrate this section.

Notes from October 2002 meeting:

This was previously resolved by an editorial change.

#### 829. At what point is `std::unexpected` called?

Section: 14.5 [except.spec] Status: NAD Submitter: UK Date: 3 March, 2009
N2800 comment UK 135

It is unclear whether `std::unexpected` is called before or after the destruction of function arguments, partially-constructed bases and members (when called from a constructor or destructor), etc.

Rationale (October, 2009):

The point at which `std::unexpected` is called is specified in _N4606_.15.5.2 [except.unexpected] paragraph 1:

> If a function with an exception-specification throws an exception that is not listed in the exception-specification, the function `std::unexpected()` is called (_N4606_.D.6 [exception.unexpected]) immediately after completing the stack unwinding for the former function.

That is, it will be called after any local automatic objects and temporaries are destroyed and before any other objects, such as function arguments, are destroyed. (See 7.6.1.3 [expr.call] paragraph 4: “The initialization and destruction of each parameter occurs within the context of the calling function.”)

#### 1053. Terminate vs undefined behavior for noexcept violation

Section: 14.5 [except.spec] Status: NAD Submitter: Dave Abrahams Date: 2010-03-12

The consensus at the Pittsburgh (March, 2010) meeting, as reflected in the adoption of paper N3050, was that it was preferable for violation of a `noexcept` guarantee to call `std::terminate`; previous versions of the paper had called for undefined behavior in this case. Not everyone was convinced that this was a good decision, however; this issue is intended to facilitate further investigation and discussion of the question with the benefit of more time and resources than were available during the deliberations at the meeting.

Rationale (August, 2010):

CWG reaffirmed the explicit decision of the Committee.

#### 1798. exception-specifications of template arguments

Section: 14.5 [except.spec] Status: NAD Submitter: Gabriel Dos Reis Date: 2013-10-16

Although 14.5 [except.spec] paragraphs 5-6 require that overriding a virtual function and initializing or assigning to a function pointer not weaken exception-specifications, the same is not true of providing a template argument for a template parameter. For example,

      template<void (*FP)() noexcept> void x() { }
      void f() noexcept(false);
      template void x<f>();

is currently well-formed, which seems inconsistent. (Note that if exception-specifications become part of the type system, as proposed in issue 92, this issue will become moot.)

See also issues 2010, 1995, 1975, and 1946.

Rationale (February, 2014):

Are template declarations that differ only in the exception-specification of the parameter redeclarations or separate templates distinguished, presumably, by deduction failure? This seems like a question more appropriate for consideration by EWG.

Additional note, April, 2015:

EWG has decided not to make a change in this area. See EWG issue 133.

#### 1934. Relaxing exception-specification compatibility requirements

Section: 14.5 [except.spec] Status: NAD Submitter: Vinny Romano Date: 2014-06-03

According to 14.5 [except.spec] paragraph 4,

> If any declaration of a function has an exception-specification that is not a noexcept-specification allowing all exceptions, all declarations, including the definition and any explicit specialization, of that function shall have a compatible exception-specification.

This seems excessive for explicit specializations, considering that paragraph 6 applies a looser requirement for virtual functions:

> If a virtual function has an exception-specification, all declarations, including the definition, of any function that overrides that virtual function in any derived class shall only allow exceptions that are allowed by the exception-specification of the base class virtual function.

The rule in paragraph 3 is also problematic in regard to explicit specializations of destructors and defaulted special member functions, as the implicit exception-specification of the template member function cannot be determined.

There is also a related problem with defaulted special member functions and exception-specifications. According to 9.6.2 [dcl.fct.def.default] paragraph 3,

> If a function that is explicitly defaulted has an explicit exception-specification that is not compatible (14.5 [except.spec]) with the exception-specification on the implicit declaration, then

> - if the function is explicitly defaulted on its first declaration, it is defined as deleted;

> - otherwise, the program is ill-formed.

This rule precludes defaulting a virtual base class destructor or copy/move functions if the derived class function will throw an exception not allowed by the implicit base class member function.

Rationale (June, 2014):

This request for a language extension should be evaluated by EWG before any action is taken.

Additional note, November, 2020:

This request applied to full exception specifications and is no longer relevant in the current language, where only noexcept-specifiers are permitted.

EWG 2022-11-11

Close as NAD.

#### 2183. Problems in description of potential exceptions

Section: 14.5 [except.spec] Status: NAD Submitter: Hubert Tong Date: 2015-10-21

The description of the “set of potential exceptions of an expression” in 14.5 [except.spec] paragraph 15 does not appear to be fully recursive, so it can miss the effect of, e.g., a throw-expression as a subexpression. In addition, bullet 15.1.1, which reads,

- If its postfix-expression is a (possibly parenthesized) id-expression (_N4567_.5.1.1 [expr.prim.general]), class member access (7.6.1.5 [expr.ref]), or pointer-to-member operation (7.6.4 [expr.mptr.oper]) whose cast-expression is an id-expression, S is the set of potential exceptions of the entity selected by the contained id-expression (after overload resolution, if applicable).

omits the case where the postfix-expression is a function call whose return type is a function pointer with an exception specification.

Notes from the June, 2016 meeting:

This text will be replaced by the removal of dynamic exception specifications (P0003) and thus does not need to be changed at this time. The issue is placed in "review" status until document P0003 is adopted.

Rationale (February, 2017):

The issue is moot after the adoption of paper P0003.

#### 2216. Exception specifications in unevaluated contexts

Section: 14.5 [except.spec] Status: NAD Submitter: Daniel Krügler Date: 2015-12-21

Consider:

      #include <type_traits>

      template<class T>
      T foo(T) noexcept(std::is_nothrow_move_constructible<T>::value);

      int main()
      {
       sizeof(foo(0));
      }

According to 14.5 [except.spec] paragraph 13:

> An exception specification is considered to be needed when:
> - in an expression, the function is selected by overload resolution (12.2 [over.match], 12.3 [over.over]);
> - ...

Is it intended that the exception specification is needed for the example? The function call is never evaluated and the exception specification is not queried.

Rationale (November, 2016):

The type of the function is needed to know how to call it, and the exception specification is part of the function type.

#### 219. Cannot defend against destructors that throw exceptions

Section: 14.6.2 [except.terminate] Status: NAD Submitter: Herb Sutter Date: 31 Mar 2000

Destructors that throw can easily cause programs to terminate, with no possible defense. Example: Given

        struct XY { X x; Y y; };

Assume that `X::~X()` is the only destructor in the entire program that can throw. Assume further that `Y` construction is the only other operation in the whole program that can throw. Then `XY` cannot be used safely, in any context whatsoever, period — even simply declaring an `XY` object can crash the program:

        XY xy; // construction attempt might terminate program:
    	   //   1. construct x -- succeeds
    	   //   2. construct y -- fails, throws exception
    	   //   3. clean up by destroying x -- fails, throws exception,
    	   //      but an exception is already active, so call
    	   //      std::terminate() (oops)
    	   // there is no defense

So it is highly dangerous to have even one destructor that could throw.

Suggested Resolution:

Fix the above problem in one of the following two ways. I prefer the first.

1. We already have text that specifies that any destructor operation in the standard library (presumably including the destructors of UDTs used in containers or as predicates, etc.) may not throw. There is good reason to widen this injunction to specify that destructors may never throw at all. (I realize this would render existing programs nonconforming if they did do this, but it's unsafe anyway.)
2. Specify what happens in the above case so that `std::terminate()` won't be called.

Fergus Henderson: I disagree. Code using `XY` may well be safe, if `X::~X()` only throws if `std::uncaught_exception()` is `false`.

I think the current exception handling scheme in C++ is certainly flawed, but the flaws are IMHO design flaws, not minor technical defects, and I don't think they can be solved by minor tweaks to the existing design. I think that at this point it is probably better to keep the standard stable, and learn to live with the existing flaws, rather than trying to solve them via TC.

Bjarne Stroustrup: I strongly prefer to have the call to `std::terminate()` be conforming. I see `std::terminate()` as a proper way to blow away "the current mess" and get to the next level of error handling. I do not want that escape to be non-conforming — that would imply that programs relying on a error handling based on serious errors being handled by terminating a process (which happens to be a C++ program) in `std::terminate()` becomes non-conforming. In many systems, there are — and/or should be — error-handling and recovery mechanisms beyond what is offered by a single C++ program.

Andy Koenig: If we were to prohibit writing a destructor that can throw, how would I solve the following problem?

I want to write a class that does buffered output. Among the other properties of that class is that destroying an object of that class writes the last buffer on the output device before freeing memory.

What should my class do if writing that last buffer indicates a hardware output error? My user had the option to flush the last buffer explicitly before destroying the object, but didn't do so, and therefore did not anticipate such a problem. Unfortunately, the problem happened anyway. Should I be required to suppress this error indication anyway? In all cases?

Herb Sutter (June, 2007): IMO, it's fine to suppress it. The user had the option of flushing the buffer and thus being notified of the problem and chose not to use it. If the caller didn't flush, then likely the caller isn't ready for an exception from the destructor, either. You could also put an assert into the destructor that would trigger if `flush()` had not been called, to force callers to use the interface that would report the error.

In practice, I would rather thrown an exception, even at the risk of crashing the program if we happen to be in the middle of stack unwinding. The reason is that the program would crash only if a hardware error occurred in the middle of cleaning up from some other error that was in the process of being handled. I would rather have such a bizarre coincidence cause a crash, which stands a chance of being diagnosed later, than to be ignored entirely and leave the system in a state where the ignore error could cause other trouble later that is even harder to diagnose.

If I'm not allowed to throw an exception when I detect this problem, what are my options?

Herb Sutter: I understand that some people might feel that "a failed dtor during stack unwinding is preferable in certain cases" (e.g., when recovery can be done beyond the scope of the program), but the problem is "says who?" It is the application program that should be able to decide whether or not such semantics are correct for it, and the problem here is that with the status quo a program cannot defend itself against a `std::terminate()` — period. The lower-level code makes the decision for everyone. In the original example, the mere existence of an `XY` object puts at risk every program that uses it, whether `std::terminate()` makes sense for that program or not, and there is no way for a program to protect itself.

That the "it's okay if the process goes south should a rare combination of things happen" decision should be made by lower-level code (e.g., `X` dtor) for all apps that use it, and which doesn't even understand the context of any of the hundreds of apps that use it, just cannot be correct.

Additional note (April, 2011):

The addition of the `noexcept` specifier, along with changes to make many destructors `noexcept` by default, may have sufficiently addressed these concerns. CWG should consider changing this to NAD or extension status.

Rationale (August, 2011):

As given in the preceding note.

#### 533. Special treatment for C-style header names

Section: 15.3 [cpp.include] Status: NAD Submitter: Jens Maurer Date: 4 October 2005

In language imported directly from the C Standard, 15.3 [cpp.include] paragraph 5 says,

> The implementation provides unique mappings for sequences consisting of one or more nondigits (5.11 [lex.name]) followed by a period (`.`) and a single nondigit.

This is clearly intended to support C header names like `stdio.h`. However, C++ has header names like `cstdio` that do not conform to this pattern but still presumably require “unique mappings.”

Proposed resolution (April, 2006):

Change 15.3 [cpp.include] paragraph 5 as indicated:

> The implementation provides unique mappings between the delimited sequence and the external source file name for sequences consisting of one or more nondigits or digits (5.11 [lex.name]), optionally followed by a period (`.`) and a single nondigit...

(Clark Nelson will discuss this revision with WG14.)

Additional notes (October, 2006):

WG14 takes no position on this proposed change.

Rationale (September, 2008):

It is unclear what effect the provision of “unique mappings” has or if a conforming program could detect the failure of an implementation to do so. There has been a significant effort to synchronize this clause with the corresponding section of the C99 Standard, and given the lack of perceptible impact of the proposed change, there is insufficient motivation to introduce a new divergence in the wording.

#### 1720. Macro invocation in `#include` directive

Section: 15.3 [cpp.include] Status: NAD Submitter: David Krauss Date: 2013-07-24

According to 15.3 [cpp.include] paragraph 4,

> A preprocessing directive of the form

> `# include` pp-tokens new-line

> (that does not match one of the two previous forms) is permitted. The preprocessing tokens after `include` in the directive are processed just as in normal text (Each identifier currently defined as a macro name is replaced by its replacement list of preprocessing tokens.). If the directive resulting after all replacements does not match one of the two previous forms, the behavior is undefined.155 The method by which a sequence of preprocessing tokens between a `<` and a `>` preprocessing token pair or a pair of `"` characters is combined into a single header name preprocessing token is implementation-defined.

It might be inferred from the phrase “in the directive” that only tokens before the terminating newline would be available for macro expansion, and that consequently the closing right parenthesis of a function-style macro must appear on the same line. However, it would be clearer if it used language like that of 15.7.2 [cpp.subst] paragraph 1:

> each argument's preprocessing tokens are completely macro replaced as if they formed the rest of the preprocessing file; no other preprocessing tokens are available.

Rationale (September, 2013):

The wording referring to preprocessing tokens “in the directive” is a clear enough indication that no tokens after the terminating newline are considered.

#### 2193. `numeric_limits<int>::radix` and `digits`

Section: 17.3.5.2 [numeric.limits.members] Status: NAD Submitter: Tony Van Eerd Date: 2015-11-02

Is `numeric_limits<int>::radix` required to be 2? 17.3.5.2 [numeric.limits.members] paragraph 23 specifies:

    static constexpr int radix;

> For integer types, specifies the base of the representation.

Rationale (November, 2016):

CWG felt that the current specification is sufficiently clear and there was no consensus for a change.

#### 1277. Lax definition of `intmax_t` and `uintmax_t`

Section: 17.4.1 [cstdint.syn] Status: NAD Submitter: Daniel Krügler Date: 2011-03-26

The definition of `intmax_t` and `uintmax_t`, inherited from C99, leaves open the possibility that the underlying types might not be the ones with the highest integer conversion rank. The requirements for these types deal only with the representation, not the conversion rank, and it is possible for, e.g., `long` and `long long` to have the same representation, although they have different conversion ranks. On such an architecture, chosing `long` instead of `long long` for `intmax_t` would be conforming.

Rationale (August, 2011):

This is a C compatibility issue and has ABI implications; there was no consensus to pursue a change.

#### 2014. Unneeded deallocation signatures

Section: 17.6.3.3 [new.delete.array] Status: NAD Submitter: Richard Smith Date: 2014-10-03

Paper N3778 added the following two deallocation signatures to the standard library:

       void operator delete(void* ptr, std::size_t size,
                            const std::nothrow_t&) noexcept;
       void operator delete[](void* ptr, std::size_t size,
                              const std::nothrow_t&) noexcept;

The core language does not currently provide for calling these functions; they could only be called as the matching deallocation function when a constructor throws an exception, but the rules for determining the matching deallocation function do not consider the existence of the sized-deallocation variants.

Rationale (November, 2014):

CWG agreed that the performance gain in using the sized-deallocation variants when a constructor throws an exception would be insignificant compared to the cost of the exception handling itself and thus insufficient motivation for changing the core language. The issue was referred to LWG for their consideration regarding removal of these signatures.

#### 266. No grammar sentence symbol

Section: Clause Annex A [gram] Status: NAD Submitter: Hans Aberg Date: 2 Dec 2000

The grammar in Appendix A does not indicate a grammar sentence symbol and is therefore formally not a grammar.

Rationale (04/01):

Appendix A does not claim to be a formal grammar. The specification is clear enough in its current formulation.

#### 1675. Size limit for automatic array object

Section: Clause Annex B [implimits] Status: NAD Submitter: Jason Merrill Date: 2013-05-03

9.3.4.5 [dcl.array] paragraph 1 says,

> The expression is erroneous if:

> - ...

> - its value is such that the size of the allocated object would exceed the implementation-defined limit (Annex Clause Annex B [implimits]);

> - ...

The only relevant limit in Clause Annex B [implimits] is that of the size of an object, but presumably an implementation might want to impose a smaller limit on a stack-based object. This separate quantity is referred to in paragraph 4 when describing an array of unspecified bound:

> If the size of the array exceeds the size of the memory available for objects with automatic storage duration, the behavior is undefined.

but perhaps it needs to be mentioned in Clause Annex B [implimits] as well.

Proposed resolution (September, 2013):

This issue is resolved by the resolution of issue 1761.

Rationale (February, 2014):

The specification was removed from the WP and moved into a Technical Specification.

Notes from the February, 2014 meeting:

CWG discussed adding such a limit, even without the changes for arrays of runtime bound, but decided that it was unneeded; such handling could be added by implementations if desirable.

#### 1933. Implementation limit for initializer-list elements

Section: Clause Annex B [implimits] Status: NAD Submitter: Daniel Krügler Date: 2014-05-30

Should there be an entry in Annex Clause Annex B [implimits] for the minimum number of elements an implementation should accept in an initializer-list, and if so, what should that be?

Rationale (June, 2014):

There are already related limits in Annex Clause Annex B [implimits] (array bounds, object size), which should be sufficient.

#### 81. Null pointers and C compatibility

Section: Clause Annex C [diff] Status: NAD Submitter: Steve Clamage Date: 27 Oct 1998

Annex C lists C compatibility issues. One item not in the annex came up in a discussion in comp.std.c++.

Consider this C and C++ code:

        const int j = 0;
        char* p = (char*)j;

Rationale (10/99): Because `j` is not a constant expression in C, this code fragment has implementation-defined behavior in C. There is no incompatibility with C resulting from the fact that C++ defines this behavior.

### Issues with "Dup" Status

#### 1422. Type of character literals containing universal-character-names

Section: 5.13.3 [lex.ccon] Status: dup Submitter: Dave Abrahams Date: 2011-12-03

The treatment of character literals containing universal-character-names is not clear. It is reasonable to conclude from 5.13.5 [lex.string] paragraph 15 that if a character named by a UCN cannot be represented by a single character in the runtime character set, it becomes a multibyte character and thus such a character literal is a multicharacter literal, with type `int` and an implementation-defined value. It would be nice if 5.13.3 [lex.ccon] had the complete story by itself or at least a reference to 5.13.5 [lex.string] for the details.

Rationale (February, 2012):

This issue is a duplicate of issue 912.

#### 82. Definition of "using" a constant expression

Section: 6.3 [basic.def.odr] Status: dup Submitter: Bill Gibbons Date: 31 Dec 1998

The wording in 6.3 [basic.def.odr] paragraph 2 about "potentially evaluated" is incomplete. It does not distinguish between expressions which are used as "integral constant expressions" and those which are not; nor does it distinguish between uses in which an objects address is taken and those in which it is not. (A suitable definition of "address taken" could be written without actually saying "address".)

Currently the definition of "use" has two parts (part (a) and (d) below); but in practice there are two more kinds of "use" as in (b) and (c):

1. Use in "sizeof" or a non-polymorphic "typeid". Neither the value nor the address is really used. No definition is needed at all.
2. Use as an integral constant expression. Only the value is used. A static data member with its initializer given in the class need not have a namespace-scope definition.
3. Use which requires the value, which is known at compile time because the object is const, of integral or enum type, and initialized with an integral constant expression. Only the value need be used, but an implementation is not required to use the value from the initializer; it might access the object. So in the original example, the namespace-scope definition is required even though most compilers will not require it.
4. All other uses require that the object actually exist because its address will be taken implicitly or explicitly.

We discussed (b) and decided that the namespace-scope definition was not needed, but the wording did not make it into the standard.

I don't think we discussed (c).

Rationale (04/99): The substantive part of this issue is covered by Core issue 48

#### 12. Default arguments on different declarations for the same function and the Koenig lookup

Section: 6.5.4 [basic.lookup.argdep] Status: dup Submitter: Daveed Vandevoorde Date: unknown

Given the following test case:

        enum E { e1, e2, e3 };

        void f(int, E e = e1);
        void f(E, E e = e1);

        void g() {
            void f(long, E e = e2);
            f(1); // calls ::f(int, E)
            f(e1); // ?
        }

First note that Koenig lookup breaks the concept of hiding functions through local extern declarations as illustrated by the call ``f(1)`'. Should the WP show this as an example?

Second, it appears the WP is silent as to what happens with the call ``f(e1)`': do the different default arguments create an ambiguity? is the local choice preferred? or the global?

Tentative Resolution (10/98) In 6.5.4 [basic.lookup.argdep] paragraph 2, change

> If the ordinary unqualified lookup of the name finds the declaration of a class member function, the associated namespaces and classes are not considered.

to

> If the ordinary unqualified lookup of the name finds the declaration of a class member function or the declaration of a function at block scope, the associated namespaces and classes are not considered.

Rationale (04/99): The proposal would also apply to local using-declarations (per Mike Ball) and was therefore deemed undesirable. The ambiguity issue is dealt with in Core issue 1

#### 321. Associated classes and namespaces for argument-dependent lookup

Section: 6.5.4 [basic.lookup.argdep] Status: dup Submitter: Andrei Iltchenko Date: 12 Nov 2001

The last bullet of the second paragraph of section 6.5.4 [basic.lookup.argdep] says that:

> If T is a template-id, its associated namespaces and classes are the namespace in which the template is defined; for member templates, the member template's class; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which any template template arguments are defined; and the classes in which any member templates used as template template arguments are defined.

The first problem with this wording is that it is misleading, since one cannot get such a function argument whose type would be a template-id. The bullet should be speaking about template specializations instead.

The second problem is owing to the use of the word "defined" in the phrases "are the namespace in which the template is defined", "in which any template template arguments are defined", and "as template template arguments are defined". The bullet should use the word "declared" instead, since scenarios like the one below are possible:

    namespace  A  {

       template<class T>
       struct  test  {

          template<class U>
          struct  mem_templ  {   };

       };

       // declaration in namespace 'A'
       template<> template<>
       struct  test<int>::mem_templ<int>;

       void  foo(test<int>::mem_templ<int>&)
       {   }

    }

    // definition in the global namespace
    template<> template<>
    struct  A::test<int>::mem_templ<int>  {
    };

    int  main()
    {
       A::test<int>::mem_templ<int>   inst;
       // According to the current definition of 3.4.2
       // foo is not found.
       foo(inst);
    }

In addition, the bullet doesn't make it clear whether a T which is a class template specialization must also be treated as a class type, i.e. if the contents of the second bullet of the second paragraph of section 6.5.4 [basic.lookup.argdep].

> - If T is a class type (including unions), its associated classes are: the class itself; the class of which it is a member, if any; and its direct and indirect base classes. Its associated namespaces are the namespaces in which its associated classes are defined. [This wording is as updated by core issue 90.]

must apply to it or not. The same stands for a T which is a function template specialization. This detail can make a difference in an example such as the one below:

    template<class T>
    struct  slist_iterator  {
       friend bool  operator==(const slist_iterator& x, const slist_iterator& y)
       {   return  true;   }
    };

    template<class T>
    struct  slist  {
       typedef slist_iterator<T>   iterator;
       iterator  begin()
       {   return  iterator();   }
       iterator  end()
       {   return  iterator();   }
    };

    int  main()
    {
       slist<int>   my_list;
       slist<int>::iterator   mi1 = my_list.begin(),  mi2 = my_list.end();
       // Must the the friend function declaration
       // bool  operator==(const slist_iterator<int>&, const slist_iterator<int>&);
       // be found through argument dependent lookup? I.e. is the specialization
       // 'slist<int>' the associated class of the arguments 'mi1' and 'mi2'. If we
       // apply only the contents of the last bullet of 3.4.2/2, then the type
       // 'slist_iterator<int>' has no associated classes and the friend declaration
       // is not found.
       mi1 == mi2;
    }

Suggested resolution:

Replace the last bullet of the second paragraph of section 6.5.4 [basic.lookup.argdep]

> - If `T` is a template-id, its associated namespaces and classes are the namespace in which the template is defined; for member templates, the member template's class; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which any template template arguments are defined; and the classes in which any member templates used as template template arguments are defined.

with

> - If `T` is a class template specialization, its associated namespaces and classes are those associated with `T` when `T` is regarded as a class type; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which the primary templates making template template arguments are declared; and the classes in which any primary member templates used as template template arguments are declared.
> - If `T` is a function template specialization, its associated namespaces and classes are those associated with `T` when `T` is regarded as a function type; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which the primary templates making template template arguments are declared; and the classes in which any primary member templates used as template template arguments are declared.

Replace the second bullet of the second paragraph of section 6.5.4 [basic.lookup.argdep]

> - If `T` is a class type (including unions), its associated classes are: the class itself; the class of which it is a member, if any; and its direct and indirect base classes. Its associated namespaces are the namespaces in which its associated classes are defined.

with

> - If `T` is a class type (including unions), its associated classes are: the class itself; the class of which it is a member, if any; and its direct and indirect base classes. Its associated namespaces are the namespaces in which its associated classes are declared [Note: in case of any of the associated classes being a class template specialization, its associated namespace is acually the namespace containing the declaration of the primary class template of the class template specialization].

Rationale (September, 2012):

The concerns in this issue were addressed by the resolutions of issues 403 and 557.

#### 1853. Defining “allocated storage”

Section: 6.8.4 [basic.life] Status: dup Submitter: Jeffrey Yasskin Date: 2014-02-09

The term “allocated storage” is used in several places in the Standard to refer to memory in which an object may be created (dynamic, static, or automatic storage), but it has no formal definition.

Rationale (CWG 2023-06-15)

This issue is a dupliate of issue 2551.

#### 2860. Remove and fix the term "vacuous initialization"

Section: 6.8.4 [basic.life] Status: dup Submitter: Jiang An Date: 2024-02-21

(From submission #505.)

A class may have a trivial default constructor that is not actually used to default-initialize a class object, e.g. because the constructor is not eligible. The definition of "vacuous initialization" in 6.8.4 [basic.life] paragraph 1, as used in 8.10 [stmt.dcl] paragraph 2, does not reflect that fact.

Possible resolution:

1. Change in 6.8.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 and, if it is of class type or a (possibly multidimensional) array thereof, that class type has a trivial default constructor. The lifetime of an object of type T begins when:
   > - storage with the proper alignment and size for type T is obtained, and
   > - its initialization (if any) is complete (including vacuous initialization) (9.5 [dcl.init]),
   > except that if the object is a union member or subobject thereof, its lifetime only begins if that union member is the initialized member in the union (9.5.2 [dcl.init.aggr], 11.9.3 [class.base.init]), or as described in 11.5 [class.union], 11.4.5.3 [class.copy.ctor], and 11.4.6 [class.copy.assign], and except as described in 20.2.10.2 [allocator.members]. ...

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

   > A variable with automatic storage duration (6.8.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 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 variables with automatic storage duration that are active at Q but not at P are initialized in declaration order; unless all such variables have vacuous initialization (6.8.4 [basic.life]) are default-initialized and no initialization is performed for any such variable other than calling a trivial default constructor, 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. ...

CWG 2024-04-05

CWG preferred to keep the term vacuous initialization and fix its definition while adressing issue 2859.

#### 1568. Temporary lifetime extension with intervening cast

Section: 6.8.7 [class.temporary] Status: dup Submitter: Steve Adamczyk Date: 2012-10-11

According to 6.8.7 [class.temporary] paragraphs 4-5,

> There are two contexts in which temporaries are destroyed at a different point than the end of the full-expression...

> The second context is when a reference is bound to a temporary. The temporary to which the reference is bound or the temporary that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference...

It is not clear whether this applies to an example like the following:

      struct S { };
      const S& r = (const S&)S();

In one sense `r` is being bound to the temporary because the object to which `r` refers is the temporary object. From another perspective, however, `r` is being bound not to a temporary but to the lvalue expression `(const S&)S()`, or, more precisely, to the invented temporary variable described in 7.6.1.9 [expr.static.cast] paragraph 4:

> Otherwise, an expression `e` can be explicitly converted to a type `T` using a `static_cast` of the form `static_cast<T>(e)` if the declaration `T t(e);` is well-formed, for some invented temporary variable `t` (9.5 [dcl.init]). The effect of such an explicit conversion is the same as performing the declaration and initialization and then using the temporary variable as the result of the conversion.

(Since the invented variable `t` is called a “temporary,” perhaps the intent is that its lifetime is extended to that of `r`, and then the lifetime of the `S()` temporary would be that of `t`. However, this reasoning is tenuous, and it may be better to make the intent explicitly clear.)

(See also issue 1299.)

Rationale (April, 2013):

This issue is a duplicate of issue 1376.

#### 1654. Literal types and `constexpr` defaulted constructors

Section: 6.9 [basic.types] Status: dup Submitter: Richard Smith Date: 2013-04-20

The requirement in 6.9 [basic.types] that a literal type must have a `constexpr` constructor has caused signficant problems with respect to defaulted default constructors, since the determination of whether a constructor is `constexpr` depends on its definition and a defaulted special member function is only defined if it is odr-used. It might be better to remove that requirement, at least as it applies to defaulted default constructors.

Rationale (September, 2013):

This issue duplicates issue 1360.

#### 1534. cv-qualification of prvalue of type “array of class”

Section: 7.2.1 [basic.lval] Status: dup Submitter: Daveed Vandevoorde Date: 2012-08-09

According to 7.2.1 [basic.lval] paragraph 4,

> Class prvalues can have cv-qualified types; non-class prvalues always have cv-unqualified types.

Presumably an array of a class type should also be permitted to have a cv-qualified type.

Rationale (October, 2012):

This issue is a subset of, and resolved by the resolution of, issue 1261.

#### 1927. Lifetime of temporaries in init-captures

Section: 7.5.6.3 [expr.prim.lambda.capture] Status: dup Submitter: Daveed Vandevoorde Date: 2014-05-14

The current Standard is not clear regarding the lifetime of a temporary created in the initializer of an init-capture:

      void g() {
        struct S { S(int); ~S(); };
        auto x = (S(1), [y = S(2)]{}, S(3));
      }

Is the initializer for `y` considered a full-expression, or does the `S(2)` temporary persist until the end of the complete `x` initializer?

Reationale (June, 2014):

This issue is a duplicate of issue 1695.

#### 2029. Abstract class return type in `decltype` operand

Section: 7.6.1.3 [expr.call] Status: dup Submitter: Mike Miller Date: 2014-10-27

According to 7.6.1.3 [expr.call] paragraph 11, when a function call is the operand of a decltype-specifier,

> a temporary object is not introduced for the prvalue. The type of the prvalue may be incomplete. [Note: as a result, storage is not allocated for the prvalue and it is not destroyed; thus, a class type is not instantiated as a result of being the type of a function call in this context. This is true regardless of whether the expression uses function call notation or operator notation (12.2.2.3 [over.match.oper]). —end note] [Note: unlike the rule for a decltype-specifier that considers whether an id-expression is parenthesized (9.2.9.3 [dcl.type.simple]), parentheses have no special meaning in this context. —end note]

This relaxation of requirements on the return type of a function does not mention abstract classes, so presumably the following example is ill-formed:

       struct Abstract {
         virtual ~Abstract() = 0;
       };

       template<class T> T func();

       typedef decltype(func<Abstract>()) type;

However, there is implementation variance on the treatment of the last line.

Rationale (November, 2014):

This issue is a duplicate of issue 1646.

#### 1300. `T()` for array types

Section: 7.6.1.4 [expr.type.conv] Status: dup Submitter: Daniel Krügler Date: 2011-04-18

In an expression of the form `T()`, 7.6.1.4 [expr.type.conv] paragraph 2 requires that `T` not be an array type. Now that temporary arrays can be created via a braced-init-list (see issue 1232), this restriction should be eliminated.

Rationale (August, 2011):

The implications of array temporaries for the language should be considered by the Evolution Working Group in a comprehensive fashion rather than on a case-by-case basis. See also issues 1307, 1326, and 1525.

Rationale (February, 2014):

This is a duplicate of issue 914.

#### 1521. `T{`expr`}` with reference types

Section: 7.6.1.4 [expr.type.conv] Status: dup Submitter: Steve Adamczyk Date: 2012-07-10

According to 7.6.1.4 [expr.type.conv] paragraph 4,

> Similarly, a simple-type-specifier or typename-specifier followed by a braced-init-list creates a temporary object of the specified type direct-list-initialized (9.5.5 [dcl.init.list]) with the specified braced-init-list, and its value is that temporary object as a prvalue.

This wording does not handle the case where `T` is a reference type: it is not possible to create a temporary object of that type, and presumably the result would be an xvalue, not a prvalue.

(Duplicate of issue 2894.)

#### 1230. Confusing description of ambiguity of destructor name

Section: 7.6.2.2 [expr.unary.op] Status: dup Submitter: Johannes Schaub Date: 2010-12-13

According to 7.6.2.2 [expr.unary.op] paragraph 10,

> There is an ambiguity in the unary-expression `~X()`, where `X` is a class-name or decltype-specifier. The ambiguity is resolved in favor of treating `~` as a unary complement rather than treating `~X` as referring to a destructor.

It is not clear whether this is intended to apply to an expression like `(~S)()`. In large measure, that depends on whether a class-name is an id-expression or not. If it is, the ambiguity described in 7.6.2.2 [expr.unary.op] paragraph 10 does apply; if not, the expression is an unambiguous reference to the destructor for class `S`. There are several places in the Standard that indicate that the name of a type is an id-expression, but that might be more confusing than helpful.

Rationale (February, 2021):

This issue is a duplicate of, and resolved by the resolution of, issue 1971.

#### 839. `sizeof` with opaque enumerations

Section: 7.6.2.5 [expr.sizeof] Status: dup Submitter: Alberto Ganesh Barbati Date: 9 March, 2009

7.6.2.5 [expr.sizeof] paragraph 1 says,

> The `sizeof` operator shall not be applied... to an enumeration type before all its enumerators have been declared...

This prevents use of `sizeof` with an opaque enumeration type, even though the underlying type of such enumerations is known.

Rationale (May, 2009):

Duplicate of issue 803.

#### 313. Class with single conversion function to integral as array size in `new`

Section: 7.6.2.8 [expr.new] Status: dup Submitter: Bill Gibbons Date: 22 Oct 2001

Should it be allowed to use an object of a class type having a single conversion function to an integral type as an array size in the first bound of the type in an array new?

      struct A {
        operator int();
      } a;
      int main () {
        new int[a];
      }

There are similar accommodations for the expression in a `delete` (7.6.2.9 [expr.delete] paragraph 1) and in a `switch` (8.5.3 [stmt.switch] paragraph 2) . There is also widespread existing practice on this (g++, EDG, MSVC++, and Sun accept it, and even cfront 3.0.2).

Rationale (October, 2004):

Duplicate of issue 299.

#### 265. Destructors, exceptions, and deallocation

Section: 7.6.2.9 [expr.delete] Status: dup Submitter: Mike Miller Date: 21 Nov 2000

Does the Standard require that the deallocation function will be called if the destructor throws an exception? For example,

        struct S {
            ~S() { throw 0; }
        };
        void f() {
            try {
                delete new S;
            }
            catch(...) { }
        }

The question is whether the memory for the S object will be freed or not. It doesn't appear that the Standard answers the question, although most people would probably assume that it will be freed.

Notes from 04/01 meeting:

There is a widespread feeling that it is a poor programming practice to allow destructors to terminate with an exception (see issue 219). This question is thus viewed as a tradeoff between efficiency and supporting "bad code." It was observed that there is no way in the current language to protect against a throwing destructor, since the throw might come from a virtual override.

It was suggested that the resolution to the issue might be to make it implementation-defined whether the storage is freed if the destructor throws. Others suggested that the Standard should require that the storage be freed, with the understanding that implementations might have a flag to allow optimizing away the overhead. Still others thought that both this issue and issue 219 should be resolved by forbidding a destructor to exit via an exception. No consensus was reached.

Rationale (October, 2008):

It was noticed that issue 353, an exact duplicate of this one, was independently opened and resolved.

#### 2696. Relational comparisons of pointers to `void`

Section: 7.6.9 [expr.rel] Status: dup Submitter: CWG Date: 2023-02-09 Liaison: SG22

While discussing issue 2526, it was noted that C++ yields an unspecified result for comparing unequal pointers to `void` in all cases, whereas C does specify the result if the pointer values point to the same object or (possibly different) subobjects thereof, because C considers `void` an object type.

February, 2023

Requested confirmation of the C status quo from SG22.

Rationale (June, 2023)

This issue is a duplicate of issue 2749.

#### 1626. `constexpr` member functions in brace-or-equal-initializers

Section: 7.7 [expr.const] Status: dup Submitter: Daveed Vandevoorde Date: 2013-02-19

The Standard should make clear that a `constexpr` member function cannot be used in a constant expression until its class is complete. For example:

      template<typename T> struct C {
        template<typename T2> static constexpr bool _S_chk() {
          return false;
        }
        static const bool __value = _S_chk<int>();
      };

      C<double> c;

Current implementations accept this, although they reject the corresponding non-template case:

      struct C {
        static constexpr bool _S_chk() { return false; }
        static const bool __value = _S_chk();
      };

      C c;

Presumably the template case should be handled consistently with the non-template case.

CWG 2024-06-28

CWG opined that, contrary to the assertion in the issue, the treatment of non-templated class definitions should be changed to more closely resemble templated ones. This direction is covered by issue 2335.

#### 1445. Argument-dependent lookup of `begin` and `end`

Section: 8.6.5 [stmt.ranged] Status: dup Submitter: Mike Miller Date: 2012-01-16

According to 8.6.5 [stmt.ranged] paragraph 1, the functions `begin` and `end` are looked up “with argument-dependent lookup (6.5.4 [basic.lookup.argdep])” for non-array, non-class types and for class types with no members of those names. It seems surprising that the lookup is different from the lookup that would result if the `for` statement were replaced by its nominal expansion, i.e., including (as does the referenced section, 6.5.4 [basic.lookup.argdep]) the result of ordinary unqualified lookup as well as the lookup in associated namespaces.

Rationale (February, 2012):

This issue is a duplicate of issue 1442.

#### 1498. Lifetime of temporaries in range-based `for`

Section: 8.6.5 [stmt.ranged] Status: dup Submitter: Beman Dawes Date: 2012-04-26

Because the reference `__range` in the expansion of a range-based `for` statement, as described in 8.6.5 [stmt.ranged] paragraph 1, is bound only to the top-level expression of range-init, the lifetime of temporaries created at lower levels in that expression expires before the body of the loop is reached, leading to dangling references. It would be helpful if the lifetime of those temporaries were extended over the entire statement.

(See also issue 1523 for another question regarding the rewritten form of the range-based `for`.)

Rationale (October, 2012):

This is a duplicate of issue 900.

#### 2884. Qualified declarations of partial specializations

Section: 9.2.9.5 [dcl.type.elab] Status: dup Submitter: Krystian Stasiowski Date: 2024-03-19

(From submission #521.)

Consider:

      namespace N
      {
        template<typename T>
        struct A;
      }

      template<>
      struct N::A<int>;   // #1

      template<typename T>
      struct N::A<T*>;    // #2

#1 is currently well-formed, but #2 is an ill-formed use of an elaborated-type-specifier. This is inconsistent and not aligned with implementation practice.

Suggested resolution:

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

CWG 2024-05-17

Duplicate of issue 2874.

#### 2493. `auto` as a conversion-type-id

Section: 9.2.9.7.1 [dcl.spec.auto.general] Status: dup Submitter: Jim X Date: 2021-03-10

Given the example,

      struct A{
       operator auto(){
         return 0;
       }
      };
      int main(){
        A a;
        a.operator auto(); // #1
        a.operator int();  // #2
      }

there is implementation divergence regarding which, if either, of the calls is well-formed. MSVC and clang reject #2, g++ rejects #1, and EDG rejects both.

According to 9.2.9.7.1 [dcl.spec.auto.general] paragraph 6:

> A program that uses a placeholder type in a context not explicitly allowed in 9.2.9.7 [dcl.spec.auto] is ill-formed.

The use of `auto` as a conversion-type-id in a function call is not mentioned in that section; however, the section is dealing with declarative contexts rather than expressions, so it's not clear how much weight that observation should carry.

Rationale (December, 2021):

This issue is a duplicate of issue 1670.

#### 548. qualified-ids in declarations

Section: 9.3.4 [dcl.meaning] Status: dup Submitter: Martin Sebor Date: 18 November 2005

According to 9.3.4 [dcl.meaning] paragraph 1, the declarator in the definition or explicit instantiation of a namespace member can only be qualified if the definition or explicit instantiation appears outside the member's namespace:

> A declarator-id shall not be qualified except for the definition of a member function (11.4.2 [class.mfct]) or static data member (11.4.9 [class.static]) outside of its class, the definition or explicit instantiation of a function or variable member of a namespace outside of its namespace, or the definition of a previously declared explicit specialization outside of its namespace, or the declaration of a friend function that is a member of another class or namespace (11.8.4 [class.friend]). When the declarator-id is qualified, the declaration shall refer to a previously declared member of the class or namespace to which the qualifier refers, and the member shall not have been introduced by a using-declaration in the scope of the class or namespace nominated by the nested-name-specifier of the declarator-id.

There is no similar restriction on a qualified-id in a class definition (Clause 11 [class] paragraph 5):

> If a class-head contains a nested-name-specifier, the class-specifier shall refer to a class that was previously declared directly in the class or namespace to which the nested-name-specifier refers (i.e., neither inherited nor introduced by a using-declaration), and the class-specifier shall appear in a namespace enclosing the previous declaration.

An elaborated-type-specifier in an explicit instatiation containing a qualified-id is also not prohibited from appearing in the namespace nominated by its nested-name-specifier (13.9.3 [temp.explicit] paragraph 2):

> An explicit instantiation shall appear in an enclosing namespace of its template. If the name declared in the explicit instantiation is an unqualified name, the explicit instantiation shall appear in the namespace where its template is declared.

(This asymmetry is due to the removal of inappropriate mention of classes in 9.3.4 [dcl.meaning] by issue 40 and a failure to insert the intended restrictions elsewhere.)

An example of this inconsistency is:

        namespace N {
          template <class T> struct S { };
          template <class T> void foo () { }

          template struct N::S<int>;   // OK
          template void N::foo<int>(); // ill-formed
        }

It is not clear that any purpose is served by the “outside of its namespace” restriction on declarators in definitions and explicit instantiations; if possible, it would be desirable to reconcile the treatment of declarators and class names by removing the restriction on declarators (which appears to be widespread implementation practice, anyway).

Rationale (April, 2006):

This is the same as issue 482.

#### 550. Pointer to array of unknown bound in parameter declarations

Section: 9.3.4.6 [dcl.fct] Status: dup Submitter: Daveed Vandevoorde Date: 22 November 2005

The current wording of 9.3.4.6 [dcl.fct] paragraph 6 encompasses more than it should:

> If the type of a parameter includes a type of the form “pointer to array of unknown bound of `T`” or “reference to array of unknown bound of `T`,” the program is ill-formed. [Footnote: This excludes parameters of type “ptr-arr-seq `T2`” where `T2` is “pointer to array of unknown bound of `T`” and where ptr-arr-seq means any sequence of “pointer to” and “array of” derived declarator types. This exclusion applies to the parameters of the function, and if a parameter is a pointer to function or pointer to member function then to its parameters also, etc. —end footnote]

The normative wording (contrary to the intention expressed in the footnote) excludes declarations like

        template<class T> struct S {};
        void f(S<int (*)[]>);

and

        struct S {};
        void f(int(*S::*)[]);

but not

        struct S {};
        void f(int(S::*)[]);

Rationale (November, 2014):

This issue is a duplicate of issue 393.

#### 998. Function parameter transformations and template functions

Section: 9.3.4.6 [dcl.fct] Status: dup Submitter: Jason Merrill Date: 8 November, 2009

9.3.4.6 [dcl.fct] paragraph 5 specifies that cv-qualifiers are deleted from parameter types. However, it's not clear what this should mean for function templates. For example,

        template<class T> struct A {
           typedef A arr[3];
        };

        template<class T> void f(const typename A<T>::arr) { }

        template void f<int>(const A<int>::arr); // #1

        template <class T> struct B {
           void g(T);
        };

        template <class T> void B<T>::g(const T) { } // #2

If cv-qualifiers are dropped, then the explicit instantiation in #1 will fail to match; if cv-qualifiers are retained, then the definition in #2 does not match the declaration.

Rationale (August, 2010):

This is a duplicate of issue 1001.

#### 15. Default arguments for parameters of function templates

Section: 9.3.4.7 [dcl.fct.default] Status: dup Submitter: unknown Date: unknown

9.3.4.7 [dcl.fct.default] paragraph 4 says:

> For non-template functions, default arguments can be added in later declarations of a functions in the same scope.

Why say for non-template functions? Why couldn't the following allowed?

        template <class T> struct B {
            template <class U> inline void f(U);
        };

        template <class T> template <class U>
        inline void B<T>::f(U = int) {} // adds default arguments
                                           // is this well-formed?
        void g()
        {
            B<int> b;
            b.f();
        }

If this is ill-formed, chapter 14 should mention this.

Rationale: This is sufficiently clear in the standard. Allowing additional default arguments would be an extension.

Notes from October 2002 meeting:

The example here is flawed. It's not clear what is being requested. One possibility is the extension introduced by issue 226. Other meanings don't seem to be useful.

#### 155. Brace initializer for scalar

Section: 9.5 [dcl.init] Status: dup Submitter: Steve Clamage Date: 12 Aug 1999

It is not clear whether the following declaration is well-formed:

        struct S { int i; } s = { { 1 } };

According to 9.5.2 [dcl.init.aggr] paragraph 2, a brace-enclosed initializer is permitted for a subaggregate of an aggregate; however, `i` is a scalar, not an aggregate. 9.5 [dcl.init] paragraph 13 says that a standalone declaration like

        int i = { 1 };

is permitted, but it is not clear whether this says anything about the form of initializers for scalar members of aggregates.

This is (more) clearly permitted by the C89 Standard.

Rationale (May, 2008):

Issue 632 refers to exactly the same question and has a more detailed discussion of the considerations involved.

#### 2269. Additional recursive references in aggregate DMIs

Section: 9.5.2 [dcl.init.aggr] Status: dup Submitter: Vinny Romano Date: 2016-06-07

Issue 1696 did not fully address recursive references in default member initializers for aggregates, for example:

      struct S {
        int i = (S{}, 0);
      };

or

      struct S {
        int i = noexcept(S{});
      };

#### 2018. Qualification conversion vs reference binding

Section: 9.5.4 [dcl.init.ref] Status: dup Submitter: Richard Smith Date: 2014-10-07

Qualification conversions are not considered when doing reference binding, which leads to some unexpected results:

      template<typename T> T make();
      struct B {}; struct D : B {};

      const int *p1 = make<int*>();           // ok, qualification conversion
      const int *const *p2 = make<int**>();   // ok, qualification conversion
      const int **p3 = make<int**>();         // error, not type safe

      const int &r1 = make<int&>();           // ok, binds directly
      const int *const &r2 = make<int*&>();   // weird, binds to a temporary
      const int *&r3 = make<int*&>();         // error

      const int &&x1 = make<int&&>();         // ok, binds directly
      const int *const &&x2 = make<int*&&>(); // weird, binds to a temporary
      const int *&&x3 = make<int*&&>();       // weird, binds to a temporary

It might make sense to say that similar types are reference-related and if there is a qualification conversion they are reference-compatible.

See also issue 2023.

Rationale (September, 2023):

This issue is a duplicate of issue 2352.

#### 1505. Direct binding of reference to temporary in list-initialization

Section: 9.5.5 [dcl.init.list] Status: dup Submitter: Steve Adamczyk Date: 2012-05-27

In an example like

      const int&r {1};

the expectation is that this creates a temporary of type `const int` containing the value `1` and binds the reference to it. And it does, but along the way it creates two temporaries. The wording in 9.5.5 [dcl.init.list] paragraph 3, the bullet on reference initialization, says that a prvalue temporary of type `const int` is created, and then we do reference binding. Because this is a non-class case and the source is a prvalue, we end up in the section of 9.5.4 [dcl.init.ref] that says we create a temporary (again of type `const int`) and initialize it from the source. So we've created two temporaries. Now, this may not matter to anyone, since the discarded temporary is not observable, but it may be a concern that the reference is not binding directly to the temporary created for the `{1}`, since we do sometimes base behavior on the “bind directly” attribute.

Rationale (September, 2012):

This issue is based on the wording prior to the application of the resolution of issue 1288. With that change, there is no longer a problem.

#### 2314. Structured bindings and lambda capture

Section: 9.7 [dcl.struct.bind] Status: dup Submitter: Richard Smith Date: 2016-08-14

Consider:

      void f() {
       tuple<int, int> a;
       auto &[x, y] = a;
       [x] {};           // ok, captures reference to int member of 'a' by value
       [&] { use(x); };  // ok, capture reference by reference
      }

      void g() {
       struct T { int a, b; } a;
       auto &[x, y] = a;
       [x] {};           // ill-formed, 'x' does not name a variable
       [&] { use(x); };  // ???
      }

The standard is silent on whether and how identifiers of a decomposition declaration can be captured by a lambda.

Rationale (July, 2017):

This issue is a duplicate of issue 2308.

#### 1713. Linkage of variable template specializations

Section: 9.12 [dcl.link] Status: dup Submitter: Richard Smith Date: 2013-07-08

Given a namespace-scope declaration like

      template<typename T> T var = T();

should `T<const int>` have internal linkage by virtue of its const-qualified type? Or should it inherit the linkage of the template?

Notes from the February, 2014 meeting:

CWG noted that linkage is by name, and a specialization of a variable template does not have a name separate from that of the variable template, thus the specialization will have the linkage of the template.

Rationale (February, 2021):

This issue is a duplicate of, and resolved by the resolution of, issue 2387.

#### 1039. Coordinating C and C++ alignment specifications

Section: 9.13.2 [dcl.align] Status: dup Submitter: Steve Adamczyk Date: 2010-03-03

WG14 intends to support alignment specifications in their next Standard. WG21 should explore possibilities for compatibility between C and C++ for these specifications. See paper N3093.

Rationale (August, 2010):

This is a duplicate of issue 1115.

#### 1041. alias-declarations as class members

Section: 11.4 [class.mem] Status: dup Submitter: Daveed Vandevoorde Date: 2010-03-04

The grammar for member-declaration in 11.4 [class.mem] does not allow an alias-declaration as a class member. This seems like an oversight.

Rationale (August, 2010):

This issue is a duplicate of 924.

#### 1052. `const` non-static data member and PODness

Section: 11.4.5.3 [class.copy.ctor] Status: dup Submitter: Jason Merrill Date: 2010-03-12

The class

        struct A {
            const int i;
        };

was previously considered a POD class, but it no longer is, because it has a non-trivial (deleted) copy assignment operator. The impact of this change is not clear.

Rationale (August, 2010):

This is a duplicate of issue 1140.

#### 1203. Misleading note regarding initialized static data members

Section: 11.4.9.3 [class.static.data] Status: dup Submitter: Jason Merrill Date: 2010-09-30

11.4.9.3 [class.static.data] paragraph 3 says,

> If a `static` data member is of `const` literal type, its declaration in the class definition can specify a brace-or-equal-initializer in which every initializer-clause that is an assignment-expression is a constant expression. A `static` data member of literal type can be declared in the class definition with the `constexpr` specifier; if so, its declaration shall specify a brace-or-equal-initializer in which every initializer-clause that is an assignment-expression is a constant expression. [Note: In both these cases, the member may appear in constant expressions. —end note]

The note is misleading; to be used for its value in a constant expression, the static data member must either be declared constexpr or have integral or enumeration type. Though strictly speaking, the note is true, because any static data member, initialized or not, may appear in an address constant expression if its address is taken.

I think the right fix is to change “const literal” back to “const integral or const enumeration.” It would also be nice to avoid the duplication of text.

Rationale (November, 2010):

This is a duplicate of issue 1101.

#### 1019. Dependent simple-template-ids in base-specifiers and mem-initializers

Section: 11.7 [class.derived] Status: dup Submitter: Doug Gregor Date: 2010-01-12

Although accepted by several compilers and used in popular code, the grammar currently does not permit the use of a dependent template name in a base-specifier or mem-initializer-id, for example:

        template<typename T, typename U>
        struct X : T::template apply<U> { };

There does not seem to be a good reason to reject this usage.

Rationale (August, 2010):

This issue is a duplicate of issue 314.

#### 747. Access of protected base classes

Section: 11.8.3 [class.access.base] Status: dup Submitter: Sam Saariste Date: 18 November, 2008

Consider the following example:

        struct B { void f(){} };
        class N : protected B { };

        struct P: N { friend int main(); };
        int main() {
              N n;
              B& b = n; // R
              b.f();
        }

This code is rendered well-formed by bullet 3 of 11.8.3 [class.access.base] paragraph 4, which says that a base class `B` of `N` is accessible at R if

- R occurs in a member or friend of a class `P` derived from `N`, and an invented public member of `B` would be a private or protected member of `P`

This provision circumvents the additional restrictions on access to protected members found in 11.8.5 [class.protected] — `main()` could not call `B::f()` directly because the reference is not via an object of the class through which access is obtained. What is the purpose of this rule?

Rationale (April, 2010):

This is a duplicate of issue 472.

#### 1855. Out-of-lifetime access to nonstatic data members

Section: 11.9.5 [class.cdtor] Status: dup Submitter: Mike Miller Date: 2014-02-11

The resolution of issue 597 and anticipated resolution of issue 1517 allow access to non-virtual base classes outside the lifetime of the object. However, for no apparent reason, references to nonstatic data members are still prohibited. This disparity should be rectified.

Rationale (November, 2014):

This issue is a duplicate of issue 1530.

#### 1373. Overload resolution changes matching reference-binding changes

Section: 12.2.2.7 [over.match.ref] Status: dup Submitter: Michael Wong Date: 2011-08-15

It looks like the resolution to issue 1138 neglected to update 12.2.2.7 [over.match.ref] (in N3225) or otherwise mention it from 9.5.4 [dcl.init.ref] for the rvalue cases.

Since this is a context where overload resolution is required (to find the correct conversion function), 12.2.2.7 [over.match.ref] should probably be used (12.2 [over.match] paragraph 2); however, there are some oddities.

(Issue 1)

Consider:

        struct A {
          typedef void functype();
          operator functype&&();
        };
        void (&&x)() = A();

We are looking for a function lvalue; 12.2.2.7 [over.match.ref] (if we take it to be applicable) says the viable functions are limited to conversion functions yielding “lvalue reference” when 9.5.4 [dcl.init.ref] requires an lvalue result. The above would then fail to have any candidate conversion functions and we are left with a non-viable indirect binding to a “function temporary.”

(Issue 2)

Also, since the candidate functions in the case where an rvalue (that is prvalue or xvalue) result is required do not include ones which return lvalue references, I do not see what the wording regarding the second standard conversion sequence having an lvalue-to-rvalue transformation added in issue 1138 is meant to catch.

If the example containing

        int&& rri2 = X();

with a comment about `operator int&()` is a clue, then it seems that 12.2.2.7 [over.match.ref] is being ignored.

(Conclusion)

It would seem that 12.2.2.7 [over.match.ref] should apply (and be fixed to match the cases from issue1138), the verbiage about the second standard conversion is redundant, and the explanation in the example is wrong.

In particular, the previous wording for 9.5.4 [dcl.init.ref] did have distinct bullets for converting to an “lvalue” and to an “rvalue;” we now have a bullet which is not exclusively one or the other.

Possible fix

Add reference to [12.2.2.7 [over.match.ref]] in 9.5.4 [dcl.init.ref] for direct binding to rvalue reference/const non-volatile via UDC.

Remove redundent sentence referring to second SCS.

Modify example to indicate `operator int&()` is not a candidate function.

Clarify that the point from 9.5.4 [dcl.init.ref] below:

> has a class type (i.e., `T2` is a class type), where `T1` is not reference-related to `T2`, and can be implicitly converted to an xvalue, class prvalue, or function lvalue of type “cv3 `T3`,” where “cv1 `T1`” is reference-compatible with “cv3 `T3`”...

is an rvalue case for 12.2.2.7 [over.match.ref] for non-function types and lvalue case for function types.

Fix 12.2.2.7 [over.match.ref] to allow candidate functions return rvalue reference to function type for lvalue cases.

Update 110510:

The example appears to be actually well-formed because the wording about the second SCS is not triggered. Falling through to indirect binding then succeeds.

Rationale (February, 2012):

This issue is a duplicate of issue 1328.

#### 2291. Implicit conversion sequences in non-call contexts

Section: 12.2.4.2 [over.best.ics] Status: dup Submitter: Hubert Tong Date: 2016-06-20

Rationale (August, 2017):

This issue is a duplicate of issue 2243.

#### 1205. Lvalue reference binding and function viability

Section: 12.2.4.2.5 [over.ics.ref] Status: dup Submitter: Steve Clamage Date: 2010-10-06

According to 12.2.4.2.5 [over.ics.ref] paragraph 3,

> Except for an implicit object parameter, for which see 12.2.2 [over.match.funcs], a standard conversion sequence cannot be formed if it requires binding an lvalue reference to non-`const` to an rvalue or binding an rvalue reference to an lvalue.

This isn't precisely the restriction placed by 9.5.4 [dcl.init.ref] on binding an lvalue reference to an rvalue; the requirement there is that the cv-qualification must be exactly `const` in such cases. This has an impact on the interpretation of the following example:

        void f(const volatile int&);
        void f(...);
        void g() {
            f(1);
        }

Because `f(const volatile int&)` is considered a viable function for the call, it is a better match than `f(...)`, but the binding of the argument to the parameter cannot be done, so the program is ill-formed. Presumably “lvalue reference to non-`const`” should be clarified to exclude the `const volatile` case. (Implementations vary on their handling of this example.)

Rationale (November, 2010):

This is a duplicate of issue 1152.

#### 507. Ambiguity assigning class object to built-in type

Section: 12.5 [over.built] Status: dup Submitter: Steve Adamczyk Date: 9 Mar 2005

The following example is ambiguous according to the Standard:

        struct Y {
          operator int();
          operator double();
        };
        void f(Y y) {
          double d;
          d = y;    // Ambiguous: Y::operator int() or Y::operator double()?
        }

The reason for the ambiguity is that 12.5 [over.built] paragraph 18 says that there are candidate functions `double& operator=(double&, int)` and `double& operator=(double&, double)` (among others). In each case, the second argument is converted by a user-defined conversion sequence (12.2.4.2.3 [over.ics.user]) where the initial and final standard conversion sequences are the identity conversion — i.e., the conversion sequences for the second argument are indistinguishable for each of these candidate functions, and they are thus ambiguous.

Intuitively one might expect that, because it converts directly to the target type in the assignment, `Y::operator double()` would be selected, and in fact, most compilers do select it, but there is currently no rule to distinguish between these user-defined conversions. Should there be?

Additional note (May, 2008):

Here is another example that is somewhat similar:

        enum En { ec };

        struct S {
           operator int();
           operator En();
        };

        void foo () {
           S() == 0;   // ambiguous?
        }

According to 12.5 [over.built] paragraph 12, the candidate functions are

`bool operator==(L, R);`

where `R` is `int` and `L` is every promoted arithmetic type. Overload resolution proceeds in two steps: first, for each candidate function, determine which implicit conversion sequence is used to convert from the argument type to the parameter type; then compare the candidate functions on the basis of the relative costs of those conversion sequences.

In the case of `operator==(int, int)` there is a clear winner: `S::operator int()` is chosen because the identity conversion `int -> int` is better than the promotion `En -> int`. For all the other candidates, the conversion for the first parameter is ambiguous: both `S::operator int()` and `S::operator En()` require either an integral conversion (for integral `L`) or a floating-integral conversion (for floating point `L`) and are thus indistinguishable.

These additional candidates are not removed from the set of viable functions, however; because of 12.2.4.2 [over.best.ics] paragraph 10, they are assigned the “ambiguous conversion sequence,” which “is treated as a user-defined sequence that is indistinguishable from any other user-defined conversion sequence.” As a result, all the viable functions are indistinguishable and the call is ambiguous. Like the earlier example, one might naively think that the exact match with `S::operator int()` and `bool operator==(int, int)` would be selected, but that is not the case.

Rationale (August, 2010):

Duplicate of issue 260.

#### 72. Linkage and storage class specifiers for templates

Section: Clause 13 [temp] Status: dup Submitter: Mike Ball Date: 19 Oct 1998

John Spicer: The standard does say that a namespace scope template has external linkage unless it is a function template declared "static". It doesn't explicitly say that the linkage of the template is also the linkage of the instantiations, but I believe that is the intent. For example, a storage class is prohibited on an explicit specialization to ensure that a specialization cannot be given a different storage class than the template on which it is based.

Mike Ball: This makes sense, but I couldn't find much support in the document. Sounds like yet another interpretation to add to the list.

John Spicer: The standard does not talk about the linkage of instantiations, because only "names" are considered to have linkage, and instances are not really names. So, from an implementation point of view, instances have linkage, but from a language point of view, only the template from which the instances are generated has linkage.

Mike Ball: Which is why I think it would be cleaner to eliminate storage class specifiers entirely and rely on the unnamed namespace. There is a statement that specializations go into the namespace of the template. No big deal, it's not something it says, so we live with what's there.

John Spicer: That would mean prohibiting static function templates. I doubt those are common, but I don't really see much motivation for getting rid of them at this point.

"export" is an additional attribute that is separate from linkage, but that can only be applied to templates with external linkage.

Mike Ball: I can't find that restriction in the standard, though there is one that templates in an unnamed namespace can't be exported. I'm pretty sure that we intended it, though.

John Spicer: I can't find it either. The "inline" case seems to be addressed, but not static. Surely this is an error as, by definition, a static template can't be used from elsewhere.

Rationale: Duplicate of Core issue 69.

#### 1023. `thread_local` objects as non-type template arguments

Section: 13.4.3 [temp.arg.nontype] Status: dup Submitter: Jeffrey Yasskin Date: 2010-01-28

Currently, 13.4.3 [temp.arg.nontype] paragraph 1 only requires that an object whose address is used as a non-type template argument have external linkage, thus allowing objects of thread storage duration to be used. The requirement should presumably be for an object to have static storage duration as well as external linkage.

Rationale (August, 2010):

This is a duplicate of issue 1154.

#### 2391. Additional template parameters following pack expansion

Section: 13.7.4 [temp.variadic] Status: dup Submitter: Richard Smith Date: 2018-12-03

The Standard is not clear on the treatment of an example like the following, and there is implementation variance:

      template<class ...Types> struct Tuple_ { // _VARIADIC_TEMPLATE
        template<Types ...T, int> int f() {
          return sizeof...(Types);
        }
      };

      int main() {
        Tuple_<char,int> a;
        int b = a.f<1, 2, 3>();
      }

Rationale (February, 2019):

This issue is covered in more detail in issue 2395.

#### 2021. Function template redeclaration via alias template

Section: 13.7.7.2 [temp.over.link] Status: dup Submitter: Richard Smith Date: 2014-10-15

See also issue 2025.

Given the declarations

       template<int> using T = int;
       template<typename U> void h(T<f(U())>);
       template<typename U> void h(T<g(U())>);

Does this declare one function template or two?

Rationale (November, 2014):

This issue is a duplicate of issue 1980.

#### 2025. Declaration matching via alias templates

Section: 13.7.7.2 [temp.over.link] Status: dup Submitter: Richard Smith Date: 2014-10-17

Consider the following example:

      template<typename ...T> struct X { void f(); static int n; };
      template<typename T, typename U> using A = T;
      template<typename ...T> void X<A<T, decltype(sizeof(T))>...>::f() {}
      template<typename ...T> void X<A<T, decltype(sizeof(T))>...>::n = 0;
      void g() { X<void>().f(); X<void>::n = 1; }

Should this be valid? The best answer would seem to be to produce an error during instantiation, and that appears to be consistent with the current Standard wording, but there is implementation divergence.

See also issue 2021.

Rationale (May, 2015):

This issue is a duplicate os issue 1979.

#### 200. Partial ordering and explicit arguments

Section: 13.7.7.3 [temp.func.order] Status: dup Submitter: Martin Sebor Date: 28 Jan 2000

The description of how the partial ordering of template functions is determined in 13.7.7.3 [temp.func.order] paragraphs 3-5 does not make any provision for nondeduced template parameters. For example, the function call in the following code is ambiguous, even though one template is "obviously" more specialized than the other:

        template <class T> T f(int);
        template <class T, class U> T f(U);
        void g() {
            f<int>(1);
        }

The reason is that neither function parameter list allows template parameter `T` to be deduced; both deductions fail, so neither template is considered more specialized than the other and the function call is ambiguous.

One possibility of addressing this situation would be to incorporate explicit template arguments from the call in the argument deduction using the transformed function parameter lists. In this case, that would result in finding the first template to be more specialized than the second.

Rationale (04/00):

This issue is covered in a more general context in issue 214.

#### 1349. Consistency of alias template redeclarations

Section: 13.7.8 [temp.alias] Status: dup Submitter: Richard Smith Date: 2011-08-16

There appears to be no requirement that a redeclaration of an alias template must be equivalent to the earlier one. An alias-declaration is not a definition (6.2 [basic.def] paragraph 2), so presumably an alias template declaration is also not a definition and thus the ODR does not apply.

Rationale (November, 2014):

This issue is superseded by issue 1896.

#### 375. Confusing example on lookup with `typename`

Section: 13.8 [temp.res] Status: dup Submitter: Manish Pagey Date: 23 August 2002

Section 13.8 [temp.res] paragraph 4 uses the following example to show that qualified name lookup described in Section 6.5.5 [basic.lookup.qual] applies even in the presence of "typename":

      struct A {
        struct X { } ;
        int X ;
      } ;
      template<class T> void f(T t) {
        typename T::X x ; // ill-formed: finds the data member X
                          // not the member type X
      }

This example is confusing because the definition of the template function itself is not ill formed unless it is instantiated with "A" as the template parameter. In other words, the example should be modified to something like:

      struct A {
        struct X { } ;
        int X ;
      } ;
      struct B {
        struct X { } ;
      } ;
      template<class T> void f(T t) {
        typename T::X x ;
      }
      void foo() {
        A a ;
        B b ;
        f(b) ; // OK -- finds member type B::X.
        f(a) ; // ill-formed: finds the data member A::X not
               // the member type A::X.
      }

Notes from October 2002 meeting:

This is a duplicate of Core Issue 345.

#### 1526. Dependent-class lookup in the current instantiation

Section: 13.8.3 [temp.dep] Status: dup Submitter: Johannes Schaub Date: 2012-07-22

According to 13.8.3 [temp.dep] paragraph 3,

> In the definition of a class or class template, if a base class depends on a template-parameter, the base class scope is not examined during unqualified name lookup either at the point of definition of the class template or member or during an instantiation of the class template or member.

Note that this is phrased not as “if a base class is a dependent type” but as “if a base class depends on a template-parameter;” the current instantiation depends on a template-parameter but is not a dependent type. The difference can be seen in this example:

      template<typename T> struct A {
        typedef int type;
        struct C;
      };

      template<typename T> struct A<T>::C {
        void type();
        struct B;
      };

      template<typename T> struct A<T>::C::B : A<T> {
        type x;
      };

      A<int>::C::B b;   // #1

If the excluded bases were dependent types, the reference to `type` at #1 would resolve to `A::type`; with the current wording, the reference resolves to `C::type`.

(See also issue 1524 for another case in which this distinction makes a difference.)

Rationale (September, 2012):

This issue is a duplicate of issue 591.

#### 1994. Confusing wording regarding multiple `template<>` prefixes

Section: 13.9.4 [temp.expl.spec] Status: dup Submitter: Richard Smith Date: 2014-09-03

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

> A member or a member template may be nested within many enclosing class templates. In an explicit specialization for such a member, the member declaration shall be preceded by a template<> for each enclosing class template that is explicitly specialized. [Example:

>       template<class T1> class A {
>         template<class T2> class B {
>           void mf();
>         };
>       };
>       template<> template<> class A<int>::B<double>;
>       template<> template<> void A<char>::B<char>::mf();

> —end example]

However, in the declaration of `A<int>::B<double>`, `A<int>` is not explicitly instantiated, it is implicitly instantiated.

Rationale (November, 2014):

This issue is a duplicate of issue 529.

#### 1326. Deducing an array bound from an initializer-list

Section: 13.10.3.2 [temp.deduct.call] Status: dup Submitter: Faisal Vali Date: 2011-05-28

It would be useful to be able to deduce an array bound from the number of elements in an initializer list.

Rationale (August, 2011):

The implications of array temporaries for the language should be considered by the Evolution Working Group in a comprehensive fashion rather than on a case-by-case basis. See also issues 1300, 1307, and 1525.

Rationale (January, 2021):

This issue is a duplicate of issue 1591.

#### 2326. Type deduction with initializer list containing ambiguous functions

Section: 13.10.3.2 [temp.deduct.call] Status: dup Submitter: Jonathan Caves Date: 2016-08-12

Consider the following example:

      template<typename T, int N> void g(T (* const (&)[N])(T)) { }

      int f1(int);
      int f4(int);
      char f4(char);

      void f() {
        g({ &f1, &f4 });  // OK, T deduced to int, N deduced to 2?
      }

There is implementation divergence on the handling of this example. According to 13.10.3.2 [temp.deduct.call] paragraph 1,

> If removing references and cv-qualifiers from `P` gives `std::initializer_list<P'>` or `P'[N]` for some `P'` and `N` and the argument is a non-empty initializer list (9.5.5 [dcl.init.list]), then deduction is performed instead for each element of the initializer list, taking `P'` as a function template parameter type and the initializer element as its argument, and in the `P'[N]` case, if `N` is a non-type template parameter, `N` is deduced from the length of the initializer list.

Deduction fails for the `&f4` element fails due to ambiguity, so by 13.10.3.6 [temp.deduct.type] bullet 5.5.1 the function parameter is a non-deduced context.

It is not clear, however, whether that implies that the function parameter is a non-deduced context from the perspective of the entire deduction, so we cannot deduct `T` and `N`, or if it's only a non-deduced context for this slice of the initializer list deduction and we can still deduce the template parameters from the `&f1` element.

See also issue 1513.

Rationale, July, 2017

This issue is a duplicate of issue 2318.

#### 1337. Partial ordering and non-deduced parameters

Section: 13.10.3.5 [temp.deduct.partial] Status: dup Submitter: Jason Merrill Date: 2011-07-05

Rationale (August, 2011):

This issue duplicates issue 455.

#### 133. Exception specifications and checking

Section: 14.5 [except.spec] Status: dup Submitter: Daveed Vandevoorde Date: 25 June 1999

14.5 [except.spec] paragraph 1 says,

> An exception-specification shall appear only on a function declarator in a function, pointer, reference or pointer to member declaration or definition.

This wording forbids exception specifications in declarations where they might plausibly occur (e.g., an array of function pointers). This restriction seems arbitrary. It's also unclear whether this wording allows declarations such as

        void (*f())() throw(int);  // returns a pointer to a function
                                   // that might throw "int"

At the same time, other cases are allowed by the wording in paragraph 1 (e.g., a pointer to a pointer to a function), but no checking for such cases is specified in paragraph 3. For example, the following appears to be allowed:

        void (*p)() throw(int);
        void (**pp)() throw() = &p;

Rationale (10/99): Duplicate of issues 87 and 92.

#### 595. Exception specifications in templates instantiated from class bodies

Section: 14.5 [except.spec] Status: dup Submitter: Daveed Vandevoorde Date: 7 September 2006

A type used in an exception specification must be complete (14.5 [except.spec] paragraph 2). The resolution of issue 437 stated that a class type appearing in an exception specification inside its own member-specification is considered to be complete. Should this also apply to exception specifications in class templates instantiated because of a reference inside the member-specification of a class? For example,

        template<class T> struct X {
            void f() throw(T) {}
        };

        struct S {
            X<S> xs;
        };

Note, January, 2012:

With the deprecation of dynamic-exception-specifications, the importance of this issue is reduced even further. The current specification is clear, and the suggested resolution is an extension. It has been suggested that the issue be closed as NAD.

Notes from the February, 2012 meeting:

The outcome of this issue will be affected by the resolution of issue 1330. See also issue 287.

This issue is subsumed by the newer issue 1330 and should be discussed in that context.

#### 2420. Exception specifications in explicit instantiation

Section: 14.5 [except.spec] Status: dup Submitter: John Spicer Date: 2019-06-19

The expected behavior of the following example is not clear:

      template<class T> struct Y {
        typedef typename T::value_type blah;
        void swap(Y<T> &);
      };
      template<class T>
      void swap(Y<T>& Left, Y<T>& Right) noexcept(noexcept(Left.swap(Right))) {
      }

      template <class T> struct Z {
         void swap(Z<T> &);
      };
      template<class T>
      void swap(Z<T>& Left, Z<T>& Right) noexcept(noexcept(Left.swap(Right))) {
      }
      Z<int> x00, y00;
      constexpr bool b00 = noexcept(x00.swap(y00));
      // Instantiates the Z<int> overload:
      template void swap<int>(Z<int>&, Z<int>&) noexcept(b00);

The question is whether the explicit instantiation directive also instantiates the `Y<int>` overload and thus `Y<int>` (because of the exception specification), which will fail because of the reference to `T::value_type` with `T=int`.

According to 14.5 [except.spec] bullet 13.3, one of the contexts in which an exception specification is needed (thus triggering its instantiation) is when:

> the exception specification is compared to that of another declaration (e.g., an explicit specialization or an overriding virtual function);

In this example, the declarations of `swap` must be compared in order to determine which function template is being instantiated, resulting in the instantiation of `Y<int>`. There is implementation divergence, however, with some accepting the example and some issuing an error for the instantiation of `Y<int>`.

Rationale (February, 2022): Duplicate of issue 2417.

#### 79. Alignment and placement new

Section: 17.6.3.4 [new.delete.placement] Status: dup Submitter: Herb Sutter Date: 15 Dec 1998

The example in 17.6.3.4 [new.delete.placement] reads:

> [Example: This can be useful for constructing an object at a known address:

>         char place[sizeof(Something)];
>         Something* p = new (place) Something();

> —end example]

This example has potential alignment problems. One way to correct it would be to change the definition of `place` to read:

        char* place = new char[sizeof(Something)];

Rationale (10/99): This is an issue for the Library Working Group.

#### 1377. Access declarations not mentioned in Annex C

Section: C.6 [diff.cpp03] Status: dup Submitter: Daveed Vandevoorde Date: 2011-08-18

Access declarations were removed from C++11 but are not mentioned in C.6 [diff.cpp03].

Rationale (January, 2012):

Issue 1279 already deals with missing differences between C++03 and C++11; this specific item has been added to the list there.

### Issues with "concepts" Status

#### 889. Default implementations of associated functions

Section: _N2914_.14.10.1.1 [concept.fct] Status: concepts Submitter: Daniel Krügler Date: 4 May, 2009

In the example in _N2914_.14.10.1.1 [concept.fct] paragraph 10,

        concept EqualityComparable<typename T> {
          bool operator==(T, T);
          bool operator!=(T x, T y) { return !(x == y); }
        }

is the call to `operator==` in the default implementation well-formed, or is another requirement needed to allow the arguments to be passed by value? If another requirement is needed, should it be added in this example, or should the rules for implicit requirements be changed so that the example is well-formed?

#### 780. Questions regarding the point of definition of a concept map

Section: _N2914_.14.10.2 [concept.map] Status: concepts Submitter: James Widman Date: 10 February, 2009

1. According to _N2914_.14.11.1.1 [temp.req.sat] paragraph 2, a concept requirement is satisfied if a concept map with the same name and template argument list is found by concept map lookup. The point at which the name of a concept map is inserted into its scope is, according to _N2914_.14.10.2 [concept.map] paragraph 2, immediately following its concept-id. This enables a requirement on a member of a concept map to be satisfied by the concept map in which it appears, for example:

           concept C2<typename T>{}

           concept D2<typename T> {
                   typename type;
                   requires C2<type>;
           }

           template<D2 T>
           concept_map C2<T>{}

           concept_map D2<int> {
                   typedef int type; // Okay
           }

   However, these rules might lead to problems with the concept maps that the compiler tries but fails to generate for auto concepts. Presumably a compiler might insert the name of the generated concept map into the containing scope, so that it can satisfy its own requirements, but then if some other requirement cannot be satisfied and thus the concept map is not defined after all (_N2914_.14.10.2 [concept.map] paragraph 11), the name must then be removed again. It might be clearer to make the point of definition for a concept map after the closing brace and just have a special case for how the concept map is handled within its own definition.

2. On a related note, the current specification seems unclear about whether a failure to generate a concept map for an auto concept means that no further attempts will be made to generate it. Consider the following example:

           auto concept A<typename X> { /* */ }
           auto concept B<typename X> : A<X> { void enabler(X); }

           template <A T> void f(T x); // #1
           template <B T> void f(T x); // #2

           class C
           {
              // a class that satisfies A<C> but not B<C>
              // because no enabler(X) in scope
           };

           int foo()
           {
              C x;
              f(x); // #3
           }

           void enabler(C);

           int bar()
           {
              C x;
              f(x); // #4
           }

   At #3, the concept map for `B` cannot be generated, so the call invokes #1. There doesn't appear to be anything currently that indicates that the reference at #4 should not once again attempt to generate the concept map for `B`, which will succeed this time and make the call invoke #2. It seems preferable that both calls should invoke #1, but that does not seem to be the effect of the current wording.

#### 911. `late_check` and concept map templates

Section: _N2914_.14.10.2 [concept.map] Status: concepts Submitter: Daniel Krügler Date: 6 June, 2009

Given a concept and an unconstrained template, e.g.,

        auto concept HasFoo<typename T> {
          void foo(T&);
        }

        template<typename T>
        struct SomeThing {
          void bar(){}
        };

how can one write a concept map template that adapts all specializations of `SomeThing` to concept `HasFoo`? Because a concept map template is a constrained context, referring to `SomeThing` violates the prohibition against using a specialization of an unconstrained template.

Surrounding the entire concept map template with `late_check` would appear not to work; the location of the `late_check` is in the unconstrained context, and `late_check` is ignored in unconstrained contexts.

One possibility would be to allow `late_check` to appear in the `concept_map` syntax.

#### 870. Context of expression when satisfying an associated function requirement

Section: _N2914_.14.10.2.1 [concept.map.fct] Status: concepts Submitter: James Widman Date: 14 April, 2009

_N2914_.14.10.2.1 [concept.map.fct] paragraph 3 says,

> Construct an expression `E` (as defined below) in the scope of the concept map.

This is the wrong context for this expression. Requirement members are visible to name lookup, and they are obviously not a desirable lookup result; names within the concept map should be invisible during the evaluation of `E`. Presumably this should read,

> ...in the scope in which the concept map is defined.

#### 871. Satisfying associated functions with built-in operators

Section: _N2914_.14.10.2.1 [concept.map.fct] Status: concepts Submitter: James Widman Date: 15 April, 2009

_N2914_.14.10.2.1 [concept.map.fct] paragraph 5 says,

> Each satisfied associated function (or function template) requirement has a corresponding associated function candidate set. An associated function candidate set is a candidate set (_N2914_.14.11.3 [temp.constrained.set]) representing the functions or operations used to satisfy the requirement. The seed of the associated function candidate set is determined based on the expression `E` used to determine that the requirement was satisfied.

> - If the evaluation of `E` involves overload resolution at the top level, the seed is the function (12.2.2 [over.match.funcs]) selected by the outermost application of overload resolution (Clause 12 [over]).

> - Otherwise, if `E` is a pseudo destructor call (_N4778_.7.6.1.4 [expr.pseudo]), the seed is a pseudo-destructor-name.

> - Otherwise, the seed is the initialization of an object.

It is not clear that this takes built-in operators into account. For example:

        concept C<class T, class U> {
           typename R;
           R operator+( T, U );
        }

        concept_map C<int, double> {}

#### 916. Does a reference type have a destructor?

Section: _N2914_.14.10.2.1 [concept.map.fct] Status: concepts Submitter: James Widman Date: 12 June, 2009

Is the following well-formed?

        auto concept HasDestructor<typename T> {
          T::~T();
        }

        concept_map HasDestructor<int&> { }

According to _N2914_.14.10.2.1 [concept.map.fct] paragraph 4, the destructor requirement in the concept map results in an expression `x.~X()`, where `X` is the type `int&`. According to _N4778_.7.6.1.4 [expr.pseudo], this expression is ill-formed because the object type and the type-name must be the same type, but the object type cannot be a reference type (references are dropped from types used in expressions, Clause 7 [expr] paragraph 5).

It is not clear whether this should be addressed by changing _N4778_.7.6.1.4 [expr.pseudo] or _N2914_.14.10.2.1 [concept.map.fct].

#### 918. Declaration/expression ambiguity in associated function expressions

Section: _N2914_.14.10.2.1 [concept.map.fct] Status: concepts Submitter: James Widman Date: 19 June, 2009

It is possible that under some circumstances an expression created under the rules of _N2914_.14.10.2.1 [concept.map.fct] might be syntactically ambiguous with declarations, in which case they would be interpreted as declarations and not expressions. It would be helpful to have an explicit statement to the effect that the expressions created by these rules shall always be interpreted as expressions and never as declarations.

#### 907. Default types in requirements in auto concepts

Section: _N2914_.14.10.2.2 [concept.map.assoc] Status: concepts Submitter: James Widman Date: 28 May, 2009

Given the following example:

        auto concept C<typename T, typename U> {
          Returnable U;
          typename type = T&&;
          U::U(type);
        }

_N2914_.14.10.2.2 [concept.map.assoc] paragraph 5 says,

> If an associated type or class template (_N2914_.14.10.1.2 [concept.assoc]) has a default value, a concept map member satisfying the associated type or class template requirement shall be implicitly defined by substituting the concept map arguments into the default value.

It is not clear what the order of processing should be between this step and the formation of the expression in _N2914_.14.10.2.1 [concept.map.fct]. Deduction of the associated type (in _N2914_.14.10.2.2 [concept.map.assoc] paragraph 4) isn't used in this example, but in general requires the expression, but the expression can't be created without the definition of the associated type. Perhaps the approach should be to attempt to define the expression, fail for want of the associated type, apply the default, and then try to define the expression again. Whatever the answer, this needs to be spelled out more clearly.

#### 841. Ill-formed concept refinement example

Section: _N2914_.14.10.3.2 [concept.refine.maps] Status: concepts Submitter: James Widman Date: 20 March, 2009

The example in _N2914_.14.10.3.2 [concept.refine.maps] paragraph 3 reads:

        concept C<typename T> { }
        concept D<typename T, typename U> : C<T> { }
        template<typename T> struct A { };
        template<typename T> concept_map D<A<T>, T> { }
        ...

Since all concept maps templates are constrained templates, we know that we're in a constrained context at the point of the `concept_map` keyword. Then the first argument to `D` is `A<T>`, and `A` is an unconstrained template, so this is ill-formed by _N2914_.14.11 [temp.constrained] paragraph 5:

> Within a constrained context, a program shall not require a template specialization of an unconstrained template for which the template arguments of the specialization depend on a template parameter.

Suggestion: make `A` a constrained template, e.g.,

        template<std::ObjectType T> struct A { };

Additional notes (May, 2009):

There are other examples that exhibit the same problem. For example, _N2960_.14.6.8 [temp.concept.map] paragraph 7 has this example:

        concept Stack<typename X> {
          typename value_type;
          value_type& top(X&);
          // ...
        }

        template<typename T> struct dynarray {
          T& top();
        };

        template<> struct dynarray<bool> {
          bool top();
        };

        template<typename T>
        concept_map Stack<dynarray<T>> {
          typedef T value_type;
          T& top(dynarray<T>& x) { return x.top(); }
        }

`dynarray` needs to be constrained. Similarly, in _N2914_.14.10.2.2 [concept.map.assoc] paragraph 3, in the example

        concept Allocator<typename Alloc> {
          template<class T> class rebind_type;
        }

        template<typename T>
        class my_allocator {
          template<typename U> class rebind_type;
        };

        template<typename T>
        concept_map Allocator<my_allocator<T>> {
          template<class U> using rebind_type = my_allocator<T>::rebind_type;
        }

`my_allocator` must be constrained. (Note also the missing template argument in the target of the template alias declaration.)

#### 825. `TriviallyCopyableType` concept

Section: _N2914_.14.10.4 [concept.support] Status: concepts Submitter: JP Date: 3 March, 2009
N2800 comment JP 20

Trivially copyable type was added in 6.9 [basic.types], so we think that it is necessary to add a concept for trivially copyable type like `TriviallyCopyableType`.

Notes from the March, 2009 meeting:

It is not clear whether this should be supported here or in _N2914_.20.2.9 [concept.copymove], similar to `TriviallyCopyConstructible` and `TriviallyCopyAssignable`.

#### 848. Unconstrained template template parameters in constrained contexts

Section: _N2914_.14.11 [temp.constrained] Status: concepts Submitter: James Widman Date: 31 March, 2009

_N2914_.14.11 [temp.constrained] paragraph 5 says,

> Within a constrained context, a program shall not require a template specialization of an unconstrained template for which the template arguments of the specialization depend on a template parameter.

This would appear to indicate that an example like the following is ill-formed:

        auto concept C<class T> {};

        template<template<class> class T, C U>
        struct Y {
             Y() {
                 T<U> x; // Well-formed?
             }
        };

because `T'` is not a constrained template archetype. However, this is not the intended outcome. The wording needs to be clarified on this point (and an example and a note explaining the rationale would be helpful).

(See also issues 849 and 851.)

#### 826. Accept boolean constant expressions as constraints

Section: _N2914_.14.11.1 [temp.req] Status: concepts Submitter: JP Date: 3 March, 2009
N2800 comment UK 129

It should be possible to support boolean constant expressions as requirements without resorting to defining the `True` concept in the library. Boolean expressions are very likely to be constraints when dealing with non-type template parameters and variadic templates, and constraints in these cases should feel just as natural as constraints on the type system.

#### 827. Use of `&&` as requirement separator

Section: _N2914_.14.11.1 [temp.req] Status: concepts Submitter: US Date: 3 March, 2009
N2800 comment US 60

The use of `&&` as the separator for a list of requirements has shown itself to be a serious teachability problem. The mental model behind `&&` treats concepts as simple predicates, which ignores the role of concepts in type-checking templates. The more programmers read into the `&&` (and especially try to fake `||` with `&&` and `!`), the harder it is for them to understand the role of concept maps. Simply changing the separator to `,` would eliminate a significant source of confusion.

#### 890. Missing requirement in example

Section: _N2914_.14.11.1.1 [temp.req.sat] Status: concepts Submitter: Daniel Krügler Date: 6 May, 2009

The example in _N2914_.14.11.1.1 [temp.req.sat] paragraph 6 reads,

        concept C<typename T> { }
        concept D<typename T> { }
        namespace N2 {
          template<C T> void f(T);                // #1
          template<C T> requires D<T> void f(T);  // #2
          template<C T> void g(T x) {
            f(x);
          }
        ...

The call `f(x)` is ill-formed without a constraint indicating that `x` can be passed by value.

#### 857. Implying requirements from enclosing scopes

Section: _N2914_.14.11.1.2 [temp.req.impl] Status: concepts Submitter: James Widman Date: 5 April, 2009

Consider the following example:

        auto concept A<class T> {
             int f(T);
        }

        auto concept B<class T> {

             int f(T)

             template<class U>
                 requires A<U> // brings f(U') into scope
             auto g(T p, U q) ->
                 decltype(f(p) + f(q));
                 // Both B<T>::f(T) and A<U>::f(U) needed here
                 // but B<T>::f(T) is hidden by A<U>::f(U)
                 // (declared in the same scope as g's template parameters)
        }

This is similar to the case that motivated 11.4 [class.mem] paragraph 19:

> A constrained member is treated as a constrained template (_N2914_.14.11 [temp.constrained]) whose template requirements include the requirements specified in its member-requirement clause and the requirements of each enclosing constrained template.

See also _N2914_.14.10.1.1 [concept.fct] paragraph 10 for a similar rule for default implementations.

A more general version of this merging of requirements is needed, but it does not appear to exist. _N2914_.14.11.1.2 [temp.req.impl] would seem to be the logical place for such a rule.

#### 781. Missing requirement in constrained function example

Section: _N2914_.14.11.2 [temp.archetype] Status: concepts Submitter: Daniel Krügler Date: 1 March, 2009

The example at the end of _N2914_.14.11.2 [temp.archetype] paragraph 13 reads,

        auto concept CopyConstructible<typename T> {
          T::T(const T&);
        }

        template<CopyConstructible T> struct vector;

        auto concept VectorLike<typename X> {
          typename value_type = typename X::value_type;
          X::X();
          void X::push_back(const value_type&);
          value_type& X::front();
        }

        template<CopyConstructible T>
        requires VectorLike<vector<T>>  // vector<T> is an archetype (but not an instantiated archetype)
        void f(const T& value) {
          vector<T> x;                  // OK: default constructor in VectorLike<vector<T> >
          x.push_back(value);           // OK: push_back in VectorLike<vector<T> >
          VectorLike<vector<T>>::value_type& val = x.front();  // OK: front in VectorLike<vector<T> >
        }

However, `x.push_back(value)` is, in fact, ill-formed: there is no relationship between `VectorLike<vector<T>>::value_type` and T in this example. The function needs one further requirement, e.g., `std::SameType<VectorLike<vector<T>>::value_type, T>` to allow use of the function parameter `value` as the argument of the `push_back` call.

#### 748. Always-complete archetypes

Section: _N2914_.14.11.2.1 [temp.archetype.assemble] Status: concepts Submitter: James Widman Date: 28 November, 2008

Suppose we have

        template<std::ObjectType T>
        T* f(T* p) {
             return ++p; // Presumably ok
        }

7.6.2.3 [expr.pre.incr] paragraph 1 requires that “The type of the operand shall be an arithmetic type or a pointer to a completely-defined effective object type.” At `++p` in this example, the type archetype `T'` is considered to be completely-defined because

> A type archetype is considered to be completely defined when it is established

(_N2914_.14.11.2.1 [temp.archetype.assemble] paragraph 1) and 13.9.3 [temp.explicit] paragraph 7 says that an archetype becomes established when

> the archetype is used in a context where a complete type is required

So far, so good. Consider use of `f(T*)` with an incomplete type, for instance:

        struct A; // A is not defined yet.

        A* g(A* p) {
             return f(p);
        }

During template argument deduction against the template `f(T*)`, we find that there is a concept map for `std::ObjectType<A>` because `std::ObjectType` is a compiler-supported concept, and because `A` is an object type (6.9 [basic.types]), so the compiler provides the concept map implicitly. Type deduction succeeds, but then we get an instantiation-time error on `++p` because `A` is incomplete.

I see two potential solutions:

1. We can remove built-in operations for ptr-to-effective-object-type, so that you would have to explicitly require something like `std::HasPreincrement<T*>` before using `++` on values of type `T*` in `f(T*)`. Then `A`'s lack of completeness would be indicated when we try to satisfy those requirements automatically (and not at instantiation time).

2. Alternatively, we can introduce the notion of a compiler-supported concept `std::CompleteType<T>`, and amend _N2914_.14.11.2.1 [temp.archetype.assemble] so that a type archetype is only considered to be completely-defined if it has that requirement. This would imply that `f(T*)` above is ill-formed at `++p` because `T` would then be an incomplete effective object type; the user could fix this by inserting `requires std::CompleteType<T>` after the template-parameter-list, and then the call `f(p)` would be ill-formed because `std::CompleteType<A>` would not be satisfied.

#### 895. Missing destructor requirements

Section: _N2914_.14.11.2.1 [temp.archetype.assemble] Status: concepts Submitter: Daniel Krügler Date: 8 May, 2009

If there is no requirement for a destructor for a type, according to _N2914_.14.11.2.1 [temp.archetype.assemble] paragraph 5 its archetype will have a deleted destructor. As a result, several examples in the current wording are ill-formed:

- _N2914_.14.10.2 [concept.map] paragraph 11: the `add` function.

- _N2914_.14.10.3.1 [concept.member.lookup] paragraph 3: the `f` function. (Also missing the copy constructor requirement.)

- _N2914_.14.10.3.1 [concept.member.lookup] paragraph 5: the `h` function. (Also missing the copy constructor requirement.)

- _N2914_.14.11.1 [temp.req] paragraph 3: the `f` function.

- _N2914_.14.11.1.1 [temp.req.sat] paragraph 6: the `g` function. (Also missing the copy constructor requirement.)

- _N2914_.14.11.2 [temp.archetype] paragraph 15: the `distance` function.

- _N2914_.14.11.2.1 [temp.archetype.assemble] paragraph 2: the `foo` function.

- _N2914_.14.11.2.1 [temp.archetype.assemble] paragraph 3: the `f` function.

- _N2914_.14.11.4 [temp.constrained.inst] paragraph 4: needed for `difference_type`.

One possibility would be to add the destructor requirement directly in these examples. Another might be to use `std::CopyConstructible` instead of a local concept. Yet another would be to consider an implicit requirement for a destructor for `std::Returnable` and `std::VariableType`.

#### 894. Incorrect example for constrained overload resolution

Section: _N2914_.14.11.4 [temp.constrained.inst] Status: concepts Submitter: Daniel Krügler Date: 8 May, 2009

The example in _N2914_.14.11.4 [temp.constrained.inst] paragraph 4 is ill-formed. The call to `advance(i, 1)` in `f` attempts to pass `1` to a parameter declared as `Iter::difference_type`, but there is nothing that says that `int` is compatible with `Iter::difference_type.`

#### 856. Overlapping concept and requirements scopes

Section: _N2960_.3.3.9 [basic.scope.req] Status: concepts Submitter: James Widman Date: 5 April, 2009

According to _N2960_.3.3.9 [basic.scope.req] paragraph 2,

> In a constrained context (_N2914_.14.11 [temp.constrained]), the names of all associated functions inside the concepts named by the concept requirements in the template's requirements are declared in the same scope as the constrained template's template parameters.

This does not appear to cover the case when the requirement appears in a concept definition:

        auto concept B<class T> {
             void f( T );
        }

        auto concept C<class T> {
             typename U = int;
             requires B<U>;  // Is void f(U) placed in the scope of C?

             void g(U x) {
                 f(x);   // Ok, finds the 'f(U)' implicitly declared as a
                         // result of the associated requirement B<U>.
             }
        }

        void f(int);

        void g() {
             C<char>::f(42); // Ok?
        }

This program should be well-formed, but the current wording does not make that clear.

Another question that must be addressed is if `C` also contained an explicit declaration of `f(U)`, either before or after `B<U>`, and whether it would need a satisfier within a concept map to `C`.

(See also issue 866.)

#### 859. Incomplete comment in `late_check` example

Section: _N2960_.6.9 [stmt.late] Status: concepts Submitter: Daniel Krügler Date: 6 April, 2009

_N2960_.6.9 [stmt.late] paragraph 2 consists of the following example:

        concept Semigroup<typename T> {
          T::T(const T&);
          T operator+(T, T);
        }

        concept_map Semigroup<int> {
          int operator+(int x, int y) { return x * y; }
        }

        template<Semigroup T>
        T add(T x, T y) {
          T r = x + y; // uses Semigroup<T>::operator+
          late_check {
            r = x + y; // uses operator+ found at instantiation time (not considering Semigroup<T>::operator+)
          }
          return r;
        }

The second comment is correct but incomplete, because the assignment operator is also found at instantiation time. The assignment would be ill-formed outside the `late_check` block, because the `Semigroup` concept has no copy assignment operator. The comment should be extended accordingly.

#### 724. Qualified name lookup in a constrained context

Section: 6.5.5 [basic.lookup.qual] Status: concepts Submitter: Daniel Krügler Date: 24 September, 2008

According to 6.5.5 [basic.lookup.qual] paragraph 7,

> In a constrained context (_N2914_.14.11 [temp.constrained]), a name prefixed by a nested-name-specifier that nominates a template type parameter `T` is looked up as follows: for each template requirement `C<`args`>` whose template argument list references `T`, the name is looked up as if the nested-name-specifier referenced `C<`args`>` instead of `T` (_N2960_.3.4.3.3 [concept.qual]), except that only the names of associated types are visible during this lookup. If an associated type of at least one requirement is found, then each name found shall refer to the same type. Otherwise, if the reference to the name occurs within a constrained context, the name is looked up within the scope of the archetype associated with `T` (and no special restriction on name visibility is in effect for this lookup).

In an example like,

        concept A<typename T> {
          typename assoc_type;
        }

        concept B<typename T> {
          typename assoc_type;
        }

        template<typename T>
        requires A<T>
        B<T::assoc_type>::assoc_type f();

it is not clear whether the argument `T::assoc_type` of `B` “references” `T` or not.

James Widman: In our mental model (and in our intentions while drafting), we still have a (non-archetype) dependent type for the `T` in your example, and, even after the `SameType` requirement is seen, we also have a distinct dependent type to represent `A<T>::assoc_type` (which itself is distinct from the type of the entity named `assoc_type` that lives in the scope of the concept `A`). And those two dependent types (`A<T>::assoc_type` and `T`) will both alias the same type archetype when that archetype is established (see the paragraph on establishment in _N2914_.14.11.2 [temp.archetype]).

I think 6.5.5 [basic.lookup.qual] paragraph 6 will read more easily if we change the “references a template parameter” verbiage to a generalized “dependent type” verbiage. (We shied away from that in the past because we wanted to say that there's nothing “dependent” within a constrained context. That's because we wanted to say that all name references are bound to something, overload resolution is done, etc. So certainly there are no instances of deferred name lookup or deferred overload resolution within a constrained context. But we still need to be able to say when a type, template, value or concept instance depends on a template parameter.) I propose we change this wording to read,

> In a constrained context (_N2914_.14.11 [temp.constrained]), the identifier of an unqualified-id prefixed by a nested-name-specifier that nominates a dependent type `T` is looked up as follows: for each template requirement `C<`args`>` such that either `T` or an equivalent type (_N2914_.14.11.1 [temp.req]) is a template argument to `C`, the identifier of the unqualified-id is looked up as if the nested-name-specifier nominated `C<`args`>` instead of `T` (_N2960_.3.4.3.3 [concept.qual]), except that only the names of associated types and class templates (_N2914_.14.10.1.2 [concept.assoc]) are visible during this lookup. If an associated type or class template of at least one requirement is found, then the unqualified-id shall refer either to the same type or to an equivalent type when its identifier is looked up in each of the concepts of the other requirements where `T` is a template argument. [Note: no part of the procedure described in the preceding part of this paragraph results in the establishment of an archetype (_N2914_.14.11.2 [temp.archetype]). However, in the event that the unqualified-id is a template-id, one of its template arguments could contain some construct that would force archetype establishment. —end note] Otherwise, the name is looked up within the scope of the archetype aliased by `T` (and no special restriction on name visibility is in effect for this lookup). [Note: this establishes the archetype of `T` (if it was not established already). —end note]

(It looks like we have a wording nit to fix in the archetype establishment paragraph: it talks about a type archetype coming into existence “when it is used [in some way].” It seems odd to say that something is used in a particular way before it exists. We should instead say something like “when a necessarily-dependent type that would alias the archetype is used [in some way].”)

(It might also be nice to have a cleanup in the paragraph that introduces the notion of `std::SameType` and “equivalent types” (_N2914_.14.11.1 [temp.req] paragraph 3) so that the congruence relation is part of the normative text rather than a note.)

#### 791. Linkage of concept names

Section: 6.7 [basic.link] Status: concepts Submitter: FR/UK Date: 3 March, 2009
N2800 comment FR 17
N2800 comment UK 30
N2800 comment UK 119

6.7 [basic.link] does not specify whether concept names have linkage or not.

#### 917. Pointer conversions between archetypes

Section: 7.3.12 [conv.ptr] Status: concepts Submitter: James Widman Date: 12 June, 2009

Given an example like:

        auto concept Conv<typename T, typename U> {
          U::U(T&&);
          U::U(const U&);
          U::~U();
        };

        template<typename U, typename T>
        requires Conv<T*, U*>
        U* f(T* p) {
          return static_cast<T*&&>(p);
        }

There is currently no normative wording that makes a `T*` convertible to a `U*` in the return statement.

One possible approach would be to take the concept map archetype as specifying an additional case for the pointer conversions in 7.3.12 [conv.ptr].

#### 802. Problems with restrictions on taking the address of a member of a concept map

Section: 7.6.2.2 [expr.unary.op] Status: concepts Submitter: UK Date: 3 March, 2009
N2800 comment UK 69

If we cannot bind references/take address of functions in concept_maps, does that mean we cannot use generic bind in constrained templates? Launch threads with expressions found via concept map lookup? Hit problems creating std::function objects? Does the problem only occur if we use qualified lookup to explicitly name a concept map? Does it only kick in if we rely on the implicit function implementation provided by a concept_map, so some types will work and others won't for the same algorithm?!

Additional note, June, 2009:

Here is an example illustrating the question:

        auto concept Fooable<T> {
           void foo(T);
        }

        struct test_type {
           void foo() {
              cout << "foo test_type\n";
           }
        };

        concept_map Fooable<test_type> {
           void foo(test_type& t) {
              t.foo();
           }
        }

        void foo(int x) {
           cout "foo int\n";
        }

        template<typename T>
           requires Fooable<T>
        function<void(T)> callback(T t) {
           void(*fn)(T) = foo;
           return fn;
        }

        int main() {
           auto fn1 = factory(test_type{});
           auto fn2 = factory(0);
           fn1(test_type{});
           fn2(0);
           return 0;
        }

#### 866. Concept maps and the range-based `for`

Section: 8.6.5 [stmt.ranged] Status: concepts Submitter: James Widman Date: 8 April, 2009

The expansion of the range-based `for` statement is given in 8.6.5 [stmt.ranged] paragraph 1 as:

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

In a non-templated context, the concept map to `std::Range` has been dropped, so the operators and initialization will be whatever they would normally be; if the concept map replaced those with some customized version (e.g., if the iterator's `++` were supposed to skip odd-numbered elements), that customized meaning would be lost.

What we really want are the operators associated with the concept map to `std::Iterator` that was used to satisfy the associated requirement (`std::Iterator<iterator>`) within `std::Range<_RangeT>` (in whatever concept map was used to satisfy `std::Range<_RangeT>`). That is, if the grammar permitted it, we want something like

        std::Range<_RangeT>::concept_map
          ::std::Iterator<std::Range<_RangeT>::iterator>::operator++(_begin)

Another alternative would be, if issue 856 is resolved by injecting the declaration of associated functions into concept definitions, something like

        std::Range<_RangeT>::operator++(__begin)

#### 723. Archetypes in skipped declarations

Section: 8.10 [stmt.dcl] Status: concepts Submitter: Doug Gregor Date: 3 October, 2008

Paper N2762 changed 8.10 [stmt.dcl] paragraph 3 from

> ...unless the variable has trivial type (6.9 [basic.types])...

to

> ...unless the variable has scalar type, class type with a trivial default constructor and a trivial destructor, a cv-qualified version of one of these types, or an array of one of the preceding types...

However, this change overrode the colliding change from N2773 that would have changed it to read

> ...unless the variable has effective trivial type...

The revised wording needs to be changed to allow for archetypes with the appropriate requirements.

#### 725. When should the requirement for `std::Returnable<T>`, etc., apply?

Section: 9.3.4.6 [dcl.fct] Status: concepts Submitter: Alberto Ganesh Barbati Date: 30 September, 2008

If we write

        concept C<class T> {}

        template<C T>
        struct B {
             B f();
             virtual void g() = 0;
        };

... it seems reasonable to expect a diagnostic about `B<T>::f()` not because it doesn't require `std::Returnable<B<T>>` (which I think should not draw an error), but because `g()` is a pure virtual function.

Now how about this:

        template<C T>
        struct G {
             B<T> f() { return B<T>(); }
        };

Here, I'd like to see an error not because we lack the requirement `std::Returnable<B<T>>`, but because, when we instantiate `B<T'>` (as the current wording indicates we must within the definition of `G<T>::f()`), it turns out to be an abstract class.

Now, it could be that when we instantiate `G`, we get a different partial specialization of `B`, and that partial specialization could have a pure virtual member. So you might see an instantiation-time error. But partial specializations present dangers like this anyway.

I suggest we make the rule about `Returnable<T>` apply only in the case where `T` is not an instantiated archetype. The rationale is that with an instantiated archetype, it's possible to see at template definition time whether the type is abstract, whereas with a non-instantiated archetype, the only known attributes come from requirements.

I suspect we need similar changes for the declarator section. E.g., for a class template `A`, we shouldn't need to explicitly require `VariableType<A<T>>` if we want to declare a variable of type `A<T>`. Instead, we just instantiate `A<T'>` (as would be naturally required at the point of definition of a variable of type `A<T'>`), and issue errors when appropriate like we do with ordinary classes today.

#### 844. Is a constrained member function a template?

Section: 11.4 [class.mem] Status: concepts Submitter: Daniel Krügler Date: 20 March, 2009

According to 11.4 [class.mem] paragraph 19,

> A non-template member-declaration that has a member-requirement (_N2914_.14.11.1 [temp.req]) is a constrained member and shall occur only in a class template (13.7.2 [temp.class]) or nested class thereof. The member-declaration for a constrained member shall declare a member function. A constrained member is treated as a constrained template (_N2914_.14.11 [temp.constrained]) whose template requirements include the requirements specified in its member-requirement clause and the requirements of each enclosing constrained template.

Furthermore, 13.7.3 [temp.mem] paragraph 9 says,

> A member template of a constrained class template is itself a constrained template (_N2914_.14.11 [temp.constrained])...

and illustrates this statement with the following example:

        concept C<typename T> { void f(const T&); }
        concept D<typename T> { void g(const T&); }

        template<C T> class A {
          requires D<T> void h(const T& x) {
            f(x); // OK: C<T>::f
            g(x); // OK: D<T>::g
          }
        };

If these passages are taken at face value and a constrained member function is, in fact, “treated as a... template,” there are negative consequences. For example, according to 11.4.5.3 [class.copy.ctor] paragraph 2, a member function template is never considered to be a copy constructor, so a constrained constructor that is in the form of a copy constructor does not suppress the implicit declaration and definition of a default copy constructor. Also, according to 13.7.3 [temp.mem] paragraph 3, a member function template cannot be virtual, so it is not possible to specify a member-requirement clause for a virtual function.

Presumably these consequences are unintended, so the wording that suggests otherwise should be revised to make that clear.

#### 875. Associated conversion functions converting to the same type

Section: 11.4.8.3 [class.conv.fct] Status: concepts Submitter: Daniel Krügler Date: 19 April, 2009

11.4.8.3 [class.conv.fct] paragraph 1 says,

> A conversion function is never used to convert a (possibly cv-qualified) object to the (possibly cv-qualified) same object type (or a reference to it), to a (possibly cv-qualified) base class of that type (or a reference to it), or to (possibly cv-qualified) void.

Does this mean that the following example is ill-formed?

        auto concept Convertible<typename T, typename U> {
          operator U(const T&);
        }

        template <typename T, typename U>
        requires Convertible<T, U>
        U convert(const T& t) { return t; }

        int main() {
          convert<int>(42);
        }

#### 878. Effective class types in built-in pointer-to-member operator

Section: 12.5 [over.built] Status: concepts Submitter: Daniel Krügler Date: 25 April, 2009

12.5 [over.built] paragraph 11 says,

> For every quintuple (C1, C2, T, CV1, CV2), where C2 is a class type, C1 is the same type as C2 or is a derived class of C2, T is an effective object type or a function type, and CV1 and CV2 are cv-qualifier-seqs, there exist candidate operator functions of the form

> `CV12 T& operator->*(CV1 C1*, CV2 T C2::*);`

> where CV12 is the union of CV1 and CV2.

C1 and C2 should be effective class types (cf 7.6.4 [expr.mptr.oper] paragraph 3.

Also, should the relationship between those two classes be expressed as `std::SameType` or `std::DerivedFrom` requirements?

#### 821. Exported concept map templates?

Section: Clause 13 [temp] Status: concepts Submitter: UK Date: 3 March, 2009
N2800 comment UK 116

Is it possible to export a concept map template? The current wording suggests it is possible, but it is not entirely clear what it would mean.

Notes from the March, 2009 meeting:

Export is only useful for non-inline function templates and static data members of class templates, so it does not make sense to export a concept map template.

#### 881. Inconsistent requirement for naming template parameters

Section: 13.2 [temp.param] Status: concepts Submitter: Daniel Krügler Date: 25 April, 2009

The grammar for constrained-template-parameter given in 13.2 [temp.param] paragraph 1 is:

constrained-template-parameter:

`::`opt nested-name-specifieropt concept-name `...`opt identifieropt
`::`opt nested-name-specifieropt concept-name identifieropt constrained-default-argumentopt
`::`opt nested-name-specifieropt concept-name `<`

simple-requirement-argument-list `> ...`opt identifier

`::`opt nested-name-specifieropt concept-name `<`

simple-requirement-argument-list `>` identifier constrained-default-argumentopt

The identifier naming the parameter is optional in the first two productions but not in the latter two productions. Is there a reason for this discrepancy?

#### 867. Naming a specialization of a constrained template

Section: 13.3 [temp.names] Status: concepts Submitter: James Widman Date: 13 April, 2009

There is currently no way to distinguish between templates that differ only by their requirements when naming a specialization. For example:

        auto concept A<class T> {}
        auto concept B<class T> {}

        template<class T> requires A<T> void f(T); // #1
        template<class T> requires B<T> void f(T); // #2

        template <> void f(int);  // Which one?

(See also issue 868.)

#### 868. Specifying a concept map in the name of a specialization

Section: 13.3 [temp.names] Status: concepts Submitter: James Widman Date: 13 April, 2009

There is no way to specify a concept map in the name of a specialization. It would be useful to be able to do something like

        void g(int n) {
            f<int : N::concept_map A<int>>(n);
        }

(See also issue 867.)

#### 849. Constraints and template template parameters

Section: 13.4.4 [temp.arg.template] Status: concepts Submitter: James Widman Date: 31 March, 2009

The requirements for matching of template template parameters and template template arguments given in 13.4.4 [temp.arg.template] do not mention constraints, leaving questions about whether examples like the following are well-formed:

        auto concept C<class T> {};

        template <template <C T> class U, C V> struct A{};

        template <class T> struct X {};

        A<X,int> ax;  // Well-formed?

        template <template <class T> class U, C V> struct B{};

        template <C T> struct Y {};

        B<Y,int> by;  // Well-formed?

        template <template <class T> class U> struct D{};

        template <C T> struct Z {};

        D<Z> dz;  // Well-formed?

(See also issue 848.)

#### 824. Constrained special member functions

Section: 13.7.2 [temp.class] Status: concepts Submitter: US Date: 3 March, 2009
N2800 comment US 53

If the requirements of a constrained special member function are not satisfied, the result is that the member function is not declared (13.7.2 [temp.class] paragraph 5). This allows the special member function to be implicitly declared and defined, which will likely result in an ill-formed program or one with the wrong semantics.

#### 843. Unclear interaction of constraints and special member functions

Section: 13.7.2 [temp.class] Status: concepts Submitter: Alisdair Meredith Date: 19 March, 2009

Although the current wording does specify the outcome, it is not immediately apparent what the result of an example like the following should be:

        template<std::ObjectType T>
        struct S {
            requires std::CopyConstructible<T>
            S(const S&) = default;
        };

The outcome (that `S` will have an implicitly-declared copy constructor that is defined as deleted in specializations in which `T` is not copy-constructible) would be clearer with the addition of two notes. First, it would be helpful if 13.7.2 [temp.class] paragraph 5, which currently reads,

> A constrained member (11.4 [class.mem]) in a class template is declared only in class template specializations in which its template requirements (_N2914_.14.11.1 [temp.req]) are satisfied (_N2914_.14.11.1.1 [temp.req.sat])...

had a note or footnote to the effect,

> When a constrained member of a template is a special member function, and when, in an instantiation, the member is not declared because its requirements are not satisfied, the special member is considered not to have been “explicitly declared” (i.e., the member is not user-declared); therefore a declaration may still be implicitly generated as specified in 11.4.4 [special].

The fact that the implicitly-declared copy constructor in this case is defined as deleted would be clearer if somewhere in the second list in 11.4.5.3 [class.copy.ctor] paragraph 5, which currently reads

> ...An implicitly-declared copy constructor for a class `X` is defined as deleted if `X` has:

> - a variant member with a non-trivial copy constructor and `X` is a union-like class,

> - a non-static data member of class type `M` (or array thereof) that cannot be copied because overload resolution (12.2 [over.match]), as applied to `M`'s copy constructor, results in an ambiguity or a function that is deleted or inaccessible from the implicitly-declared copy constructor, or

> - a direct or virtual base class `B` that cannot be copied because overload resolution (12.2 [over.match]), as applied to `B`'s copy constructor, results in an ambiguity or a function that is deleted or inaccessible from the implicitly-declared copy constructor.

there were a cross-reference to _N2914_.14.11.2.1 [temp.archetype.assemble], whose third paragraph reads,

> If no requirement specifies a copy constructor for a type `T`, a copy constructor is implicitly declared (11.4.5.3 [class.copy.ctor]) in the archetype of `T` with the following signature:

>         T(const T&) = delete;

#### 851. Constraints and template aliases

Section: 13.7.8 [temp.alias] Status: concepts Submitter: James Widman Date: 1 April, 2009

The relationship of requirements with template aliases is not clear in the current wording. For example, something like

        auto concept C{};

        template <class T> struct A{};

        template <C T>  using B = A<T>;

is presumably allowed by the current wording of 13.7.8 [temp.alias] but, unless a good use case is presented, should probably be prohibited.

On the other hand, _N2914_.14.11 [temp.constrained] paragraph 5,

> Within a constrained context, a program shall not require a template specialization of an unconstrained template for which the template arguments of the specialization depend on a template parameter.

might be considered to forbid an example like

        template <C T> struct X {};

        template <class T> using Y = X<T>;

        template <std::VariableType T>
        void f(Y<T>); // Error?

although it should probably be allowed. (Note, however, that 13.7.8 [temp.alias] paragraph 2,

> When a template-id refers to the specialization of a template alias, it is equivalent to the associated type obtained by substitution of its template-arguments for the template-parameters in the type-id of the template alias.

could be viewed as allowing this example, depending on how the word “equivalent” is understood.)

The text should be amended to clarify the resolution of these questions. (See also issue 848.)

### Issues with "Extension" Status

#### 2097. Lambdas and `noreturn` attribute

Section: 7.5.6 [expr.prim.lambda] Status: extension Submitter: Jonathan Caves Date: 2015-03-12

The current grammar does not allow indicating that a lambda is `noreturn`, because currently attributes in a lambda-expression appertain to the type of the conversion function/template, per 7.5.6 [expr.prim.lambda] paragraph 5.

Additional note (February, 2022):

This issue was addressed by the adoption of paper P2173R1 at the February, 2022 plenary.

#### 2500. `noexcept(false)` functions and `noexcept` expressions

Section: 7.6.1.9 [expr.static.cast] Status: extension Submitter: CWG Date: 2021-08-09

Part of issue 2486 raised the question of whether `static_cast` should be permitted to cast a `noexcept(false)` function type to a `noexcept` function type. Presumably that would also involve changing 7.6.1.3 [expr.call] paragraph 6 to allow a call through the converted value, with undefined behavior resulting only if the called function actually exits via an exception.

CWG felt these questions should be addressed by EWG, so they were spun off into a separate issue.

#### 2449. Thunks as an implementation technique for pointers to virtual functions

Section: 7.6.2.2 [expr.unary.op] Status: extension Submitter: John McCall Date: 2020-06-03

Although there are implementations that use thunks for pointers to virtual member functions, it appears that such a technique is not permitted by the Standard. Concerns particularly include the requirements for complete types for parameter and return types at the point at which the member function pointer is formed.

#### 2320. `constexpr if` and boolean conversions

Section: 8.5.2 [stmt.if] Status: extension Submitter: Richard Smith Date: 2016-09-06

Consider:

      template<void *P> void f() {
        if constexpr (P) {}  // #1
      }

This is ill-formed at #1, because an expression of type `void*` cannot be converted to `bool` as a contextually converted constant expression.

#### 1914. Duplicate standard attributes

Section: 9.13 [dcl.attr] Status: extension Submitter: Aaron Ballman Date: 2014-04-15

[This suggestion was adopted as paper P2156R1 at the June, 2021 plenary.]

The standard attributes `noreturn`, `carries_dependency`, and `deprecated` all specify that they cannot appear more than once in an attribute-list, but there is no such prohibition if they appear in separate attribute-specifiers within a single attribute-specifier-seq. Since intuitively these cases are equivalent, they should be treated the same, accepting duplicates in both or neither.

Rationale (June, 2014):

EWG should determine the desired outcome for this question.

#### 2261. Explicit instantiation of in-class `friend` definition

Section: 13.7.5 [temp.friend] Status: extension Submitter: Jens Maurer Date: 2016-04-28

The status of an example like the following is unclear:

      struct S {
       template <class T> friend void f(T) { }
      };
      template void f(int);  // Well-formed?

A friend is not found by ordinary name lookup until it is explicitly declared in the containing namespace, but declaration matching does not use ordinary name lookup. There is implementation divergence on the handling of this example.

Notes from the March, 2018 meeting:

CWG did not come to consensus on the desired outcome and feels that the question should be addressed by EWG.