Document number:  PL22.16/10-0105 = WG21 N3115
Date:  2010-08-23
Project:  Programming Language C++
Reference:  ISO/IEC IS 14882:2003
Reply to:  William M. Miller
 Edison Design Group, Inc.
 wmm@edg.com


C++ Standard Core Language Active Issues, Revision 72


This document contains the C++ core language issues on which the Committee (J16 + WG21) has not yet acted, that is, issues with status "Ready," "Tentatively Ready," "Review," "Drafting," and "Open."

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:

Section references in this document reflect the section numbering of document PL22.16/10-0082 = WG21 N3092.

The purpose of these documents is to record the disposition of issues that have come before the Core Language Working Group of the ANSI (INCITS PL22.16) and ISO (WG21) C++ Standard Committee.

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

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

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


Revision History

Issue status

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

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

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

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

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

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

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

TC1: A DR issue included in Technical Corrigendum 1. TC1 is a revision of the Standard issued in 2003.

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

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

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

Dup: The issue is identical to or a subset of another issue, identified in a Rationale statement.

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

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

Concepts: The issue relates to the “Concepts” proposal that was removed from the working paper at the Frankfurt (July, 2009) meeting and hence is no longer under consideration.

Issues with "Ready" Status

1173. Unclear specification of effects of signal handling

Section: 1.9  [intro.execution]     Status: ready     Submitter: GB     Date: 2010-08-06

N3092 comment GB 7

The current wording of 1.9 [intro.execution] paragraph 6 could be read as saying that any signal would leave the program in an unspecified state after completing.

Proposed resolution (August, 2010):

Change 1.9 [intro.execution] paragraph 6 as follows:

When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects which are neither

are unspecified during the execution of the signal handler, and the value of any object not in either of these two categories that is modified by the handler becomes undefined.



1103. Reversion of phase 1 and 2 transformations in raw string literals

Section: 2.2  [lex.phases]     Status: ready     Submitter: US     Date: 2010-08-02

N3092 comment US 13
 N3092 comment US 14

“Raw” strings are still only Pittsburgh-rare strings: the reversion in phase 3 only applies to an r-char-sequence. It should apply to the entire raw string literal.

Proposed resolution (August, 2010):

  1. Change 2.2 [lex.phases] paragraph 1 phase 1 as follows:

    2. ...(An implementation may use any internal encoding, so long as an actual extended character encountered in the source file, and the same extended character expressed in the source file as a universal-character-name (i.e., using the \uXXXX notation), are handled equivalently except where this replacement is reverted in a raw string literal.).)

  2. Change 2.2 [lex.phases] paragraph 1 phase 3 as follows:

    3. ...[Example: see the handling of < within a #include preprocessing directive. —end example] Within the r-char-sequence of a raw string literal, any transformations performed in phases 1 and 2 (trigraphs, universal-character-names, and line splicing) are reverted.

  3. Change 2.2 [lex.phases] paragraph 1 phase 5 as follows:

    4. Each source character set member and universal-character-name in a character literal or a string literal, as well as each escape sequence and universal-character-name in a character literal or a non-raw string literal, is converted to the corresponding member of the execution character set (2.14.3 [lex.ccon], 2.14.5 [lex.string]); if there is no corresponding member, it is converted to an implementation-defined member other than the null (wide) character.

  4. Change 2.3 [lex.charset] paragraph 2 as follows:

    5. ...Additionally, if the hexadecimal value for a universal-character-name outside the c-char-sequence, s-char-sequence, or r-char-sequence of a character or string literal corresponds to a control character (in either of the ranges 0x000x1F or 0x7F0x9F, both inclusive) or to a character in the basic source character set, the program is ill-formed. [Footnote: A sequence of characters resembling a universal-character-name in an r-char-sequence (2.14.5 [lex.string]) does not form a universal-character-name. —end footnote]

  5. Change 2.5 [lex.pptoken] paragraph 3 as follows:

    6. If the input stream has been parsed into preprocessing tokens up to a given character:

  6. Delete footnote 24 in 2.14.5 [lex.string] paragraph 2:

    7. Use of characters with trigraph equivalents in a d-char-sequence may produce unintended results.

  7. Insert the following examples after 2.14.5 [lex.string] paragraph 4:

    8. [Example: The raw string

      R"a(
  )\
  a"
  )a"

    is equivalent to "\n)\\\na\"\n". The raw string

      R"(??)"

    is equivalent to "\?\?". The raw string

      R"#(
  )??="
  )#"

    is equivalent to "\n)\?\?=\"\n". —end example]



1104. Global-scope template arguments vs the <: digraph

Section: 2.6  [lex.digraph]     Status: ready     Submitter: US     Date: 2010-08-02

N3092 comment US 15

Passing a name qualified by the global scope operator :: as a template argument can inadvertently trigger recognition of the <: digraph, causing a syntax error. This should be handled by a lexical rule similar to the special treament given to >> so that <:: would be recognized as an open angle-bracket followed by the scope-resolution operator.

Proposed resolution (August, 2010):

Insert a bullet into the list in 2.5 [lex.pptoken] paragraph 3 as follows:

If the input stream has been parsed into preprocessing tokens up to a given character:


1107. Overload resolution for user-defined integer literals

Section: 2.14.8  [lex.ext]     Status: ready     Submitter: US     Date: 2010-08-02

N3092 comment US 17

In general, the parameter type of a literal operator must be the same as the argument passed to it. That is not the case for a user-defined-character-literal, where the argument could inadvertently match a literal operator intended for use with user-defined-integer-literals:

    typedef unsigned long long ULL;
    int operator "" X(ULL);
    int i = 'c'X; // operator"" X(ULL('c'))

Suggested resolution: Add the following phrase to the description in paragraph 6:

S shall contain a literal operator whose parameter type is the same as the type of ch.

Proposed resolution (August, 2010):

Change 2.14.8 [lex.ext] paragraph 6 as follows:

If L is a user-defined-character-literal, let ch be the literal without its ud-suffix. The S shall contain a literal operator (13.5.8 [over.literal]) whose only parameter has the type of ch and the literal L is treated as a call of the form 
    operator "" X (ch )


1112. constexpr variables should have internal linkage like const

Section: 3.5  [basic.link]     Status: ready     Submitter: US     Date: 2010-08-02

N3092 comment US 24

One of the critieria for giving a name internal linkage is “a variable that is explicitly declared const and neither explicitly declared extern nor previously declared to have external linkage.” This should presumably apply to variables declared constexpr as well.

Proposed resolution (August, 2010):

Change 3.5 [basic.link] paragraph 3 bullet 2 as follows:



1113. Linkage of namespace member of unnamed namespace

Section: 3.5  [basic.link]     Status: ready     Submitter: DE     Date: 2010-08-02

N3092 comment DE 4

It is odd that, in the following example, N has no linkage but g has external linkage:

    namespace {
      namespace N // has no linkage
      {
        void g(); // has external linkage
      }
    }

Proposed resolution (August, 2010):

Change 3.5 [basic.link] paragraph 4 as follows:

An unnamed namespace or a namespace declared directly or indirectly within an unnamed namespace has internal linkage. All other namespaces have external linkage. A name having namespace scope that has not been given internal linkage above has external linkage the same linkage as the enclosing namespace if it is the name of


1027. Type consistency and reallocation of scalar types

Section: 3.8  [basic.life]     Status: ready     Submitter: Gabriel Dos Reis     Date: 2010-02-03

Is the following well-formed?

    int f() {
        int i = 3;
        new (&i) float(1.2);
        return i;
    }

The wording that is intended to prevent such shenanigans, 3.8 [basic.life] paragraphs 7-9, doesn't quite apply here. In particular, paragraph 7 reads,

If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if:

The problem here is that this wording only applies “after the lifetime of an object has ended and before the storage which the object occupied is reused;” for an object of a scalar type, its lifetime only ends when the storage is reused or released (paragraph 1), so it appears that these restrictions cannot apply to such objects.

Proposed resolution (August, 2010):

This issue is resolved by the resolution of issue 1116.



1114. Incorrect use of placement new in example

Section: 3.8  [basic.life]     Status: ready     Submitter: GB     Date: 2010-08-02

N3092 comment GB 18

The example in 3.8 [basic.life] paragraph 9 reads,

    struct B {
      B();
      ~B();
    };

    const B b;

    void h() {
      b.~B();
      new (&b) const B;  // undefined behavior
    }

Assuming that the placement new is intended to use the operator defined in the Standard library, the new-expression is ill-formed, because there is no implicit conversion from “pointer to const B” to void*.

Proposed resolution (August, 2010):

Change the example in 3.8 [basic.life] paragraph 9 as follows:

    ...
    new (const_cast<B *>(&b)) const B;  // undefined behavior
    ...


1062. Syntax of attribute-specifiers in lambdas

Section: 5.1.2  [expr.prim.lambda]     Status: ready     Submitter: Peter Sommerlad     Date: 2010-03-23

N3092 comment CH 4

The adoption of paper N3067 at the March, 2010 meeting moved the position of the optional attribute-specifier in a function declarator from immediately following the parameter-declaration-clause to after the exception-specification. However, the grammar in 5.1.2 [expr.prim.lambda] paragraph 1 and the verbal description in paragraph 5 still have the attribute-specifier in a lambda-declarator at its old position. These should be updated to reflect the new function declarator syntax.

Proposed resolution (August, 2010):

  1. Change the grammar in 5.1.2 [expr.prim.lambda] paragraph 1 as follows:

  2. Change 5.1.2 [expr.prim.lambda] paragraph 5 as follows:

    3. ...Any attribute-specifiers appearing immediately after the lambda-expression's parameter-declaration-clause appertain An attribute-specifier in a lambda-declarator appertains to the type of the corresponding function call operator...


1121. Unnecessary ambiguity error in formation of pointer to member

Section: 5.3.1  [expr.unary.op]     Status: ready     Submitter: US     Date: 2010-08-02

N3092 comment US 33

The resolution of issue 983 restored an error, inadvertently removed by the resolution of issue 39, for the formation of a member of an ambiguous base class. For example:

    struct B { int i; };
    struct I1: B { };
    struct I2: B { };
    struct D: I1, I2 { };
    int B::* pm = &D::i;    // Originally and again ambiguous

This error is not necessary, because the result of taking the address of a member of an ambiguous base class is a pointer to a member of that class; an actual ambiguity would occur only if that pointer to a base class member is converted to a pointer to a member of the derived class. (See issue 203, which suggests changing the result of taking the address of a member to reflect the naming class of the member instead of the class of which it is directly a member; if that change were made, the ambiguity error would be needed.)

The resolution of issue 983 should be reverted.

Proposed resolution (August, 2010):

  1. Change 5.3.1 [expr.unary.op] paragraph 3 as follows:

    2. ...If the operand is a qualified-id naming a non-static member m of some class C with type T, the result has type “pointer to member of class C of type T and is a prvalue designating C::m; the program is ill formed if C is an ambiguous base (10.2) of the class designated by the nested-name-specifier of the qualified-id. Otherwise...

  2. Change 10.2 [class.member.lookup] paragraph 13 as follows:

    3. [Note: Even if the result of name lookup is unambiguous, use of a name found in multiple subobjects might still be ambiguous (4.11 [conv.mem], 5.2.5 [expr.ref], 5.3.1 [expr.unary.op], 11.2 [class.access.base]). —end note]...


1125. Unclear definition of “potential constant expression”

Section: 5.19  [expr.const]     Status: ready     Submitter: DE     Date: 2010-08-02

N3092 comment DE 8

In the definition of “potential constant expression” in 5.19 [expr.const] paragraph 6, it is unclear how “arbitrary” the substitution of the function parameters is. Does it mean “there exists a value for which the result is a constant expression” or does it mean “for all possible values, the result needs to be a constant expression?” Example:

    constexpr int f(int x){ return x + 1; }

is a constant expression under the first interpretation, but not under the second (because overflow occurs for x == INT_MAX, cf 5.19 [expr.const] paragraph 2 bullet 5). The answer also affects expressions such as:

    constexpr int f2(bool v) { return v ? throw 0 : 0; }
    constexpr int f3(bool v) { return v && (throw 0, 0); }

See also issue 1129.

Proposed resolution (August, 2010):

  1. Change 3.6.2 [basic.start.init] paragraph 2 as follows:

    2. ...Constant initialization is performed:

  2. Change 5.19 [expr.const] paragraph 2 as follows:

  3. Delete 5.19 [expr.const] paragraph 6:

    4. An expression is a potential constant expression if it is a constant expression when all occurrences of function parameters are replaced as follows:

  4. Change 7.1.5 [dcl.constexpr] paragraph 3 bullet 3 as follows:

  5. Change 7.1.5 [dcl.constexpr] paragraph 4 as follows:

    6. The definition of a constexpr constructor shall satisfy the following constraints:

    A trivial copy/move constructor is also a constexpr constexpr constructor.

  6. Add the following as a new paragraph after 7.1.5 [dcl.constexpr] paragraph 4:

    7. Function invocation substitution for a call of a constexpr function or of a constexpr constructor means to convert implicitly each argument expression to the corresponding parameter type, to substitute that converted expression for each use of the corresponding parameter in the function-body, and, for constexpr functions, to convert implicitly the resulting expression to the return type of the function. Such substitution does not change the meaning. [Example:

      constexpr int f(void *) { return 0; }
  constexpr int f(...) { return 1; }
  constexpr int g1() { return f(0); }         // calls f(void *)
  constexpr int g2(int n) { return f(n); }    // calls f(...) even for n == 0
  constexpr int g3(int n) { return f(n*0); }  // calls f(...)

  namespace N {
    constexpr int c = 5;
    constexpr int h() { return c; }
  }
  constexpr int c = 0;
  constexpr int g4() { return N::h(); }  // value is 5, c is not looked up again after the substitution

    —end example] For a constexpr function, if no function argument values exist such that the function invocation substitution would produce a constant expression (5.19 [expr.const]), the program is ill-formed; no diagnostic required. For a constexpr constructor, if no argument values exist such that after recursive function invocation substitution for all contained function and constructor calls, every expression or full-expression used for subobject and reference member initialization would be a constant expression (including conversions), the program is ill-formed; no diagnostic required. [Example:

      constexpr int f(bool b) { return b ? throw 0 : 0; }   // OK
  constexpr int f() { throw 0; }         // ill-formed, no diagnostic required

  struct B {
    constexpr B(int x) : i(0) { }    // x is unused
    int i;
  };

  int global;

  struct D : B {
    constexpr D() : B(global) { }   // OK
  };

    —end example]

  7. Change 7.1.5 [dcl.constexpr] paragraph 8 as follows:

    8. A constexpr specifier used in an object declaration declares the object as const. Such an object shall have literal type and shall be initialized. If it is initialized by a constructor call, the constructor shall be a constexpr constructor and every argument to the constructor shall be a constant expression after recursive function invocation substitution for all contained function and constructor calls, every expression or full-expression used for subobject initialization shall be a constant expression. Otherwise, every full-expression that appears...

This resolution also resolves issue 1127.



1126. constexpr functions in const initializers

Section: 5.19  [expr.const]     Status: ready     Submitter: GB     Date: 2010-08-02

N3092 comment GB 25

It does not appear to be clearly enough stated that the example

    constexpr int f() { return 42 + 84; }
    const int sz = f();
    int a[sz];

is equivalent to

    const int sz = 42 + 84;
    int a[sz];

Proposed resolution (August, 2010):

Change 5.19 [expr.const] paragraph 1 as follows:

Certain contexts require expressions that satisfy additional requirements as detailed in this sub-clause; other contexts have different semantics depending on whether or not an expression satisfies these requirements. Such expressions Expressions that satisfy these requirements are called constant expressions. [Note: Those Constant expressions can be evaluated during translation. —end note]


1127. Overload resolution in constexpr functions

Section: 5.19  [expr.const]     Status: ready     Submitter: GB     Date: 2010-08-02

N3092 comment GB 26

It is not clear how overload resolution is performed inside the body of a constexpr function. In particular, if the function is invoked with parameters such that an expression evaluates to an integral 0, does that make the expression eligible for the null pointer conversion and thus potentially select a different overloaded function than in invocations in which the expression has a non-zero value? (Suggested answer: no.)

Proposed resolution (August, 2010):

This issue is resolved by the resolution of issue 1125.



1128. attribute-specifiers in decl-specifier-seqs

Section: 7.1  [dcl.spec]     Status: ready     Submitter: US     Date: 2010-08-02

N3092 comment US 39

The current wording of 7.1 [dcl.spec] paragraph 1 says,

The optional attribute-specifier in a decl-specifier-seq appertains to the type determined by the decl-specifier-seq (8.3 [dcl.meaning]).

However, decl-specifier-seq is a recursive production. The intent is that the attribute-specifier appertains to the type determined by the top-level decl-specifier-seq, but this makes it sound as if it appertains to the one that directly contains the attribute-specifier.

Proposed resolution (August, 2010):

Change 7.1 [dcl.spec] paragraph 1 as follows:

The optional attribute-specifier in a decl-specifier-seq appertains to the type determined by the decl-specifier-seq preceding decl-specifiers (8.3 [dcl.meaning]).


1129. Default nothrow for constexpr functions

Section: 7.1.5  [dcl.constexpr]     Status: ready     Submitter: GB     Date: 2010-08-02

N3092 comment GB 29

A constexpr function is not permitted to return via an exception. This should be recognised, and a function declared constexpr without an explicit exception specification should be treated as if declared noexcept(true) rather than the usual noexcept(false). For a function template declared constexpr without an explicit exception specification, it should be considered noexcept(true) if and only if the constexpr keyword is respected on a given instantiation.

See also issue 1125.

Notes from the August, 2010 meeting:

The premise is not correct: an exception is forbidden only when a constexpr function is invoked in a context that requires a constant expression. Used as an ordinary function, it can throw.

Proposed resolution (August, 2010):

Change 5.3.7 [expr.unary.noexcept] paragraph 3 bullet 1 as follows:



1130. Function parameter type adjustments and decltype

Section: 7.1.6.2  [dcl.type.simple]     Status: ready     Submitter: US     Date: 2010-08-02

N3092 comment US 40

The description of decltype does not specify whether the type of a parameter is the declared type or the type as adjusted in 8.3.5 [dcl.fct] paragraph 5:

    auto f(int a[])->decltype(a);     // ill-formed or int*?
    auto g(const int i)->decltype(i); // int or const int?

Suggested resolution: Clarify the wording to indicate that the type of a parameter is after the array- and function-to-pointer decay but before the removal of cv-qualification.

Proposed resolution (August, 2010):

Change 8.3.5 [dcl.fct] paragraph 5 as follows:

...After producing the list of parameter types, several transformations take place upon these types to determine the function type. Any any top-level cv-qualifiers modifying a parameter type is are deleted when forming the function type. [Example: the type void(*)(const int) becomes void(*)(int) —end example] Such cv-qualifiers affect only the definition of the parameter within the body of the function; they do not affect the function type. If a storage-class-specifier modifies a parameter type, the specifier is deleted. [Example: register char* becomes char* —end example] Such storage-class-specifiers affect only the definition of the parameter within the body of the function; they do not affect the function type. The resulting list of transformed parameter types and the presence or absence of the ellipsis or a function parameter pack is the function's parameter-type-list. [Note: This transformation does not affect the types of the parameters. For example, int(*)(const int p, decltype(p)*) and int(*)(int, const int*) are identical types. —end note]


1131. Template aliases in elaborated-type-specifiers

Section: 7.1.6.3  [dcl.type.elab]     Status: ready     Submitter: US     Date: 2010-08-02

N3092 comment US 41

The current wording disallows use of typedef-names in elaborated-type-specifiers. This prohibition should also apply to template aliases:

    struct A { };
    template<typename T> using X = A;
    struct X<int>* p2; // ill-formed

Proposed resolution (August, 2010):

Change 7.1.6.3 [dcl.type.elab] paragraph 2 as follows:

...If the identifier resolves to a typedef-name or the simple-template-id resolves to an alias template specialization, the elaborated-type-specifier is ill-formed. [Note:...

[Note: this wording assumes the change from “template alias” to “alias template” requested by comment FI 11 on FCD N3092.]



1012. Undeprecating static

Section: 7.3.1.1  [namespace.unnamed]     Status: ready     Submitter: Ville Voutilainen     Date: 2009-12-09

N3092 comment FI 6

Although 7.3.1.1 [namespace.unnamed] states that the use of the static keyword for declaring variables in namespace scope is deprecated because the unnamed namespace provides a superior alternative, it is unlikely that the feature will be removed at any point in the foreseeable future, especially in light of C compatibility concerns. The Committee should consider removing the deprecation.

Proposed resolution (August, 2010):

  1. Delete 7.3.1.1 [namespace.unnamed] paragraph 2:

    2. The use of the static keyword is deprecated when declaring variables in a namespace scope (see annex D [depr]); the unnamed-namespace provides a superior alternative.

  2. Delete D.2 [depr.static]:

    3. D.2 static keyword[depr.static]

    The use of the static keyword is deprecated when declaring objects in namespace scope (see 3.3.6 [basic.scope.namespace]).



341. extern "C" namespace member function versus global variable

Section: 7.5  [dcl.link]     Status: ready     Submitter: Steve Adamczyk     Date: 1 Mar 2002

Here's an interesting case: 

  int f;
  namespace N {
    extern "C" void f () {}
  }
As far as I can tell, this is not precluded by the ODR section (3.2 [basic.def.odr]) or the extern "C" section (7.5 [dcl.link]). However, I believe many compilers do not do name mangling on variables and (more-or-less by definition) on extern "C" functions. That means the variable and the function in the above end up having the same name at link time. EDG's front end, g++, and the Sun compiler all get essentially the same error, which is a compile-time assembler-level error because of the duplicate symbols (in other words, they fail to check for this, and the assembler complains). MSVC++ 7 links the program without error, though I'm not sure how it is interpreted.

Do we intend for this case to be valid? If not, is it a compile time error (required), or some sort of ODR violation (no diagnostic required)? If we do intend for it to be valid, are we forcing many implementations to break binary compatibility by requiring them to mangle variable names?

Personally, I favor a compile-time error, and an ODR prohibition on such things in separate translation units.

Notes from the 4/02 meeting:

The working group agreed with the proposal. We feel a diagnostic should be required for declarations within one translation unit. We also noted that if the variable in global scope in the above example were declared static we would still expect an error.

Relevant sections in the standard are 7.5 [dcl.link] paragraph 6 and 3.5 [basic.link] paragraph 9. We feel that the definition should be written such that the entities in conflict are not "the same entity" but merely not allowed together.

Additional note (September, 2004)

This problem need not involve a conflict between a function and a variable; it can also arise with two variable declarations:

    int x;
    namespace N {
        extern "C" int x;
    }

Proposed resolution (March, 2008):

Change 7.5 [dcl.link] paragraph 6 as follows:

At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object. A function or object with C linkage shall not be declared with the same name (clause 3 [basic]) as an object or reference declared in global scope, unless both declarations denote the same object; no diagnostic is required if the declarations appear in different translation units. [Note: because of the one definition rule (3.2 [basic.def.odr]), only Only one definition for a function or object with C linkage may appear in the program (see 3.2 [basic.def.odr]); that is, implies that such a function or object must not be defined in more than one namespace scope. For example,

    int x;
    namespace A {
      extern "C" int f();
      extern "C" int g() { return 1; }
      extern "C" int h();
      extern "C" int x();               // ill-formed: same name as global-scope object x
    }

    namespace B {
      extern "C" int f();               // A::f and B::f refer
                                        // to the same function
      extern "C" int g() { return 1; }  // ill-formed, the function g
                                        // with C language linkage
                                        // has two definitions
    }

    int A::f() { return 98; }           // definition for the function f
                                        // with C language linkage
    extern "C" int h() { return 97; }
                                        // definition for the function h
                                        // with C language linkage
                                        // A::h and ::h refer to the same function

—end note]

Notes from the September, 2008 meeting:

It should also be possible to declare references with C name linkage (although the meaning the first sentence of 7.5 [dcl.link] paragraph 1 with respect to the meaning of such a declaration is not clear), which would mean that the changed wording should refer to declaring “the same entity” instead of “the same object.” The formulation here would probably benefit from the approach currently envisioned for issues 570 and 633, in which “variable” is defined as being either an object or a reference.

Proposed resolution (February, 2010):

Change 7.5 [dcl.link] paragraph 6 as follows:

At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object or reference with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object or reference. An entity with C language linkage shall not be declared with the same name as an entity in global scope, unless both declarations denote the same object or reference; no diagnostic is required if the declarations appear in different translation units. [Note: because of the one definition rule (3.2 [basic.def.odr]), only Only one definition for a function or object an entity with C linkage may appear in the program (see 3.2 [basic.def.odr]); that is, implies that such a function or object an entity must not be defined in more than one namespace scope. —end note] For example, [Example:

  int x;
  namespace A {
    extern "C" int f();
    extern "C" int g() { return 1; }
    extern "C" int h();
    extern "C" int x();               // ill-formed: same name as global-scope object x
  }

  namespace B {
   extern "C" int f();                // A::f and B::f refer
                                      // to the same function
   extern "C" int g() { return 1; }   // ill-formed, the function g
                                      // with C language linkage
                                      // has two definitions
  }

  int A::f() { return 98; }           // definition for the function f
                                      // with C language linkage
  extern "C" int h() { return 97; }
                                      // definition for the function h
                                      // with C language linkage
                                      // A::h and ::h refer to the same function

—end note example]

Additional note (February, 2010):

The proposed wording above does not cover the case where two different entities with C linkage are declared in different namespaces, only the case where one of the entities is in global scope.

Proposed resolution (August, 2010):

Change 7.5 [dcl.link] paragraph 6 as follows:

At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object a variable with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object variable. An entity with C language linkage shall not be declared with the same name as an entity in global scope, unless both declarations denote the same entity; no diagnostic is required if the declarations appear in different translation units. A variable with C language linkage shall not be declared with the same name as a function with C language linkage (ignoring the namespace names that qualify the respective names); no diagnostic is required if the declarations appear in different translation units. [Note: because of the one definition rule (3.2 [basic.def.odr]), only Only one definition for a function or object an entity with a given name with C language linkage may appear in the program (see 3.2 [basic.def.odr]); that is, implies such a function or object an entity must not be defined in more than one namespace scope. —end note] For example, [Example:

  int x;
  namespace A {
    extern "C" int f();
    extern "C" int g() { return 1; }
    extern "C" int h();
    extern "C" int x();               // ill-formed: same name as global-scope object x
  }

  namespace B {
    extern "C" int f();               // A::f and B::f refer
                                      // to the same function
    extern "C" int g() { return 1; }  // ill-formed, the function g
                                      // with C language linkage
                                      // has two definitions
  }

  int A::f() { return 98; }           // definition for the function f
                                      // with C language linkage
  extern "C" int h() { return 97; }
                                      // definition for the function h
                                      // with C language linkage
                                      // A::h and ::h refer to the same function

—end note example]

[Note to editor: please consider reformatting the comments in the example.]



1070. Missing initializer clauses in aggregate initialization

Section: 8.5.1  [dcl.init.aggr]     Status: ready     Submitter: Jason Merrill     Date: 2010-06-01
Issue 990 added the following text to 8.5.4 [dcl.init.list] paragraph 3:

A better way to handle this would be to delete that bullet and change 8.5.1 [dcl.init.aggr] paragraph 7 as follows:

If there are fewer initializer-clauses in the list than there are members in the aggregate, then each member not explicitly initialized shall be value-initialized (8.5 [dcl.init]) initialized from an empty initializer list (8.5.4 [dcl.init.list]).

This makes { } less of a special case and makes the following example work:

    struct A {
       A(std::initializer_list<int>);
    };
    struct B {
       int i;
       A a;
    };
    B b = { 1 };

Proposed resolution (August, 2010):

  1. Delete 8.5.4 [dcl.init.list] paragraph 3 bullet 2, includeing the example:

  2. Change 8.5.1 [dcl.init.aggr] paragraph 7 as follows:

    3. If there are fewer initializer-clauses in the list than there are members in the aggregate, then each member not explicitly initialized shall be value-initialized (8.5 [dcl.init]) initialized from an empty initializer list (8.5.4 [dcl.init.list]).


1138. Rvalue-ness check for rvalue reference binding is wrong

Section: 8.5.3  [dcl.init.ref]     Status: ready     Submitter: US     Date: 2010-08-02

N3092 comment US 48
 N3092 comment GB 37
 N3092 comment DE 10

The requirement that an rvalue reference must be bound to an rvalue is found in 8.5.3 [dcl.init.ref] paragraph 5 bullet 2:

This is not quite correct, as it is phrased in terms of the value category of the initializer expression itself rather than that of the result of any conversions applied to the initializer. It should be permitted to bind an rvalue reference to a temporary created from an lvalue, for instance, or to the rvalue result of a conversion function for an lvalue object of class type. Also, it should not be permitted to bind an rvalue reference to the lvalue result of a conversion function for a class rvalue.

Proposed resolution (August, 2010):

Change 8.5.3 [dcl.init.ref] paragraph 5 as follows:

A reference to type “cv1 T1” is initialized by an expression of type “cv2 T2” as follows:

In all cases except the last (i.e., creating and initializing a temporary from the initializer expression), the reference is said to bind directly to the initializer expression.

This resolution also resolves issue 1139.



1139. Rvalue reference binding to scalar xvalues

Section: 8.5.3  [dcl.init.ref]     Status: ready     Submitter: US     Date: 2010-08-02

N3092 comment US 49

The current wording of 8.5.3 [dcl.init.ref] paragraph 5 does not specify direct binding of an rvalue reference to a scalar xvalue; instead, it requires creation of a temporary and binding the rvalue reference to the temporary.

Proposed resolution (August, 2010):

This issue is resolved by the resolution of 1138.



1144. Remove access declarations

Section: 11.3  [class.access.dcl]     Status: ready     Submitter: US     Date: 2010-08-03

N3092 comment US 56

Access declarations were deprecated in the 1998 standard and have no benefits over using-declarations. They should be removed in C++0x.

Proposed resolution (August, 2010):

  1. Delete 11.3 [class.access.dcl].

  2. Delete D.3 [depr.access.dcl].

  3. Delete the following production from the grammar in 9.2 [class.mem] paragraph 1:

  4. Change 9.2 [class.mem] paragraph 1 as follows:
    5. ...Except when used to declare friends (11.4) or to introduce the name of a member of a base class into a derived class (7.3.3, 11.3), member-declarations declare members of the class...

  5. Delete 7.3.3 [namespace.udecl] paragraph 19:

    6. [Note: use of access-declarations (11.3 [class.access.dcl]) is deprecated; member using-declarations provide a better alternative. —end note]


1146. exception-specifications of defaulted functions

Section: 12.4  [class.dtor]     Status: ready     Submitter: GB     Date: 2010-08-03

N3092 comment GB 39
 N3092 comment GB 41

The note in 12.4 [class.dtor] paragraph 4 says,

An explictly defaulted definition has no implicit exception-specification.

There are similar notes in 12.8 [class.copy] paragraphs 15 and 29.

However, 8.4.2 [dcl.fct.def.default] paragraph 2 bullet 4 says that a special member function that is explicitly defaulted on its first declaration

is implicitly considered to have the same exception-specification as if it had been implicitly declared (15.4 [except.spec])

The notes are incorrect.

Proposed resolution (August, 2010):

  1. Change 12.4 [class.dtor] paragraph 4 as follows:

    2. [Note: an implicitly- declared destructor has an exception-specification (15.4). An explictly defaulted definition has no implicit exception-specification. —end note]

  2. Change 12.8 [class.copy] paragraph 15 as follows:

    3. [Note: an implicitly-declared copy/move constructor has an exception-specification (15.4). An explicitly-defaulted definition (8.4.2) has no implicit exception-specification. —end note]

  3. Change 12.8 [class.copy] paragraph 29 as follows:

    4. [Note: An implicitly-declared copy/move assignment operator has an exception- specification (15.4). An explicitly-defaulted definition has no implicit exception-specification. —end note]


1020. Implicitly-defined copy constructors and explicit base class constructors

Section: 12.8  [class.copy]     Status: ready     Submitter: Niels Dekker     Date: 2010-01-12

N3092 comment FI 19

It is not clear whether the current specification allows a defaulted copy constructor to call an explicit constructor to copy a base or member subobject, and if so, whether that is desirable or not. See also issues 535 and 1118.

Proposed resolution (August, 2010):

This issue is resolved by the resolution of issue 1051.



1051. Reference members and generated copy constructors

Section: 12.8  [class.copy]     Status: ready     Submitter: Steve Adamczyk     Date: 2010-03-11

N3092 comment US 62

The new wording describing generated copy constructors (12.8 [class.copy] paragraph 16) does not describe the initialization of members with reference type.

Proposed resolution (August, 2010):

  1. Change 12.8 [class.copy] paragraph 16 as follows:

    2. The implicitly-defined copy constructor for a non-union class X performs a memberwise copy of its subobjects bases and members. [Note: brace-or-equal-initializers of non-static data members are ignored. See also the example in 12.6.2 [class.base.init]. —end note] The order of copying is the same as the order of initialization of bases and members in a user-defined constructor (see 12.6.2 [class.base.init]). Each subobject Given a parameter named x, each base or non-static data member is copied in the manner appropriate to its type:

    Virtual base class subobjects shall be copied only once by the implicitly-defined copy constructor (see 12.6.2 [class.base.init]).

  2. Change 12.8 [class.copy] paragraph 17 as follows:

    3. The implicitly-defined move constructor for a non-union class X performs a memberwise move of its subobjects bases and members. [Note: brace-or-equal-initializers of non-static data members are ignored. See also the example in 12.6.2 [class.base.init]. —end note] The order of moving is the same as the order of initialization of bases and members in a user-defined constructor (see 12.6.2 [class.base.init]). Given a parameter named x, each base or non-static data member is moved in the manner appropriate to its type:

    Virtual base class subobjects shall be moved only once by the implicitly-defined move constructor (see 12.6.2 [class.base.init]).

  3. Change 12.8 [class.copy] paragraph 18 as follows:

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

  4. Change 12.8 [class.copy] paragraph 28 as follows:

    5. A copy/move assignment operator that is defaulted and not defined as deleted is implicitly defined when it is used (3.2 [basic.def.odr]) (e.g., when it is selected by overload resolution to assign to an object of its class type) is assigned a value of its class type or a value of a class type derived from its class type or when it is explicitly defaulted after its first declaration.

  5. Change 12.8 [class.copy] paragraph 30 as follows:

    6. ...the order in which they were declared in the class definition. Each Given a parameter named x, each subobject is assigned in the manner appropriate to its type:

  6. Change 12.8 [class.copy] paragraph 31 as follows:

    7. ...each subobject is assigned in the manner appropriate to its type:

This resolution also resolves issues 1064 and 1066.



1064. Defaulted move constructor for a union

Section: 12.8  [class.copy]     Status: ready     Submitter: Mike Miller     Date: 2010-03-23

N3092 comment US 63

The new wording in 12.8 [class.copy] specifies the behavior of an implicitly-defined copy constructor for a non-union class (paragraph 16), an implicitly-defined move constructor for a non-union class (paragraph 17), and an implicitly-defined copy constructor for a union (paragraph 18), but not an implicitly-defined move constructor for a union.

Proposed resolution (August, 2010):

This issue is resolved by the resolution of issue 1051.



1066. When is a copy/move assignment operator implicitly defined?

Section: 12.8  [class.copy]     Status: ready     Submitter: Mike Miller     Date: 2010-03-24

N3092 comment US 64

According to 12.8 [class.copy] paragraph 28,

A copy/move assignment operator that is defaulted and not defined as deleted is implicitly defined when an object of its class type is assigned a value of its class type or a value of a class type derived from its class type or when it is explicitly defaulted after its first declaration.

This sounds as if any assignment to a class object, regardless of whether it is a copy or a move assignment, defines both the copy and move operators. Presumably an assignment should only define the assignment operator chosen by overload resolution for the operation. (Compare the corresponding wording in paragraph 14 for the copy/move constructors: “...implicitly defined if it is used to initialize an object of its class type...”)

Proposed resolution (August, 2010):

This issue is resolved by the resolution of issue 1051.



1087. Additional applications of issue 899

Section: 13.3.1.4  [over.match.copy]     Status: ready     Submitter: Jason Merrill     Date: 2010-06-25

The resolution of issue 899 needs to be extended to cover move constructors and template constructors as well.

Proposed resolution (August, 2010):

For example

    struct C {
       template <class T = int> C(C&, T = 0);
    };

    struct A {
       explicit operator C&() const;
    };

    int main() {
       A a;
       C c (a); // should use template constructor
    }


1152. Rules for determining existence of implicit conversion sequence

Section: 13.3.2  [over.match.viable]     Status: ready     Submitter: US     Date: 2010-08-03

N3092 comment US 67

To determine whether there is an implicit conversion sequence that converts the argument to the corresponding parameter, 13.3.2 [over.match.viable] paragraph 3 uses 13.3.3.1 [over.best.ics] instead of just saying “there is an ICS if-and-only-if a copy initialization would be well-formed.” Apparently this is intended, but to a casual reader or an implementor reading these rules for the first time for a new implementation, it's not clear why that's desirable. A note should be added to explain the rationale.

Proposed resolution (August, 2010):

Change 13.3.3.1.4 [over.ics.ref] paragraph 3 as follows:

Except for an implicit object parameter, for which see 13.3.1 [over.match.funcs], a standard conversion sequence cannot be formed if it requires binding an lvalue reference to non-const other than a reference to a non-volatile const type to an rvalue or binding an rvalue reference to an lvalue. [Note:...


1154. Address of thread_local variable as non-type template argument

Section: 14.3.2  [temp.arg.nontype]     Status: ready     Submitter: US     Date: 2010-08-03

N3092 comment US 69

The standard permits the address of a thread_local object as a non-type template argument. The addresses of these objects are not constant, however. Such template arguments should require objects of static storage duration.

Proposed resolution (August, 2010):

This issue is resolved by the resolution of issue 1155.



1155. Internal-linkage non-type template arguments

Section: 14.3.2  [temp.arg.nontype]     Status: ready     Submitter: US     Date: 2010-08-03

N3092 comment DE 12

Now that local classes can be used as template arguments, it seems odd that there are “external linkage” restrictions on non-type template parameters. The addresses of objects and functions with internal linkage should be permitted as well.

Proposed resolution (August, 2010):

Change 14.3.2 [temp.arg.nontype] paragraph 1 bullet 3 as follows:

This resolution also resolves issue 1154.



1158. Recursive instantiation via alias template

Section: 14.5.7  [temp.alias]     Status: ready     Submitter: US     Date: 2010-08-03

N3092 comment US 73

The current wording of 7.1.3 [dcl.typedef] paragraph 2 requires that the identifier in an alias-declaration “...shall not appear in the type-id.” With template aliases, however, the name of the alias can be used indirectly:

    template<typename T> struct A;
    template<typename T> using B=typename A<T>::U;
    template<typename T> struct A {
      typedef B<T> U;
    };
    B<short> b;

Here the instantiation of B<short> causes the instantiation of A<short>, and the typedef in A<short> ends up attempting to use B<short>, which is still in the process of being instantiated.

There should be an explicit prohibition of such uses.

Proposed resolution (August, 2010):

Add the following as a new paragraph at the end of 14.5.7 [temp.alias]:

The type-id in an alias template declaration shall not refer to the alias template being declared. The type produced by an alias template specialization shall not directly or indirectly make use of that specialization. [Example:

  template <class T> struct A;
  template <class T> using B = typename A<T>::U;
  template <class T> struct A {
    typedef B<T> U;
  };
  B<short> b; // Error: instantiation of B<short> uses own type via A<short>::U.

—end example]

[Note: this wording assumes the change from “template alias” to “alias template” requested by comment FI 11 on FCD N3092.]

1159. Class and enumeration definitions in template aliases

Section: 14.5.7  [temp.alias]     Status: ready     Submitter: US     Date: 2010-08-03

N3092 comment US 74

An alias-declaration allows a class or enumeration type to be defined in its type-id (7.1.6 [dcl.type] paragraph 3). However, it's not clear that this is desirable when the alias-declaration is part of a template alias:

    template<typename T> using A =
      struct { void f(T) { } };

Proposed resolution (August, 2010):

Change 7.1.6 [dcl.type] paragraph 3 as follows:

...A type-specifier-seq shall not define a class or enumeration unless it appears in the type-id of an alias-declaration (7.1.3 [dcl.typedef]) that is not the declaration of a template-declaration.


1161. Dependent nested-name-specifier in a pointer-to-member declarator

Section: 14.6  [temp.res]     Status: ready     Submitter: GB     Date: 2010-08-03

N3092 comment GB 44

It is not clear from the current wording of 14.6 [temp.res] whether the following is well-formed or not:

    template<typename T> struct id { typedef T type; };
    template<typename T> void f() { int id<T>::type::*p = 0; }
    struct A { };
    int main() { f<A>(); }

If typename is required before the use of id<T>::type, it is not permitted by the current syntax.

Proposed resolution (August, 2010):

Change 14.6 [temp.res] paragraph 5 as follows:

A qualified name used as the name in a mem-initializer-id, a base-specifier, or an elaborated-type-specifier is implicitly assumed to name a type, without the use of the typename keyword. In a nested-name-specifier that immediately contains a nested-name-specifier that depends on a template parameter, the identifier or simple-template-id is implicitly assumed to name a type, without the use of the typename keyword. [Note: the typename keyword is not permitted by the syntax of these constructs. —end note]


1160. Definitions of template members and the current instantiation

Section: 14.6.2.1  [temp.dep.type]     Status: ready     Submitter: GB     Date: 2010-08-03

N3092 comment GB 43

The current rules for determining whether a name refers to the current instantiation, given in 14.6.2.1 [temp.dep.type] paragraph 1, do not cover the case when a template-id matching a primary template or partial specialization appears in the definition of a member of the template.

Proposed resolution (August, 2010):

Change 14.6.2.1 [temp.dep.type] paragraph 1 as follows:

In the definition of a class template, a nested class of a class template, a member of a class template, or a member of a nested class of a class template, a A name refers to the current instantiation if it is


1164. Partial ordering of f(T&) and f(T&&)

Section: 14.8.2.1  [temp.deduct.call]     Status: ready     Submitter: US     Date: 2010-08-03

N3092 comment US 77

The following example is ambiguous:

    template<typename T> int f(T&);
    template<typename T> int f(T&&);
    int i;
    int j = f(i);

Because of the special deduction rule for lvalues passed to rvalue-reference parameters, deduction produces f(int&) for both templates, and they are indistinguishable.

Because f(T&) accepts a strict subset of the things that f(T&&) does, it should be considered more specialized by the partial ordering rules.

Proposed resolution (August, 2010):

Change 14.8.2.4 [temp.deduct.partial] paragraph 9 as follows:

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):

  1. If the type from the argument template was an lvalue reference and the type from the parameter template was not, the argument type is considered to be more specialized than the other; otherwise,

  2. and if the type from the argument template is more cv-qualified than the type from the parameter template (as described above), the argument that type is considered to be more specialized than the other.; otherwise

  3. If neither type is more cv-qualified than the other then neither type is more specialized than the other.

[Editing note: this change transforms the running text at the end of the paragraph into a bulleted list.]



1167. function-try-blocks for destructors

Section: 15.4  [except.spec]     Status: ready     Submitter: GB     Date: 2010-08-03

N3092 comment GB 46

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

Proposed resolution (August, 2010):

Change 15 [except] paragraph 4 as follows:

...An exception thrown during the execution of the initializer expressions in the ctor-initializer or during the execution of the compound-statement, or — in the case of a destructor — during the destruction of a subobject, transfers control to a handler in a function-try-block in the same way as an exception thrown during the execution of a try-block transfers control to other handlers. [Example:...


1168. Additional reasons to call std::terminate

Section: 15.5.1  [except.terminate]     Status: ready     Submitter: GB     Date: 2010-08-03

N3092 comment GB 47

The list of reasons for which std::terminate is called needs to be extended to cover several additional cases in C++0x:

Proposed resolution (August, 2010):

  1. Change 15.5.1 [except.terminate] paragraph 1 as follows:

    2. In the following some situations exception handling must be abandoned for less subtle error handling techniques:. [Note: These situations are:

    —end note]

  2. Insert the following as a new paragraph following 15.1 [except.throw] paragraph 6:

    3. An exception is considered caught...

    If the exception handling mechanism, after completing evaluation of the expression to be thrown but before the exception is caught, calls a function that exits via an exception, std::terminate is called (15.5.1 [except.terminate]). [Example:

        struct C {
      C() { }
      C(const C&) { throw 0; }
    };

    int main() {
      try {
        throw C();   // calls std::terminate()
      } catch(C) { }
    }

    —end example]

  3. Change 15.2 [except.ctor] paragraph 3 as follows:

    4. The process of calling destructors for automatic objects constructed on the path from a try block to a throw-expression is called “stack unwinding.” [Note: If a destructor called during stack unwinding exits with an exception, std::terminate is called (15.5.1 [except.terminate]). [Note: So destructors should generally catch exceptions and not let them propagate out of the destructor. —end note]

  4. Change 3.6.2 [basic.start.init] paragraph 6 as follows:

    5. [Note: If the initialization of a non-local variable with static or thread storage duration terminates by throwing exits via an exception, std::terminate is called (see 15.5.1 [except.terminate]). —end note]

  5. Change 3.6.3 [basic.start.term] paragraph 1 as follows:

    6. ...[Note: If the destruction of a non-local an object with static or thread storage duration terminates by throwing exits via an exception, std::terminate is called (see 15.5.1 [except.terminate]). —end note]

  6. Change 18.5 [support.start.term] paragraph 8 bullet 1 as follows:



1171. Partial stack unwinding with noexcept violation

Section: 15.5.1  [except.terminate]     Status: ready     Submitter: Merrill     Date: 2010-08-04

The current wording of 15.5.1 [except.terminate] paragraph 2 makes it sound as if stack unwinding in the case of a noexcept violation is an all-or-nothing proposition. It would be useful to be able to partially unwind the stack, in particular, not to call destructors for the function containing the noexcept-specification.

Proposed resolution (August, 2010):

Change 15.5.1 [except.terminate] paragraph 2 as follows:

...In the situation where the search for a handler (15.3 [except.handle]) encounters the outermost block of a function with a noexcept-specification that does not allow the exception (15.4 [except.spec]), it is implementation-defined whether the stack is unwound, unwound partially, or not unwound at all before std::terminate() is called. In all other situations, the stack shall not be unwound...


1169. Missing feature macro for strict pointer safety

Section: 16.8  [cpp.predefined]     Status: ready     Submitter: GB     Date: 2010-08-03

N3092 comment DE 13

The recommendations of document N2693 included a feature macro to enable a program to determine whether the implementation enforces strict pointer safety or not, but this macro is not specified in 16.8 [cpp.predefined].

Proposed resolution (August, 2010):

Add the following to the end of 16.8 [cpp.predefined] paragraph 2:





Issues with "Tentatively Ready" Status



Issues with "Review" Status

712. Are integer constant operands of a conditional-expression “used?”

Section: 3.2  [basic.def.odr]     Status: review     Submitter: Mike Miller     Date: 9 September, 2008

In describing static data members initialized inside the class definition, 9.4.2 [class.static.data] paragraph 3 says,

The member shall still be defined in a namespace scope if it is used in the program...

The definition of “used” is in 3.2 [basic.def.odr] paragraph 1:

An object or non-overloaded function whose name appears as a potentially-evaluated expression is used unless it is an object that satisfies the requirements for appearing in a constant expression (5.19 [expr.const]) and the lvalue-to-rvalue conversion (4.1 [conv.lval]) is immediately applied.

Now consider the following example:

    struct S {
      static const int a = 1;
      static const int b = 2;
    };
    int f(bool x) {
      return x ? S::a : S::b;
    }

According to the current wording of the Standard, this example requires that S::a and S::b be defined in a namespace scope. The reason for this is that, according to 5.16 [expr.cond] paragraph 4, the result of this conditional-expression is an lvalue and the lvalue-to-rvalue conversion is applied to that, not directly to the object, so this fails the “immediately applied” requirement. This is surprising and unfortunate, since only the values and not the addresses of the static data members are used. (This problem also applies to the proposed resolution of issue 696.)

Proposed resolution (November, 2009):

Change 3.2 [basic.def.odr] paragraph 1 as follows:

...An object or non-overloaded function whose name appears as a potentially-evaluated expression x is used unless it is an object that satisfies the requirements for appearing in a constant expression (5.19 [expr.const]) and the lvalue-to-rvalue conversion (4.1 [conv.lval]) is immediately applied eventually applied to all lvalue expressions e that could possibly denote that object, where e is a subexpression of the full-expression containing x...

Additional notes (November, 2009):

The proposed wording (like the existing wording) requires that S::a be defined in the following example:

  struct S {
    static const int a = 1;
  };
  void g() {
    S::a;  // no lvalue-to-rvalue conversion
  }

Although this particular example is obviously unimportant, there could be similar cases where a use is buried in a nested conditional and the result eventually discarded, perhaps as the result of a macro expansion. An alternative approach that addresses this point might be something along the lines of

There is no lvalue expression e of which x is a subexpression to which a reference is bound or to which the unary & operator is applied that could possibly denote that object.

One objection to this latter approach is that it would require defining S::a if the expression were something like *&S::a, which would not be the case with the wording in the proposed resolution.



554. Definition of “declarative region” and “scope”

Section: 3.3  [basic.scope]     Status: review     Submitter: Gabriel Dos Reis     Date: 29 December 2005

The various uses of the term “declarative region” throughout the Standard indicate that the term is intended to refer to the entire block, class, or namespace that contains a given declaration. For example, 3.3 [basic.scope] paragraph 2 says, in part:

[Example: in

    int j = 24;
    int main()
    {
        int i = j, j;
        j = 42;
    }

The declarative region of the first j includes the entire example... The declarative region of the second declaration of j (the j immediately before the semicolon) includes all the text between { and }...

However, the actual definition given for “declarative region” in 3.3 [basic.scope] paragraph 1 does not match this usage:

Every name is introduced in some portion of program text called a declarative region, which is the largest part of the program in which that name is valid, that is, in which that name may be used as an unqualified name to refer to the same entity.

Because (except in class scope) a name cannot be used before it is declared, this definition contradicts the statement in the example and many other uses of the term throughout the Standard. As it stands, this definition is identical to that of the scope of a name.

The term “scope” is also misused. The scope of a declaration is defined in 3.3 [basic.scope] paragraph 1 as the region in which the name being declared is valid. However, there is frequent use of the phrase “the scope of a class,” not referring to the region in which the class's name is valid but to the declarative region of the class body, and similarly for namespaces, functions, exception handlers, etc. There is even a mention of looking up a name “in the scope of the complete postfix-expression” (3.4.5 [basic.lookup.classref] paragraph 3), which is the exact inverse of the scope of a declaration.

This terminology needs a thorough review to make it logically consistent. (Perhaps a discussion of the scope of template parameters could also be added to section 3.3 [basic.scope] at the same time, as all other kinds of scopes are described there.)

Proposed resolution (November, 2006):

  1. Change 3.3 [basic.scope] paragraph 1 as follows:

    2. Every name is introduced in some portion of program text called a declarative region, which is the largest part of the program in which that name is valid, that is, in which that name may be used as an unqualified name to refer to the same entity a statement, block, function declarator, function-definition, class, handler, template-declaration, template-parameter-list of a template template-parameter, or namespace. In general, each particular name is valid may be used as an unqualified name to refer to the entity of its declaration or to the label only within some possibly discontiguous portion of program text called its scope. To determine the scope of a declaration...

  2. Change 3.3 [basic.scope] paragraph 3 as follows:

    3. The names declared by a declaration are introduced into the scope in which the declaration occurs declarative region that directly encloses the declaration, except that declaration-statements, function parameter names in the declarator of a function-definition, exception-declarations (3.3.3 [basic.scope.local]), the presence of a friend specifier (11.4 [class.friend]), certain uses of the elaborated-type-specifier (7.1.6.3 [dcl.type.elab]), and using-directives (7.3.4 [namespace.udir]) alter this general behavior.

  3. Change 3.3.3 [basic.scope.local] paragraphs 1-3 and add a new paragraph 4 before the existing paragraph 4 as follows:

    4. A name declared in a block (6.3 [stmt.block]) is local to that block. Its potential scope begins at its point of declaration (3.3.2 [basic.scope.pdecl]) and ends at the end of its declarative region. The declarative region of a name declared in a declaration-statement is the directly enclosing block (6.3 [stmt.block]). Such a name is local to the block.

    The potential scope declarative region of a function parameter name (including one appearing in the declarator of a function-definition or in a lambda-parameter-declaration-clause) or of a function-local predefined variable in a function definition (8.4 [dcl.fct.def]) begins at its point of declaration. If the function has a function-try-block the potential scope of a parameter or of a function-local predefined variable ends at the end of the last associated handler, otherwise it ends at the end of the outermost block of the function definition. A parameter name is the entire function definition or lambda-expression. Such a name is local to the function definition and shall not be redeclared in the any outermost block of the function definition nor in the outermost block of any handler associated with a function-try-block function-body (including handlers of a function-try-block) or lambda-expression.

    The name in a catch exception-declaration The declarative region of a name declared in an exception-declaration is its entire handler. Such a name is local to the handler and shall not be redeclared in the outermost block of the handler.

    The potential scope of any local name begins at its point of declaration (3.3.2 [basic.scope.pdecl]) and ends at the end of its declarative region.

  4. Change 3.3.5 [basic.funscope] as indicated:

    5. Labels (6.1 [stmt.label]) have function scope and may be used anywhere in the function in which they are declared except in members of local classes (9.8 [class.local]) of that function. Only labels have function scope.

  5. Change 6.7 [stmt.dcl] paragraph 1 as follows:

    6. A declaration statement introduces one or more new identifiers names into a block; it has the form

    [Note: If an identifier a name introduced by a declaration was previously declared in an outer block, the outer declaration is hidden for the remainder of the block, after which it resumes its force (3.3.10 [basic.scope.hiding]). —end note]

[Drafting notes: This resolution deals almost exclusively with the unclear definition of “declarative region.” I've left the ambiguous use of “scope” alone for now. However sections 3.3.x all have headings reading “xxx scope,” but they don't mean the scope of a declaration but the different kinds of declarative regions and their effects on the scope of declarations contained therein. To me, it looks like most of 3.4 should refer to “declarative region” and not to “scope.”

The change to 6.7 fixes an “identifier” misuse (e.g., extern T operator+(T,T); at block scope introduces a name but not an identifier) and removes normative redundancy.]



555. Pseudo-destructor name lookup

Section: 3.4  [basic.lookup]     Status: review     Submitter: Krzysztof Zelechowski     Date: 26 January 2006

The Standard does not completely specify how to look up the type-name(s) in a pseudo-destructor-name (5.2 [expr.post] paragraph 1, 5.2.4 [expr.pseudo]), and what information it does have is incorrect and/or in the wrong place. Consider, for instance, 3.4.5 [basic.lookup.classref] paragraphs 2-3:

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

If the unqualified-id is ~type-name, and the type of the object expression is of a class type C (or of pointer to a class type C), the type-name is looked up in the context of the entire postfix-expression and in the scope of class C. The type-name shall refer to a class-name. If type-name is found in both contexts, the name shall refer to the same class type. If the type of the object expression is of scalar type, the type-name is looked up in the scope of the complete postfix-expression.

There are at least three things wrong with this passage with respect to pseudo-destructors:

  1. A pseudo-destructor call (5.2.4 [expr.pseudo]) is not a “class member access”, so the statements about scalar types in the object expressions are vacuous: the object expression in a class member access is required to be a class type or pointer to class type (5.2.5 [expr.ref] paragraph 2).

  2. On a related note, the lookup for the type-name(s) in a pseudo-destructor name should not be described in a section entitled “Class member access.”

  3. Although the class member access object expressions are carefully allowed to be either a class type or a pointer to a class type, paragraph 2 mentions only a “pointer to scalar type” (disallowing references) and paragraph 3 deals only with a “scalar type,” presumably disallowing pointers (although it could possibly be a very subtle way of referring to both non-class pointers and references to scalar types at once).

The other point at which lookup of pseudo-destructors is mentioned is 3.4.3 [basic.lookup.qual] paragraph 5:

If a pseudo-destructor-name (5.2.4 [expr.pseudo]) contains a nested-name-specifier, the type-names are looked up as types in the scope designated by the nested-name-specifier.

Again, this specification is in the wrong location (a pseudo-destructor-name is not a qualified-id and thus should not be treated in the “Qualified name lookup” section).

Finally, there is no place in the Standard that describes the lookup for pseudo-destructor calls of the form p->T::~T() and r.T::~T(), where p and r are a pointer and reference to scalar, respectively. To the extent that it gives any guidance at all, 3.4.5 [basic.lookup.classref] deals only with the case where the ~ immediately follows the . or ->, and 3.4.3 [basic.lookup.qual] deals only with the case where the pseudo-destructor-name contains a nested-name-specifier that designates a scope in which names can be looked up.

See document J16/06-0008 = WG21 N1938 for further discussion of this and related issues, including 244, 305, 399, and 414.

Proposed resolution (June, 2008):

  1. Add a new paragraph following 5.2 [expr.post] paragraph 2 as follows:

    2. When a postfix-expression is followed by a dot . or arrow -> operator, the interpretation depends on the type T of the expression preceding the operator. If the operator is ., T shall be a scalar type or a complete class type; otherwise, T shall be a pointer to a scalar type or a pointer to a complete class type. When T is a (pointer to) a scalar type, the postfix-expression to which the operator belongs shall be a pseudo-destructor call (5.2.4 [expr.pseudo]); otherwise, it shall be a class member access (5.2.5 [expr.ref]).

  2. Change 5.2.4 [expr.pseudo] paragraph 2 as follows:

    3. The left-hand side of the dot operator shall be of scalar type. The left-hand side of the arrow operator shall be of pointer to scalar type. This scalar type The type of the expression preceding the dot operator, or the type to which the expression preceding the arrow operator points, is the object type...

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

    4. For the first option (dot) the type of the first expression (the object expression) shall be “class object” (of a complete type) is a class type. For the second option (arrow) the type of the first expression (the pointer expression) shall be “pointer to class object” (of a complete type) is a pointer to a class type. In these cases, the id-expression shall name a member of the class or of one of its base classes.

  4. Add a new paragraph following 3.4 [basic.lookup] paragraph 2 as follows:

    5. In a pseudo-destructor-name that does not include a nested-name-specifier, the type-names are looked up as types in the context of the complete expression.

  5. Delete the last sentence of 3.4.5 [basic.lookup.classref] paragraph 2:

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


597. Conversions applied to out-of-lifetime non-POD lvalues

Section: 3.8  [basic.life]     Status: review     Submitter: Mike Miller     Date: 27 September 2006

An lvalue referring to an out-of-lifetime non-POD class objects can be used in limited ways, subject to the restrictions in 3.8 [basic.life] paragraph 6:

if the original object will be or was of a non-POD class type, the program has undefined behavior if:

There are at least a couple of questionable things in this list. First, there is no “implicit conversion to a reference to a base class,” as assumed by the second bullet. Presumably this is intended to say that the lvalue is bound to a reference to a base class, and the cross-reference should be to 8.5.3 [dcl.init.ref], not to 4.10 [conv.ptr] (which deals with pointer conversions). However, even given that adjustment, it is not clear why it is forbidden to bind a reference to a non-virtual base class of an out-of-lifetime object, as that is just an address offset calculation. (Binding to a virtual base, of course, would require access to the value of the object and thus cannot be done outside the object's lifetime.)

The third bullet also appears questionable. It's not clear why static_cast is discussed at all here, as the only permissible static_cast conversions involving reference types and non-POD classes are to references to base or derived classes and to the same type, modulo cv-qualification; if implicit “conversion” to a base class reference is forbidden in the second bullet, why would an explicit conversion be permitted in the third? Was this intended to refer to reinterpret_cast? Also, is there a reason to allow char types but disallow array-of-char types (which are more likely to be useful than a single char)?

Proposed resolution (March, 2008):

  1. Change 3.8 [basic.life] paragraph 5 as follows:

    2. ...If the object will be or was of a non-trivial class type, the program has undefined behavior if:

  2. Change 3.8 [basic.life] paragraph 6 as follows:

    3. ...if the original object will be or was of a non-trivial class type, the program has undefined behavior if:

[Drafting notes: Paragraph 5 was changed to track the changes to paragraph 6. See also the resolution for issue 658.]



1116. Aliasing of union members

Section: 3.8  [basic.life]     Status: review     Submitter: US     Date: 2010-08-02

N3092 comment US 27

Related to issue 1027, consider:

    int f() {
      union U { double d; } u1, u2;
      (int&)u1.d = 1;
      u2 = u1;
      return (int&)u2.d;
    }

Does this involve undefined behavior? 3.8 [basic.life] paragraph 4 seems to say that it's OK to clobber u1 with an int object. Then union assignment copies the object representation, possibly creating an int object in u2 and making the return statement well-defined. If this is well-defined, compilers are significantly limited in the assumptions they can make about type aliasing. On the other hand, the variant where U has an array of unsigned char member must be well-defined in order to support std::aligned_storage.

Suggested resolution: Clarify that this case is undefined, but that adding an array of unsigned char to union U would make it well-defined — if a storage location is allocated with a particular type, it should be undefined to create an object in that storage if it would be undefined to access the stored value of the object through the allocated type.

Proposed resolution (August, 2010):

  1. Change 3.8 [basic.life] paragraph 1 as follows:

    2. ...The lifetime of an object of type T begins when storage with the proper alignment and size for type T is obtained, and either:

    The lifetime of an object of type T ends...

  2. Change 3.8 [basic.life] paragraph 4 as follows:

    3. A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor. For an object of a class type with a non-trivial destructor, the program is not required to call the destructor explicitly before the storage which the object occupies is reused or released; however, if there is no explicit call to the destructor or if a delete-expression (5.3.5 [expr.delete]) is not used to release the storage, the destructor shall not be implicitly called and any program that depends on the side effects produced by the destructor has undefined behavior. If a program obtains storage for an object of a particular type A (e.g. with a variable definition or new-expression) and later reuses that storage for an object of another type B such that accessing the stored value of the B object through a glvalue of type A would have undefined behavior (3.10 [basic.lval]), the behavior is undefined. [Example: 

      int i;
  (double&)i = 1.0; // undefined behavior

  struct S { unsigned char alignas(double) ar[sizeof (double)]; } s;
  (double&)s = 1.0; // OK, can access stored double through s because it has an unsigned char subobject

    —end example]

  3. Change 3.10 [basic.lval] paragraph 10 as follows:

    4. If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined52:

This resolution also resolves issue 1027.



572. Standard conversions for non-built-in types

Section: 4  [conv]     Status: review     Submitter: Jens Maurer     Date: 6 April 2006

4 [conv] paragraph 1 says,

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

However, enumeration types (which take part in the integral promotions) and class types (which take part in the lvalue-to-rvalue conversion) are not “built-in” types, so the definition of “standard conversions” is wrong.

Proposed resolution (October, 2006):

Change 4 [conv] paragraph 1 as follows:

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


240. Uninitialized values and undefined behavior

Section: 4.1  [conv.lval]     Status: review     Submitter: Mike Miller     Date: 8 Aug 2000

4.1 [conv.lval] paragraph 1 says,

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.

I think there are at least three related issues around this specification:

  1. Presumably assigning a valid value to an uninitialized object allows it to participate in the lvalue-to-rvalue conversion without undefined behavior (otherwise the number of programs with defined behavior would be vanishingly small :-). However, the wording here just says "uninitialized" and doesn't mention assignment.

  2. There's no exception made for unsigned char types. The wording in 3.9.1 [basic.fundamental] was carefully crafted to allow use of unsigned char to access uninitialized data so that memcpy and such could be written in C++ without undefined behavior, but this statement undermines that intent.

  3. It's possible to get an uninitialized rvalue without invoking the lvalue-to-rvalue conversion. For instance:

            struct A {
            int i;
            A() { } // no init of A::i
        };
        int j = A().i;  // uninitialized rvalue

    There doesn't appear to be anything in the current IS wording that says that this is undefined behavior. My guess is that we thought that in placing the restriction on use of uninitialized objects in the lvalue-to-rvalue conversion we were catching all possible cases, but we missed this one.

In light of the above, I think the discussion of uninitialized objects ought to be removed from 4.1 [conv.lval] paragraph 1. Instead, something like the following ought to be added to 3.9 [basic.types] paragraph 4 (which is where the concept of "value" is introduced):

Any use of an indeterminate value (5.3.4 [expr.new], 8.5 [dcl.init], 12.6.2 [class.base.init]) of any type other than char or unsigned char results in undefined behavior.

John Max Skaller:

A().i had better be an lvalue; the rules are wrong. Accessing a member of a structure requires it be converted to an lvalue, the above calculation is 'as if':

    struct A {
        int i;
        A *get() { return this; }
    };
    int j = (*A().get()).i;

and you can see the bracketed expression is an lvalue.

A consequence is:

    int &j= A().i; // OK, even if the temporary evaporates

j now refers to a 'destroyed' value. Any use of j is an error. But the binding at the time is valid.

Proposed Resolution (November, 2006):

  1. Add the indicated words to 3.9 [basic.types] paragraph 4:

    ... For trivial types, the value representation is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-defined set of values. Any use of an indeterminate value (5.3.4 [expr.new], 8.5 [dcl.init], 12.6.2 [class.base.init]) of a type other than unsigned char results in undefined behavior.

  2. Change 4.1 [conv.lval] paragraph 1 as follows:

    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.

Additional note (May, 2008):

The C committee is dealing with a similar issue in their DR336. According to this analysis, they plan to take almost the opposite approach to the one described above by augmenting the description of their version of the lvalue-to-rvalue conversion. The CWG did not consider that access to an unsigned char might still trap if it is allocated in a register and needs to reevaluate the proposed resolution in that light. See also issue 129.



1120. reinterpret_cast and void*

Section: 5.2.10  [expr.reinterpret.cast]     Status: review     Submitter: GB     Date: 2010-08-02

N3092 comment GB 22

It is not permitted to use reinterpret_cast to convert between pointers to object type and pointers to void.

See also issue 573.

Proposed resolution (August, 2010):

Change 5.2.10 [expr.reinterpret.cast] paragraph 7 as follows:

A pointer to an object An object pointer can be explicitly converted to a pointer to a different object type different object pointer type.70 When a prvalue v of type “pointer to T1” is converted to the type “pointer to cv T2”, the result is static_cast<cv T2*>(static_cast<cv void*>(v)) if both T1 and T2 are standard-layout types (3.9 [basic.types]) and the alignment requirements of T2 are no stricter than those of T1, or if either type is void. Converting a prvalue of type “pointer to T1” to the type “pointer to T2” (where T1 and T2 are object types and where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value. The result of any other such pointer conversion is unspecified.

(Note: this resolution depends on that of issue 573.)



342. Terminology: "indirection" versus "dereference"

Section: 5.3  [expr.unary]     Status: review     Submitter: Jason Merrill     Date: 7 Oct 2001

Split off from issue 315.

Incidentally, another thing that ought to be cleaned up is the inconsistent use of "indirection" and "dereference". We should pick one.

Proposed resolution (December, 2006):

  1. Change 5.3.1 [expr.unary.op] paragraph 1 as follows:

    2. The unary * operator performs indirection dereferences a pointer value: the expression to which it is applied shall be a pointer...

  2. Change 8.3.4 [dcl.array] paragraph 8 as follows:

    3. The results are added and indirection applied values are added and the result is dereferenced to yield an array (of five integers), which in turn is converted to a pointer to the first of the integers.

  3. Change 8.3.5 [dcl.fct] paragraph 9 as follows:

    4. The binding of *fpi(int) is *(fpi(int)), so the declaration suggests, and the same construction in an expression requires, the calling of a function fpi, and then using indirection through dereferencing the (pointer) result to yield an integer. In the declarator (*pif)(const char*, const char*), the extra parentheses are necessary to indicate that indirection through dereferencing a pointer to a function yields a function, which is then called.

  4. Change the index for * and “dereferencing” no longer to refer to “indirection.”

[Drafting note: 26.6.9 [template.indirect.array] requires no change. Many more places in the current wording use “dereferencing” than “indirection.”]



292. Deallocation on exception in new before arguments evaluated

Section: 5.3.4  [expr.new]     Status: review     Submitter: Andrei Iltchenko     Date: 26 Jun 2001

According to the C++ Standard section 5.3.4 [expr.new] paragraph 21 it is unspecified whether the allocation function is called before evaluating the constructor arguments or after evaluating the constructor arguments but before entering the constructor.

On top of that paragraph 17 of the same section insists that

If any part of the object initialization described above [Footnote: This may include evaluating a new-initializer and/or calling a constructor.] terminates by throwing an exception and a suitable deallocation function is found, the deallocation function is called to free the memory in which the object was being constructed... If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed...

Now suppose we have:

  1. An implementation that always evaluates the constructor arguments first (for a new-expression that creates an object of a class type and has a new-initializer) and calls the allocation function afterwards.
  2. A class like this: 
        struct  copy_throw  {
       copy_throw(const copy_throw&)
       {   throw  std::logic_error("Cannot copy!");   }
       copy_throw(long, copy_throw)
       {   }
       copy_throw()
       {   }
    };
  3. And a piece of code that looks like the one below: 
        int  main()
    try  {
       copy_throw   an_object,     /* undefined behaviour */
          * a_pointer = ::new copy_throw(0, an_object);
       return  0;
    }
    catch(const std::logic_error&)
    {   }

Here the new-expression '::new copy_throw(0, an_object)' throws an exception when evaluating the constructor's arguments and before the allocation function is called. However, 5.3.4 [expr.new] paragraph 17 prescribes that in such a case the implementation shall call the deallocation function to free the memory in which the object was being constructed, given that a matching deallocation function can be found.

So a call to the Standard library deallocation function '::operator delete(void*)' shall be issued, but what argument is an implementation supposed to supply to the deallocation function? As per 5.3.4 [expr.new] paragraph 17 - the argument is the address of the memory in which the object was being constructed. Given that no memory has yet been allocated for the object, this will qualify as using an invalid pointer value, which is undefined behaviour by virtue of 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 4.

Suggested resolution:

Change the first sentence of 5.3.4 [expr.new] paragraph 17 to read:

If the memory for the object being created has already been successfully allocated and any part of the object initialization described above...

Proposed resolution (March, 2008):

Change 5.3.4 [expr.new] paragraph 18 as follows:

If any part of the object initialization described above [Footnote: ...] terminates by throwing an exception, storage has been obtained for the object, and a suitable deallocation function can be found, the deallocation function is called...


236. Explicit temporaries and integral constant expressions

Section: 5.19  [expr.const]     Status: review     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 5.2.3 [expr.type.conv] (at least, it's described in a section entitled "Explicit type conversion") and type conversions to integral types are permitted in integral constant expressions (5.19 [expr.const]). However, this reasoning is somewhat tenuous, and some at least have argued otherwise.

Note (March, 2008):

This issue should be closed as NAD as a result of the rewrite of 5.19 [expr.const] in conjunction with the constexpr proposal.



539. Constraints on type-specifier-seq

Section: 7.1.6  [dcl.type]     Status: review     Submitter: Mike Miller     Date: 5 October 2005

The constraints on type-specifiers given in 7.1.6 [dcl.type] paragraphs 2 and 3 (at most one type-specifier except as specified, at least one type-specifier, no redundant cv-qualifiers) are couched in terms of decl-specifier-seqs and declarations. However, they should also apply to constructs that are not syntactically declarations and that are defined to use type-specifier-seqs, including 5.3.4 [expr.new], 6.6 [stmt.jump], 8.1 [dcl.name], and 12.3.2 [class.conv.fct].

Proposed resolution (March, 2008):

Change 7.1.6 [dcl.type] paragraph 3 as follows:

At In a complete type-specifier-seq or in a complete decl-specifier-seq of a declaration, at least one type-specifier that is not a cv-qualifier is required in a declaration shall appear unless it the declaration declares a constructor, destructor or conversion function.

(Note: paper N2546, voted into the Working Draft in February, 2008, addresses part of this issue.)



1022. Can an enumeration variable have values outside the values of the enumeration?

Section: 7.2  [dcl.enum]     Status: review     Submitter: Jason Merrill     Date: 2010-01-22

N3092 comment US 31

According to 7.2 [dcl.enum] paragraph 10,

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

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

Proposed resolution (August, 2010):

  1. Change 5.2.9 [expr.static.cast] paragraph 10 as follows:

    2. A value of integral or enumeration type can be explicitly converted to an enumeration type. The value is unchanged if the original value is within the range of the enumeration values (7.2 [dcl.enum]). Otherwise, the resulting enumeration value is unspecified (and might not be in that range).

  2. Change 7.2 [dcl.enum] paragraph 10 as follows:

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

  3. Change 7.2 [dcl.enum] paragraph 7 as follows:

    4. ...If the enumerator-list is empty, the values of the enumeration are as if the enumeration had a single enumerator with value 0. [Footnote: This set of values is used to define promotion and conversion semantics for the enumeration type; it does not exclude an expression of enumeration type from having a value that falls outside this range. —end footnote]


482. Qualified declarators in redeclarations

Section: 8.3  [dcl.meaning]     Status: review     Submitter: Daveed Vandevoorde     Date: 03 Nov 2004

According to 8.3 [dcl.meaning] paragraph 1,

A declarator-id shall not be qualified except for the definition of a member function (9.3 [class.mfct]) or static data member (9.4 [class.static]) outside of its class, the definition or explicit instantiation of a function or variable member of a namespace outside of its namespace, or the definition of a previously declared explicit specialization outside of its namespace, or the declaration of a friend function that is a member of another class or namespace (11.4 [class.friend]). When the declarator-id is qualified, the declaration shall refer to a previously declared member of the class or namespace to which the qualifier refers...

This restriction prohibits examples like the following:

    void f();
    void ::f();        // error: qualified declarator

    namespace N {
      void f();
      void N::f() { }  // error: qualified declarator
    }

There doesn't seem to be any good reason for disallowing such declarations, and a number of implementations accept them in spite of the Standard's prohibition. Should the Standard be changed to allow them?

Notes from the April, 2006 meeting:

In discussing issue 548, the CWG agreed that the prohibition of qualified declarators inside their namespace should be removed.

Proposed resolution (October, 2006):

Remove the indicated words from 8.3 [dcl.meaning] paragraph 1:

...An unqualified-id occurring in a declarator-id shall be a simple identifier except for the declaration of some special functions (12.3 [class.conv], 12.4 [class.dtor], 13.5 [over.oper]) and for the declaration of template specializations or partial specializations (). A declarator-id shall not be qualified except for the definition of a member function (9.3 [class.mfct]) or static data member (9.4 [class.static]) outside of its class, the definition or explicit instantiation of a function or variable member of a namespace outside of its namespace, or the definition of a previously declared explicit specialization outside of its namespace, or the declaration of a friend function that is a member of another class or namespace (11.4 [class.friend]). When the 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...

[Drafting note: The omission of “outside of its class” here does not give permission for redeclaration of class members; that is still prohibited by 9.2 [class.mem] paragraph 1. The removal of the enumeration of the kinds of declarations in which a qualified-id can appear does allow a typedef declaration to use a qualified-id, which was not permitted before; if that is undesirable, the prohibition can be reinstated here.]



547. Partial specialization on member function types

Section: 8.3.5  [dcl.fct]     Status: review     Submitter: Peter Dimov     Date: 04 November 2005

The following example appears to be well-formed, with the partial specialization matching the type of Y::f(), even though it is rejected by many compilers:

    template<class T> struct X;

    template<class R> struct X< R() > {
    };

    template<class F, class T> void test(F T::* pmf) {
        X<F> x;
    }

    struct Y {
        void f() {
        }
    };

    int main() {
        test( &Y::f );
    }

However, 8.3.5 [dcl.fct] paragraph 4 says,

A cv-qualifier-seq shall only be part of the function type for a non-static member function, the function type to which a pointer to member refers, or the top-level function type of a function typedef declaration. The effect of a cv-qualifier-seq in a function declarator is not the same as adding cv-qualification on top of the function type. In the latter case, the cv-qualifiers are ignored.

This specification makes it impossible to write a partial specialization for a const member function:

    template<class R> struct X<R() const> {
    };

A template argument is not one of the permitted contexts for cv-qualification of a function type. This restriction should be removed.

Notes from the April, 2006 meeting:

During the meeting the CWG was of the opinion that the “R() const” specialization would not match the const member function even if it were allowed and so classified the issue as NAD. Questions have been raised since the meeting, however, suggesting that the template argument in the partial specialization would, in fact, match the type of a const member function (see, for example, the very similar usage via typedefs in 9.3 [class.mfct] paragraph 9). The issue is thus being left open for renewed discussion at the next meeting.

Proposed resolution (June, 2008):

Change 8.3.5 [dcl.fct] paragraph 7 as follows:

A cv-qualifier-seq shall only be part of the function type for a non-static member function, the function type to which a pointer to member refers, or the top-level function type of a function typedef declaration, or the top-level function type of a type-id that is a template-argument for a type template-parameter. The effect... A ref-qualifier shall only be part of the function type for a non-static member function, the function type to which a pointer to member refers, or the top-level function type of a function typedef declaration, or the top-level function type of a type-id that is a template-argument for a type template-parameter. The return type...


512. Union members with user-declared non-default constructors

Section: 9.5  [class.union]     Status: review     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 9.5 [class.union] paragraph 1 only mention default and copy constructors:

An object of a class with a non-trivial default constructor (12.1 [class.ctor]), a non-trivial copy constructor (12.8 [class.copy]), a non-trivial destructor (12.4 [class.dtor]), or a non-trivial copy assignment operator (13.5.3 [over.ass], 12.8 [class.copy]) cannot be a member of a union...

(12.1 [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, 12.2 [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.



462. Lifetime of temporaries bound to comma expressions

Section: 12.2  [class.temporary]     Status: review     Submitter: Steve Adamczyk     Date: April 2004

Split off from issue 86.

Should binding a reference to the result of a "," operation whose second operand is a temporary extend the lifetime of the temporary?

  const SFileName &C = ( f(), SFileName("abc") );

Notes from the March 2004 meeting:

We think the temporary should be extended.

Proposed resolution (October, 2004):

Change 12.2 [class.temporary] paragraph 2 as indicated:

... In all these cases, the temporaries created during the evaluation of the expression initializing the reference, except the temporary that is the overall result of the expression [Footnote: For example, if the expression is a comma expression (5.18 [expr.comma]) and the value of its second operand is a temporary, the reference is bound to that temporary.] and to which the reference is bound, are destroyed at the end of the full-expression in which they are created and in the reverse order of the completion of their construction...

[Note: this wording partially resolves issue 86. See also issue 446.]

Notes from the April, 2005 meeting:

The CWG suggested a different approach from the 10/2004 resolution, leaving 12.2 [class.temporary] unchanged and adding normative wording to 5.18 [expr.comma] specifying that, if the result of the second operand is a temporary, that temporary is the result of the comma expression as well.

Proposed Resolution (November, 2006):

Add the indicated wording to 5.18 [expr.comma] paragraph 1:

... The type and value of the result are the type and value of the right operand; the result is an lvalue if its right operand is an lvalue, and is a bit-field if its right operand is an lvalue and a bit-field. If the value of the right operand is a temporary (12.2 [class.temporary]), the result is that temporary.


395. Conversion operator template syntax

Section: 12.3.2  [class.conv.fct]     Status: review     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 12.3.2 [class.conv.fct] paragraph 1 actually prohibits this. The issue here is that we do in fact specify (part of) a return type.

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.



111. Copy constructors and cv-qualifiers

Section: 12.8  [class.copy]     Status: review     Submitter: Jack Rouse     Date: 4 May 1999

Jack Rouse: In 12.8 [class.copy] paragraph 8, the standard includes the following about the copying of class subobjects in such a constructor:

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 12.8 [class.copy] paragraph 7, which lists the situations in which an implicitly-defined copy constructor can render a program ill-formed. Inaccessible and ambiguous copy constructors are listed, but not a copy constructor with a cv-qualification mismatch. These two paragraphs taken together could be read as requiring the calling of a copy constructor with a non-const reference parameter for a const data member.

Proposed Resolution (November, 2006):

This issue is resolved by the proposed resolution for issue 535.



535. Copy construction without a copy constructor

Section: 12.8  [class.copy]     Status: review     Submitter: Mike Miller     Date: 7 October 2005

Footnote 112 (12.8 [class.copy] paragraph 2) says,

Because a template constructor is never a copy constructor, the presence of such a template does not suppress the implicit declaration of a copy constructor. Template constructors participate in overload resolution with other constructors, including copy constructors, and a template constructor may be used to copy an object if it provides a better match than other constructors.

However, many of the stipulations about copy construction are phrased to refer only to “copy constructors.” For example, 12.8 [class.copy] paragraph 14 says,

A program is ill-formed if the copy constructor... for an object is implicitly used and the special member function is not accessible (clause 11 [class.access]).

Does that mean that using an inaccessible template constructor to copy an object is permissible, because it is not a “copy constructor?” Obviously not, but each use of the term “copy constructor” in the Standard should be examined to determine if it applies strictly to copy constructors or to any constructor used for copying. (A similar issue applies to “copy assignment operators,” which have the same relationship to assignment operator function templates.)

Proposed Resolution (February, 2008):

  1. Change 3.2 [basic.def.odr] paragraph 2 as follows:

    2. ... [Note: this covers calls to named functions (5.2.2 [expr.call]), operator overloading (clause 13 [over]), user-defined conversions (12.3.2 [class.conv.fct]), allocation function for placement new (5.3.4 [expr.new]), as well as non-default initialization (8.5 [dcl.init]). A copy constructor selected to copy class objects is used even if the call is actually elided by the implementation (12.8 [class.copy]). —end note] ... A copy-assignment function for a class An assignment operator function in a class is used by an implicitly-defined copy-assignment function for another class as specified in 12.8 [class.copy]...

  2. Delete 12.1 [class.ctor] paragraphs 10 and 11:

    3. A copy constructor (12.8 [class.copy]) is used to copy objects of class type.

    A union member shall not be of a class type (or array thereof) that has a non-trivial constructor.

  3. Replace the “example” in 12.2 [class.temporary] paragraph 1 with a note as follows:

    4. [Example: even if the copy constructor is not called, all the semantic restrictions, such as accessibility (clause 11 [class.access]), shall be satisfied. —end example] [Note: This includes accessibility (clause 11 [class.access]) for the constructor selected. —end note]

  4. Change 12.8 [class.copy] paragraph 7 as follows:

    5. A non-user-provided copy constructor is implicitly defined if it is used to initialize an object of its class type from a copy of an object of its class type or of a class type derived from its class type (3.2 [basic.def.odr]). [Footnote: See 8.5 [dcl.init] for more details on direct and copy initialization. —end footnote] [Note: the copy constructor is implicitly defined even if the implementation elided its use (12.2 [class.temporary]) the copy operation (12.8 [class.copy]). —end note] A program is ill-formed if the class for which a copy constructor is implicitly defined or explicitly defaulted has:

    • a non-static data member of class type (or array thereof) with an inaccessible or ambiguous copy constructor, or

    • a base class with an inaccessible or ambiguous copy constructor.

    Before the non-user-provided copy constructor for a class is implicitly defined...

  5. Change 12.8 [class.copy] paragraph 8 as follows:

    6. ...Each subobject is copied in the manner appropriate to its type:

    [Drafting note: 8.5 [dcl.init] paragraph 15 requires “unambiguous” and 13.3 [over.match] paragraph 3 requires “accessible,” thus no need for normative text here.]

  6. Change 12.8 [class.copy] paragraph 12 as follows:

    7. A non-user-provided copy assignment operator is implicitly defined when an object of its class type is assigned a value of its class type or a value of a class type derived from its class type it is used (3.2 [basic.def.odr]). A program is ill-formed if the class for which a copy assignment operator is implicitly defined or explicitly defaulted has: a non-static data member of const or reference type.

    • a non-static data member of const type, or

    • a non-static data member of reference type, or

    • a non-static data member of class type (or array thereof) with an inaccessible copy assignment operator, or

    • a base class with an inaccessible copy assignment operator.

  7. Change 12.8 [class.copy] paragraph 13 as follows:

    8. ... Each subobject is assigned in the manner appropriate to its type:

  8. Delete 12.8 [class.copy] paragraph 14:

    9. A program is ill-formed if the copy constructor or the copy assignment operator for an object is implicitly used and the special member function is not accessible (clause 11 [class.access]). [Note: Copying one object into another using the copy constructor or the copy assignment operator does not change the layout or size of either object. —end note]

  9. Change 12.8 [class.copy] paragraph 15 as follows:

    10. When certain criteria are met, an implementation is allowed to omit the copy construction of a class object, even if the copy constructor selected for the copy operation and/or the destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization. [Footnote: Because only one object is destroyed instead of two, and one copy constructor is not executed, there is still one object destroyed for each one constructed. —end footnote] This elision...

  10. Change 13.3.3.1.2 [over.ics.user] paragraph 4 as follows:

    11. A conversion of an expression of class type to the same class type is given Exact Match rank, and a conversion of an expression of class type to a base class of that type is given Conversion rank, in spite of the fact that a copy constructor (i.e., a user-defined conversion function) is called for those cases.

  11. Change 15.1 [except.throw] paragraph 3 as follows:

    12. A throw-expression initializes a temporary object, called the exception object, the type of which by copy-initialization (8.5 [dcl.init]). The type of that temporary object is determined...

  12. Change 15.1 [except.throw] paragraph 5 as follows:

    13. When the thrown object is a class object, the copy constructor selected for the copy-initialization and the destructor shall be accessible, even if the copy operation is elided (12.8 [class.copy]).

  13. Change 15.3 [except.handle] paragraphs 16-17 as follows:

    14. When the exception-declaration specifies a class type, a copy constructor copy-initialization (8.5 [dcl.init]) is used to initialize either the object declared in the exception-declaration or, if the exception-declaration does not specify a name, a temporary object of that type. The object shall not have an abstract class type. The object is destroyed when the handler exits, after the destruction of any automatic objects initialized within the handler. The copy constructor selected for the copy-initialization and the destructor shall be accessible in the context of the handler, even if the copy operation is elided (12.8 [class.copy]). If the copy constructor and destructor are implicitly declared (12.8 [class.copy]), such a use in the handler causes these functions to be implicitly defined; otherwise, the program shall provide a definition for these functions.

    The copy constructor and destructor associated with the object shall be accessible even if the copy operation is elided (12.8 [class.copy]).

  14. Change the footnote in 15.5.1 [except.terminate] paragraph 1 as follows:

    15. [Footnote: For example, if the object being thrown is of a class with a copy constructor type, std::terminate() will be called if that copy constructor the constructor selected to copy the object exits with an exception during a throw. —end footnote]

(This resolution also resolves issue 111.)

[Drafting note: The following do not require changes: 5.17 [expr.ass] paragraph 4; 9 [class] paragraph 5; 9.5 [class.union] paragraph 1; 12.2 [class.temporary] paragraph 2; 12.8 [class.copy] paragraphs 1-2; 15.4 [except.spec] paragraph 14.]

Notes from February, 2008 meeting:

These changes overlap those that will be made when concepts are added. This issue will be maintained in “review” status until the concepts proposal is adopted and any conflicts will be resolved at that point.



1151. Overload resolution with initializer-list and non-list constructors

Section: 13.3.1.7  [over.match.list]     Status: review     Submitter: US     Date: 2010-08-03

N3092 comment US 66

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

Proposed resolution (August, 2010):

  1. Change 8.5.4 [dcl.init.list] paragraph 3 bullet 5 as follows:

  2. Change 13.3.1.7 [over.match.list] as follows:

    3. When objects of non-aggregate class type T are list-initialized (8.5.4 [dcl.init.list]), overload resolution selects the constructor in two phases as follows, where T is the cv-unqualified class type of the object being initialized:



1079. Overload resolution involving aggregate initialization

Section: 13.3.3.2  [over.ics.rank]     Status: review     Submitter: Jason Merrill     Date: 2010-06-15

The current wording makes some calls involving aggregate initialization ambiguous that should not be. For example, the calls below to f and g should each prefer the second overload:

    struct A { int i; };

    void f (const A &);
    void f (A &&);

    void g (A, double);
    void g (A, int);

    int main() {
       f ( { 1 } );
       g ( { 1 }, 1 );
    }

Proposed resolution (August, 2010):

Change 13.3.3.2 [over.ics.rank] paragraph 3 bullet 2 as follows:



531. Defining members of explicit specializations

Section: 14.7.3  [temp.expl.spec]     Status: review     Submitter: Mike Miller     Date: 1 October 2005

The Standard does not fully describe the syntax to be used when a member of an explicitly-specialized member class or member class template is defined in namespace scope. 14.7.3 [temp.expl.spec] paragraph 4 says that the “explicit specialization syntax” (presumably referring to “template<>”) is not used in defining a member of an explicit specialization when a class template is explicitly specialized as a class. However, nothing is said anywhere about how to define a member of a specialization when:

  1. the entity being specialized is a class (member of a template class) rather than a class template.

  2. the result of the specialization is a class template rather than a class (cf 14.7.3 [temp.expl.spec] paragraph 18, which describes this case as a “member template that... remain[s] unspecialized”).

(See paper J16/05-0148 = WG21 N1888 for further details, including a survey of existing implementation practice.)

Notes from the October, 2005 meeting:

The CWG felt that the best approach, balancing consistency with implementation issues and existing practice, would be to require that template<> be used when defining members of all explicit specializations, including those currently covered by 14.7.3 [temp.expl.spec] paragraph 4.

Proposed resolution (February, 2010):

Change 14.7.3 [temp.expl.spec] paragraph 5 as follows:

...The definition of an explicitly specialized class is unrelated to the definition of a generated specialization. That is, its members need not have the same names, types, etc. as the members of a generated specialization. Definitions of members of an explicitly specialized class are defined in the same manner as members of normal classes, and not using the syntax for explicit specialization using the same template<> prefix(es) as the explicitly specialized class. [Example:

    template<class T> struct A {
      void f(T) { /* ... */ }
      struct B { /* ... */ };
      template<class U> struct C { /* ... */ };
    };
    template<> struct A<int> {
      void f(int);
      struct B;
      template<class U> struct C;
    };
    void h() {
      A<int> a;
      a.f(16); // A<int>::f must be defined somewhere
    }
    // explicit specialization syntax not used for a member of
    // explicitly specialized class template specialization
    // members of explicitly specialized classes are defined using
    //the same syntax as the explicitly specialized class:
    template<> void A<int>::f(int) { /* ... */ }
    template<> struct A<int>::B { /* ... */ };
    template<> template<class T> struct A<int>::C { /* ... */ };

—end example]

Note (June, 2010):

Because the survey of implementations on which the CWG relied in reaching this resolution is quite old, a new survey of current practice is needed.



388. Catching base*& from a throw of derived*

Section: 15.3  [except.handle]     Status: review     Submitter: John Spicer     Date: 28 Oct 2002

I have a question about exception handling with respect to derived to base conversions of pointers caught by reference.

What should the result of this program be?

  struct S             {};
  struct SS : public S {};

  int main()
  {
  	SS ss;
  	int result = 0;
  	try
  	{
  		throw &ss; // throw object has type SS*
  		           // (pointer to derived class)
  	}
  	catch (S*& rs) // (reference to pointer to base class)
  	{
  		result = 1;
  	}
  	catch (...)
  	{
  		result = 2;
  	}
  	return result;
  }

The wording of 15.3 [except.handle] paragraph 3 would seem to say that the catch of S*& does not match and so the catch ... would be taken.

All of the compilers I tried (EDG, g++, Sun, and Microsoft) used the catch of S*& though.

What do we think is the desired behavior for such cases?

My initial reaction is that this is a bug in all of these compilers, but the fact that they all do the same thing gives me pause.

On a related front, if the handler changes the parameter using the reference, what is caught by a subsequent handler?

  extern "C" int printf(const char *, ...);
  struct S             {};
  struct SS : public S {};
  SS ss;

  int f()
  {
  	try
  	{
  		throw &ss;
  	}
  	catch (S*& rs) // (reference to pointer to base class)
  	{
  		rs = 0;
  		throw;
  	}
  	catch (...)
  	{
  	}
  	return 0;
  }

  int main()
  {
  	try { f(); }
  	catch (S*& rs) {
  		printf("rs=%p, &ss=%p\n", rs, &ss);
  	}
  }

EDG, g++, and Sun all catch the original (unmodified) value. Microsoft catches the modified value. In some sense the EDG/g++/Sun behavior makes sense because the later catch could catch the derived class instead of the base class, which would be difficult to do if you let the catch clause update the value to be used by a subsequent catch.

But on this non-pointer case, all of the compilers later catch the modified value:

  extern "C" int printf(const char *, ...);
  int f()
  {
  	try
  	{
  		throw 1;
  	}
  	catch (int& i)
  	{
  		i = 0;
  		throw;
  	}
  	catch (...)
  	{
  	}
  	return 0;
  }

  int main()
  {
  	try { f(); }
  	catch (int& i) {
  		printf("i=%p\n", i);
  	}
  }

To summarize:

  1. Should "base*const&" be able to catch a "derived*"? The current standard seems to say "no" but parallels to how calls work, and existing practice, suggest that the answer should be "yes".
  2. Should "base*&" be able to catch a "derived*". Again, the standard seems seems to say "no". Parallels to how calls work still suggest "no", but existing practice suggests "yes".
  3. If either of the above is "yes", what happens if you modify the pointer referred to by the reference. This requires a cast to remove const for case #2.
  4. On a related front, if you catch "derived*&" when a "derived*" is thrown, what happens if you modify the pointer referred to by the reference? EDG/g++/Sun still don't modify the underlying value that would be caught by a rethrow in this case. This case seems like it should be the same as the "int&" example above, but is not on the three compilers mentioned.

(See also issue 729.)

Notes from the October, 2009 meeting:

The consensus of the CWG was that it should not be possible to catch a pointer to a derived class using a reference to a base class pointer, and that a handler that takes a reference to non-const pointer should allow the pointer to be modified by the handler.

Proposed resolution (February, 2010):

Change 15.3 [except.handle] paragraph 3 as follows:

A handler is a match for an exception object of type E if

(This resolution also resolves issue 729.)



729. Qualification conversions and handlers of reference-to-pointer type

Section: 15.3  [except.handle]     Status: review     Submitter: John Spicer     Date: 6 October, 2008

Given the following example:

    int f() {
        try { /* ... */ }
        catch(const int*&) {
            return 1;
        }
        catch(int*&) {
            return 2;
        }
        return 3;
    }

can f() return 2? That is, does an int* exception object match a const int*& handler?

According to 15.3 [except.handle] paragraph 3, it does not:

A handler is a match for an exception object of type E if

Only the third bullet allows qualification conversions, but only the first bullet applies to a handler of reference-to-pointer type. This is consistent with how other reference bindings work; for example, the following is ill-formed:

    int* p;
    const int*& r = p;

(The consistency is not complete; the reference binding would be permitted if r had type const int* const &, but a handler of that type would still not match an int* exception object.)

However, implementation practice seems to be in the other direction; both EDG and g++ do match an int* with a const int*&, and the Microsoft compiler issues an error for the presumed hidden handler in the code above. Should the Standard be changed to reflect existing practice?

(See also issue 388.)

Notes from the October, 2009 meeting:

The CWG agreed that matching the exception object with a handler should, to the extent possible, mimic ordinary reference binding in cases like this.

Proposed resolution (February, 2010):

This issue is resolved by the resolution of issue 388.





Issues with "Drafting" Status

1102. Better example of undefined behavior

Section: 1.9  [intro.execution]     Status: drafting     Submitter: GB     Date: 2010-08-02

N3092 comment GB 6

There are core issues surrounding the undefined behavior of dereferencing a null pointer. It appears the intent is that dereferencing is well defined, but using the result of the dereference will yield undefined behavior. This topic is too confused to be the reference example of undefined behavior, or should be stated more precisely if it is to be retained.

(See also issue 232.)



369. Are new/delete identifiers or preprocessing-op-or-punc?

Section: 2.5  [lex.pptoken]     Status: drafting     Submitter: Martin v. Loewis     Date: 30 July 2002

2.5 [lex.pptoken] paragraph 2 specifies that there are 5 categories of tokens in phases 3 to 6. With 2.13 [lex.operators] paragraph 1, it is unclear whether new is an identifier or a preprocessing-op-or-punc; likewise for delete. This is relevant to answer the question whether

#define delete foo

is a well-formed control-line, since that requires an identifier after the define token.

(See also issue 189.)



189. Definition of operator and punctuator

Section: 2.13  [lex.operators]     Status: drafting     Submitter: Mike Miller     Date: 20 Dec 1999

The nonterminals operator and punctuator in 2.7 [lex.token] are not defined. There is a definition of the nonterminal operator in 13.5 [over.oper] paragraph 1, but it is apparent that the two nonterminals are not the same: the latter includes keywords and multi-token operators and does not include the nonoverloadable operators mentioned in paragraph 3.

There is a definition of preprocessing-op-or-punc in 2.13 [lex.operators] , with the notation that

Each preprocessing-op-or-punc is converted to a single token in translation phase 7 (2.1).
However, this list doesn't distinguish between operators and punctuators, it includes digraphs and keywords (can a given token be both a keyword and an operator at the same time?), etc.

Suggested resolution:


  1. Change 13.5 [over.oper] to use the term overloadable-operator.
  2. Change 2.7 [lex.token] to use the term operator-token instead of operator (since there are operators that are keywords and operators that are composed of more than one token).
  3. Change 2.13 [lex.operators] to define the nonterminals operator-token and punctuator.

Additional note (April, 2005):

The resolution for this problem should also address the fact that sizeof and typeid (and potentially others like decltype that may be added in the future) are described in some places as “operators” but are not listed in 13.5 [over.oper] paragraph 3 among the operators that cannot be overloaded.

(See also issue 369.)



1106. Need more detail in nullptr keyword description

Section: 2.14.7  [lex.nullptr]     Status: drafting     Submitter: DE     Date: 2010-08-02

N3092 comment DE 3

It is not sufficiently clear that std::nullptr_t is a distinct type and neither a pointer type nor a pointer-to-member type. Add a note in 2.14.7 [lex.nullptr] stating that, preferably with cross-references to the normative statements in 3.9 [basic.types].



1109. When is “use” a reference to the ODR meaning?

Section: 3.2  [basic.def.odr]     Status: drafting     Submitter: US     Date: 2010-08-02

N3092 comment US 19

It is not always clear when an occurrence of the word “use” is intended as an implicit reference to 3.2 [basic.def.odr] and when it is simply the ordinary English meaning. This could be addressed by:

  1. Replacing all the non-technical appearances of the word “use” with synonyms such as “occurrence” or “appearance” or “reference to.”

  2. Following each occurrence of the word “use” that is intended in the technical sense with a cross-reference to 3.2 [basic.def.odr].

  3. Replacing all the technical occurrences of the word “use” with a different word or phrase, such as “odr-use,” that would unambiguously indicate the intent.



225. Koenig lookup and fundamental types

Section: 3.4.2  [basic.lookup.argdep]     Status: drafting     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.



156. Name lookup for conversion functions

Section: 3.4.5  [basic.lookup.classref]     Status: drafting     Submitter: Derek Inglis     Date: 18 Aug 1999

Paragraph 7 of 3.4.5 [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 3.4.3.1 [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 3.4.3.1 [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 3 [basic] paragraph 7 and 12.3 [class.conv] paragraph 5). (This is true even for types that must be written using typedefs because of the limited syntax in 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.



682. Missing description of lookup of template aliases

Section: 3.4.5  [basic.lookup.classref]     Status: drafting     Submitter: Daveed Vandevoorde     Date: 1 March, 2008

3.4.5 [basic.lookup.classref] does not mention template aliases as the possible result of the lookup but should do so.



1089. Template parameters in member selections

Section: 3.4.5  [basic.lookup.classref]     Status: drafting     Submitter: Daveed Vandevoorde     Date: 2010-06-29

In an example like

    template<typename T> void f(T p)->decltype(p.T::x);

The nested-name-specifier T:: looks like it refers to the template parameter. However, if this is instantiated with a type like

    struct T { int x; };
    struct S: T { };

the reference will be ambiguous, since it is looked up in both the context of the expression, finding the template parameter, and in the class, finding the base class injected-class-name, and this could be a deduction failure. As a result, the same declaration with a different parameter name

    template<typename U> void f(U p)->decltype(p.U::x);

is, in fact, not a redeclaration because the two can be distinguished by SFINAE.

It would be better to add a new lookup rule that says that if a name in a template definition resolves to a template parameter, that name is not subject to further lookup at instantiation time.



1111. Remove dual-scope lookup of member template names

Section: 3.4.5  [basic.lookup.classref]     Status: drafting     Submitter: US     Date: 2010-08-02

N3092 comment US 23

According to 3.4.5 [basic.lookup.classref] paragraph 1,

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

This makes the following ill-formed:

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

That's confusing and unnecessary. The compiler has already done the lookup in X's scope, and the obviously-correct resolution is that one, not the identifier from the postfix-expression's scope. Issue 305 fixed a similar issue for destructor names but missed member functions.

Suggested resolution: Delete the end of paragraph 1, starting with “If the lookup in the class...” and including all three bullets.



426. Identically-named variables, one internally and one externally linked, allowed?

Section: 3.5  [basic.link]     Status: drafting     Submitter: Steve Adamczyk     Date: 2 July 2003

An example in 3.5 [basic.link] paragraph 6 creates two file-scope variables with the same name, one with internal linkage and one with external.

  static void f();
  static int i = 0;                       //1
  void g() {
          extern void f();                // internal linkage
          int i;                          //2: i has no linkage
          {
                  extern void f();        // internal linkage
                  extern int i;           //3: external linkage
          }
  }

Is this really what we want? C99 has 6.2.2.7/7, which gives undefined behavior for having an identifier appear with internal and external linkage in the same translation unit. C++ doesn't seem to have an equivalent.

Notes from October 2003 meeting:

We agree that this is an error. We propose to leave the example but change the comment to indicate that line //3 has undefined behavior, and elsewhere add a normative rule giving such a case undefined behavior.

Proposed resolution (October, 2005):

Change 3.5 [basic.link] paragraph 6 as indicated:

...Otherwise, if no matching entity is found, the block scope entity receives external linkage. If, within a translation unit, the same entity is declared with both internal and external linkage, the behavior is undefined.

[Example:

    static void f();
    static int i = 0;            // 1
    void g () {
        extern void f ();        // internal linkage
        int i;                   // 2: i has no linkage
        {
            extern void f ();    // internal linkage
            extern int i;        // 3: external linkage
        }
    }

There are three objects named i in this program. The object with internal linkage introduced by the declaration in global scope (line //1 ), the object with automatic storage duration and no linkage introduced by the declaration on line //2, and the object with static storage duration and external linkage introduced by the declaration on line //3. Without the declaration at line //2, the declaration at line //3 would link with the declaration at line //1. But because the declaration with internal linkage is hidden, //3 is given external linkage, resulting in a linkage conflict. —end example]

Notes frum the April 2006 meeting:

According to 3.5 [basic.link] paragraph 9, the two variables with linkage in the proposed example are not “the same entity” because they do not have the same linkage. Some other formulation will be needed to describe the relationship between those two variables.

Notes from the October 2006 meeting:

The CWG decided that it would be better to make a program with this kind of linkage mismatch ill-formed instead of having undefined behavior.



981. Constexpr constructor templates and literal types

Section: 3.9  [basic.types]     Status: drafting     Submitter: Gabriel Dos Reis     Date: 16 October, 2009

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

    struct IntValue {
      template<typename T>
        constexpr IntValue(T t) : val(t) { }

      constexpr intmax_t get_value() { return val; }
     
     private:
       intmax_t val;
    };

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

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



1071. Literal class types and trivial default constructors

Section: 3.9  [basic.types]     Status: drafting     Submitter: Daniel Krügler     Date: 2010-06-02

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

This rule has unfortunate consequences. For example, in

    struct A { int x; };
    struct B: A { int y; };

B is a literal type, even though it is impossible to initialize a constant of that type. Conversely, in

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

D is not a literal type, even though it could be initialized as an aggregate.

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



1055. Permissible uses of void

Section: 3.9.1  [basic.fundamental]     Status: drafting     Submitter: Nikolay Ivchenkov     Date: 2010-03-17

According to 3.9.1 [basic.fundamental] paragraph 9,

Any expression can be explicitly converted to type cv void (5.4 [expr.cast]). An expression of type void shall be used only as an expression statement (6.2 [stmt.expr]), as an operand of a comma expression (5.18 [expr.comma]), as a second or third operand of ?: (5.16 [expr.cond]), as the operand of typeid, or as the expression in a return statement (6.6.3 [stmt.return]) for a function with the return type void.

First, this is self-contradictory: if “any expression” can be converted to void, why is such a conversion not listed among the acceptable uses of an expression of type void?

Second, presumably an expression of type void can be used as an operand of decltype, but this use is not listed.

Finally, there are several places in the Standard that speak of expressions having a cv-qualified void type (5.16 [expr.cond] paragraph 2, 6.6.3 [stmt.return] paragraph 3). However, an expression of type void is a non-class prvalue, and there are no cv-qualified non-class prvalues (3.10 [basic.lval] paragraph 4).



1059. Cv-qualified array types (with rvalues)

Section: 3.9.3  [basic.type.qualifier]     Status: drafting     Submitter: Nikolay Ivchenkov     Date: 2010-03-20

In spite of the resolution of issue 112, the exact relationship between cv-qualifiers and array types is not clear. There does not appear to be a definitive normative statement answering the question of whether an array with a const-qualified element type is itself const-qualified; the statement in 3.9.3 [basic.type.qualifier] paragraph 5,

Cv-qualifiers applied to an array type attach to the underlying element type, so the notation “cv T,” where T is an array type, refers to an array whose elements are so-qualified. Such array types can be said to be more (or less) cv-qualified than other types based on the cv-qualification of the underlying element types.

hints at an answer but is hardly decisive. For example, is the following example well-formed?

    template <class T> struct is_const {
        static const bool value = false;
    };
    template <class T> struct is_const<const T> {
        static const bool value = true;
    };

    template <class T> void f(T &) {
        char checker[is_const<T>::value];
    }

    int const arr[1] = {};

    int main() {
        f(arr);
    }

Also, when 3.10 [basic.lval] paragraph 4 says,

Class prvalues can have cv-qualified types; non-class prvalues always have cv-unqualified types.

does this apply to array rvalues, as it appears? That is, given

    struct S {
        const int arr[10];
    };

is the array rvalue S().arr an array of int or an array of const int?

(The more general question is, when the Standard refers to non-class types, should it be considered to include array types? Or perhaps only arrays of non-class types?)



636. Dynamic type of objects and aliasing

Section: 3.10  [basic.lval]     Status: drafting     Submitter: Gabriel Dos Reis     Date: 23 May 2007

The aliasing rules given in 3.10 [basic.lval] paragraph 10 rely on the concept of “dynamic type.” The problem is that the dynamic type of an object often cannot be determined (or even sufficiently constrained) at the point at which an optimizer needs to be able to determine whether aliasing might occur or not. For example, consider the function

    void foo(int* p, double* q) {
        *p = 42;
        *q = 3.14;
    }

An optimizer, on the basis of the existing aliasing rules, might decide that an int* and a double* cannot refer to the same object and reorder the assignments. This reordering, however, could result in undefined behavior if the function foo is called as follows:

   void goo() {
      union {
         int i; 
         double d;
      } t;

      t.i = 12;

      foo(&t.i, &t.d);

      cout << t.d << endl;
   };

Here, the reference to t.d after the call to foo will be valid only if the assignments in foo are executed in the order in which they were written; otherwise, the union will contain an int object rather than a double.

One possibility would be to require that if such aliasing occurs, it be done only via member names and not via pointers.

Notes from the July, 2007 meeting:

This is the same issue as C's DR236. The CWG expressed a desire to address the issue the same way C99 does. The issue also occurs in C++ when placement new is used to end the lifetime of one object and start the lifetime of a different object occupying the same storage.



964. Incorrect description of when the lvalue-to-rvalue conversion applies

Section: 3.10  [basic.lval]     Status: drafting     Submitter: Doug Gregor     Date: 14 September, 2009

3.10 [basic.lval] paragraph 7 says,

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

That is not correct in the context of an attempt to bind an rvalue reference to an lvalue (8.5.3 [dcl.init.ref]).

Proposed resolution (October, 2009):

Change 3.10 [basic.lval] paragraph 7 as follows:

Whenever an lvalue appears in a context where an rvalue is expected and an lvalue is not explicitly prohibited (as, for example, in 8.5.3 [dcl.init.ref]), the lvalue it is converted to an rvalue; see 4.1 [conv.lval], 4.2 [conv.array], and 4.3 [conv.func].

Notes from the March, 2010 meeting:

This resolution needs to be reconsidered in light of the new expression taxonomy.



1090. Alignment of subobjects

Section: 3.11  [basic.align]     Status: drafting     Submitter: Daveed Vandevoorde     Date: 2010-06-23

The current wording of the Standard does not recognize the fact that the alignment of a complete object of a given type may be different from its alignment as a subobject. This arises in particular with virtual base classes. For example,

    struct B { long double d; };
    struct D: virtual B { char c; };

When D is a complete object, it will have a subobject of type B, which must be aligned appropriately for a long double. On the other hand, if D appears as a suboject of another object, the B subobject might be part of a different subobject, reducing the alignment requirement on the D subobject.

The Standard should make clear that it is the complete-object alignment that is being described, in parallel with the distinction between the size of a complete object and a subobject of the same type.



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

Section: 4.1  [conv.lval]     Status: drafting     Submitter: Alan Stokes     Date: 6 February 2007

According to 4.1 [conv.lval] paragraph 1, applying the lvalue-to-rvalue conversion to any uninitialized object results in undefined behavior. However, character types are intended to allow any data, including uninitialized objects and padding, to be copied (hence the statements in 3.9.1 [basic.fundamental] paragraph 1 that “For character types, all bits of the object representation participate in the value representation” and in 3.10 [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.



170. Pointer-to-member conversions

Section: 4.11  [conv.mem]     Status: drafting     Submitter: Mike Stump     Date: 16 Sep 1999

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

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

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

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

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

(See also issue 794.)



1117. Incorrect note about xvalue member access expressions

Section: 5  [expr]     Status: drafting     Submitter: JP     Date: 2010-08-02

N3092 comment JP 1

One of the bullets in the note in 5 [expr] paragraph 6 says that an expression is an xvalue if it is:

This is incorrect if the type of the non-static data member is a reference type (cf 5.2.5 [expr.ref] paragraph 4.)



536. Problems in the description of id-expressions

Section: 5.1.1  [expr.prim.general]     Status: drafting     Submitter: Mike Miller     Date: 13 October 2005

There are at least a couple of problems in the description of the various id-expressions in 5.1.1 [expr.prim.general]:

  1. Paragraph 4 embodies an incorrect assumption about the syntax of qualified-ids:

    The operator :: followed by an identifier, a qualified-id, or an operator-function-id is a primary-expression.

    The problem here is that the :: is actually part of the syntax of qualified-id; consequently, “:: followed by... a qualified-id” could be something like “:: ::i,” which is ill-formed. Presumably this should say something like, “A qualified-id with no nested-name-specifier is a primary-expression.”

  2. More importantly, some kinds of id-expressions are not described by 5.1.1 [expr.prim.general]. The structure of this section is that the result, type, and lvalue-ness are specified for each of the cases it covers:

    This treatment leaves unspecified all the non-identifier unqualified-ids (operator-function-id, conversion-function-id, and template-id), as well as (perhaps) “:: template-id” (it's not clear whether the “:: followed by a qualified-id” case is supposed to apply to template-ids or not). Note also that the proposed resolution of issue 301 slightly exacerbates this problem by removing the form of operator-function-id that contains a tmeplate-argument-list; as a result, references like “::operator+<X>” are no longer covered in 5.1.1 [expr.prim.general].



1034. Attributes for return statements in lambdas

Section: 5.1.2  [expr.prim.lambda]     Status: drafting     Submitter: Daveed Vandevoorde     Date: 2010-02-18

5.1.2 [expr.prim.lambda] paragraph 4 bullet 1 says,

if the compound-statement if [sic] of the form

the type of the returned expression...

The problem (besides the typo “if”) is that the attribute-specifier for a return statement precedes, rather than following, the keyword (6 [stmt.stmt] paragraph 1).



1083. Passing an object to ellipsis with non-trivial move constructor

Section: 5.2.2  [expr.call]     Status: drafting     Submitter: Jason Merrill     Date: 2010-06-22

5.2.2 [expr.call] paragraph 7 should mention a non-trivial move constructor as well, for consistency with “trivially copyable.”



1119. Missing case in description of member access ambiguity

Section: 5.2.5  [expr.ref]     Status: drafting     Submitter: US     Date: 2010-08-02

N3092 comment US 32

According to 5.2.5 [expr.ref] paragraph 5,

If E2 is a non-static data member or a non-static member function, the program is ill-formed if the class of which E2 is directly a member is an ambiguous base (10.2 [class.member.lookup]) of the naming class (11.2 [class.access.base]) of E2.

This does not cover the following case:

    struct A { int i; };
    struct B: A { };
    struct C: A, B { };
    void f(C* p) {
      p->A::i; // Should be ambiguous
    }

Notes (August, 2010):

The example in the FCD National Body comment is incorrect: it is missing the A:: in the next-to-last line.

The ambiguity actually is covered in the Standard but in an unexpected location: 11.2 [class.access.base] paragraph 6:

If a class member access operator, including an implicit “this->,” is used to access a non-static data member or non-static member function, the reference is ill-formed if the left operand (considered as a pointer in the “.” operator case) cannot be implicitly converted to a pointer to the naming class of the right operand.

An explanatory note, including a cross-reference to 11.2 [class.access.base], should be added to 5.2.5 [expr.ref] paragraph 6.



1011. Standard conversions that cannot be inverted

Section: 5.2.9  [expr.static.cast]     Status: drafting     Submitter: John Spicer     Date: 2009-12-03

According to 5.2.9 [expr.static.cast] paragraph 7, static_cast can be used to perform the inverse of any standard conversion sequence except the lvalue-to-rvalue, array-to-pointer, function-to-pointer, and boolean conversions. The null pointer and null pointer-to-member conversions should also be listed — it should not be permitted to cast a pointer or pointer-to-member to either integral type or std::nullptr_t.



573. Conversions between function pointers and void*

Section: 5.2.10  [expr.reinterpret.cast]     Status: drafting     Submitter: Steve Adamczyk     Date: 13 April 2006

The resolution to issue 195 makes “converting a pointer to a function into a pointer to an object type or vice versa” conditionally-supported behavior. In doing so, however, it overlooked the fact that void is not an “object type” (3.9 [basic.types] paragraph 9). The wording should be amended to allow conversion to and from void* types.

Proposed resolution (June, 2008):

  1. Change 3.9.2 [basic.compound] paragraph 4 as follows:

    2. Objects of cv-qualified (3.9.3 [basic.type.qualifier]) or cv-unqualified type void* (pointer to void) A pointer to cv-qualified or cv-unqualified void can be used to point to objects of unknown type. A void* shall be able to hold any object pointer and is thus considered to be an object pointer type, although it is not a pointer to object type (because void is not an object type). A cv-qualified or cv-unqualified (3.9.3 [basic.type.qualifier]) An object of type cv void* shall have the same representation and alignment requirements as a cv-qualified or cv-unqualified cv char*.

  2. Change 4.10 [conv.ptr] paragraph 1 as follows:

    3. ...A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type and is distinguishable from every other value of pointer to object or pointer to function object pointer or function pointer type...

  3. Change 5.2.10 [expr.reinterpret.cast] paragraph 7 as follows:

    4. A pointer to an object An object pointer can be explicitly converted to a pointer to an object an object pointer of different type. Except that converting an rvalue of type “pointer to T1” to the type “pointer to T2” (where T1 and T2 are object types or void and where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value, the result of such a pointer conversion is unspecified.

  4. Change 5.2.10 [expr.reinterpret.cast] paragraph 8 as follows:

    5. Converting a pointer to a function into a pointer to an object type a function pointer to an object pointer or vice versa is conditionally-supported...

[Drafting note: 14.1 [temp.param] paragraph 4 was not changed and thus continues to allow only pointers to objects, not object pointers, as non-type template parameters.]

Proposed resolution (February, 2010):

  1. Change 3.7.4.3 [basic.stc.dynamic.safety] paragraphs 1-2 as follows:

    2. A traceable pointer object is

    A pointer value is a safely-derived pointer to a dynamic object only if it has pointer-to-object object pointer type and...

  2. Change 3.9.2 [basic.compound] paragraphs 3-4 as follows:

    3. The type of a pointer that can hold the address of an object is called an object pointer type. The type of a pointer that can designate a function is called a function pointer type. A pointer to objects of type T is referred to as a “pointer to T.” Example:...

    Objects of cv-qualified (3.9.3 [basic.type.qualifier]) or cv-unqualified type void* (pointer to void), A pointer to cv-qualified or cv-unqualified void can be used to point to objects of unknown type. A void* Such a pointer shall be able to hold any object pointer and is thus considered to be an object pointer and to have an object pointer type (but not a pointer to object type, because void is not an object type). A cv-qualified or cv-unqualified (3.9.3 [basic.type.qualifier]) An object of type cv void* shall have the same representation and alignment requirements as a cv-qualified or cv-unqualified cv char*.

  3. Change 4.10 [conv.ptr] paragraph 1 as follows:

    4. ...A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type and is distinguishable from every other value of pointer to object or pointer to function object pointer or function pointer type...

  4. Change 5.2.10 [expr.reinterpret.cast] paragraphs 6-8 as follows:

    5. A pointer to a function function pointer can be explicitly converted to a pointer to a function of a different function pointer type...

    A pointer to an object An object pointer can be explicitly converted to a pointer to a different object pointer type.69...

    Converting a pointer to a function function pointer into a pointer to an object to an object pointer type or vice versa is conditionally-supported...

  5. In the “Index of Implementation Defined Behavior,” change the following item as indicated:

    6. converting pointer to function into pointer to object function pointer to object pointer and vice versa

(See also issue 1120.)



1086. const_cast to rvalue reference to function type

Section: 5.2.11  [expr.const.cast]     Status: drafting     Submitter: Steve Adamczyk     Date: 2010-06-25

5.2.11 [expr.const.cast] paragraph 1 refers to casting to an rvalue reference to function type. This was an accidental edit in the application of the value categories and should be removed.



232. Is indirection through a null pointer undefined behavior?

Section: 5.3.1  [expr.unary.op]     Status: drafting     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: 1.9 [intro.execution] paragraph 4 gives "dereferencing the null pointer" as an example of undefined behavior, and 8.3.2 [dcl.ref] paragraph 4 (in a note) uses this supposedly undefined behavior as justification for the nonexistence of "null references."

However, 5.3.1 [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: 5.2.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 (4.10 [conv.ptr]), the typeid expression throws the bad_typeid exception (18.7.3 [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 3.10 [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, 4.1 [conv.lval]:

An lvalue (3.10 [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 3.10 [basic.lval] paragraph 2:

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

  2. Add the indicated words to 5.3.1 [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 (4.10 [conv.ptr]) or points one past the last element of an array object (5.7 [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 4.1 [conv.lval].—end note]

  3. Add the indicated words to 4.1 [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 (5.3.1 [expr.unary.op]), a program that necessitates this conversion has undefined behavior.

  4. Change 1.9 [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 3.9.2 [basic.compound] paragraph 3 to the effect that a pointer containing the address one past the end of an array is considered to “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.)



1122. Circular definition of std::size_t

Section: 5.3.3  [expr.sizeof]     Status: drafting     Submitter: GB     Date: 2010-08-02

N3092 comment GB 24

The return type of the sizeof operator is defined as being of type std::size_t, defined in library clause 18.2 [support.types]. This, in turn, says that size_t is defined in the C standard, which in turn says that size_t is defined as the type of the result of the sizeof operator!

The C definition of sizeof returns an implementation-defined unsigned integer type, recommended not to have “an integer conversion rank greater than signed long int, unless the implementation supports objects large enough to make this necessary.”



901. Deleted operator delete

Section: 5.3.4  [expr.new]     Status: drafting     Submitter: John Spicer     Date: 20 May, 2009

It is not clear from 5.3.4 [expr.new] whether a deleted operator delete is referenced by a new-expression in which there is no initialization or in which the initialization cannot throw an exception, rendering the program ill-formed. (The question also arises as to whether such a new-expression constitutes a “use” of the deallocation function in the sense of 3.2 [basic.def.odr].)

Notes from the July, 2009 meeting:

The rationale for defining a deallocation function as deleted would presumably be to prevent such objects from being freed. Treating the new-expression as a use of such a deallocation function would mean that such objects could not be created in the first place. There is already an exemption from freeing an object if “a suitable deallocation function [cannot] be found;” a deleted deallocation function should be treated similarly.



1061. Negative array bounds in a new-expression

Section: 5.3.4  [expr.new]     Status: drafting     Submitter: Sean Hunt     Date: 2010-03-23

Recent changes have added the requirement (5.3.4 [expr.new] paragraph 7),

If the value of that expression is such that the size of the allocated object would exceed the implementation-defined limit, no storage is obtained and the new-expression terminates by throwing an exception of a type that would match a handler (15.3 [except.handle]) of type std::bad_array_new_length (18.6.2.2 [new.badlength]).

Given this checking, is there any current reason for the statement in the preceding paragraph,

If the value of the expression is negative, the behavior is undefined.

Presumably for most negative expressions on most platforms, a negative value would result in a too-large request anyway, and even if not the check could easily be expanded to look explicitly for a negative value in addition to a too-large request.



1037. Requirements for operands of delete-expressions and deallocation functions

Section: 5.3.5  [expr.delete]     Status: drafting     Submitter: Daniel Krügler     Date: 2010-03-01

According to 5.3.5 [expr.delete] paragraph 2,

...in the first alternative (delete object), the value of the operand of delete shall be a pointer to a non-array object or a pointer to a subobject (1.8 [intro.object]) representing a base class of such an object (Clause 10 [class.derived]). If not, the behavior is undefined. In the second alternative (delete array), the value of the operand of delete shall be the pointer value which resulted from a previous array new-expression.79 If not, the behavior is undefined.

The second part of this specification makes it clear that an array object being deleted must have been allocated via new. However, the first part, for the non-array object, completely omits this vital requirement, requiring only that it not be an array.

The corresponding requirement for an argument to a deallocation function is found in 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 3:

...the value supplied to operator delete(void*) in the standard library shall be one of the values returned by a previous invocation of either operator new(std::size_t) or operator new(std::size_t, const std::nothrow_t&) in the standard library, and the value supplied to operator delete[](void*) in the standard library shall be one of the values returned by a previous invocation of either operator new[](std::size_t) or operator new[](std::size_t, const std::nothrow_t&) in the standard library.

This correctly states the required provenance of the pointer, but it does so using “shall,” which is inappropriate for a runtime requirement. This wording should be recast in terms of undefined behavior if the requirement is not met.



1124. Error in description of value category of pointer-to-member expression

Section: 5.5  [expr.mptr.oper]     Status: drafting     Submitter: JP     Date: 2010-08-02

N3092 comment JP 2

According to 5.5 [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 (3.10 [basic.lval]) as its first operand.

This is incorrect if the member has a reference type, in which case the result is an lvalue.



1060. Scoped enumerators in integral constant expressions

Section: 5.19  [expr.const]     Status: drafting     Submitter: Jonathan Caves     Date: 2010-03-21

According to 5.19 [expr.const] paragraph 3,

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

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

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

This seems surprising.



1018. Ambiguity between simple-declaration and attribute-declaration

Section: 7  [dcl.dcl]     Status: drafting     Submitter: Mike Miller     Date: 2010-01-04

The grammar for declarations includes the following two nonterminals:

An attribute-specifier followed by a semicolon could thus be parsed as either an attribute-declaration or as a simple-declaration that omits the optional decl-specifier-seq and init-declarator-list, and the current wording does not disambiguate the two. (There doesn't seem to be a compelling need for attribute-declaration as a separate nonterminal, given that simple-declaration can accommodate that form.)



1042. Attributes in alias-declarations

Section: 7  [dcl.dcl]     Status: drafting     Submitter: Daveed Vandevoorde     Date: 2010-03-04

The grammar for an alias-declaration does not have a place for an attribute-specifier, although a typedef declaration does. Since an alias-declaration is essentially a different syntactic form of a typedef declaration (7.1.3 [dcl.typedef] paragraph 2), this could be surprising.



407. Named class with associated typedef: two names or one?

Section: 7.1.3  [dcl.typedef]     Status: drafting     Submitter: Clark Nelson     Date: 31 March 2003

Here's an example:

  typedef struct S { ... } S;
  void fs(S *x) { ... }

The big question is, to what declaration does the reference to identifier S actually refer? Is it the S that's declared as a typedef name, or the S that's declared as a class name (or in C terms, as a struct tag)? (In either case, there's clearly only one type to which it could refer, since a typedef declaration does not introduce a new type. But the debugger apparently cares about more than just the identity of the type.)

Here's a classical, closely related example:

  struct stat { ... };
  int stat();
  ... stat( ... ) ...

Does the identifier stat refer to the class or the function? Obviously, in C, you can't refer to the struct tag without using the struct keyword, because it is in a different name space, so the reference must be to the function. In C++, the reference is also to the function, but for a completely different reason.

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

The first difference is that, in C++, typedef names and class names are not in separate name spaces. On the other hand, according to section 3.3.10 [basic.scope.hiding] (Name hiding), paragraph 2:

A class name (9.1) or enumeration name (7.2) can be hidden by the name of an object, function, or enumerator declared in the same scope. If a class or enumeration name and an object, function, or enumerator are declared in the same scope (in any order) with the same name, the class or enumeration name is hidden wherever the object, function, or enumerator name is visible.

Please consider carefully the phrase I have highlighted, and the fact that a typedef name is not the name of an object, function or enumerator. As a result, this example:

  struct stat { ... };
  typedef int stat;

Which would be perfectly legal in C, is disallowed in C++, both implicitly (see the above quote) and explicitly (see section 7.1.3 [dcl.typedef] (The typedef specifier), paragraph 3):

In a given scope, a typedef specifier shall not be used to redefine the name of any type declared in that scope to refer to a different type. Similarly, in a given scope, a class or enumeration shall not be declared with the same name as a typedef-name that is declared in that scope and refers to a type other than the class or enumeration itself.

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

The second difference is that, in C++, a typedef name that refers to a class is a class-name; see 7.1.3 [dcl.typedef] paragraph 4:

A typedef-name that names a class is a class-name(9.1). If a typedef-name is used following the class-key in an elaborated-type-specifier (7.1.5.3) or in the class-head of a class declaration (9), or is used as the identifier in the declarator for a constructor or destructor declaration (12.1, 12.4), the program is ill-formed.

This implies, for instance, that a typedef-name referring to a class can be used in a nested-name-specifier (i.e. before :: in a qualified name) or following ~ to refer to a destructor. Note that using a typedef-name as a class-name in an elaborated-type-specifier is not allowed. For example:

  struct X { };
  typedef struct X X2;
  X x; // legal
  X2 x2; // legal
  struct X sx; // legal
  struct X2 sx2; // illegal

The final relevant piece of the standard is 7.1.3 [dcl.typedef] paragraph 2:

In a given scope, a typedef specifier can be used to redefine the name of any type declared in that scope to refer to the type to which it already refers.

This of course is what allows the original example, to which let us now return:

  typedef struct S { ... } S;
  void fs(S *x) { ... }

The question, again is, to which declaration of S does the reference actually refer? In C, it would clearly be to the second, since the first would be accessible only by using the struct keyword. In C++, if typedef names hid class names declared in the same scope, the answer would be the same. But we've already seen that typedef names do not hide class names declared in the same scope.

So to which declaration does the reference to S refer? The answer is that it doesn't matter. The second declaration of S, which appears to be a declaration of a typedef name, is actually a declaration of a class name (7.1.3 [dcl.typedef] paragraph 4), and as such is simply a redeclaration. Consider the following example:

  typedef int I, I;
  extern int x, x;
  void f(), f();

To which declaration would a reference to I, x or f refer? It doesn't matter, because the second declaration of each is really just a redeclaration of the thing declared in the first declaration. So to save time, effort and complexity, the second declaration of each doesn't add any entry to the compiler's symbol table.

Note (March, 2005):

Matt Austern: Is this legal?

    struct A { };
    typedef struct A A;
    struct A* p;

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

Mike Miller: I think you're right. 7.1.3 [dcl.typedef] paragraph 1:

A name declared with the typedef specifier becomes a typedef-name.

7.1.3 [dcl.typedef] paragraph 2:

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

After the typedef declaration in the example, the name X has been “redefined” — it is no longer just a class-name, it has been “redefined” to be a typedef-name (that, by virtue of the fact that it refers to a class type, is also a class-name).

John Spicer: In C, and originally in C++, an elaborated-type-specifier did not consider typedef names, so “struct X* x” would find the class and not the typedef.

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

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

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

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

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

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

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

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

Notes from the April, 2005 meeting:

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



837. Constexpr functions and return braced-init-list

Section: 7.1.5  [dcl.constexpr]     Status: drafting     Submitter: Mike Miller     Date: 11 March, 2009

The body of a constexpr function is required by 7.1.5 [dcl.constexpr] paragraph 3 to be of the form

However, there does not seem to be any good reason for prohibiting the alternate return syntax involving a braced-init-list. The restriction should be removed.

Proposed resolution (March, 2010):

  1. Change 6.6.3 [stmt.return] paragraph 2 as follows:

    2. A return statement without an expression with neither an expression nor a braced-init-list can be used only in functions that do not return a value...

  2. Change 7.1.5 [dcl.constexpr] paragraph 3 bullets 4 and 5 as follows:

Notes from the March, 2010 meeting:

The new wording added in 5.19 [expr.const] in support of reference parameters for constexpr functions should also be considered to see whether additional changes are needed.



1075. Grammar does not allow template alias in type-name

Section: 7.1.6.2  [dcl.type.simple]     Status: drafting     Submitter: Jason Merrill     Date: 2010-06-06

According to 14.2 [temp.names] paragraph 7,

A template-id that names a template alias specialization is a type-name.

However, the grammar for type-name in 7.1.6.2 [dcl.type.simple] does not include a production for simple-template-id.



138. Friend declaration name lookup

Section: 7.3.1.2  [namespace.memdef]     Status: drafting     Submitter: Martin von Loewis     Date: 14 Jul 1999

7.3.1.2 [namespace.memdef] paragraph 3 says,

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... When looking for a prior declaration of a class or a function declared as a friend, scopes outside the innermost enclosing namespace scope are not considered.
It is not clear from this passage how to determine whether an entity is "first declared" in a friend declaration. One question is whether a using-declaration influences this determination. For instance: 
    void foo();
    namespace A{
      using ::foo;
      class X{
	friend void foo();
      };
    }
Is the friend declaration a reference to ::foo or a different foo?

Part of the question involves determining the meaning of the word "synonym" in 7.3.3 [namespace.udecl] paragraph 1:

A using-declaration introduces a name into the declarative region in which the using-declaration appears. That name is a synonym for the name of some entity declared elsewhere.
Is "using ::foo;" the declaration of a function or not?

More generally, the question is how to describe the lookup of the name in a friend declaration.

John Spicer: When a declaration specifies an unqualified name, that name is declared, not looked up. There is a mechanism in which that declaration is linked to a prior declaration, but that mechanism is not, in my opinion, via normal name lookup. So, the friend always declares a member of the nearest namespace scope regardless of how that name may or may not already be declared there.

Mike Miller: 3.4.1 [basic.lookup.unqual] paragraph 7 says:

A name used in the definition of a class X outside of a member function body or nested class definition shall be declared in one of the following ways:... [Note: when looking for a prior declaration of a class or function introduced by a friend declaration, scopes outside of the innermost enclosing namespace scope are not considered.]
The presence of this note certainly implies that this paragraph describes the lookup of names in friend declarations.

John Spicer: It most certainly does not. If that section described the friend lookup it would yield the incorrect results for the friend declarations of f and g below. I don't know why that note is there, but it can't be taken to mean that that is how the friend lookup is done.

    void f(){}
    void g(){}
    class B {
        void g();
    };
    class A : public B {
        void f();
        friend void f(); // ::f not A::f
        friend void g(); // ::g not B::g
    };

Mike Miller: If so, the lookups for friend functions and classes behave differently. Consider the example in 3.4.4 [basic.lookup.elab] paragraph 3:

    struct Base {
        struct Data;         // OK: declares nested Data
        friend class Data;   // OK: nested Data is a friend
    };

If the friend declaration is not a reference to ::foo, there is a related but separate question: does the friend declaration introduce a conflicting (albeit "invisible") declaration into namespace A, or is it simply a reference to an as-yet undeclared (and, in this instance, undeclarable) A::foo? Another part of the example in 3.4.4 [basic.lookup.elab] paragraph 3 is related:

    struct Data {
        friend struct Glob;  // OK: Refers to (as yet) undeclared Glob
                             // at global scope.
    };

John Spicer: You can't refer to something that has not yet been declared. The friend is a declaration of Glob, it just happens to declare it in a such a way that its name cannot be used until it is redeclared.

(A somewhat similar question has been raised in connection with issue 36. Consider:

    namespace N {
        struct S { };
    }
    using N::S;
    struct S;          // legal?

According to 9.1 [class.name] paragraph 2,

A declaration consisting solely of class-key identifier ; is either a redeclaration of the name in the current scope or a forward declaration of the identifier as a class name.

Should the elaborated type declaration in this example be considered a redeclaration of N::S or an invalid forward declaration of a different class?)

(See also issues 95, 136, 139, 143, 165, and 166, as well as paper J16/00-0006 = WG21 N1229.)



972. Allowing multiple attribute-specifiers

Section: 7.6.1  [dcl.attr.grammar]     Status: drafting     Submitter: Daveed Vandevoorde     Date: 5 October, 2009

The current syntax requires that multiple attributes that appertain to the same entity be grouped into a single attribute-specifier. The migration from existing vendor-specific attributes would be easier if the syntax allowed multiple attribute-specifiers at each location where an attribute-specifier currently appears.



1031. Optional elements in attributes

Section: 7.6.1  [dcl.attr.grammar]     Status: drafting     Submitter: Daveed Vandevoorde     Date: 2010-02-10

An attribute-argument-clause should be allowed to consist solely of (), i.e., with no balanced-token-seq. Furthermore, the grammar for balanced-token should make the balanced-token-seq optional. Both of these goals could be accomplished by making the balanced-token optional in the first production of the rule for balanced-token-seq.



1033. Restrictions on alignment attributes

Section: 7.6.2  [dcl.align]     Status: drafting     Submitter: Daveed Vandevoorde     Date: 2010-02-17

According to 7.6.2 [dcl.align] paragraph 5,

The combined effect of all alignment attributes in a declaration shall not specify an alignment that is less strict than the alignment that would otherwise be required for the entity being declared.

“...would otherwise be required” could be read as referring to the alignment set by another declaration of the entity. However, it was intended to prevent specifying an alignment smaller than the natural alignment the entity would have in the absence of an align attribute. The wording should be changed to make that clearer.



1036. Alignment attribute in an exception-declaration

Section: 7.6.2  [dcl.align]     Status: drafting     Submitter: Daveed Vandevoorde     Date: 2010-02-26

The Standard explicitly bans alignment attributes for function parameters (7.6.2 [dcl.align] paragraph 1), but it is silent regarding the “parameter” of an exception handler. This should be clarified one way or the other.



453. References may only bind to “valid” objects

Section: 8.3.2  [dcl.ref]     Status: drafting     Submitter: Gennaro Prota     Date: 18 Jan 2004

8.3.2 [dcl.ref] paragraph 4 says:

A reference shall be initialized to refer to a valid object or function. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the "object" obtained by dereferencing a null pointer, which causes undefined behavior ...]

What is a "valid" object? In particular the expression "valid object" seems to exclude uninitialized objects, but the response to Core Issue 363 clearly says that's not the intent. This is an example (overloading construction on constness of *this) by John Potter, which I think is supposed to be legal C++ though it binds references to objects that are not initialized yet:

 struct Fun {
    int x, y;
    Fun (int x, Fun const&) : x(x), y(42) { }
    Fun (int x, Fun&) : x(x), y(0) { }
  };
  int main () {
    const Fun f1 (13, f1);
    Fun f2 (13, f2);
    cout << f1.y << " " << f2.y << "\n";
  }

Suggested resolution: Changing the final part of 8.3.2 [dcl.ref] paragraph 4 to:

A reference shall be initialized to refer to an object or function. From its point of declaration on (see 3.3.2 [basic.scope.pdecl]) its name is an lvalue which refers to that object or function. The reference may be initialized to refer to an uninitialized object but, in that case, it is usable in limited ways (3.8 [basic.life], paragraph 6) [Note: On the other hand, a declaration like this: 
    int & ref = *(int*)0;
is ill-formed because ref will not refer to any object or function ]

I also think a "No diagnostic is required." would better be added (what about something like int& r = r; ?)

Proposed Resolution (October, 2004):

(Note: the following wording depends on the proposed resolution for issue 232.)

Change 8.3.2 [dcl.ref] paragraph 4 as follows:

A reference shall be initialized to refer to a valid object or function. If an lvalue to which a reference is directly bound designates neither an existing object or function of an appropriate type (8.5.3 [dcl.init.ref]), nor a region of memory of suitable size and alignment to contain an object of the reference's type (1.8 [intro.object], 3.8 [basic.life], 3.9 [basic.types]), the behavior is undefined. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” empty lvalue obtained by dereferencing a null pointer, which causes undefined behavior. As does not designate an object or function. Also, as described in 9.6 [class.bit], a reference cannot be bound directly to a bit-field. ]

The name of a reference shall not be used in its own initializer. Any other use of a reference before it is initialized results in undefined behavior. [Example: 

  int& f(int&);
  int& g();

  extern int& ir3;
  int* ip = 0;

  int& ir1 = *ip;     // undefined behavior: null pointer
  int& ir2 = f(ir3);  // undefined behavior: ir3 not yet initialized
  int& ir3 = g();
  int& ir4 = f(ir4);  // ill-formed: ir4 used in its own initializer
—end example]

Rationale: The proposed wording goes beyond the specific concerns of the issue. It was noted that, while the current wording makes cases like int& r = r; ill-formed (because r in the initializer does not "refer to a valid object"), an inappropriate initialization can only be detected, if at all, at runtime and thus "undefined behavior" is a more appropriate treatment. Nevertheless, it was deemed desirable to continue to require a diagnostic for obvious compile-time cases.

It was also noted that the current Standard does not say anything about using a reference before it is initialized. It seemed reasonable to address both of these concerns in the same wording proposed to resolve this issue.

Notes from the April, 2005 meeting:

The CWG decided that whether to require an implementation to diagnose initialization of a reference to itself should be handled as a separate issue (504) and also suggested referring to “storage” instead of “memory” (because 1.8 [intro.object] defines an object as a “region of storage”).

Proposed Resolution (April, 2005):

(Note: the following wording depends on the proposed resolution for issue 232.)

Change 8.3.2 [dcl.ref] paragraph 4 as follows:

A reference shall be initialized to refer to a valid object or function. If an lvalue to which a reference is directly bound designates neither an existing object or function of an appropriate type (8.5.3 [dcl.init.ref]), nor a region of storage of suitable size and alignment to contain an object of the reference's type (1.8 [intro.object], 3.8 [basic.life], 3.9 [basic.types]), the behavior is undefined. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” empty lvalue obtained by dereferencing a null pointer, which causes undefined behavior. As does not designate an object or function. Also, as described in 9.6 [class.bit], a reference cannot be bound directly to a bit-field. ]

Any use of a reference before it is initialized results in undefined behavior. [Example: 

  int& f(int&);
  int& g();

  extern int& ir3;
  int* ip = 0;

  int& ir1 = *ip;     // undefined behavior: null pointer
  int& ir2 = f(ir3);  // undefined behavior: ir3 not yet initialized
  int& ir3 = g();
  int& ir4 = f(ir4);  // undefined behavior: ir4 used in its own initializer
—end example]

Note (February, 2006):

The word “use” in the last paragraph of the proposed resolution was intended to refer to the description in 3.2 [basic.def.odr] paragraph 2. However, that section does not define what it means for a reference to be “used,” dealing only with objects and functions. Additional drafting is required to extend 3.2 [basic.def.odr] paragraph 2 to apply to references.

Additional note (May, 2008):

The proposed resolution for issue 570 adds wording to define “use” for references.



393. Pointer to array of unknown bound in template argument list in parameter

Section: 8.3.5  [dcl.fct]     Status: drafting     Submitter: Mark Mitchell     Date: 12 Dec 2002

EDG rejects this code: 

  template <typename T>
  struct S {};

  void f (S<int (*)[]>);
G++ accepts it.

This is another case where the standard isn't very clear:

The language from 8.3.5 [dcl.fct] is:

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.
Since "includes a type" is not a term defined in the standard, we're left to guess what this means. (It would be better if this were a recursive definition, the way a type theoretician would do it: )

Notes from April 2003 meeting:

We agreed that the example should be allowed.



1069. Incorrect function type with trailing-return-type

Section: 8.3.5  [dcl.fct]     Status: drafting     Submitter: James Widman     Date: 2010-04-30

In 8.3.5 [dcl.fct] paragraph 2, the type of a function declarator with a trailing-return-type is said to be

“function of (parameter-declaration-clause) cv-qualifier-seqopt ref-qualifieropt returning type-id”.

This formulation incorrectly omits the derived-declarator-type-list modifier for the type, and it should refer to “the trailing-type-specifier-seq of the trailing-return-type” as the return type instead of type-id (which is left over from before the introduction of trailing-return-type).



1134. When is an explicitly-defaulted function defined?

Section: 8.4.2  [dcl.fct.def.default]     Status: drafting     Submitter: US     Date: 2010-08-02

N3092 comment US 47

8.4.2 [dcl.fct.def.default] paragraph 4 says,

A special member function is user-provided if it is user-declared and not explicitly defaulted on its first declaration. A user-provided explicitly-defaulted function is defined at the point where it is explicitly defaulted...

The second sentence should say “user-declared” instead of “user-provided.”



1135. Explicitly-defaulted non-public special member functions

Section: 8.4.2  [dcl.fct.def.default]     Status: drafting     Submitter: FI     Date: 2010-08-02

N3092 comment FI 1

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



1136. Explicitly-defaulted explicit constructors

Section: 8.4.2  [dcl.fct.def.default]     Status: drafting     Submitter: FI     Date: 2010-08-02

N3092 comment FI 2

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



1137. Explicitly-defaulted virtual special member functions

Section: 8.4.2  [dcl.fct.def.default]     Status: drafting     Submitter: FI     Date: 2010-08-02

N3092 comment FI 3

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



694. Zero- and value-initialization of union objects

Section: 8.5  [dcl.init]     Status: drafting     Submitter: Clark Nelson     Date: 14 May, 2008

The C committee is considering changing the definition of zero-initialization of unions to guarantee that the bytes of the entire union are set to zero before assigning 0, converted to the appropriate type, to the first member. The argument (summarized here) is for backward compatibility. The C++ Committee may want to consider the same change.

Proposed resolution (August, 2008):

Change bullet 3 of 8.5 [dcl.init] paragraph 5 (in the first list, dealing with zero-initialization) as follows:

[Drafting notes: Ask a C liaison about the progress of WG14 paper N1311, which deals with this issue. Since the adoption of WG21 paper N2544, unions may have static data members, hence the change to refer to the first non-static data member and the deletion of the footnote.]

Notes from the September, 2008 meeting:

It was observed that padding bytes in structs are zero-initialized in C, so if we are changing the treatment of unions in this way we should consider adding the C behavior for padding bytes at the same time. In particular, using memcmp to compare structs only works reliably if the padding bytes are zero-initialized.

Additional notes (February, 2010):

The C Committee has changed its approach to this question and is no longer using a two-phase process; in C, zero-initialization is specific to program start-up and thus is not appropriate for use with thread-local storage. See C paper N1387.



938. Initializer lists and array new

Section: 8.5.1  [dcl.init.aggr]     Status: drafting     Submitter: Alisdair Meredith     Date: 12 July, 2009

8.5.1 [dcl.init.aggr] paragraph 4 says,

An initializer-list is ill-formed if the number of initializer-clauses exceeds the number of members or elements to initialize.

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

Notes from the August, 2010 meeting:

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



233. References vs pointers in UDC overload resolution

Section: 8.5.3  [dcl.init.ref]     Status: drafting     Submitter: Matthias Meixner     Date: 9 Jun 2000

There is an inconsistency in the handling of references vs pointers in user defined conversions and overloading. The reason for that is that the combination of 8.5.3 [dcl.init.ref] and 4.4 [conv.qual] circumvents the standard way of ranking conversion functions, which was probably not the intention of the designers of the standard.

Let's start with some examples, to show what it is about:

    struct Z { Z(){} };

    struct A {
       Z x;

       operator Z *() { return &x; }
       operator const Z *() { return &x; }
    };

    struct B {
       Z x;

       operator Z &() { return x; }
       operator const Z &() { return x; }
    };

    int main()
    {
       A a;
       Z *a1=a;
       const Z *a2=a; // not ambiguous

       B b;
       Z &b1=b;
       const Z &b2=b; // ambiguous
    }

So while both classes A and B are structurally equivalent, there is a difference in operator overloading. I want to start with the discussion of the pointer case (const Z *a2=a;): 13.3.3 [over.match.best] is used to select the best viable function. Rule 4 selects A::operator const Z*() as best viable function using 13.3.3.2 [over.ics.rank] since the implicit conversion sequence const Z* -> const Z* is a better conversion sequence than Z* -> const Z*.

So what is the difference to the reference case? Cv-qualification conversion is only applicable for pointers according to 4.4 [conv.qual]. According to 8.5.3 [dcl.init.ref] paragraphs 4-7 references are initialized by binding using the concept of reference-compatibility. The problem with this is, that in this context of binding, there is no conversion, and therefore there is also no comparing of conversion sequences. More exactly all conversions can be considered identity conversions according to 13.3.3.1.4 [over.ics.ref] paragraph 1, which compare equal and which has the same effect. So binding const Z* to const Z* is as good as binding const Z* to Z* in terms of overloading. Therefore const Z &b2=b; is ambiguous. [13.3.3.1.4 [over.ics.ref] paragraph 5 and 13.3.3.2 [over.ics.rank] paragraph 3 rule 3 (S1 and S2 are reference bindings ...) do not seem to apply to this case]

There are other ambiguities, that result in the special treatment of references: Example:

    struct A {int a;};
    struct B: public A { B() {}; int b;};

    struct X {
       B x;
       operator A &() { return x; }
       operator B &() { return x; }
    };

    main()
    {
       X x;
       A &g=x; // ambiguous
    }

Since both references of class A and B are reference compatible with references of class A and since from the point of ranking of implicit conversion sequences they are both identity conversions, the initialization is ambiguous.

So why should this be a defect?

So overall I think this was not the intention of the authors of the standard.

So how could this be fixed? For comparing conversion sequences (and only for comparing) reference binding should be treated as if it was a normal assignment/initialization and cv-qualification would have to be defined for references. This would affect 8.5.3 [dcl.init.ref] paragraph 6, 4.4 [conv.qual] and probably 13.3.3.2 [over.ics.rank] paragraph 3.

Another fix could be to add a special case in 13.3.3 [over.match.best] paragraph 1.



355. Global-scope :: in nested-name-specifier

Section: 9  [class]     Status: drafting     Submitter: Clark Nelson     Date: 16 May 2002

In looking at a large handful of core issues related to elaborated-type-specifiers and the naming of classes in general, I discovered an odd fact. It turns out that there is exactly one place in the grammar where nested-name-specifier is not immediately preceded by "::opt": in class-head, which is used only for class definitions. So technically, this example is ill-formed, and should evoke a syntax error: 

  struct A;
  struct ::A { };

However, all of EDG, GCC and Microsoft's compiler accept it without a qualm. In fact, I couldn't get any of them to even warn about it.

Suggested resolution:

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

Proposed resolution (November, 2006):

  1. In 3.4.3 [basic.lookup.qual] paragraph 6, change the grammar snippet as follows:

  2. Delete 5.1.1 [expr.prim.general] paragraph 4 (“The operator :: followed by...”). [Drafting note: It's covered by paragraph 8 (type, lvalue-ness, member-ness, reference to 3.4.3.2 [namespace.qual]) and 3.4.3.2 [namespace.qual] (qualified lookup for namespace members).]

  3. Change the grammar in 5.1.1 [expr.prim.general] paragraph 7 as follows (deleting the :: forms from qualified-id and adding :: as a new production for nested-name-specifier):

  4. Change 5.1.1 [expr.prim.general] paragraph 8 as follows:

    A nested-name-specifier that names designates a namespace (7.3 [basic.namespace]), followed by the name of a member of that namespace...

  5. Change 5.1.1 [expr.prim.general] paragraph 10 as follows:

    In a qualified-id, if the id-expression unqualified-id is a conversion-function-id...

  6. In 5.2 [expr.post] paragraph 1, change the grammar as follows:

  7. In 5.2.4 [expr.pseudo] paragraph 2, change the grammar snippet as follows:

  8. In 7.1.6.2 [dcl.type.simple] paragraph 1, change the grammar as follows:

  9. In 7.1.6.3 [dcl.type.elab] before paragraph 1, change the grammar as follows:

  10. In 7.1.6.3 [dcl.type.elab] paragraph 1, change the grammar snippet as follows:

  11. In 7.3.2 [namespace.alias] paragraph 1, change the grammar as follows:

  12. In 7.3.3 [namespace.udecl] paragraph 1, change the grammar as follows:

  13. In 7.3.4 [namespace.udir] before paragraph 1, change the grammar as follows:

  14. In 8 [dcl.decl] paragraph 4, change the grammar as follows:

  15. In 8.3.3 [dcl.mptr] paragraph 1, change the grammar snippet as follows:

  16. In 9.2 [class.mem] before paragraph 1, change the grammar as follows:

  17. In 10 [class.derived] paragraph 1, change the grammar as follows:

  18. In 12.6.2 [class.base.init] paragraph 1, change the grammar as follows:

  19. In 14.6 [temp.res] paragraph 3, change the grammar as follows:

[Drafting notes: gcc 4.1.1 rejects the example in the issue description. I still think it's a good idea to make the grammar more uniform, and there ought to be nothing special about the global scope operator. However, there is a slight change in effective grammar with these modification: all places that require a non-optional nested-name-specifier used to required at least one named level of nesting. With these changes, "::" is a valid nested-name-specifier (that denotes the global scope). Any such use needed to protect against non-class (i.e. namespace) scopes in its semantic description anyway, which also covers the "::" case.]



1140. Incorrect redefinition of POD class

Section: 9  [class]     Status: drafting     Submitter: US     Date: 2010-08-02

N3092 comment US 50

The class

    struct A { const int i; };

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

Suggested resolution: Change POD to be standard layout and trivially copyable.



1035. Omitted and required decl-specifiers

Section: 9.2  [class.mem]     Status: drafting     Submitter: Daveed Vandevoorde     Date: 2010-02-25

According to 9.2 [class.mem] paragraph 6,

The decl-specifier-seq is omitted in constructor, destructor, and conversion function declarations only.

This is incorrect, as some decl-specifiers (explicit, virtual, inline, constexpr) are permitted in these declarations. Conversely, C.1.5 [diff.dcl], “Banning implicit int,” says,

In C++ a decl-specifier-seq must contain a type-specifier.

This is also incorrect for these declarations.



1072. Scoped enumerator with the same name as its containing class

Section: 9.2  [class.mem]     Status: drafting     Submitter: Pavel Minaev     Date: 2010-06-02

9.2 [class.mem] paragraph 13 requires that all enumerators of a member enumeration type have names different from that of the containing class. This is only necessary for unscoped enumeration; scoped enumerators are not in the scope of the containing class.



1142. friend declaration of member function of containing class

Section: 9.3  [class.mfct]     Status: drafting     Submitter: US     Date: 2010-08-02

N3092 comment US 52

The current wording of 9.3 [class.mfct] paragraph 7 allows friend declarations to name member functions “after their class has been defined.” This appears to prohibit a friend declaration in a nested class defined inside its containing class that names a member function of the containing class, because the containing class is still considered to be incomplete at that point.



696. Use of block-scope constants in local classes

Section: 9.8  [class.local]     Status: drafting     Submitter: Steve Adamczyk     Date: 29 May, 2008

According to 9.8 [class.local] paragraph 1,

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

This would presumably make both of the members of S2 below ill-formed:

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

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

Notes from the September, 2008 meeting:

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

Proposed resolution (March, 2009):

Change 9.8 [class.local] paragraph 1 as follows:

Declarations in a local class can use only type names, static variables, extern variables and functions, and enumerators shall not use (3.2 [basic.def.odr]) an automatic variable or reference from the enclosing scope. [Example: 
  int x;
  void f() {
    static int s ;
    int x;
    extern int g();
    const int c = 42;
    struct local {
      int g() { return x; }     // error: x has automatic storage duration
      int h() { return s; }     // OK
      int k() { return ::x; }   // OK
      int l() { return g(); }   // OK
      int m() { return c; }     // OK
    };
  }

  local* p = 0;                 // error: local not in scope
—end example]

Notes from the July, 2009 meeting:

This proposed resolution relies on the definition of “use” in 3.2 [basic.def.odr]. The CWG was concerned about cases in which it might not be possible to immediately determine whether a reference to a local automatic variable constitutes a “use” or not, such as in overload resolution, conditional expressions, dependent contexts, etc. To address this concern, the CWG expressed support for an approach in which a reference to a local automatic variable in a nested class or lambda body would enter the expression as an rvalue, which would reduce the complexity of the problem.

Proposed resolution (September, 2009):

  1. Change 5.1.1 [expr.prim.general] paragraph 6 as follows and add a new paragraph immediately following:

    2. ...The type of the expression is the type of the identifier. The result is the entity denoted by the identifier. The result is an lvalue if the entity is a function, variable, or data member.

    Certain contexts (9.8 [class.local], 5.1.2 [expr.prim.lambda]) are called restricted automatic variable contexts because they permit the use of automatic variables declared in enclosing scopes only under certain conditions. In these contexts (only), an identifier denoting a variable with automatic storage duration declared in an enclosing scope that satisfies the requirements for appearing in a constant expression (5.19 [expr.const]) is called an r-variable expression. The result of an r-variable expression is an rvalue whose value is that of the variable. In all other cases, the result of an identifier expression denoting a variable is an lvalue.

  2. Change 5.1.2 [expr.prim.lambda] paragraph 9 as follows:

    3. A The compound-statement of a lambda-expression is a restricted automatic variable context (5.1.1 [expr.prim.general]), and r-variable expressions within its scope are permitted. In addition, a lambda-expression's compound-statement can use (see above) this from an immediately-enclosing member function definition, as well as variables and references with automatic storage duration from an immediately-enclosing function definition or lambda-expression, provided these entities are captured (as described below). Any other use (3.2 [basic.def.odr]) of a variable or reference with automatic storage duration declared outside the lambda-expression is ill-formed. [Example:

        void f1(int i) {
      int const N = 20;
      [=]{
        int const M = 30;
        int j;
        [=]{
          int x[N][M]; // OK: N and M are not used r-variable expressions
          x[0][0] = i; // error: i is not declared in the immediately
        };             // enclosing lambda-expression
          int y = N+M; // OK: N and M are r-variable expressions
          &M;          // error: taking the address of an rvalue
          y = i;       // error: i is not an r-variable expression and variable i
                       // is declared outside the immediately-enclosing
                       // lambda-expression and thus not captured
          sizeof(i);   // OK: i is not “used”
          int z = j;   // OK: variable j is implicitly captured
        };
        [M]{
          int a[M];    // error: variable M explicitly captured, so M
                       //refers to a member of the closure type
        };
      };
    }

    —end example]

  3. Change 5.1.2 [expr.prim.lambda] paragraph 11 as follows:

    4. If a lambda-expression has an associated capture-default and its compound-statement uses (3.2 [basic.def.odr]) this or a variable or reference with automatic storage duration declared in an enclosing function or lambda-expression and the used entity is not explicitly captured, then the used entity is said to be implicitly captured. An entity that is used (3.2 [basic.def.odr]) in the compound-statement of a lambda-expression but not explicitly captured will be implicitly captured if:

    [Note: Implicit uses of this can result in implicit capture. —end note]

  4. Change 5.1.2 [expr.prim.lambda] paragraph 16 as follows:

    5. Every id-expression that is a use (3.2 [basic.def.odr]) of an entity captured by copy If an id-expression denotes an entity that is explicitly captured by copy, or it it is a use (3.2 [basic.def.odr]) of an entity that is implicitly captured by copy, that id-expression is transformed into an access to the corresponding unnamed data member of the closure type. [Note: r-variable expressions designating variables that are explicitly captured by copy are thus not id-expressions after this transformation and consequently are no longer r-variable expressions. If a variable is not explicitly captured, however, the fact that it is used as an r-variable expression does not cause that variable to be implicitly captured, either. As a result, such an id-expression will not be transformed to a member access, and it will therefore be treated as a constant rvalue. —end note] If this is captured, each use of this is transformed into an access to the corresponding unnamed data member of the closure type cast (5.4 [expr.cast]) to the type of this. [Note: The cast ensures that the transformed expression is an rvalue. —end note]

  5. Change 9.8 [class.local] paragraph 1 as follows:

    6. A class can be declared within a function definition; such a class is called a local class. The name of a local class is local to its enclosing scope. The local class is in the scope of the enclosing scope, and has the same access to names outside the function as does the enclosing function. A local class definition is a restricted automatic variable context (5.1.1 [expr.prim.general]). Declarations in a local class can use only type names, static variables, extern variables and functions, and enumerators shall not use (3.2 [basic.def.odr]) a variable or reference with automatic storage duration from the enclosing scope except as an r-variable expression. [Example: 
    int x;
  void f() {
    static int s ;
    int x;
    extern int g();
    const int c = 42;

    struct local {
      int g() { return x; }    // error: x has automatic storage duration is not an r-variable expression
      int h() { return s; }    // OK
      int k() { return ::x; }  // OK
      int l() { return g(); }  // OK
      int m() { return c; }    // OK: c is an r-variable expression
      int* n() { return &c; }  // error: taking the address of an rvalue
    };
  }

  local* p = 0;                // error: local not in scope

    —end example]

Drafting note: The change to 5.1.2 [expr.prim.lambda] paragraph 16 has the effect of making explicitly-captured variables no longer usable in constant expressions in lambda bodies. This change facilitates the design goal to be able to determine in a context-free manner whether a given id-expression should be transformed to a member access expression or not.

Notes from the October, 2009 meeting:

There was interest in an approach that would allow explicitly-captured constants to appear in constant expressions but also to be “used.” Another suggestion was to have variables captured if they appear in either “use” or “non-use” contexts.



580. Access in template-parameters of member and friend definitions

Section: 11  [class.access]     Status: drafting     Submitter: John Spicer     Date: 16 May 2006

The resolution of issue 372 leaves unclear whether the following are well-formed or not:

    class C {
        typedef int I;                // private
        template <int> struct X;
        template <int> friend struct Y;
    }

    template <C::I> struct C::X { };  // C::I accessible to member?

    template <C::I> struct Y { };     // C::I accessible to friend?

Presumably the answer to both questions is “yes,” but the new wording does not address template-parameters.

Proposed resolution (June, 2008):

Change 11 [class.access] paragraph 6 as follows:

...For purposes of access control, the base-specifiers of a class, the template-parameters of a template-declaration, and the definitions of class members that appear outside of the class definition are considered to be within the scope of that class...

Notes from the September, 2008 meeting:

The proposed resolution preserves the word “scope” as a holdover from the original specification prior to issue 372, which intended to change access determination from a scope-based model to an entity-based model. The resolution should eliminate all references to scope and simply use the entity-based model.

(See also issue 718.)

Proposed resolution (February, 2010):

Change 11 [class.access] paragraphs 6-7 as follows:

All access controls in Clause 11 [class.access] affect the ability to access a class member name from a declaration of a particular scope entity, including references appearing in those parts of the declaration that precede the name of the entity being declared and implicit references to constructors, conversion functions, and destructors involved in the creation and destruction of a static data member. For purposes of access control, the base-specifiers of a class and the definitions of class members that appear outside of the class definition are considered to be within the scope of that class. In particular, access controls apply as usual to member names accessed as part of a function return type, even though it is not possible to determine the access privileges of that use without first parsing the rest of the function declarator. Similarly, access control for implicit calls to the constructors, the conversion functions, or the destructor called to create and destroy a static data member is performed as if these calls appeared in the scope of the member's class. [Example:

  class A {
    typedef int I;    // private member
    I f();
    friend I g(I);
    static I x;
    template<int> struct X;
    template<int> friend struct Y;
  protected:
    struct B { };
  };

  A::I A::f() { return 0; }
  A::I g(A::I p = A::x);
  A::I g(A::I p) { return 0; }
  A::I A::x = 0;
  template<A::I> struct A::X { };
  template<A::I> struct Y { };

  struct D: A::B, A { };

Here, all the uses of A::I are well-formed because A::f and, A::x, and A::X are members of class A and g is a friend and Y are friends of class A. This implies, for example, that access checking on the first use of A::I must be deferred until it is determined that this use of A::I is as the return type of a member of class A. Similarly, the use of A::B as a base-specifier is well-formed because D is derived from A, so checking of base-specifiers must be deferred until the entire base-specifier-list has been seen. —end example]



952. Insufficient description of “naming class”

Section: 11.2  [class.access.base]     Status: drafting     Submitter: James Widman     Date: 7 August, 2009

The access rules in 11.2 [class.access.base] do not appear to handle references in nested classes and outside of nonstatic member functions correctly. For example,

    struct A {
        typedef int I;    // public
    };
    struct B: private A { };
    struct C: B {
        void f() {
            I i1;         // error: access violation
        }
        I i2;             // OK
        struct D {
            I i3;         // OK
            void g() {
                I i4;     // OK
            }
        };
    };

The reason for this discrepancy is that the naming class in the reference to I is different in these cases. According to 11.2 [class.access.base] paragraph 5,

The access to a member is affected by the class in which the member is named. This naming class is the class in which the member name was looked up and found.

In the case of i1, the reference to I is subject to the transformation described in 9.3.1 [class.mfct.non-static] paragraph 3:

Similarly during name lookup, when an unqualified-id (5.1 [expr.prim]) used in the definition of a member function for class X resolves to a static member, an enumerator or a nested type of class X or of a base class of X, the unqualified-id is transformed into a qualified-id (5.1 [expr.prim]) in which the nested-name-specifier names the class of the member function.

As a result, the reference to I in the declaration of i1 is transformed to C::I, so that the naming class is C, and I is inacessible in C. In the remaining cases, however, the transformation does not apply. Thus, the naming class of I in these references is A, and I is publicly accessible in A.

Presumably either the definition of “naming class” must be changed or the transformation of unqualified-ids must be broadened to include all uses within the scope of a class and not just within nonstatic member functions (and following the declarator-id in the definition of a static member, per 9.4 [class.static] paragraph 4).



472. Casting across protected inheritance

Section: 11.5  [class.protected]     Status: drafting     Submitter: Mike Miller     Date: 16 Jun 2004

Does the restriction in 11.5 [class.protected] apply to upcasts across protected inheritance, too? For instance,

    struct B {
        int i;
    };
    struct I: protected B { };
    struct D: I {
        void f(I* ip) {
            B* bp = ip;    // well-formed?
            bp->i = 5;     // aka "ip->i = 5;"
        }
    };

I think the rationale for the 11.5 [class.protected] restriction applies equally well here — you don't know whether ip points to a D object or not, so D::f can't be trusted to treat the protected B subobject consistently with the policies of its actual complete object type.

The current treatment of “accessible base class” in 11.2 [class.access.base] paragraph 4 clearly makes the conversion from I* to B* well-formed. I think that's wrong and needs to be fixed. The rationale for the accessibility of a base class is whether “an invented public member” of the base would be accessible at the point of reference, although we obscured that a bit in the reformulation; it seems to me that the invented member ought to be considered a non-static member for this purpose and thus subject to 11.5 [class.protected].

(See also issues 385 and 471.).

Notes from October 2004 meeting:

The CWG tentatively agreed that casting across protective inheritance should be subject to the additional restriction in 11.5 [class.protected].

Proposed resolution (February, 2010):

Change 11.2 [class.access.base] paragraph 4 as follows:

A base class B of N is accessible at R, if

[Example:

    class B {
    public:
      int m;
    };

    class S: private B {
      friend class N;
    };
    class N: private S {
      void f() {
        B* p = this;    // OK because class S satisfies the fourth condition
                        // above: B is a base class of N accessible in f() because
                        // B is an accessible base class of S and S is an accessible
                        // base class of N.
      }
    };

    class N2: protected B { };

    class P2: public N2 {
      void f2(N2* n2p) {
        B* bp = n2p;    // error: invented member would be protected and naming
                        // class N2 not the same as or derived from the referencing
                        // class P2 (cf 11.5 [class.protected])
      }
    };

—end example]



399. Destructor lookup redux

Section: 12.4  [class.dtor]     Status: drafting     Submitter: John Spicer     Date: 17 Jan 2003

Mark Mitchell raised a number of issues related to the resolution of issue 244 and of destructor lookup in general.

Issue 244 says:

... in a qualified-id of the form: the second class-name is looked up in the same scope as the first.

But if the reference is "p->X::~X()", the first class-name is looked up in two places (normal lookup and a lookup in the class of p). Does the new wording mean:

  1. You look up the second class-name in the scope that you found the first one.
  2. You look up the second class-name using the same kind of lookup that found the first one (normal vs. class).
  3. If you did a dual lookup for the first you do a dual lookup for the second.

This is a test case that illustrates the issue:

  struct A {
    typedef A C;
  };

  typedef A B;

  void f(B* bp) {
    bp->B::~B();  // okay B found by normal lookup
    bp->C::~C();  // okay C found by class lookup
    bp->B::~C();  // B found by normal lookup C by class -- okay?
    bp->C::~B();  // C found by class lookup B by normal -- okay?
  }

A second issue concerns destructor references when the class involved is a template class.

  namespace N {
    template <typename T> struct S {
      ~S();
    };
  }

  void f(N::S<int>* s) {
    s->N::S<int>::~S();
  }

The issue here is that the grammar uses "~class-name" for destructor names, but in this case S is a template name when looked up in N.

Finally, what about cases like:

  template <typename T> void f () {
    typename T::B x;
    x.template A<T>::template B<T>::~B();
  }

When parsing the template definition, what checks can be done on "~B"?

Sandor Mathe adds :

The standard correction for issue 244 (now in DR status) is still incomplete.

Paragraph 5 of 3.4.3 [basic.lookup.qual] is not applicable for p->T::~T since there is no nested-name-specifier. Section 3.4.5 [basic.lookup.classref] describes the lookup of p->~T but p->T::~T is still not described. There are examples (which are non-normative) that illustrate this sort of lookup but they still leave questions unanswered. The examples imply that the name after ~ should be looked up in the same scope as the name before the :: but it is not stated. The problem is that the name to the left of the :: can be found in two different scopes. Consider the following:

  struct S {
    struct C { ~C() { } };
  };

  typedef S::C D;

  int main() {
    D* p;
    p->C::~D();  // valid?
  }

Should the destructor call be valid? If there were a nested name specifier, then D should be looked for in the same scope as C. But here, C is looked for in 2 different ways. First, it is searched for in the type of the left hand side of -> and it is also looked for in the lexical context. It is found in one or if both, they must match. So, C is found in the scope of what p points at. Do you only look for D there? If so, this is invalid. If not, you would then look for D in the context of the expression and find it. They refer to the same underlying destructor so this is valid. The intended resolution of the original defect report of the standard was that the name before the :: did not imply a scope and you did not look for D inside of C. However, it was not made clear whether this was to be resolved by using the same lookup mechanism or by introducing a new form of lookup which is to look in the left hand side if that is where C was found, or in the context of the expression if that is where C was found. Of course, this begs the question of what should happen when it is found in both? Consider the modification to the above case when C is also found in the context of the expression. If you only look where you found C, is this now valid because it is in 1 of the two scopes or is it invalid because C was in both and D is only in 1?

  struct S {
    struct C { ~C() { } };
  };

  typedef S::C D;
  typedef S::C C;

  int main() {
    D* p;
    p->C::~D();  // valid?
  }

I agree that the intention of the committee is that the original test case in this defect is broken. The standard committee clearly thinks that the last name before the last :: does not induce a new scope which is our current interpretation. However, how this is supposed to work is not defined. This needs clarification of the standard.

Martin Sebor adds this example (September 2003), along with errors produced by the EDG front end:

namespace N {
    struct A { typedef A NA; };
    template <class T> struct B { typedef B NB; typedef T BT; };
    template <template <class> class T> struct C { typedef C NC; typedef T<A> CA; };
}

void foo (N::A *p)
{
    p->~NA ();
    p->NA::~NA ();
}

template <class T>
void foo (N::B<T> *p)
{
    p->~NB ();
    p->NB::~NB ();
}

template <class T>
void foo (typename N::B<T>::BT *p)
{
    p->~BT ();
    p->BT::~BT ();
}

template <template <class> class T>
void foo (N::C<T> *p)
{
    p->~NC ();
    p->NC::~NC ();
}

template <template <class> class T>
void foo (typename N::C<T>::CA *p)
{
    p->~CA ();
    p->CA::~CA ();
}

Edison Design Group C/C++ Front End, version 3.3 (Sep  3 2003 11:54:55)
Copyright 1988-2003 Edison Design Group, Inc.

"t.cpp", line 16: error: invalid destructor name for type "N::B<T>"
      p->~NB ();
          ^

"t.cpp", line 17: error: qualifier of destructor name "N::B<T>::NB" does not
          match type "N::B<T>"
      p->NB::~NB ();
              ^

"t.cpp", line 30: error: invalid destructor name for type "N::C<T>"
      p->~NC ();
          ^

"t.cpp", line 31: error: qualifier of destructor name "N::C<T>::NC" does not
          match type "N::C<T>"
      p->NC::~NC ();
              ^

4 errors detected in the compilation of "t.cpp".

John Spicer: The issue here is that we're unhappy with the destructor names when doing semantic analysis of the template definitions (not during an instantiation).

My personal feeling is that this is reasonable. After all, why would you call p->~NB for a class that you just named as N::B<T> and you could just say p->~B?

Additional note (September, 2004)

The resolution for issue 244 removed the discussion of p->N::~S, where N is a namespace-name. However, the resolution did not make this construct ill-formed; it simply left the semantics undefined. The meaning should either be defined or the construct made ill-formed.

See also issues 305 and 466.



1029. Type of a destructor call

Section: 12.4  [class.dtor]     Status: drafting     Submitter: Johannes Schaub     Date: 2010-02-08

The Standard does not define the type of a destructor call. Although that is not of any practical importance, it should do so as a matter of completeness. (5.2.4 [expr.pseudo] paragraph 1 defines the type of a pseudo-destructor call as void.)



1081. Defaulted destructor and unusable operator delete

Section: 12.4  [class.dtor]     Status: drafting     Submitter: Jason Merrill     Date: 2010-06-22

A defaulted destructor should be implicitly defined as deleted if operator delete is deleted or inaccessible.



1080. Confusing relationship between templates and copy constructors

Section: 12.8  [class.copy]     Status: drafting     Submitter: Jason Merrill     Date: 2010-06-19

12.8 [class.copy] paragraphs 6-7 currently read,

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

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

    struct S {
        template<typename T> S(T);
        template<typename T> S(T&&);
        S();
    };

    S f();
    const S g;

    void h() {
        S a( f() ); // does not instantiate member template;
                    // uses the implicitly generated move constructor
        S a(g);     // does not instantiate the member template;
                    // uses the implicitly generated copy constructor
    }

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

    template <class T> A(T):

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

Lawrence Crowl: I suggest something along the lines of

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


1148. Copy elision and move construction of function parameters

Section: 12.8  [class.copy]     Status: drafting     Submitter: DE     Date: 2010-08-03

N3092 comment DE 11

It is unclear whether copy elision is permitted when returning a parameter of class type. If not, it should still be possible to move, rather than copy, the return value.

Suggested resolution: Amend paragraph 34 to explicitly exclude function parameters from copy elision. Amend paragraph 35 to include function parameters as eligible for move-construction.



1016. Overloadable declarations, function templates, and references

Section: 13  [over]     Status: drafting     Submitter: Johannes Schaub     Date: 2009-12-27

According to 13 [over] paragraph 1,

Only function declarations can be overloaded; object and type declarations cannot be overloaded.

There are two problems with this statement. First, it does not allow for overloading function templates. (There may be other places in the Standard that refer to “functions” but should include function templates, as well.)

Second, the restriction on “object” declarations should presumably be on “variable” declarations instead, since one can also not overload reference declarations.



1153. Type matching in address of overloaded function

Section: 13.4  [over.over]     Status: drafting     Submitter: US     Date: 2010-08-03

N3092 comment US 68

Overload resolution within the operand of a unary & operator is done by selecting the function “whose type matches the target type required in the context.” The criterion for determining whether the types match, however, is not defined. At least three possibilities suggest themselves:

  1. The types are identical.

  2. The source type can be implicitly converted to the target type.

  3. The expression would be well-formed if the function under consideration were not overloaded.

This question arises for pointer-to-member types, where there is an implicit conversion from a pointer-to-base-member to a pointer-to-derived-member, as well as when the context is an explicit type conversion (which allows, for static_cast, a conversion from pointer-to-derived-member to a pointer-to-base-member and, in the reinterpret_cast interpretation of functional and old-style casts, essentially any conversion).

Notes from the August, 2010 meeting:

CWG observed that the only case in which the types might not match exactly was for pointers to member functions. In this case, the approach should be to ignore the class of which the functions are members and just match (exactly) on the function type.



260. User-defined conversions and built-in operator=

Section: 13.6  [over.built]     Status: drafting     Submitter: Scott Douglas     Date: 4 Nov 2000

According to the Standard (although not implemented this way in most implementations), the following code exhibits non-intuitive behavior:

  struct T {
    operator short() const;
    operator int() const;
  };

  short s;

  void f(const T& t) {
    s = t;  // surprisingly calls T::operator int() const
  }

The reason for this choice is 13.6 [over.built] paragraph 18:

For every triple (L, VQ, R), where L is an arithmetic type, VQ is either volatile or empty, and R is a promoted arithmetic type, there exist candidate operator functions of the form

Because R is a "promoted arithmetic type," the second argument to the built-in assignment operator is int, causing the unexpected choice of conversion function.

Suggested resolution: Provide built-in assignment operators for the unpromoted arithmetic types.

Related to the preceding, but not resolved by the suggested resolution, is the following problem. Given:

    struct T {
	 operator int() const;
	 operator double() const;
    };

I believe the standard requires the following assignment to be ambiguous (even though I expect that would surprise the user):

    double x;
    void f(const T& t) { x = t; }

The problem is that both of these built-in operator=()s exist (13.6 [over.built] paragraph 18):

    double& operator=(double&, int);
    double& operator=(double&, double);

Both are an exact match on the first argument and a user conversion on the second. There is no rule that says one is a better match than the other.

The compilers that I have tried (even in their strictest setting) do not give a peep. I think they are not following the standard. They pick double& operator=(double&, double) and use T::operator double() const.

I hesitate to suggest changes to overload resolution, but a possible resolution might be to introduce a rule that, for built-in operator= only, also considers the conversion sequence from the second to the first type. This would also resolve the earlier question.

It would still leave x += t etc. ambiguous -- which might be the desired behavior and is the current behavior of some compilers.

Notes from the 04/01 meeting:

The difference between initialization and assignment is disturbing. On the other hand, promotion is ubiquitous in the language, and this is the beginning of a very slippery slope (as the second report above demonstrates).

Additional note (August, 2010):

See issue 507 for a similar example involving comparison operators.



205. Templates and static data members

Section: 14  [temp]     Status: drafting     Submitter: Mike Miller     Date: 11 Feb 2000

Static data members of template classes and of nested classes of template classes are not themselves templates but receive much the same treatment as template. For instance, 14 [temp] paragraph 1 says that templates are only "classes or functions" but implies that "a static data member of a class template or of a class nested within a class template" is defined using the template-declaration syntax.

There are many places in the clause, however, where static data members of one sort or another are overlooked. For instance, 14 [temp] paragraph 6 allows static data members of class templates to be declared with the export keyword. I would expect that static data members of (non-template) classes nested within class templates could also be exported, but they are not mentioned here.

Paragraph 8, however, overlooks static data members altogether and deals only with "templates" in defining the effect of the export keyword; there is no description of the semantics of defining a static data member of a template to be exported.

These are just two instances of a systematic problem. The entire clause needs to be examined to determine which statements about "templates" apply to static data members, and which statements about "static data members of class templates" also apply to static data members of non-template classes nested within class templates.

(The question also applies to member functions of template classes; see issue 217, where the phrase "non-template function" in 8.3.6 [dcl.fct.default] paragraph 4 is apparently intended not to include non-template member functions of template classes. See also issue 108, which would benefit from understanding nested classes of class templates as templates. Also, see issue 249, in which the usage of the phrase "member function template" is questioned.)

Notes from the 4/02 meeting:

Daveed Vandevoorde will propose appropriate terminology.



1009. Missing cases in the declarator-id of a function template declaration

Section: 14  [temp]     Status: drafting     Submitter: Johannes Schaub     Date: 2009-11-28

According to 14 [temp] paragraph 2,

In a function template declaration, the last component of the declarator-id shall be a template-name or operator-function-id (i.e., not a template-id).

This is too restrictive; it should also allow conversion-function-ids and literal-operator-ids.



778. Template parameter packs in non-type template parameters

Section: 14.1  [temp.param]     Status: drafting     Submitter: Michael Wong     Date: 13 February, 2009

Consider an example like:

    template <typename T, T Value> struct bar { };
    template <typename... T, T ...Value> void foo(bar<T, Value>);

The current wording in 14.1 [temp.param] is unclear as to whether this is permitted or not. For comparison, 8.3.5 [dcl.fct] paragraph 13 says,

A declarator-id or abstract-declarator containing an ellipsis shall only be used in a parameter-declaration. Such a parameter-declaration is a parameter pack (14.5.3 [temp.variadic]). When it is part of a parameter-declaration-clause, the parameter pack is a function parameter pack (14.5.3 [temp.variadic]). [Note: Otherwise, the parameter-declaration is part of a template-parameter-list and the parameter pack is a template parameter pack; see 14.1 [temp.param]. —end note] A function parameter pack, if present, shall occur at the end of the parameter-declaration-list. The type T of the declarator-id of the function parameter pack shall contain a template parameter pack; each template parameter pack in T is expanded by the function parameter pack.

The requirement here that the type of a function parameter pack must contain a template parameter pack is not repeated for template non-type parameters in 14.1 [temp.param], nor is the statement that it expands the template parameter pack.

A related issue is that neither function nor template parameter packs are listed in 14.5.3 [temp.variadic] paragraph 4 among the contexts in which a pack expansion can appear.



1006. std::nullptr_t as a non-type template parameter

Section: 14.1  [temp.param]     Status: drafting     Submitter: Mike Miller     Date: 2009-11-20

std::nullptr_t is not currently allowed by 14.1 [temp.param] paragraph 4 to be used as the type of a non-type template parameter. However, this could arise for a template with a non-type template parameter with a dependent type in a template intended for use with pointers, e.g.,

    template<typename T, T t> void f();
    ...
    f<std::nullptr_t, nullptr>();

or in a case of delegation.



1068. Template aliases with default arguments and template parameter packs

Section: 14.1  [temp.param]     Status: drafting     Submitter: Nikolay Ivchenkov     Date: 2010-03-27

Since there appear to be no restrictions against it, it would appear that default arguments and template parameter packs can be used with template aliases just as with other templates. If that is the case, then, the current wording in 14.1 [temp.param] paragraph 11 requires adjustment:

If a template-parameter of a class template has a default template-argument, each subsequent template-parameter shall either have a default template-argument supplied or be a template parameter pack. If a template-parameter of a class template is a template parameter pack, it shall be the last template-parameter.

Presumably these restrictions should also apply to template aliases, but as written, they only apply to class templates.



314. template in base class specifier

Section: 14.2  [temp.names]     Status: drafting     Submitter: Mark Mitchell     Date: 23 Aug 2001

The EDG front-end accepts:

template <typename T>
struct A {
  template <typename U>
  struct B {};
};

template <typename T>
struct C : public A<T>::template B<T> {
};

It rejects this code if the base-specifier is spelled A<T>::B<T>.

However, the grammar for a base-specifier does not allow the template keyword.

Suggested resolution:

It seems to me that a consistent approach to the solution that looks like it will be adopted for issue 180 (which deals with the typename keyword in similar contexts) would be to assume that B is a template if it is followed by a "<". After all, an expression cannot appear in this context.

Notes from the 4/02 meeting:

We agreed that template must be allowed in this context. The syntax needs to be changed. We also opened the related issue 343.

Additional note (August, 2010):

The same considerations apply to mem-initializer-ids, as noted in issue 1019.



1025. Use of a reference as a non-type template argument

Section: 14.3.2  [temp.arg.nontype]     Status: drafting     Submitter: Mike Miller     Date: 2010-01-31

The current wording of 14.3.2 [temp.arg.nontype] paragraph 1 does not prevent the use a reference as a non-type template argument. It simply requires

the address of an object or function with external linkage... expressed as & id-expression...

This would presumably (but unintentionally?) allow an example like the following:

    struct S { };
    template<S*> struct X { };
    S s;
    S& ref = s;
    X<&ref> xr;   // well-formed?

The expression &ref is not a constant expression, but the current wording of 14.3.2 [temp.arg.nontype] does not require a constant expression.



1032. Empty pack expansions

Section: 14.5.3  [temp.variadic]     Status: drafting     Submitter: James Widman     Date: 2010-02-16

It was intended for empty pack expansions to be useful in contexts like base-specifiers, e.g.,

    template<class... T> struct A : T... {};
    A<> x; // ok?

However, the current wording provides no description of how that might work. (More generally, the problem arises in any context where the pack expansion follows a token that should only be present when the pack expansion is non-empty: following another argument in a function call, etc.)



549. Non-deducible parameters in partial specializations

Section: 14.5.5.1  [temp.class.spec.match]     Status: drafting     Submitter: Martin Sebor     Date: 18 November 2005

In the following example, the template parameter in the partial specialization is non-deducible:

    template <class T> struct A { typedef T U; };
    template <class T> struct C { };
    template <class T> struct C<typename A<T>::U> { };

Several compilers issue errors for this case, but there appears to be nothing in the Standard that would make this ill-formed; it simply seems that the partial specialization will never be matched, so the primary template will be used for all specializations. Should it be ill-formed?

Notes from the April, 2006 meeting:

It was noted that there are similar issues for constructors and conversion operators with non-deducible parameters, and that they should probably be dealt with similarly.



1156. Partial ordering in a non-call context

Section: 14.5.6.2  [temp.func.order]     Status: drafting     Submitter: US     Date: 2010-08-03

N3092 comment US 70

14.8.2.4 [temp.deduct.partial] paragraph 3 specifies that the deduction used in partial ordering in a non-call context is based on the complete function type of the function templates. The wording in 14.5.6.2 [temp.func.order] paragraph 2 (and echoed in paragraph 4) reflects an earlier specification, however, saying that the deduction uses only “the function parameter types, or in the case of a conversion function the return type.” This is a contradiction. The wording in 14.5.6.2 [temp.func.order] should be changed.



560. Use of the typename keyword in return types

Section: 14.6  [temp.res]     Status: drafting     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 14.6 [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 (14.6.2 [temp.dep]) but does not refer to a member of the current instantiation (14.6.2.1 [temp.dep.type]) shall be prefixed by the keyword 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?



1004. Injected-class-names as arguments for template template parameters

Section: 14.6.1  [temp.local]     Status: drafting     Submitter: Jason Merrill     Date: 2009-11-19

The injected-class-name of a class template can be used either by itself, in which case it is a type denoting the current instantiation, or followed by a template argument list, in which case it is a template-name. It would be helpful to extend this treatment so that the injected-class-name could be used as an argument for a template template parameter:

    template <class T> struct A { };

    template <template <class> class TTP> struct B { };

    struct C: A<int> {
       B<A> b;
    };

(This is accepted by g++.)

James Widman:

It would not be so helpful when used with overloaded function templates, for example:

    template <template <class> class TTP>  void f(); // #1
    template <                 class T  >  void f(); // #2

    template <class T> struct A { };

    struct C: A<int> {
        void h(  ) {
            f<A>(); //  #1?  #2?  Substitution failure?
        }
    };

(See also issue 602.)



1047. When is typeid value-dependent?

Section: 14.6.2.3  [temp.dep.constexpr]     Status: drafting     Submitter: Steve Adamczyk     Date: 2010-03-08

The Standard should, but does not currently, say that typeid is value-dependent if its expression or type is type-dependent.



1088. Dependent non-type template arguments

Section: 14.6.2.3  [temp.dep.constexpr]     Status: drafting     Submitter: Jason Merrill     Date: 2010-06-28

Given

    template <const char *N> struct A { static const char *p; };
    template <class T>
       struct B { static const char c[1]; typedef A<B<T>::c> C; };
    template <class T>
       struct D { static const char c[1]; typedef A<c> C; };

14.6.2.4 [temp.dep.temp] says that B<T>::c is dependent because it is used as a non-integral non-type template argument and it is a qualified-id with a nested-name-specifier that names a dependent type.

There doesn't seem to be anything to say that c in the definition of D<T>::C is dependent, which suggests that D<T>::C is the same type for all T, which is clearly false.

Instead of this special rule in 14.6.2.4 [temp.dep.temp], 14.6.2.3 [temp.dep.constexpr] should say that the address of a member of a dependent type is value-dependent, regardless of whether the address is written with a qualified-id.



2. How can dependent names be used in member declarations that appear outside of the class template definition?

Section: 14.6.4  [temp.dep.res]     Status: drafting     Submitter: unknown     Date: unknown
    template <class T> class Foo {
    
       public:
       typedef int Bar;
       Bar f();
    };
    template <class T> typename Foo<T>::Bar Foo<T>::f() { return 1;}
                       --------------------
In the class template definition, the declaration of the member function is interpreted as: 
   int Foo<T>::f();
In the definition of the member function that appears outside of the class template, the return type is not known until the member function is instantiated. Must the return type of the member function be known when this out-of-line definition is seen (in which case the definition above is ill-formed)? Or is it OK to wait until the member function is instantiated to see if the type of the return type matches the return type in the class template definition (in which case the definition above is well-formed)?

Suggested resolution: (John Spicer)

My opinion (which I think matches several posted on the reflector recently) is that the out-of-class definition must match the declaration in the template. In your example they do match, so it is well formed.

I've added some additional cases that illustrate cases that I think either are allowed or should be allowed, and some cases that I don't think are allowed.

    template <class T> class A { typedef int X; };
    
    
    template <class T> class Foo {
     public:
       typedef int Bar;
       typedef typename A<T>::X X;
       Bar f();
       Bar g1();
       int g2();
       X h();
       X i();
       int j();
     };
    
     // Declarations that are okay
     template <class T> typename Foo<T>::Bar Foo<T>::f()
                                                     { return 1;}
     template <class T> typename Foo<T>::Bar Foo<T>::g1()
                                                     { return 1;}
     template <class T> int Foo<T>::g2() { return 1;}
     template <class T> typename Foo<T>::X Foo<T>::h() { return 1;}
    
     // Declarations that are not okay
     template <class T> int Foo<T>::i() { return 1;}
     template <class T> typename Foo<T>::X Foo<T>::j() { return 1;}
In general, if you can match the declarations up using only information from the template, then the declaration is valid.

Declarations like Foo::i and Foo::j are invalid because for a given instance of A<T>, A<T>::X may not actually be int if the class is specialized.

This is not a problem for Foo::g1 and Foo::g2 because for any instance of Foo<T> that is generated from the template you know that Bar will always be int. If an instance of Foo is specialized, the template member definitions are not used so it doesn't matter whether a specialization defines Bar as int or not.



1028. Dependent names in non-defining declarations

Section: 14.6.4  [temp.dep.res]     Status: drafting     Submitter: Sean Hunt     Date: 2010-02-03

The current wording of 14.6.4 [temp.dep.res] seems to assume that dependent names can only appear in the definition of a template:

In resolving dependent names, names from the following sources are considered:

However, dependent names can occur in non-defining declarations of the template as well; for instance,

    template<typename T>
    T foo(T, decltype(bar(T())));

bar needs to be looked up, even though there is no definition of foo in the translation unit.



287. Order dependencies in template instantiation

Section: 14.6.4.1  [temp.point]     Status: drafting     Submitter: Martin Sebor     Date: 17 May 2001

Implementations differ in their treatment of the following code:

    template <class T>
    struct A {
	typename T::X x;
    };

    template <class T>
    struct B {
	typedef T* X;
	A<B> a;
    };

    int main ()
    {
	B<int> b;
    }

Some implementations accept it. At least one rejects it because the instantiation of A<B<int> > requires that B<int> be complete, and it is not at the point at which A<B<int> > is being instantiated.

Erwin Unruh:

In my view the programm is ill-formed. My reasoning:

So each class needs the other to be complete.

The problem can be seen much easier if you replace the typedef with

    typedef T (*X) [sizeof(B::a)];

Now you have a true recursion. The compiler cannot easily distinguish between a true recursion and a potential recursion.

John Spicer:

Using a class to form a qualified name does not require the class to be complete, it only requires that the named member already have been declared. In other words, this kind of usage is permitted:

    class A {
        typedef int B;
        A::B ab;
    };

In the same way, once B has been declared in A, it is also visible to any template that uses A through a template parameter.

The standard could be more clear in this regard, but there are two notes that make this point. Both 3.4.3.1 [class.qual] and 5.1.1 [expr.prim.general] paragraph 7 contain a note that says "a class member can be referred to using a qualified-id at any point in its potential scope (3.3.7 [basic.scope.class])." A member's potential scope begins at its point of declaration.

In other words, a class has three states: incomplete, being completed, and complete. The standard permits a qualified name to be used once a name has been declared. The quotation of the notes about the potential scope was intended to support that.

So, in the original example, class A does not require the type of T to be complete, only that it have already declared a member X.

Bill Gibbons:

The template and non-template cases are different. In the non-template case the order in which the members become declared is clear. In the template case the members of the instantiation are conceptually all created at the same time. The standard does not say anything about trying to mimic the non-template case during the instantiation of a class template.

Mike Miller:

I think the relevant specification is 14.6.4.1 [temp.point] paragraph 3, dealing with the point of instantiation:

For a class template specialization... if the specialization is implicitly instantiated because it is referenced from within another template specialization, if the context from which the specialization is referenced depends on a template parameter, and if the specialization is not instantiated previous to the instantiation of the enclosing template, the point of instantiation is immediately before the point of instantiation of the enclosing template. Otherwise, the point of instantiation for such a specialization immediately precedes the namespace scope declaration or definition that refers to the specialization.

That means that the point of instantiation of A<B<int> > is before that of B<int>, not in the middle of B<int> after the declaration of B::X, and consequently a reference to B<int>::X from A<B<int> > is ill-formed.

To put it another way, I believe John's approach requires that there be an instantiation stack, with the results of partially-instantiated templates on the stack being available to instantiations above them. I don't think the Standard mandates that approach; as far as I can see, simply determining the implicit instantiations that need to be done, rewriting the definitions at their respective points of instantiation with parameters substituted (with appropriate "forward declarations" to allow for non-instantiating references), and compiling the result normally should be an acceptable implementation technique as well. That is, the implicit instantiation of the example (using, e.g., B_int to represent the generated name of the B<int> specialization) could be something like

        struct B_int;

        struct A_B_int {
            B_int::X x;    // error, incomplete type
        };

        struct B_int {
            typedef int* X;
            A_B_int a;
        };

Notes from 10/01 meeting:

This was discussed at length. The consensus was that the template case should be treated the same as the non-template class case it terms of the order in which members get declared/defined and classes get completed.

Proposed resolution:

In 14.6.4.1 [temp.point] paragraph 3 change:

the point of instantiation is immediately before the point of instantiation of the enclosing template. Otherwise, the point of instantiation for such a specialization immediately precedes the namespace scope declaration or definition that refers to the specialization.

To:

the point of instantiation is the same as the point of instantiation of the enclosing template. Otherwise, the point of instantiation for such a specialization immediately precedes the nearest enclosing declaration. [Note: The point of instantiation is still at namespace scope but any declarations preceding the point of instantiation, even if not at namespace scope, are considered to have been seen.]

Add following paragraph 3:

If an implicitly instantiated class template specialization, class member specialization, or specialization of a class template references a class, class template specialization, class member specialization, or specialization of a class template containing a specialization reference that directly or indirectly caused the instantiation, the requirements of completeness and ordering of the class reference are applied in the context of the specialization reference.

and the following example

  template <class T> struct A {
          typename T::X x;
  };

  struct B {
          typedef int X;
          A<B> a;
  };

  template <class T> struct C {
          typedef T* X;
          A<C> a;
  };

  int main ()
  {
          C<int> c;
  }

Notes from the October 2002 meeting:

This needs work. Moved back to drafting status.



993. Freedom to perform instantiation at the end of the translation unit

Section: 14.6.4.1  [temp.point]     Status: drafting     Submitter: John Spicer     Date: 6 March, 2009

The intent is that it is a permissible implementation technique to do template instantiation at the end of a translation unit rather than at an actual point of instantiation. This idea is not reflected in the current rules, however.



212. Implicit instantiation is not described clearly enough

Section: 14.7.1  [temp.inst]     Status: drafting     Submitter: Christophe de Dinechin     Date: 7 Mar 2000

Three points have been raised where the wording in 14.7.1 [temp.inst] may not be sufficiently clear.

  1. In paragraph 4, the statement is made that
    A class template specialization is implicitly instantiated... if the completeness of the class type affects the semantics of the program...

    It is not clear what it means for the "completeness... [to affect] the semantics." Consider the following example:

            template<class T> struct A;
        extern A<int> a;

        void *foo() { return &a; }

        template<class T> struct A
        {
        #ifdef OPTION
                void *operator &() { return 0; }
        #endif
        };

    The question here is whether it is necessary for template class A to declare an operator & for the semantics of the program to be affected. If it does not do so, the meaning of &a will be the same whether the class is complete or not and thus arguably the semantics of the program are not affected.

    Presumably what was intended is whether the presence or absence of certain member declarations in the template class might be relevant in determining the meaning of the program. A clearer statement may be desirable.

  2. Paragraph 5 says,
    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.

    The intent of this wording, as illustrated in the example in that paragraph, is to allow a "smart" implementation not to instantiate class templates if it can determine that such an instantiation will not affect the result of overload resolution, even though the algorithm described in clause 13 [over] requires that all the viable functions be enumerated, including functions that might be found as members of specializations.

    Unfortunately, the looseness of the wording allowing this latitude for implementations makes it unclear what "the overload resolution process" is — is it the algorithm in 13 [over] or something else? — and what "the correct function" is.

  3. According to paragraph 6,
    If an implicit instantiation of a class template specialization is required and the template is declared but not defined, the program is ill-formed.

    Here, it is not clear what conditions "require" an implicit instantiation. From the context, it would appear that the intent is to refer to the conditions in paragraph 4 that cause a specialization to be instantiated.

    This interpretation, however, leads to different treatment of template and non-template incomplete classes. For example, by this interpretation,

        class A;
    template <class T> struct TA;
    extern A a;
    extern TA<int> ta;

    void f(A*);
    void f(TA<int>*);

    int main()
    {
        f(&a);    // well-formed; undefined if A
                  // has operator &() member
        f(&ta);   // ill-formed: cannot instantiate
    }

    A different approach would be to understand "required" in paragraph 6 to mean that a complete type is required in the expression. In this interpretation, if an incomplete type is acceptable in the context and the class template definition is not visible, the instantiation is not attempted and the program is well-formed.

    The meaning of "required" in paragraph 6 must be clarified.

(See also issues 204 and 63.)

Notes on 10/01 meeting:

It was felt that item 1 is solved by addition of the word "might" in the resolution for issue 63; item 2 is not much of a problem; and item 3 could be solved by changing "required" to "required to be complete".



529. Use of template<> with “explicitly-specialized” class templates

Section: 14.7.3  [temp.expl.spec]     Status: drafting     Submitter: James Widman     Date: 16 August 2005

Paragraph 17 of 14.7.3 [temp.expl.spec] says,

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.

This is curious, because paragraph 3 only allows explicit specialization of members of implicitly-instantiated class specializations, not explicit specializations. Furthermore, paragraph 4 says,

Definitions of members of an explicitly specialized class are defined in the same manner as members of normal classes, and not using the explicit specialization syntax.

Paragraph 18 provides a clue for resolving the apparent contradiction:

In an explicit specialization declaration for a member of a class template or a member template that appears in namespace scope, the member template and some of its enclosing class templates may remain unspecialized, except that the declaration shall not explicitly specialize a class member template if its enclosing class templates are not explicitly specialized as well. In such explicit specialization declaration, the keyword template followed by a template-parameter-list shall be provided instead of the template<> preceding the explicit specialization declaration of the member.

It appears from this and the following example that the phrase “explicitly specialized” in paragraphs 17 and 18, when referring to enclosing class templates, does not mean that explicit specializations have been declared for them but that their names in the qualified-id are followed by template argument lists. This terminology is confusing and should be changed.

Proposed resolution (October, 2005):

  1. Change 14.7.3 [temp.expl.spec] paragraph 17 as indicated:

    2. 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 specialization. [Example:...

  2. Change 14.7.3 [temp.expl.spec] paragraph 18 as indicated:

    3. In an explicit specialization declaration for a member of a class template or a member template that appears in namespace scope, the member template and some of its enclosing class templates may remain unspecialized, except that the declaration shall not explicitly specialize a class member template if its enclosing class templates are not explicitly specialized as well that is, the template-id naming the template may be composed of template parameter names rather than template-arguments. In For each unspecialized template in such an explicit specialization declaration, the keyword template followed by a template-parameter-list shall be provided instead of the template<> preceding the explicit specialization declaration of the member. The types of the template-parameters in the template-parameter-list shall be the same as those specified in the primary template definition. In such declarations, an unspecialized template-id shall not precede the name of a template specialization in the qualified-id naming the member. [Example:...

Notes from the April, 2006 meeting:

The revised wording describing “unspecialized” templates needs more work to ensure that the parameter names in the template-id are in the correct order; the distinction between template argyments and parameters is also probably not clear enough. It might be better to replace this paragraph completely and avoid the “unspecialized” wording altogether.

Proposed resolution (February, 2010):

  1. Change 14.7.3 [temp.expl.spec] paragraph 17 as follows:

    2. 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 specialization. [Example:...

  2. Change 14.7.3 [temp.expl.spec] paragraph 18 as follows:

    3. In an explicit specialization declaration for a member of a class template or a member template that appears in namespace scope, the member template and some of its enclosing class templates may remain unspecialized, except that the declaration shall not explicitly specialize a class member template if its enclosing class templates are not explicitly specialized as well. In such explicit specialization declaration, the keyword template followed by a template-parameter-list shall be provided instead of the template<> preceding the explicit specialization declaration of the member. The types of the template-parameters in the template-parameter-list shall be the same as those specified in the primary template definition. that is, the corresponding template prefix may specify a template-parameter-list instead of template<> and the template-id naming the template be written using those template-parameters as template-arguments. In such a declaration, the number, kinds, and types of the template-parameters shall be the same as those specified in the primary template definition, and the template-parameters shall be named in the template-id in the same order that they appear in the template-parameter-list. An unspecialized template-id shall not precede the name of a template specialization in the qualified-id naming the member. [Example:...


1170. Access checking during template argument deduction

Section: 14.8.2  [temp.deduct]     Status: drafting     Submitter: Adamczyk     Date: 2010-08-03

According to 14.8.2 [temp.deduct] paragraph 8,

Access checking is not done as part of the substitution process. Consequently, when deduction succeeds, an access error could still result when the function is instantiated.

This mimics the way access checking is done in overload resolution. However, experience has shown that this exemption of access errors from deduction failure significantly complicates the Standard library, so this rule should be changed.



692. Partial ordering of variadic class template partial specializations

Section: 14.8.2.5  [temp.deduct.type]     Status: drafting     Submitter: Doug Gregor     Date: 16 April, 2008

14.8.2.5 [temp.deduct.type] paragraph 22 describes how we cope with partial ordering between two function templates that differ because one has a function parameter pack while the other has a normal function parameter. However, this paragraph was meant to apply to template parameter packs as well, e.g., to help with partial ordering of class template partial specializations:

   template <class T1, class ...Z> class S; // #1
   template <class T1, class ...Z> class S<T1, const Z&...> {}; // #2
   template <class T1, class T2> class S<T1, const T2&> {};; // #3
   S<int, const int&> s; // both #2 and #3 match; #3 is more specialized

(See also issue 818.)

Proposed resolution (March, 2009):

Change 14.8.2.5 [temp.deduct.type] paragraphs 9-10 as follows (and add the example above to paragraph 9):

If P has a form that contains <T> or <i>, then each argument Pi of the respective template argument list of P is compared with the corresponding argument Ai of the corresponding template argument list of A. If the template argument list of P contains a pack expansion that is not the last template argument, the entire template argument list is a non-deduced context. If Pi is a pack expansion, then the pattern of Pi is compared with each remaining argument in the template argument list of A. Each comparison deduces template arguments for subsequent positions in the template parameter packs expanded by Pi. During partial ordering (14.8.2.4 [temp.deduct.partial]), if Ai was originally a pack expansion and Pi is not a pack expansion, or if P does not contain a template argument corresponding to Ai, argument deduction fails.

Similarly, if P has a form that contains (T), then each parameter type Pi of the respective parameter-type-list of P is compared with the corresponding parameter type Ai of the corresponding parameter-type-list of A. If the parameter-declaration corresponding to Pi is a function parameter pack, then the type of its declarator-id is compared with each remaining parameter type in the parameter-type-list of A. Each comparison deduces template arguments for subsequent positions in the template parameter packs expanded by the function parameter pack. During partial ordering (14.8.2.4 [temp.deduct.partial]), if Ai was originally a function parameter pack and Pi is not a function parameter pack, or if P does not contain a function parameter type corresponding to Ai, argument deduction fails. [Note: A function parameter pack can only occur at the end of a parameter-declaration-list (8.3.5 [dcl.fct]). —end note]



1165. Exceptions when destroying array elements

Section: 15.2  [except.ctor]     Status: drafting     Submitter: US     Date: 2010-08-03

N3092 comment US 78

According to 15.2 [except.ctor] paragraph 2,

An object that is partially constructed or partially destroyed will have destructors executed for all of its fully constructed base classes and non-variant members, that is, for subobjects for which the principal constructor (12.6.2 [class.base.init]) has completed execution and the destructor has not yet begun execution.

This wording leaves unclear whether the remaining elements of an array will be destroyed if the destructor for one of the elements exits via an exception: an array element is a subobject (1.8 [intro.object] paragraph 2), but it is not a base class or non-variant member.



1073. Merging dynamic-exception-specifications and noexcept-specifications

Section: 15.4  [except.spec]     Status: drafting     Submitter: Jason Merrill     Date: 2010-06-02

It is not clear how to handle compatible dynamic-exception-specifications and noexcept-specifications. For example, given

    void f() throw();
    void f() noexcept {
       throw 1;
    }

should we call terminate() or unexpected()? And for

    void g() throw (int);
    void g() noexcept (false) {
       throw 1.0;
    }

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

Alisdair Meredith:

And what about something like

    struct A { ~A() throw() { } };
    struct B { ~B() noexcept { } };
    struct C: A, B { };

What is the exception specification for C's destructor?





Issues with "Open" Status

248. Identifier characters

Section: _N2691_.E  [extendid]     Status: open     Submitter: John Spicer