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

This document is part of a group of related documents that together describe the issues that have been raised regarding the C++ Standard. The other documents in the group are:

• Active Issues List, which contains explanatory material for the entire document group and a list of the issues that have not yet been acted upon by the Committee.
• Closed Issues List, which contains the issues which the Committee has decided are not defects in the International Standard, including a brief rationale explaining the reason for the decision.
• Table of Contents, which contains a summary listing of all issues in numerical order.
• Index by Section, which contains a summary listing of all issues arranged in the order of the sections of the Standard with which they deal most directly.
• Index by Status, which contains a summary listing of all issues grouped by status.

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

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

Issues with "DR" Status

1441. Unclear wording for signal handler restrictions

[Moved to DR at the February, 2014 meeting as paper N3910.]

The wording of 1.9 [intro.execution] paragraph 6 is intended to describe the values of objects upon entry to and exit from the handler — i.e., that signal handler cannot rely on non-atomic objects being in a consistent state upon entry, nor can it reliably set the value of non-atomic objects and expect that they will continue to have those values after the handler exits. However, the wording could be read as saying even during the execution of the handler it cannot set and use non-atomic objects. The wording should be clarified.

1466. Visible sequences of side effects are redundant

[Moved to DR at the February, 2014 meeting as part of document N3914.]

[The following is reproduced verbatim from WG14 DR406 as a C-liaison issue.]

It has been mathematically proved that a simplification can be made to the memory model as it is specified in the final draft of the C++11 standard. Essentially, the restriction defining visible sequence of side effects (vsse) is redundant and can be removed with no ill effects. The main motivation for doing this is that the current restriction is misleading. 5.1.2.4p22 defines vsse's:

The visible sequence of side effects on an atomic object M, with respect to a value computation B of M, is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first side effect is visible with respect to B, and for every subsequent side effect, it is not the case that B happens before it. The value of an atomic object M, as determined by evaluation B, shall be the value stored by some operation in the visible sequence of M with respect to B.

The wording of this paragraph makes it seem as if the vsse identifies the writes that an atomic read is allowed to read from, but this is not the case. There can be writes in the vsse that cannot be read due to the coherence requirements (to be included in C, 1.10p15 through 1.10p18 in C++ N3291). Consequently this is even more confusing than it at first appears.

Also propose changing 5.1.2.4p22 to the following:

The value of an atomic object M, as determined by evaluation B, shall be the value stored by some side effect A that modifies M, where B does not happen before A.

With a note to remind the reader of the coherence requirements:

NOTE: The set of side effects that a given evaluation might take its value from is also restricted by the rest of the rules described here, and in particular, by the coherence requirements below

If the committee is concerned about allowing a differing text from C++11, then a note could be added to assure the reader:

NOTE: Although the rules for multi-threaded executions differ here from those of C++11, the executions they allow are precisely the same. Visible sequences of side effects are a redundant restriction.

Proposed resolution (January, 2014) [SSUPERSEDED]:

1. Change 1.10 [intro.multithread] paragraph 14 as follows:

The visible sequence of side effects on an atomic object M, with respect to a value computation B of M, is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first side effect is visible with respect to B, and for every side effect, it is not the case that B happens before it. The value of an atomic object M, as determined by evaluation B, shall be the value stored by some operation in the visible sequence of M with respect to B side effect A that modifies M, where B does not happen before A. [Note: It can be shown that the visible sequence of side effects of a value computation is unique given The set of side effects that a given evaluation might take its value from is also restricted by the rest of the rules described here, and in particular, by the coherence requirements below. —end note]

2. Change 1.10 [intro.multithread] paragraph 20 as follows:

[Note: The visible sequence of side effects value observed by a load of an atomic depends on the “happens before” relation, which depends on the values observed by loads of atomics, which we are restricting here. The intended reading is that there must exist an association of atomic loads with modifications they observe that, together with suitably chosen modification orders and the “happens before” relation derived as described above, satisfy the resulting constraints as imposed here. —end note]

3. Change 1.10 [intro.multithread] paragraph 22 as follows:

[Note: Compiler transformations that introduce assignments to a potentially shared memory location that would not be modified by the abstract machine are generally precluded by this standard, since such an assignment might overwrite another assignment by a different thread in cases in which an abstract machine execution would not have encountered a data race. This includes implementations of data member assignment that overwrite adjacent members in separate memory locations. Reordering of atomic loads in cases in which the atomics in question may alias is also generally precluded, since this may violate the “visible sequence” coherence rules. —end note]

4. Change 29.3 [atomics.order] paragraph 3 as follows:

There shall be a single total order S on all memory_order_seq_cst operations, consistent with the “happens before” order and modification orders for all affected locations, such that each memory_order_seq_cst operation B that loads a value from an atomic object M observes one of the following values:

• the result of the last modification A of M that precedes B in S, if it exists, or

• if A exists, the result of some modification of M in the visible sequence of side effects with respect to B that is not memory_order_seq_cst and that does not happen before A, or

• if A does not exist, the result of some modification of M in the visible sequence of side effects with respect to B that is not memory_order_seq_cst.

[Note:...

1775. Undefined behavior of line splice in raw string literal

[Moved to DR at the February, 2014 meeting.]

According to phase 2 of 2.2 [lex.phases] paragraph 1,

Each instance of a backslash character (\) immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines. Only the last backslash on any physical source line shall be eligible for being part of such a splice. If, as a result, a character sequence that matches the syntax of a universal-character-name is produced, the behavior is undefined.

There does not appear to be a good reason for the behavior to be undefined when the line splice occurs within a raw string literal, since the splicing will be reverted (2.5 [lex.pptoken] paragraph 3).

Proposed resolution (September, 2013):

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

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

1759. UTF-8 code units in plain char

[Moved to DR at the February, 2014 meeting as part of document N3914.]

A UTF-8 string literal might result in a code unit with the value 0x80. However, plain char is not guaranteed to be able to represent 0x80.

1741. odr-use of class object in lvalue-to-rvalue conversion

[Moved to DR at the February, 2014 meeting.]

According to 4.1 [conv.lval] paragraph 2,

if the glvalue has a class type, the [lvalue-to-rvalue] conversion copy-initializes a temporary of type T from the glvalue and the result of the conversion is a prvalue for the temporary.

The implications of such a conversion for odr-use do not appear to have been factored into 3.2 [basic.def.odr] paragraph 3, which exempts constant objects that are immediately lvalue-to-rvalue converted. For example, given

  struct S { int n; };
  struct T {
    static constexpr S s = {};
  };
  void f(...);
  void g() { f(T::s); }

Does this odr-use T::s, requiring it to have a definition, because of binding it to the reference parameter of S's copy constructor? How about

  struct S { int n; };
  void f(...);
  void g() {
    constexpr S s = {};
    [] { f(s); };
  }

Does s need to be captured? There is implementation variance on both these examples.

Proposed resolution (September, 2013):

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

A variable x whose name appears as a potentially-evaluated expression ex is odr-used unless x satisfies the requirements for appearing in a constant expression (5.19 [expr.const]) applying the lvalue-to-rvalue conversion (4.1 [conv.lval]) to x yields a constant expression (5.19 [expr.const]) that does not invoke any non-trivial functions and, if x is an object, ex is an element of the set of potential results of an expression e, where either the lvalue-to-rvalue conversion (4.1 [conv.lval]) is applied to e, or e is a discarded-value expression (Clause 5 [expr]). this is odr-used...

1690. Associated namespace for local type

[Moved to DR at the February, 2014 meeting.]

We can return a lambda or an object of a local class type from a lambda in c++11, and we can return them from normal functions in c++14. If those lambdas and normal functions are in a namespace, the returned lambdas/local-classes apparently aren't in that namespace, or even if they are, ADL won't find them. Is this intended?

(See also issue 1664.)

Proposed resolution (September, 2013):

This issue is resolved by the resolution of issue 1691.

1691. Argument-dependent lookup and opaque enumerations

[Moved to DR at the February, 2014 meeting.]

According to 3.4.2 [basic.lookup.argdep] paragraph 2,

If T is an enumeration type, its associated namespace is the namespace in which it is defined. If it is class member, its associated class is the member's class; else it has no associated class.

This does not take into account opaque enumerations, which can be defined in an enclosing namespace of the one of which is a member.

Proposed resolution (September, 2013):

Change 3.4.2 [basic.lookup.argdep] paragraph 2 as follows:

...The sets of namespaces and classes are determined in the following way:

• ...

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

• If T is an enumeration type, its associated namespace is the innermost enclosing namespace in which it is defined of its declaration. If it is a class member, its associated class is the member's class; else it has no associated class.

• ...

This resolution also resolves issues 1690 and 1692.

1692. Associated namespaces of doubly-nested classes

[Moved to DR at the February, 2014 meeting.]

According to 3.4.2 [basic.lookup.argdep] paragraph 2,

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

Consider an example like

  struct A {
    struct B {
      struct C { };
    };
  };

A has one associated class, itself, and has the global namespace as its associated namespace. A::B has two associated classes, A and itself, and by virtue of its association with A, has the global namespace as its associated namespace. A::B::C has two associated classes, A::B and itself. However, because neither A::B nor A::B::C is a member of a namespace, A::B::C has no associated namespaces.

This seems like a defect.

Proposed resolution (September, 2013):

This issue is resolved by the resolution of issue 1691.

1747. Constant initialization of reference to function

[Moved to DR at the February, 2014 meeting.]

According to 3.6.2 [basic.start.init] paragraph 2,

...Constant initialization is performed:

• if each full-expression (including implicit conversions) that appears in the initializer of a reference with static or thread storage duration is a constant expression (5.19 [expr.const]) and the reference is bound to an lvalue designating an object with static storage duration or to a temporary (see 12.2 [class.temporary]);

• ...

This wording, presumably inadvertently, excludes a reference to a function from being constant initialization.

Proposed resolution (January, 2014):

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

...Constant initialization is performed:

• if each full-expression (including implicit conversions) that appears in the initializer of a reference with static or thread storage duration is a constant expression (5.19 [expr.const]) and the reference is bound to an lvalue designating an object with static storage duration, or to a temporary (see 12.2 [class.temporary]), or to a function;

• ...

1746. Are volatile scalar types trivially copyable?

[Moved to DR at the February, 2014 meeting.]

According to 3.9 [basic.types] paragraph 9,

Arithmetic types (3.9.1 [basic.fundamental]), enumeration types, pointer types, pointer to member types (3.9.2 [basic.compound]), std::nullptr_t, and cv-qualified versions of these types (3.9.3 [basic.type.qualifier]) are collectively called scalar types... Scalar types, trivially copyable class types (Clause 9 [class]), arrays of such types, and non-volatile const-qualified versions of these types (3.9.3 [basic.type.qualifier]) are collectively called trivially copyable types.

This is confusing, because “scalar types” include volatile-qualified types, but the intent of the definition of “trivially copyable type” appears to be to exclude volatile-qualified types. Perhaps the second quoted sentence should read something like,

A non-volatile type T or an array of such T is called a trivially copyable type if T is either a scalar type or a trivially copyable class type.

(Note that the following sentence, defining “trivial type,” has a similar formal issue, although it has no actual significance because all cv-qualifiers are permitted.)

Proposed resolution (January, 2014):

Change 3.9 [basic.types] paragraph 10 as follows:

...Scalar Cv-unqualified scalar types, trivially copyable class types (Clause 9 [class]), arrays of such types, and non-volatile const-qualified versions of these types (3.9.3 [basic.type.qualifier]) are collectively called trivially copyable types...

1773. Out-of-lifetime lvalue-to-rvalue conversion

[Moved to DR at the February, 2014 meeting.]

Consider an example like the following:

  struct Base { 
    virtual int call() = 0; 
  }; 
  Base *foo() { 
    constexpr int x = 0; 
    struct Local : Base { 
      virtual int call() { return x; } 
    }; 
    static Local local; 
    return &local; 
  } 

  int main() { 
    return foo()->call(); 
  } 

While the likely intention is that the lvalue-to-rvalue conversion of the block-scope constant is implemented by using the value of the constant expression in place of reading from storage, it seems that the wording of 4.1 [conv.lval] paragraph 2 does not prevent this program from being subject to undefined behaviour caused by lifetime violation. In particular, it seems that a name expression that appears in a potentially-evaluated expression such that the object named is not odr-used (by that instance of the name) may still be evaluated, in theory, as an lvalue through which the object named or a subobject thereof is accessed.

Proposed resolution (September, 2013):

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

When an lvalue-to-rvalue conversion occurs in an unevaluated operand or a subexpression thereof (Clause 5 [expr]) is applied to an expression e, and either

• e is not potentially evaluated, or

• the evaluation of e results in the evaluation of a member ex of the set of potential results of e, and ex names a variable x that is not odr-used by ex (3.2 [basic.def.odr]),

the value contained in the referenced object is not accessed. [Example:

  struct S { int n; };
  auto f() {
    S x { 1 };
    constexpr S y { 2 };
    return [&](bool b) { return (b ? y : x).n; };
  }
  auto g = f();
  int m = g(false); // undefined behavior due to access of x.n outside its lifetime
  int n = g(true);  // OK, does not access y.n

—end example] In all other cases, the result of the conversion...

1787. Uninitialized unsigned char values

[Moved to DR at the February, 2014 meeting as part of document N3914.]

The current wording of 4.1 [conv.lval] gives the result of fetching an uninitialized unsigned character an unspecified value, which is then stable: assigned to a different variable, it will be the same throughout the lifetime of that variable. It would be more helpful to optimizers for the unspecified value to be viral, so that fetching from the second variable would also yield an unspecified result, not necessarily the same each time.

1607. Lambdas in template parameters

[Moved to DR at the February, 2014 meeting.]

Lambda expressions cannot appear in unevaluated operands nor in evaluated portions of constant expressions. However, the following example appears to circumvent those restrictions:

  template <bool> struct BoolSink { typedef void type; };

  template <typename T, typename U>
  struct AddRvalueReferenceImpl { typedef T type; };

  template <typename T>
  struct AddRvalueReferenceImpl<T, typename BoolSink<false &&
     [] {
       extern T &&tref;
     }>::type> {
    typedef T &&type;
  };

  template <typename T>
  struct AddRvalueReference : AddRvalueReferenceImpl<T, void> { };

  namespace ImplHelpers {
    template <typename T>
    typename AddRvalueReference<T>::type create(void) { }
  }

  template <typename T, typename U, typename ...Args>
  struct IsConstructibleImpl { enum { value = 0 }; };

  template <typename T, typename ...Args>
  struct IsConstructibleImpl<T, typename BoolSink<false &&
     [] {
       T t( ::ImplHelpers::create<Args>() ...);
     }>::type, Args ...> {
    enum { value = 1 };
  };

  template <typename T, typename ...Args>
  struct IsConstructible : IsConstructibleImpl<T, void, Args ...> { };

  struct DestroyMe {
    ~DestroyMe() = delete;
  };

  static_assert(+IsConstructible<int>::value, "error");
  static_assert(!IsConstructible<void>::value, "error");
  static_assert(+IsConstructible<int [1]>::value, "error");
  static_assert(!IsConstructible<DestroyMe>::value, "error");
  static_assert(!IsConstructible<int *, char *>::value, "error");

  static_assert(+IsConstructible<int &&, int>::value, "error");
  static_assert(!IsConstructible<int &&, int &>::value, "error");
  static_assert(+IsConstructible<int &&, int &&>::value, "error");

Is this intended?

Additional notes, April, 2013:

Further discussion has arisen regarding lambda-expressions in function template signatures. Although the restriction that lambda-expressions cannot appear as unevaluated operands (5.1.2 [expr.prim.lambda] paragraph 2) was intended to avert the need to deal with them in function template signatures, the fact that 5.19 [expr.const] treats unevaluated subexpressions separately from unevaluated operands opens another avenue for lambda-expressions in template signatures, e.g.,

  template<typename T>
  void f(int [(0 && [] { for (auto x : T()) {} }, 1)]);

Four possible approaches for dealing with this issue have been suggested:

1. Allow lambda-expressions in function template signatures. This would be costly in some implementations.

2. Give a function template internal linkage if its signature includes a lambda-expression. This would allow SFINAE and redeclaration to work without requiring that lambda-expressions be mangled.

3. Specify that a function signature containing a lambda-expression is not a redeclaration of any other function template, which would allow SFINAE to work but not require declaration matching and mangling.

4. Do not allow lambda-expressions in function template signatures.

If any of these approaches were adopted, the rationale for disallowing lambda-expressions in unevaluated operands would be removed, so it might make sense to remove the restriction at the same time.

Proposed resolution (September, 2013):

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

...A lambda-expression shall not appear in an unevaluated operand (Clause 5 [expr]), in a template-argument, in an alias-declaration, in a typedef declaration, or in the declaration of a function or function template outside its function body and default arguments. [Note: The intention is to prevent lambdas from appearing in a signature —end note]. [Note: A closure object behaves like a function object (20.9 [function.objects]). —end note]

1612. Implicit lambda capture and anonymous unions

[Moved to DR at the February, 2014 meeting.]

It is not clear from the description of capturing in 5.1.2 [expr.prim.lambda] whether an implicit capture resulting from the odr-use of a member of an anonymous union captures that member or the anonymous union, and there is implementation divergence. For example,

  int main() {
    static int result;
    struct A { int x; };
    struct B { int y; };
    union {
      A a; B b;
    };
    a.x = 1;
    [=]() mutable { a.x = 2; result = b.y; }();
    if (result == 1) return 0;
    throw 0;
  }

Notes from the April, 2013 meeting:

CWG decided that an attempt to capture a member of an anonymous union should be ill-formed.

Proposed resolution (September, 2013):

1. Change 5.1.2 [expr.prim.lambda] paragraph 15 as follows:

...An array of runtime bound (8.3.4 [dcl.array]) or a member of an anonymous union shall not be captured by copy.

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

...It is unspecified whether additional unnamed non-static data members are declared in the closure type for entities captured by reference. A member of an anonymous union shall not be captured by reference. [Note:...

1613. Constant expressions and lambda capture

[Moved to DR at the February, 2014 meeting.]

Since instances of a variable in constant expressions may be odr-uses, the ordering of:

• constant expression evaluation,

• the determination of implicit captures, and

• the transformation to use closure members for odr-uses of captured variables

may affect the semantics of a program such as the one below.

The transformation under 5.1.2 [expr.prim.lambda] paragraph 17 introduces uses of the this pointer of the operator() in its function-body. These instances of this are invalid under issue 1369 if the transformation is applied before the evaluation of the constant expressions. Without the resolution of issue 1369, another situation occurs where instances of this in the compound-statement are transformed into class member access expressions (see the initializations of addrEqA and addrEqB below).

Also, for the initialization of nonZero below, the expression fails to be a constant expression if the transformation is applied before constant expression evaluation.

Finally, the answer to the static assertion changes depending on whether the constant expression evaluation is performed before the transformation as opposed to after and whether the proposed resolution issue 1472 is enabled.

There appears to be implementation divergence regarding

• whether the lexical instances of this in the initialization of addrEqB is valid and

• whether the static assertion should pass.

Using explicit value captures is not a panacea, since the paragraph 17 transformations only apply to odr-uses. As a result of the resolution of issue 1472, if the reference r below happened to have been initialized with a constant expression, the value of its (modifiable) target is not captured; if the same target were specified in the initialization of the reference with a non-constant expression, its value would be captured.

  struct A {
    void foo();
  };

  struct LitType { int val; };
  constexpr int ceFunc(const LitType &x) { return x.val; }

  void A::foo() {
    constexpr LitType y = { 0 };
    static int z;
    int x, &r = z;
    [=] {
     constexpr bool addrEqA = &x == &x;         // ill-formed under issue 1369 after transformation
                                                // under paragraph 17
     constexpr bool addrEqB = &*this == &*this; // well-formed after transformation under N3290
                                                // paragraph 17
     constexpr bool nonZero = ceFunc(y);        // lvalue-to-rvalue conversion occurs only after
                                                // function invocation substitution; the closure member,
                                                // being not a variable, cannot be constexpr
     static_assert(&r != &z,
       "reference which could be captured by value found to alias target");
                                                // affected by issue 1472
    };
  }

Proposed resolution (September, 2013):

Add the following bullet to 5.19 [expr.const] paragraph 2:

A conditional-expression e is a core constant expression unless the evaluation of e, following the rules of the abstract machine (1.9 [intro.execution]), would evaluate one of the following expressions:

• ...

• in a lambda-expression, a reference to this or to a variable with automatic storage duration defined outside that lambda-expression, where the reference would be an odr-use (3.2 [basic.def.odr], 5.1.2 [expr.prim.lambda]);

• a conversion from type cv void * to a pointer-to-object type;

• ...

1629. Can a closure class be a literal type?

[Moved to DR at the February, 2014 meeting.]

The description of the characteristics of a closure class in 5.1.2 [expr.prim.lambda] leaves open the possibility that such a class might be a literal type, although it could also be a non-literal type. It would probably be good to specify that a closure class is not a literal type, in the interests of portability.

On a related note, it might be wise to remove the implementation freedom to make a closure class either a POD or not a POD; it seems only to be an invitation for portability problems with no real advantage.

Additional note, April, 2013:

Some have expressed the opinion that such portability issues are just “par for the course,” and that specifying these characteristics at this point might unnecessarily limit the ability to extend the language in desirable directions at some point in the future.

Proposed resolution (April, 2013) [superseded]:

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

...An implementation may define the closure type differently from what is described below provided this does not alter the observable behavior of the program other than by changing:

• the size and/or alignment of the closure type,

• whether the closure type is trivially copyable (Clause 9 [class]),

• whether the closure type is a literal type (3.9 [basic.types]),

• whether the closure type is a standard-layout class (Clause 9 [class]), or

• whether the closure type is a POD class (Clause 9 [class]).

Notes from the September, 2013 meeting:

At the suggestion of EWG, it was decided that closure types should be specified as not literal, rather than being unspecified as in the April, 2013 proposed resolution. The issue has thus been returned to "drafting" status.

Proposed resolution (January, 2014):

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

The type of the lambda-expression (which is also the type of the closure object) is a unique, unnamed non-union class type — called the closure type — whose properties are described below. This class type is not neither an aggregate (8.5.1 [dcl.init.aggr]) nor a literal type (3.9 [basic.types]). The closure type is declared...

1662. Capturing function parameter packs

[Moved to DR at the February, 2014 meeting.]

The example in 5.1.2 [expr.prim.lambda] paragraph 24 reads,

  template<class... Args>
  void f(Args... args) {
    auto lm = [&, args...] { return g(args...); };
    lm();
  }

However, it's not clear how this example squares with the requirements in paragraph 10,

The identifier in a simple-capture is looked up using the usual rules for unqualified name lookup (3.4.1 [basic.lookup.unqual]); each such lookup shall find a variable with automatic storage duration declared in the reaching scope of the local lambda expression.

since a function parameter pack is not a variable. Although the requirement might be met in a given specialization of the function template, is there a rule that relaxes it in the context of the function template definition?

Proposed resolution (September, 2013):

1. Change 5.1.2 [expr.prim.lambda] paragraph 10 as follows:

The identifier in a simple-capture is looked up using the usual rules for unqualified name lookup (3.4.1 [basic.lookup.unqual]); each such lookup shall find an entity. An entity that is designated by a simple-capture is said to be explicitly captured, and shall be this or a variable with automatic storage duration declared in the reaching scope of the local lambda expression. An entity (i.e. a variable or this) is said to be explicitly captured if it is found by this process.

2. Change 14.5.3 [temp.variadic] paragraph 4 as follows:

...Pack expansions can occur in the following contexts:

• ...

For the purpose of determining whether a parameter pack satisfies a rule regarding entities other than parameter packs, the parameter pack is considered to be the entity that would result from an instantiation of the pattern in which it appears.

[Example:

...

3. Change 14.5.3 [temp.variadic] paragraph 6 as follows:

...Each E_i is generated by instantiating the pattern and replacing each pack expansion parameter with its ith element. Such an element, in the context of the instantiation, is interpreted as follows:

• if the pack is a template parameter pack, the element is a template parameter (14.1 [temp.param]) of the corresponding kind (type or non-type) designating the type or value from the template argument; otherwise,

• if the pack is a function parameter pack, the element is an id-expression designating the function parameter that resulted from the instantiation of the pattern where the pack is declared.

All of the E_i become elements in the enclosing list. [Note:...

1664. Argument-dependent lookup of lambdas used in default arguments

[Moved to DR at the February, 2014 meeting.]

According to 5.1.2 [expr.prim.lambda] paragraph 3,

The closure type is declared in the smallest block scope, class scope, or namespace scope that contains the corresponding lambda-expression. [Note: This determines the set of namespaces and classes associated with the closure type (3.4.2 [basic.lookup.argdep]). The parameter types of a lambda-declarator do not affect these associated namespaces and classes. —end note]

However, 14.7.1 [temp.inst] paragraph 13 says,

If a function template f is called in a way that requires a default argument to be used, the dependent names are looked up, the semantics constraints are checked, and the instantiation of any template used in the default argument is done as if the default argument had been an initializer used in a function template specialization with the same scope, the same template parameters and the same access as that of the function template f used at that point.

A possibility, then, is that the closure type for a lambda expression in a default argument for a template function (or, presumably, a member function of a class template) is to be considered as having been declared in some block scope in the body of the fictional function template specialization.

Consider the following example:

  namespace J {
    inline namespace K {
      template <typename T> int zap(const T &t) { foo(t); return 0; }
      template <typename T> void zip(int = zap([] { })) { }
    }
    template <typename T> void foo(const T &) { }
  }
  void bar() { J::K::zip<long>(); }

If zip were not a template, argument-dependent lookup successfully resolves the lookup for foo in all implementations tested; however, there is implementation variance in the handling of the example as written.

(See also issue 1690.)

Proposed resolution (September, 2013):

Change 14.7.1 [temp.inst] paragraph 13 as follows:

If a function template f is called in a way that requires a default argument to be used, the dependent names are looked up, the semantics constraints are checked, and the instantiation of any template used in the default argument is done as if the default argument had been an initializer used in a function template specialization with the same scope, the same template parameters and the same access as that of the function template f used at that point, except that the scope in which a closure type is declared (5.1.2 [expr.prim.lambda]) — and therefore its associated namespaces — remain as determined from the context of the definition for the default argument. This analysis is called default argument instantiation. The instantiated default argument is then used as the argument of f.

1772. __func__ in a lambda body

[Moved to DR at the February, 2014 meeting.]

It is not clear whether __func__ in the body of a lambda refers to the operator() of the closure class or to the containing function (if any). Since lambdas can appear in non-function scope, it would be preferable for them to refer to the closure class's operator().

Proposed resolution (September, 2013):

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

The lambda-expression's compound-statement yields the function-body... —end example] Further, a variable __func__ is implicitly defined at the beginning of the compound-statement of the lambda-expression, with semantics as described in 8.4.1 [dcl.fct.def.general].

1376. static_cast of temporary to rvalue reference

[Moved to DR at the February, 2014 meeting.]

In a declaration like

    T&& r = static_cast<T&&>(T());

it is not clear what the lifetime of the T temporary should be. According to 5.2.9 [expr.static.cast] paragraph 4, the static_cast is equivalent to a declaration of an invented temporary variable t. The lifetime of the temporary is extended to that of t, but it is not clear what that lifetime should be, nor if the subsequent binding of t to r would affect the lifetime of the original temporary. (See also issue 1568.)

Notes from the February, 2012 meeting:

The reference is bound to the xvalue result of the static_cast, so the lifetime of the temporary is not extended and this example results in a dangling reference.

Proposed resolution (February, 2012) [SUPERSEDED]:

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

Otherwise, an expression e can be explicitly converted to a type T using a static_cast of the form static_cast<T>(e) if the declaration T t(e); is well-formed, for some invented temporary variable t (8.5 [dcl.init]). The effect...

Proposed resolution (September, 2013):

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

A glvalue, class prvalue, or array prvalue of type “cv1 T1” can be cast to type “rvalue reference to cv2 T2” if “cv2 T2” is reference-compatible with “cv1 T1” (8.5.3 [dcl.init.ref]). If the glvalue value is not a bit-field, the result refers to the object or the specified base class subobject thereof; otherwise, the lvalue-to-rvalue conversion (4.1 [conv.lval]) is applied to the bit-field and the resulting prvalue is used as the expression of the static_cast for the remainder of this section. If T2 is an inaccessible (Clause 11 [class.access]) or ambiguous (10.2 [class.member.lookup]) base class of T1, a program that necessitates such a cast is ill-formed.

1739. Conversion of floating point to enumeration

[Moved to DR at the February, 2014 meeting.]

The specification of conversion from integral or enumeration type in 5.2.9 [expr.static.cast] paragraph 10 uses the phrase “explicitly converted,” while the description of conversion from floating point to enumeration omits the word “explicitly.” Presumably these should be harmonized.

Proposed resolution (January, 2014):

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

...A value of floating-point type can also be explicitly converted to an enumeration type...

1786. Effect of merging allocations on memory leakage

[Applied to WP at the February, 2014 meeting as part of document N3914.]

The strategy of merging allocations could turn a small memory leak into a big one. For example,

  class P { 
    int x; 
  }; 
  class Q { 
  public: 
    Q(){ throw 42; } 
  private:
    int x[LARGE_NUMBER]; 
  }; 

  { 
    P* p1 = new P(); 
    Q* q1 = new Q(); // bang :-( 
    // don't get here 
    delete q1; 
    delete p1; 
  } 

Instead of just leaking the first allocation, this could result in leaking the combined allocation.

Notes from the September, 2013 meeting:

EWG was not so concerned with memory leaks, but there are problems with the current wording dealing with lifetime issues. In particular, the existing wording did not guarantee that all of the merged allocations would, in fact, be executed. The intended direction is to relax the strict lifetime containment requirement from the current wording but to ensure that all of the allocations and frees will be executed, which requires that the allocation and initialization of later objects be non-throwing.

1598. Criterion for equality of pointers to members

[Moved to DR at the February, 2014 meeting.]

According to 5.10 [expr.eq] paragraph 2, pointers to data members compare equal

if and only if they would refer to the same member of the same most derived object (1.8 [intro.object]) or the same subobject if indirection with a hypothetical object of the associated class type were performed.

This specification is overly constrained. For data members, most implementations simply compare the offsets of the members involved, violating the “only if” part of the specification. For example:

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

  int A::*bx = (int(A::*))&B::x;
  int A::*cx = (int(A::*))&C::x;

  bool b1 = bx == cx;

The existing wording requires b1 to have the value false, even though the offsets of the members are the same. It would be better if the result of the comparison were unspecified unless the class containing the original member for the LHS is a base or derived class of the class containing the original member for the RHS.

Proposed resolution (January, 2014):

Change 5.10 [expr.eq] paragraph 3 as follows:

...Comparing pointers to members is defined as follows:

• ...

• If either is a pointer to a virtual member function, the result is unspecified.

• If one refers to a member of class C1 and the other refers to a member of a different class C2, where neither is a base class of the other, the result is unspecified. [Example:

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

    int A::*bx = (int(A::*))&B::x;
    int A::*cx = (int(A::*))&C::x;

    bool b1 = (bx == cx);   // unspecified

—end example]

• Two Otherwise, two pointers to members compare equal if they would refer to the same member of the same most derived object (1.8 [intro.object]) or the same subobject if indirection with a hypothetical object of the associated class type were performed, otherwise they compare unequal. [Example:

  struct B {
    int f();
  };
  struct L : B { };
  struct R : B { };
  struct D : L, R { };

  int (B::*pb)() = &B::f;
  int (L::*pl)() = pb;
  int (R::*pr)() = pb;
  int (D::*pdl)() = pl;
  int (D::*pdr)() = pr;
  bool x = (pdl == pdr);   // false
  bool y = (pb == pl);     // true

—end example]

1732. Defining types in conditions and range-based for statements

[Moved to DR at the February, 2014 meeting.]

The interaction of various issue resolutions has inadvertently resulted in the loss of the prohibition of defining types in conditions (6.4 [stmt.select] paragraph 1) and in a range-based for (6.5 [stmt.iter] paragraph 1). Issue 686 addressed a patchwork of restrictions by banning type definitions in type-specifier-seqs. Issue 948 then changed the definition of condition to use a decl-specifier-seq instead of a type-specifier-seq in order to permit the constexpr specifier. A similar change was made for range-based for statements by issue 1204.

The restrictions against type definitions in these contexts should be restored.

Proposed resolution (January, 2014):

1. Change 6.4 [stmt.select] paragraph 2 as follows:

The rules for conditions apply both to selection-statements and to the for and while statements (6.5 [stmt.iter]). The declarator shall not specify a function or an array. The decl-specifier-seq shall not define a class or enumeration. If the auto type-specifier appears in the decl-specifier-seq, the type of the identifier being declared is deduced from the initializer as described in 7.1.6.4 [dcl.spec.auto].

2. Change 6.5.4 [stmt.ranged] paragraph 2 as follows:

In the decl-specifier-seq of a for-range-declaration, each decl-specifier shall be either a type-specifier or constexpr. The decl-specifier-seq shall not define a class or enumeration.

1767. Scoped enumeration in a switch statement

[Moved to DR at the February, 2014 meeting.]

The description of the switch statement and case labels in 6.4.2 [stmt.switch] paragraph 2 apply integral promotions to the condition value and refer to the “promoted type” of the condition. However, the integral promotions (4.5 [conv.prom]) do not describe the result when they are applied to a scoped enumeration value.

Proposed resolution (September, 2013):

Change 6.4.2 [stmt.switch] paragraph 2 as follows:

The condition shall be of integral type, enumeration type, or class type. If of class type, the condition is contextually implicitly converted (Clause 4 [conv]) to an integral or enumeration type. Integral promotions are performed. If the (possibly converted) type is subject to integral promotions (4.5 [conv.prom]), the condition is converted to the promoted type. Any statement within the switch statement can be labeled with one or more case labels as follows:

case constant-expression :

where the constant-expression shall be a converted constant expression (5.19 [expr.const]) of the promoted adjusted type of the switch condition. No two of the case constants in the same switch shall have the same value after conversion to the promoted type of the switch condition.

1707. template in elaborated-type-specifier without nested-name-specifier

[Moved to DR at the February, 2014 meeting.]

The grammar for elaborated-type-specifier in 7.1.6.3 [dcl.type.elab] reads, in part,

elaborated-type-specifier:
class-key nested-name-specifier_opt template_opt simple-template-id

This allows use of the template keyword without a nested-name-specifier, e.g., struct template S<int>. This is inconsistent with other uses of the template keyword. It might be better to split the production in two and only allow the keyword following a nested-name-specifier, i.e.,

elaborated-type-specifier:
class-key simple-template-id
class-key nested-name-specifier template_opt simple-template-id

Proposed resolution (January, 2014):

Change the grammar in 7.1.6.3 [dcl.type.elab] as follows:

elaborated-type-specifier:
class-key attribute-specifier-seq_opt nested-name-specifier_opt identifier
class-key simple-template-id
class-key nested-name-specifier_opt template_opt simple-template-id
enum nested-name-specifier_opt identifier

1765. Overflow of enumeration used as enumerator value

[Moved to DR at the February, 2014 meeting.]

Regarding the value of an enumerator whose enumeration's underlying type is not fixed, 7.2 [dcl.enum] paragraph 5 says,

the type of the initializing value is the same as the type of the initializing value of the preceding enumerator unless the incremented value is not representable in that type, in which case the type is an unspecified integral type sufficient to contain the incremented value.

It is not clear how this is to be applied when the preceding enumerator value is given by an enumerator whose value is the largest of its enumeration's values, and there is implementation variance on this point.

Proposed resolution (September, 2013):

Change 7.2 [dcl.enum] paragraph 5 as follows:

...If the underlying type is fixed, the type of each enumerator enumerator prior to the closing brace is the underlying type and the constant-expression in the enumerator-definition shall be a converted constant expression of the underlying type (5.19 [expr.const]); if the initializing value of an enumerator cannot be represented by the underlying type, the program is ill-formed. If the underlying type is not fixed, the type of each enumerator prior to the closing brace is the type of its initializing value determined as follows:

• If an initializer is specified for an enumerator, the initializing value the constant-expression shall be an integral constant expression (5.19 [expr.const]). If the expression has unscoped enumeration type, the enumerator has the underlying type of that enumeration type, otherwise it has the same type as the expression and the constant-expression shall be an integral constant expression (5.19 [expr.const]).

• If no initializer is specified for the first enumerator, the initializing value has its type is an unspecified integral type.

• Otherwise the type of the initializing value enumerator is the same as the type that of the initializing value of the preceding enumerator unless the incremented value is not representable in that type, in which case the type is an unspecified integral type sufficient to contain the incremented value. If no such type exists, the program is ill-formed.

1689. Syntactic nonterminal for operand of alignas

[Moved to DR at the February, 2014 meeting.]

Issue 1323 dealt with correcting the specification of the operand of alignas, which was originally given as the nonexistent term alignment-expression. It was corrected editorially to match the use of assignment-expression in 7.6.2 [dcl.align].

In 7.6.2 [dcl.align] paragraph 2, the expression is semantically constrained to be an integral constant expression. Since a constant-expression is syntactically a conditional-expression rather than an assignment-expression, it would probably make sense to change the syntactic nonterminal for the operand of alignas to be either a constant-expression or a conditional-expression.

Proposed resolution (November, 2013):

1. Change 7.6.1 [dcl.attr.grammar] paragraph 1 as follows:

alignment-specifier:
alignas ( type-id ..._opt )
alignas ( assignment-expression constant-expression ..._opt )

2. Change 7.6.2 [dcl.align] paragraph 2 as follows:

When the alignment-specifier is of the form alignas( assignment-expression constant-expression ):

• the assignment-expression constant-expression shall be an integral constant expression

1716. When are default arguments evaluated?

[Moved to DR at the February, 2014 meeting.]

According to 8.3.6 [dcl.fct.default] paragraph 9,

Default arguments are evaluated each time the function is called.

Obviously, what was intended by this is that the default argument is evaluated only if no corresponding actual argument is provided, but this could be read as indicating that the default argument is evaluated and discarded by every function call.

Proposed resolution (January, 2014):

Change 8.3.6 [dcl.fct.default] paragraph 9 as follows:

Default arguments are A default argument is evaluated each time the function is called with no argument for the corresponding parameter. The order of evaluation...

1778. exception-specification in explicitly-defaulted functions

[Moved to DR at the February, 2014 meeting.]

According to 8.4.2 [dcl.fct.def.default] paragraph 2,

An explicitly-defaulted function may be declared constexpr only if it would have been implicitly declared as constexpr, and may have an explicit exception-specification only if it is compatible (15.4 [except.spec]) with the exception-specification on the implicit declaration.

The requirement for exception-specifications has unfortunate consequences for the standard library component atomic, as described in LWG issue 2165: the component cannot be used with a T unless T is nothrow default constructible, even if the std::atomic<T> variable is never default initialized.

Proposed resolution (September, 2013):

Change 8.4.2 [dcl.fct.def.default] paragraphs 2 and 3 as follows:

An explicitly-defaulted function may be declared constexpr only if it would have been implicitly declared as constexpr, and may have an explicit exception-specification only if it is compatible (15.4 [except.spec]) with the exception-specification on the implicit declaration. If a function is explicitly defaulted on its first declaration,

• it is implicitly considered to be constexpr if the implicit declaration would be, and,

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

If a function that is explicitly defaulted has an explicit exception-specification that is not compatible (15.4 [except.spec]) with the exception-specification on the implicit declaration, then

• if the function is explicitly defaulted on its first declaration, it is defined as deleted;

• otherwise, the program is ill-formed.

[Example:

  struct S {
    constexpr S() = default;            // ill-formed: implicit S() is not constexpr
    S(int a = 0) = default;             // ill-formed: default argument
    void operator=(const S&) = default; // ill-formed: non-matching return type
    ~S() throw(int) = default;          // ill-formed deleted: exception specification does not match
  private:
    int i;
    S(S&);                              // OK: private copy constructor
  };
  S::S(S&) = default;                   // OK: defines copy constructor

—end example]

Additional note, January, 2014:

The proposed resolution appears to have the undesirable implication that a special member function could become deleted after the class is complete. For example, given

  struct S {
    S() noexcept(false) = default;
  };

we need to check that the explicit exception specification is compatible with the one on the implicit declaration. After the resolution of issue 1330, the class is regarded as complete within exception-specifications, per 9.2 [class.mem] paragraph 2. This implies that the explicit exception-specification can only be checked once the class is complete.

The issue has been returned to "review" status to allow discussion of this concern.

1604. Double temporaries in reference initialization

[Moved to DR at the February, 2014 meeting.]

Bullet 2 sub-bullet 2 of 8.5.3 [dcl.init.ref] paragraph 5 says,

Otherwise, a temporary of type “cv1 T1” is created and initialized from the initializer expression using the rules for a non-reference copy-initialization (8.5 [dcl.init]). The reference is then bound to the temporary.

It is not clear what “using the rules for a non-reference copy-initialization” means. If it means that the temporary is initialized as if it were a standalone variable, the last bullet of 8.5 [dcl.init] paragraph 17 could apply:

Otherwise (i.e., for the remaining copy-initialization cases), user-defined conversion sequences that can convert from the source type to the destination type or (when a conversion function is used) to a derived class thereof are enumerated as described in 13.3.1.4 [over.match.copy], and the best one is chosen through overload resolution (13.3 [over.match]). If the conversion cannot be done or is ambiguous, the initialization is ill-formed. The function selected is called with the initializer expression as its argument; if the function is a constructor, the call initializes a temporary of the cv-unqualified version of the destination type. The temporary is a prvalue. The result of the call (which is the temporary for the constructor case) is then used to direct-initialize, according to the rules above, the object that is the destination of the copy-initialization.

That is, for an example like

  struct X {
    X(int) {}
      X(X const &) = delete;
    };

  void f() {
    X const &x = 0;
  }

the specification requires creation of a temporary X(0), copying that tempoary to another temporary (subject to copy elision), and binding the reference to that second temporary. In the example above, because the copy constructor is deleted, the example is ill-formed, although current implementations fail to diagnose it as an error.

Is this intended?

Proposed resolution (September, 2013):

1. Change the last bullet of 8.5.3 [dcl.init.ref] paragraph 5, breaking it into sub-bullets, and the subsequent example as follows:

• Otherwise:

• If T1 is a class type, user-defined conversions are considered using the rules for copy-initialization of an object of type “cv1 T1” by user-defined conversion (8.5 [dcl.init], 13.3.1.4 [over.match.copy]); the program is ill-formed if the corresponding non-reference copy-initialization would be ill-formed. The result of the call to the conversion function, as described for the non-reference copy-initialization, is then used to direct-initialize the reference. The program is ill-formed if the direct-initialization does not result in a direct binding or if it involves a user-defined conversion.

• If T1 is a non-class type, a temporary of type “cv1 T1” is created and copy-initialized (8.5 [dcl.init]) from the initializer expression using the rules for a non-reference copy-initialization (8.5 [dcl.init]). The reference is then bound to the temporary.

If T1 is reference-related to T2,:

• cv1 shall be the same cv-qualification as, or greater cv-qualification than, cv2.; and

• If T1 is reference-related to T2 and if the reference is an rvalue reference, the initializer expression shall not be an lvalue.

[Example:

  struct Banana { };
  struct Enigma { operator const Banana(); };
  void enigmatic() {
    typedef const Banana ConstBanana;
    Banana &&banana1 = ConstBanana(); // ill-formed
    Banana &&banana2 = Enigma();      // ill-formed
  }

  const double& rcd2 = 2;             // rcd2 refers to temporary with value 2.0
  ...

2. Change 13.3.1.4 [over.match.copy] paragraph 1 as follows:

Under the conditions specified in 8.5 [dcl.init], as part of a copy-initialization of an object of class type, a user-defined conversion can be invoked to convert an initializer expression to the type of the object being initialized. Overload resolution is used to select the user-defined conversion to be invoked. [Note: The conversion performed for indirect binding to a reference to a possibly cv-qualified class type is determined in terms of a corresponding non-reference copy-initialization. —end note] Assuming that

1660. member-declaration requirements and unnamed bit-fields

[Moved to DR at the February, 2014 meeting.]

According to 9.2 [class.mem] paragraph 1,

Except when used to declare friends (11.3 [class.friend]) or to introduce the name of a member of a base class into a derived class (7.3.3 [namespace.udecl]), member-declarations declare members of the class, and each such member-declaration shall declare at least one member name of the class.

Unnamed bit-fields (9.6 [class.bit] paragraph 2) are described as not being members, and they obviously do not declare a member name; presumably they should therefore be included among the exceptions to this rule.

Additional note (October, 2013):

Curiously, the exemption for an unnamed bit-field not introducing names is in 7 [dcl.dcl] paragraph 3, referring to a simple-declaration. However, a simple-declaration is not a member-declaration and thus does not apply.

Proposed resolution (November, 2013):

1. Change 7 [dcl.dcl] paragraph 3 as follows:

...In such cases, and except for the declaration of an unnamed bit-field (9.6 [class.bit]), the decl-specifier-seq shall introduce one or more names into the program, or shall redeclare a name introduced by a previous declaration. [Example:...

2. Change 9.2 [class.mem] paragraph 1 as follows:

...Except when used to declare friends (11.3 [class.friend]), to declare an unamed bit-field (9.6 [class.bit]), or to introduce the name of a member of a base class into a derived class (7.3.3 [namespace.udecl]), member-declarations declare members of the class, and each such member-declaration shall declare at least one member name of the class. A member shall not...

1693. Superfluous semicolons in class definitions

[Moved to DR at the February, 2014 meeting.]

The grammar in 9.2 [class.mem] and 8.4.1 [dcl.fct.def.general] paragraph 1 are (in part):

member-declaration:
function-definition ;_opt

function-definition:
function-body

function-body:
= default ;
= delete ;

This leads to the following curiosity:

  struct A {
    void f1() = delete;   // #1, ok
    void f2() = delete;;  // #2, ok
    void f3() = delete;;; // #3, error, extraneous semicolon
  };

This could be addressed by moving the semicolon into the productions for function-body for the non-default/delete forms or by adding empty-declaration to the list of member-declaration productions, as is done with namespace-scope declarations.

Proposed resolution (November, 2013):

1. Change the grammar in 9.2 [class.mem] as follows:

member-declaration:
attribute-specifier-seq_opt decl-specifier-seq_opt member-declarator-list_opt ;
function-definition ;_opt
using-declaration
static_assert-declaration
template-declaration
alias-declaration
empty-declaration

2. Change 9.2 [class.mem] paragraph 1 as follows:

...Except when used to declare friends (11.3 [class.friend]) or to introduce the name of a member of a base class into a derived class (7.3.3 [namespace.udecl]), or when the declaration is an empty-declaration, member-declarations declare members of the class, and each such member-declaration shall declare at least one member name of the class.

1764. Hiding of function from using-declaration by signature

[Moved to DR at the February, 2014 meeting.]

According to 7.3.3 [namespace.udecl] paragraph 15,

When a using-declaration brings names from a base class into a derived class scope, member functions and member function templates in the derived class override and/or hide member functions and member function templates with the same name, parameter-type-list (8.3.5 [dcl.fct]), cv-qualification, and ref-qualifier (if any) in a base class (rather than conflicting).

The algorithm for class-scope name lookup given in 10.2 [class.member.lookup], however, does not implement this requirement; there is nothing that removes a hidden base class member (replacing the using-declaration, per paragraph 3) from the result set.

Proposed resolution (September, 2013):

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

The lookup set for f in C, called S(f, C), consists of two component sets: the declaration set, a set of members named f; and the subobject set, a set of subobjects where declarations of these members (possibly including using-declarations) were found. In the declaration set, using-declarations are replaced by the members they designate set of designated members that are not hidden or overridden by members of the derived class (7.3.3 [namespace.udecl]), and type declarations (including injected-class-names) are replaced by the types they designate...

1611. Deleted default constructor for abstract class

[Moved to DR at the February, 2014 meeting.]

Bullet 6 of 12.1 [class.ctor] paragraph 5 gives an abstract class a deleted default constructor when the virtual base has no default constructor, even though the abstract class's default constructor can never construct the virtual base class subobject. This seems parallel to the case described in issue 257 for mem-initializers. Should a similar accommodation be made to avoid deleted default constructors in abstract classes?

Notes from the April, 2013 meeting:

CWG agreed that a virtual base class should not cause an abstract class's default constructor to be defined as deleted.

Proposed resolution (August, 2013) [superseded]:

Change 12.1 [class.ctor] paragraph 4 as follows:

...A defaulted default constructor for class X is defined as deleted if:

• ...

• any direct or virtual base class, or non-static data member with no brace-or-equal-initializer, or any direct base class, or, if X is not abstract, any virtual base class, has class type M (or array thereof) and either M has no default constructor or overload resolution (13.3 [over.match]) as applied to M's default constructor results in an ambiguity or in a function that is deleted or inaccessible from the defaulted default constructor, or

• ...

Proposed resolution (November, 2013):

This issue is resolved by the resolution of issue 1658.

1658. Deleted default constructor for abstract class via destructor

[Moved to DR at the February, 2014 meeting.]

While reviewing the resolution of issue 1611, it was noticed that the final bullet of 12.1 [class.ctor] paragraph 4 has a similar issue:

...A defaulted default constructor for class X is defined as deleted if:

• ...

• any direct or virtual base class or non-static data member has a type with a destructor that is deleted or inaccessible from the defaulted default constructor.

Presumably destructors for virtual bases of abstract classes should not be considered in making this determination.

A question was also raised regarding whether odr-use is correctly defined for destructors of virtual bases of abstract classes. 3.2 [basic.def.odr] paragraph 3 simply refers to 12.4 [class.dtor], where the relevant passage (paragraph 8) reads,

After executing the body of the destructor and destroying any automatic objects allocated within the body, a destructor for class X calls the destructors for X's direct non-variant non-static data members, the destructors for X's direct base classes and, if X is the type of the most derived class (12.6.2 [class.base.init]), its destructor calls the destructors for X's virtual base classes.

It could be argued, particularly in light of the reference to 12.6.2 [class.base.init], that this is clear enough that the destructor for an abstract class does not invoke destructors for its virtual bases, but a note to that effect might be helpful.

Proposed resolution (November, 2013):

1. Add the following as a new paragraph at the end of 12 [special]:

For a class, its non-static data members, its non-virtual direct base classes, and, if the class is not abstract (10.4 [class.abstract]), its virtual base classes are called its potentially constructed subobjects.

2. Change 12.1 [class.ctor] paragraph 4 as follows:

...A defaulted default constructor for class X is defined as deleted if:

• ...

• any direct or virtual base class, or non-static data member potentially constructed subobject, except for a non-static data member with no a brace-or-equal-initializer, has class type M (or array thereof) and either M has no default constructor or overload resolution (13.3 [over.match]) as applied to M's default constructor results in an ambiguity or in a function that is deleted or inaccessible from the defaulted default constructor, or

• any direct or virtual base class or non-static data member potentially constructed subobject has a type with a destructor that is deleted or inaccessible from the defaulted default constructor.

3. Change 12.4 [class.dtor] paragraph 5 as follows:

A defaulted destructor for a class X is defined as deleted if:

• X is a union-like class that has a variant member with a non-trivial destructor,

• any of the non-static data members potentially constructed subobject has class type M (or array thereof) and M has a deleted destructor or a destructor that is inaccessible from the defaulted destructor,

• any direct or virtual base class has a deleted destructor or a destructor that is inaccessible from the defaulted destructor,

4. Change 12.6.2 [class.base.init] paragraph 8 as follows:

In a non-delegating constructor, if a given non-static data member or base class potentially constructed subobject is not designated by a mem-initializer-id (including the case where there is no mem-initializer-list because the constructor has no ctor-initializer) and the entity is not a virtual base class of an abstract class (10.4 [class.abstract]), then...

5. Change 12.6.2 [class.base.init] paragraph 10 as follows:

In a non-delegating constructor, the destructor for each direct or virtual base class and for each non-static data member potentially constructed subobject of class type is potentially invoked (12.4 [class.dtor]). [Note: This provision ensures that destructors can be called for fully-constructed sub-objects in case an exception is thrown (15.2 [except.ctor]). —end note]

6. Change 12.8 [class.copy] paragraph 8, replacing the bulleted list with a single sentence, as follows:

The implicitly-declared copy constructor for a class X will have the form

X::X(const X&)

if each potentially constructed subobject

• each direct or virtual base class B of X has a copy constructor whose first parameter is of type const B& or const volatile B&, and

• for all the non-static data members of X that are of a class type M (or array thereof), each such class type has a copy constructor whose first parameter is of type const M& or const volatile M&.¹²¹

Otherwise...

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

An implicitly-declared copy/move constructor is an inline public member of its class. A defaulted copy/move constructor for a class X is defined as deleted (8.4.3 [dcl.fct.def.delete]) if X has:

• a variant member with a non-trivial corresponding constructor and X is a union-like class,

• a non-static data member potentially constructed subobject of class type M (or array thereof) that cannot be copied/moved because overload resolution (13.3 [over.match]), as applied to M's corresponding constructor, results in an ambiguity or a function that is deleted or inaccessible from the defaulted constructor,

• a direct or virtual base class B that cannot be copied/moved because overload resolution (13.3 [over.match]), as applied to B's corresponding constructor, results in an ambiguity or a function that is deleted or inaccessible from the defaulted constructor,

• any direct or virtual base class or non-static data member potentially constructed subobject of a type with a destructor that is deleted or inaccessible from the defaulted constructor, or,

• ...

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

Before the defaulted copy/move constructor for a class is implicitly defined, all non-user-provided copy/move constructors for its direct and virtual base classes and its non-static data members potentially constructed subobjects shall have been implicitly defined. [Note: An implicitly-declared copy/move constructor has an exception-specification (15.4 [except.spec]). —end note]

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

A defaulted copy/move assignment operator for class X is defined as deleted if X has:

• ...

• a non-static data member potentially constructed subobject of class type M (or array thereof) that cannot be copied/moved because overload resolution (13.3 [over.match]), as applied to M's corresponding assignment operator, results in an ambiguity or a function that is deleted or inaccessible from the defaulted assignment operator, or.

• a direct or virtual base class B that cannot be copied/moved because overload resolution (13.3 [over.match]), as applied to B's corresponding assignment operator, results in an ambiguity or a function that is deleted or inaccessible from the defaulted assignment operator.

This resolution also resolves issue 1611.

1344. Adding new special member functions to a class via default arguments

[Moved to DR at the February, 2014 meeting.]

If default arguments added in the out-of-class definition of a constructor make it a special member function, this can affect the overload resolution and thus the implicit exception specification and the triviality of an implicitly-declared special member function in a derived class.

See also issue 1496, which should also be addressed by the resolution of this issue.

Notes from the September, 2013 meeting:

It was decided to resolve this issue separately from issue 1496, which is now decoupled from this issue.

Proposed resolution (September, 2013):

1. Change 8.3.6 [dcl.fct.default] paragraph 6 as follows:

Except for member functions of class templates, the default arguments in a member function definition that appears outside of the class definition are added to the set of default arguments provided by the member function declaration in the class definition; the program is ill-formed if a default constructor (12.1 [class.ctor]), copy or move constructor, or copy or move assignment operator (12.8 [class.copy]) is so declared. Default arguments for a member function of a class template shall be specified on the initial declaration of the member function within the class template. [Example:...

2. Delete the following from 12.8 [class.copy] paragraph 7:

...The latter case is deprecated if the class has a user-declared copy assignment operator or a user-declared destructor. Thus, for the class definition

  struct X {
    X(const X&, int);
  };

a copy constructor is implicitly-declared. If the user-declared constructor is later defined as

  X::X(const X& x, int i =0) { /* ... */ }

then any use of X's copy constructor is ill-formed because of the ambiguity; no diagnostic is required.

1493. Criteria for move-construction

[Moved to DR at the February, 2014 meeting.]

The decision in 12.8 [class.copy] paragraph 32 on whether or not a copy must be replaced by a move is phrased largely in terms of when copy elision can be performed, as described in the preceding paragraph. In particular, the fourth bullet of paragraph 31 applies

when the exception-declaration of an exception handler (Clause 15 [except]) declares an object of the same type (except for cv-qualification) as the exception object (15.1 [except.throw]), the copy/move operation can be omitted by treating the exception-declaration as an alias for the exception object if the meaning of the program will be unchanged except for the execution of constructors and destructors for the object declared by the exception-declaration.

The determination of “when the meaning of the program will be unchanged” is, in the general case, not practical. Copy elision is optional, meaning that the compiler can simply choose not to perform it if the determination is too difficult. Choosing whether to do a copy or a move, however, is mandatory, even if the copy is elided, and such a broad criterion is not appropriate. Probably the best way to address this problem would be to eliminate exception-declarations as a possible target for move-construction.

(See also issue 1579.)

Proposed resolution (September, 2013):

Change 12.8 [class.copy] paragraphs 31 and 32 as follows:

...This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):

• ...

• when the exception-declaration of an exception handler (Clause 15 [except]) declares an object of the same type (except for cv-qualification) as the exception object (15.1 [except.throw]), the copy/move operation can be omitted by treating the exception-declaration as an alias for the exception object if the meaning of the program will be unchanged except for the execution of constructors and destructors for the object declared by the exception-declaration. [Note: there cannot be a move from the exception object because it is always an lvalue. —end note]

[Example:...

When the criteria for elision of a copy/move operation are met, but not for an exception-declaration, or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue. If the first overload resolution fails or was not performed, or if the type of the first parameter of the selected constructor is not an rvalue reference to the object's type (possibly cv-qualified), overload resolution is performed again, considering the object as an lvalue. [Note:...

1579. Return by converting move constructor

[Moved to DR at the February, 2014 meeting.]

Currently the conditions for moving from an object returned from a function are tied closely to the criteria for copy elision, which requires that the type of the object being returned be the same as the return type of the function. Another possibility that should be considered is to allow something like

  optional<T> foo() {
    T t;
    ...
    return t;
  }

and allow optional<T>::optional(T&&) to be used for the initialization of the return type. Currently this can be achieved explicitly by use of std::move, but it would be nice not to have to remember to do so.

Similarly, the current rules apply only to complete objects; it could make sense to allow moving from subobjects of local objects.

(See also issue 1493 for other questions about the criteria for moving from a returned object.)

Rationale (April, 2013):

CWG felt that this suggestion should be considered in a broader context and was thus more appropriate for EWG.

Additional note (September, 2013):

Returned to "open" status in light of CD National Body comment.

Proposed resolution (September, 2013):

Change 12.8 [class.copy] paragraph 32 as follows:

When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, or when the expression in a return statement is a (possibly parenthesized) id-expression that names an object with automatic storage duration declared in the body or parameter-declaration-clause of the innermost enclosing function or lambda-expression, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue. If overload resolution fails...

1738. Explicit instantiation/specialization of inheriting constructor templates

[Moved to DR at the February, 2014 meeting.]

It is not clear whether it is permitted to explicitly instantiate or explicitly specialize specializations of inheriting constructor templates. Since inheriting constructors are considered to be implicitly declared (12.9 [class.inhctor] paragraph 1), it might be inferred that 14.7.2 [temp.explicit] paragraph 4 forbids their explicit instantiation:

If the declaration of the explicit instantiation names an implicitly-declared special member function (Clause 12 [special]), the program is ill-formed.

Similarly, an explicit specialization provides a definition for the specialized member, and 12 [special] paragraph 1 forbids defining an implicitly-declared special member function.

These inferences do not seem conclusive, however, so an explicit statement in 12.9 [class.inhctor] would be helpful.

(See also issue 1780.)

Proposed resolution (January, 2014):

Change 12.9 [class.inhctor] paragraph 4 as follows:

A constructor so declared has the same access as the corresponding constructor in X. It is deleted if the corresponding constructor in X is deleted (8.4 [dcl.fct.def]). An inheriting constructor shall not be explicitly instantiated (14.7.2 [temp.explicit]) or explicitly specialized (14.7.3 [temp.expl.spec]).

1687. Conversions of operands of built-in operators

[Moved to DR at the February, 2014 meeting.]

Consider an example like:

  struct Y {
    operator int*();
  };

  extern int *p;
  int *a = p + 100.0;   // #1
  int *b = Y() + 100.0; // #2

#1 is ill-formed because it violates the requirement of 5.7 [expr.add] that the non-pointer operand have integral or enumeration type. It appears that #2 is well-formed, however, because 13.3.1.2 [over.match.oper] paragraph 7 says,

If a built-in candidate is selected by overload resolution, the operands are converted to the types of the corresponding parameters of the selected operation function. Then the operator is treated as the corresponding built-in operator and interpreted according to Clause 5 [expr].

In this case, the selected operation function is

  int *operator+(int *, std::ptrdiff_t)

100.0 is thus converted to std::ptrdiff_t before reaching 5.7 [expr.add].

This problem could be addressed by restricting the conversion to the class or enumeration operand rather than both operands.

Proposed resolution (January, 2014):

Change 13.3.1.2 [over.match.oper] paragraph 7 as follows:

If a built-in candidate is selected by overload resolution, the operands of class type are converted to the types of the corresponding parameters of the selected operation function, except that the second standard conversion sequence of a user-defined conversion sequence (13.3.3.1.2 [over.ics.user]) is not applied. Then the operator is treated as the corresponding built-in operator and interpreted according to Clause 5 [expr]. [Example:

  struct X {
    operator double();
  };

  struct Y {
    operator int*();
  };

  int *a = Y() + 100.0; // error: pointer arithmetic requires integral operand
  int *b = Y() + X();   // error: pointer arithmetic requires integral operand

—end example]

1673. Clarifying overload resolution for the second step of copy-initialization

[Moved to DR at the February, 2014 meeting as part of document N3914.]

Currently, 13.3.3.1 [over.best.ics] paragraph 4 reads,

However, when considering the argument of a constructor or user-defined conversion function that is a candidate by 13.3.1.3 [over.match.ctor] when invoked for the copying/moving of the temporary in the second step of a class copy-initialization, by 13.3.1.7 [over.match.list] when passing the initializer list as a single argument or when the initializer list has exactly one element and a conversion to some class X or reference to (possibly cv-qualified) X is considered for the first parameter of a constructor of X, or by 13.3.1.4 [over.match.copy], 13.3.1.5 [over.match.conv], or 13.3.1.6 [over.match.ref] in all cases, only standard conversion sequences and ellipsis conversion sequences are considered.

This is cumbersome and hard to understand. A possible improvement might be:

However, only standard conversion sequences and ellipsis conversion sequences are considered if:

• the parameter is the first parameter of a constructor of a class X, or

• the parameter is the implicit object parameter of a user-defined conversion function, and

• the constructor or user-defined conversion function is a candidate by:

13.3.1.3 [over.match.ctor] — when the argument is the temporary being copied/moved in the second step of a class copy-initialization.

13.3.1.4 [over.match.copy], 13.3.1.5 [over.match.conv], or 13.3.1.6 [over.match.ref] — in all cases.

13.3.1.7 [over.match.list] — during phase two, when the argument was the only element in the initializer list, and the parameter is of type X or reference to (possibly cv-qualified) X.

(Note that this rewording removes the restriction that applies during phase one of 13.3.1.7 [over.match.list], as there is no longer any way to trigger it due to the fact that only initializer-list constructors are candidates. See this bug report for details.)

Proposed resolution (September, 2013) [SUPERSEDED]:

Change 13.3.3.1 [over.best.ics] paragraph 4 as follows:

However, when considering the argument of a constructor or user-defined conversion function that is a candidate by 13.3.1.3 [over.match.ctor] when invoked for the copying/moving of the temporary in the second step of a class copy-initialization, by 13.3.1.7 [over.match.list] when passing the initializer list as a single argument or when the initializer list has exactly one element and a conversion to some class X or reference to (possibly cv-qualified) X is considered for the first parameter of a constructor of X, or by 13.3.1.4 [over.match.copy], 13.3.1.5 [over.match.conv], or 13.3.1.6 [over.match.ref] in all cases, only standard conversion sequences and ellipsis conversion sequences are considered. if the target is

• the first parameter of a constructor of a class X or

• the implicit object parameter of a user-defined conversion function,

and the constructor or user-defined conversion function is a candidate by

• 13.3.1.3 [over.match.ctor], when the argument is the temporary acting as the source in the second step of a class copy-initialization,

• 13.3.1.4 [over.match.copy], 13.3.1.5 [over.match.conv], or 13.3.1.6 [over.match.ref] (in all cases), or

• the second phase of 13.3.1.7 [over.match.list] when the initializer list has exactly one element, and the conversion is to X or reference to (possibly cv-qualified) X,

user-defined conversion sequences are not considered. [Example:

  struct X { X(); };
  struct B { operator X&(); };
  B b;
  X x({b}); // error: B::operator X&() is not a candidate

—end example]

Additional note (October, 2013):

Questions have been raised about several of the bullets in the September, 2013 proposed resolution and whether a note would be preferable instead of or in addition to the example . The issue has been returned to "review" status to allow consideration of these questions.

Additional note (January, 2014):

It has also been observed that the proposed resolution would make the following example ill-formed by preventing the consideration of B's conversion function when initializing the first parameter of A's copy constructor:

  struct A {
    A() {}
    A(const A &) {}
  };

  struct B {
    operator A() { return A(); }
  } b;
  A a{b};

1762. Reserved identifier used in literal-operator-id example

[Moved to DR at the February, 2014 meeting.]

The example in 13.5.8 [over.literal] paragraph 8 contains the line

  float operator ""E(const char*); // OK

E does not begin with an underscore and thus is a reserved name.

Proposed resolution (September, 2013):

Change the example in 13.5.8 [over.literal] paragraph 8 as follows:

  void operator "" _km(long double);                     // OK
  string operator "" _i18n(const char*, std::size_t);    // OK
  template <char...> double operator "" _\u03C0();       // OK: UCN for lowercase pi
  float operator ""_E(const char*);                      // OK
  float operator ""E(const char*);                       // error: reserved identifier
  float operator " " B(const char*);                     // error: non-empty string-literal
  string operator "" 5X(const char*, std::size_t);       // error: invalid literal suffix identifier
  double operator "" _miles(double);                     // error: invalid parameter-declaration-clause
  template <char...> int operator "" _j(const char*);    // error: invalid parameter-declaration-clause

Rationale (February, 2014):

The specification was removed from the WP and moved into a Technical Specification.

1666. Address constant expressions

[Moved to DR at the February, 2014 meeting.]

The term “address constant expression” was removed by paper N3652, but it is still referenced in the list of permissible nontype template arguments in 14.3.2 [temp.arg.nontype] paragraph 1:

• an address constant expression of type std::nullptr_t.

Proposed resolution (November, 2013):

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

A template-argument for a non-type, non-template template-parameter shall be one of:

• ...

• an address a constant expression of type std::nullptr_t.

1737. Type dependence of call to a member of the current instantiation

[Moved to DR at the February, 2014 meeting.]

Since we don't deduce the return type of a function temploid until it is instantiated, it seems that a call to such a function as a member of the current instantiation must have a dependent type, but 14.6.2.2 [temp.dep.expr] doesn't appear to say that. For example:

   template<typename T> struct X { typedef int type; };
   template<typename T> struct S {
     auto f() { return 0; }
     void g() {
       X<decltype(f())>::type x; // typename presumably needed here
     }
   }

Presumably there should be a bullet in 14.6.2.1 [temp.dep.type] paragraph 8 for this case.

Proposed resolution (November, 2013):

Change 14.6.2.2 [temp.dep.expr] paragraph 3 as follows:

An id-expression is type-dependent if it contains

• an identifier associated by name lookup with one or more declarations declared with a dependent type,

• an identifier associated by name lookup with one or more declarations of member functions of the current instantiation declared with a return type that contains a placeholder type (7.1.6.4 [dcl.spec.auto]),

• a template-id that is dependent,

• a conversion-function-id that specifies a dependent type, or

• a nested-name-specifier or a qualified-id that names a member of an unknown specialization;

or if it names a dependent member...

1770. Type matching of non-type template parameters and arguments

[Moved to DR at the February, 2014 meeting.]

According to 14.8.2.5 [temp.deduct.type] paragraph 17,

If, in the declaration of a function template with a non-type template-parameter, the non-type template-parameter is used in an expression in the function parameter-list and, if the corresponding template-argument is deduced, the template-argument type shall match the type of the template-parameter exactly, except that a template-argument deduced from an array bound may be of any integral type.

This does not cover return types, leaving the outcome of an example like the following unclear:

  template <int N> struct A; 

  template <short N> 
  A<N> *foo(); 

  void bar() { 
    A<1> *(*fp)(void) = &foo; 
  } 

Proposed resolution (September, 2013):

Change 14.8.2.5 [temp.deduct.type] paragraph 17 as follows:

If, in the declaration of a function template with a non-type template-parameter, the non-type template-parameter is used in an expression in the function parameter-list and, if the corresponding template-argument is deduced, the template-argument type shall match the type of the template-parameter exactly, except that a template-argument deduced from an array bound may be of any integral type P has a form that contains <i>, and if the type of the corresponding value of A differs from the type of i, deduction fails. If P has a form that contains [i], and if the type of i is not an integral type, deduction fails.¹⁴⁷ [Example:...

1769. Catching a base class of the exception object

[Moved to DR at the February, 2014 meeting.]

In saying that the catch-clause parameter is copy-initialized from the exception object, 15.3 [except.handle] paragraph 16 leaves open the possibility that a converting constructor might be used for the initialization when the type of the exception-declaration is a base of the type of the exception object. It should be specified that the parameter is copy-constructed from the corresponding base class subobject in such cases.

Proposed resolution (September, 2013) [superseded]:

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

If the exception-declaration specifies introduces a name, it declares a variable which is copy-initialized (8.5 [dcl.init]) from the exception object. If the exception-declaration denotes an object type but does not specify a name, a temporary (12.2 [class.temporary]) is copy-initialized (8.5 [dcl.init]) from the exception object.; otherwise, an unnamed variable is created. That variable, of type cv T or cv T&, is initialized from the exception object, of type E, as follows:

• if T is a base class of E, the variable is copy-initialized from the corresponding base class subobject of the exception object;

• otherwise, the variable is copy-initialized from the exception object.

The lifetime of the variable or temporary ends when the handler exits, after the destruction of any automatic objects initialized within the handler.

Additional note (October, 2013):

Additional discussion has pointed out that, although the unnamed handler parameter is no longer called a “temporary” in the proposed resolution, 12.2 [class.temporary] paragraph 1 still lists “entering a handler (15.3 [except.handle])” as one of the contexts in which a temporary is created. A question was also raised as to whether it is necessary to deal with named and unnamed handler parameters separately, since both are now referred to as “variables” in the revised wording. This issue has therefore been returned to "review" status to allow consideration of these points.

Proposed resolution (November, 2013):

1. Change 3 [basic] paragraph 6 as follows:

A variable is introduced by the declaration of a reference other than a non-static data member or of an object. The variable's name, if any, denotes the reference or object.

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

Temporaries of class type are created in various contexts: binding a reference to a prvalue (8.5.3 [dcl.init.ref]), returning a prvalue (6.6.3 [stmt.return]), a conversion that creates a prvalue (4.1 [conv.lval], 5.2.9 [expr.static.cast], 5.2.11 [expr.const.cast], 5.4 [expr.cast]), throwing an exception (15.1 [except.throw]), entering a handler (15.3 [except.handle]), and in some initializations (8.5 [dcl.init]). [Note:...

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

Throwing an exception copy-initializes (8.5 [dcl.init], 12.8 [class.copy]) a temporary object, called the exception object. The temporary is an lvalue and is used to initialize the variable named declared in the matching handler (15.3 [except.handle]). If the type...

4. Change 15.3 [except.handle] paragraph 16 as follows:

If the exception-declaration specifies a name, it declares a variable which is copy-initialized (8.5 [dcl.init]) from the exception object. If the exception-declaration denotes an object type but does not specify a name, a temporary (12.2 [class.temporary]) is copy-initialized (8.5 [dcl.init]) from the exception object. The variable declared by the exception-declaration, of type cv T or cv T&, is initialized from the exception object, of type E, as follows:

• if T is a base class of E, the variable is copy-initialized (8.5 [dcl.init]) from the corresponding base class subobject of the exception object;

• otherwise, the variable is copy-initialized (8.5 [dcl.init]) from the exception object.

The lifetime of the variable or temporary ends when the handler exits, after the destruction of any automatic objects initialized within the handler.

1740. Disambiguation of noexcept

[Moved to DR at the February, 2014 meeting.]

There is an ambiguity between a noexcept specifier's optional parenthesized constant-expression and an initializer:

  void f() noexcept;
  void (*p)() noexcept (&f);

Here, we can just about make 8.2 [dcl.ambig.res] paragraph 1's rule fit, and say that the (&f) is part of the exception-specification rather than being an initializer. However, this case is much more problematic:

  void (*fp2)() noexcept, (*fp)() noexcept (fp2 = 0);

The (fp = 0) here is unambiguously an initializer, because an assignment-expression cannot syntactically be a constant-expression, although current implementations treat it as an ill-formed part of the exception-specification.

Probably the best approach would be to change 15.4 [except.spec] to say that a ( following noexcept is always treated as being part of the noexcept-specification.

Proposed resolution (September, 2013):

Change 15.4 [except.spec] paragraph 1 as follows:

...In a noexcept-specification, the constant-expression, if supplied, shall be a constant expression (5.19 [expr.const]) that is contextually converted to bool (Clause 4 [conv]). A noexcept-specification noexcept is equivalent to noexcept( true). A ( token that follows noexcept is part of the noexcept-specification (and does not commence an initializer (8.5 [dcl.init]).

Issues with "accepted" Status

1717. Missing specification of type of binary literal

[Applied to WP at the February, 2014 meeting.]

Table 6 of 2.14.2 [lex.icon] paragraph 2 covers only decimal, octal, and hexadecimal literals. Binary literals should be treated like the latter two. (It would also be more consistent to refer to these as “literals” instead of “constants.”)

Proposed resolution (September, 2013):

Change the caption and header row of Table 6 in 2.14.2 [lex.icon] paragraph 2 as follows:

Table 6 — Types of integer constants literals

Suffix	Decimal constants literal	Binary, Octal octal, or hexadecimal constant literal

1669. auto return type for main

[Applied to WP at the February, 2014 meeting.]

Should it be permitted for main to have a deduced return type?

(See also issue 1676.)

Proposed resolution (November, 2013):

Change 3.6.1 [basic.start.main] paragraph 2 as follows:

An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a declared return type of type int, but otherwise its type is implementation-defined. All implementations An implementation shall allow both

• a function of () returning int and

• a function of (int, pointer to pointer to char) returning int

as the type...

1681. init-captures and nested lambdas

[Applied to WP at the February, 2014 meeting.]

According to 5.1.2 [expr.prim.lambda] paragraph 10,

The identifier in a simple-capture is looked up using the usual rules for unqualified name lookup (3.4.1 [basic.lookup.unqual]); each such lookup shall find a variable with automatic storage duration declared in the reaching scope of the local lambda expression.

This does not permit a nested lambda to capture the non-static data member of the closure type introduced by an init-capture. A similar restriction applies to implicit capture in paragraph 12.

Presumably such captures should be allowed, capturing the non-static data member directly rather than the this pointer from the enclosing lambda's operator().

Proposed resolution (September, 2013):

This issue is resolved by the resolution of issue 1760.

1760. Access of member corresponding to init-capture

[Applied to WP at the February, 2014 meeting.]

The access of the non-static data member corresponding to an init-capture is not specified. The question would be moot if the member were unnamed like the other non-static data members of the closure class.

Proposed resolution (September, 2013):

1. Change 5.1.2 [expr.prim.lambda] paragraph 11 as follows:

For every init-capture a non-static data member named by the identifier of the init-capture is declared in the closure type. This member is not a bit-field and not mutable. The type of that member corresponds to the type of a hypothetical An init-capture behaves as if it declares and explicitly captures a variable declaration of the form “auto init-capture ;” whose declarative region is the lambda-expression's compound-statement, except that the variable name (i.e., the identifier of the init-capture) is replaced by a unique identifier.:

• if the capture is by copy (see below), the non-static data member declared for the capture and the variable are treated as two different ways of referring to the same object, which has the lifetime of the non-static data member, and no additional copy and destruction is performed, and

• if the capture is by reference, the variable's lifetime ends when the closure object's lifetime ends.

[Note: This enables an init-capture like “x = std::move(x)”; the second “x” must bind to a declaration in the surrounding context. —end note] No entity is captured by an init-capture. Within the lambda-expressions lambda-declarator and compound-statement, the identifier in the init-capture hides any declaration of the same name in scopes enclosing the lambda-expression. [Example:...

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

An entity is captured by copy if it is implicitly captured and the capture-default is = or if it is explicitly captured with a capture that does not include an & is not of the form & identifier or & identifier initializer. For each entity...

3. Change 5.1.2 [expr.prim.lambda] paragraph 18 as follows:

Every id-expression within the compound-statement of a lambda-expression that is an odr-use (3.2 [basic.def.odr]) of an entity captured by copy is transformed into an access to the corresponding unnamed data member of the closure type. [Note:...

This resolution also resolves issue 1681.

1684. Static constexpr member functions for non-literal classes

[Applied to WP at the February, 2014 meeting.]

The current wording of 7.1.5 [dcl.constexpr] paragraph 8 is:

The constexpr specifier has no effect on the type of a constexpr function or a constexpr constructor. The class of which a constexpr function is a member shall be a literal type (3.9 [basic.types]).

The previous version of this wording made clear that the restriction on the class type applied only to non-static member functions; consequently, the new formulation has inadvertently banned static constexpr member functions of non-literal classes.

Proposed resolution (November, 2013):

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

The constexpr specifier has no effect on the type of a constexpr function or a constexpr constructor. The class of which a constexpr function is a member shall be a literal type (3.9 [basic.types]). [Example:...

1674. Return type deduction for address of function

[Applied to WP at the February, 2014 meeting.]

The following example appears in 7.1.6.4 [dcl.spec.auto] paragraph 12:

  template <class T> auto f(T t) { return t; } // return type deduced at instantiation time
  typedef decltype(f(1)) fint_t;               // instantiates f<int> to deduce return type
  template<class T> auto f(T* t) { return *t; }
  void g() { int (*p)(int*) = &f; }            // instantiates both fs to determine return types,
                                               // chooses second

This is the desired behavior, but the current wording does not achieve that effect. One possible way this could work would be:

• auto is treated as a non-deduced context

• in 14.8.2.2 [temp.deduct.funcaddr], the deduced A is produced by substituting the deduced template arguments into the original function template, rather than substituting them into P, and the deduced A is the type of the produced function declaration (triggering instantiation of a definition as needed to complete the type)

Proposed resolution (November, 2013):

Add the following as a new paragraph at the end of 14.8.2.2 [temp.deduct.funcaddr]:

A placeholder type (7.1.6.4 [dcl.spec.auto]) in the return type of a function template is a non-deduced context. If template argument deduction succeeds for such a function, the return type is determined from instantiation of the function body.

Issues with "DRWP" Status

1509. Definition of “non-template function”

[Moved to DR at the September, 2013 meeting.]

The term “non-template function” is used in various places but never defined.

Proposed resolution (June, 2013):

1. Change 5.2.2 [expr.call] paragraph 1 as follows:

There are two kinds of function call: ordinary function call and member function [Footnote: A static member function (9.4 [class.static]) is an ordinary function. —end foot note] (9.3 [class.mfct]) call. A function call is a postfix expression followed by parentheses containing a possibly empty, comma-separated list of initializer-clauses which constitute the arguments to the function. The postfix expression shall have function type or pointer to function type. For an ordinary function a call to a non-member function or to a static member function, the postfix expression shall be either... For a member function call to a non-static member function, the postfix expression shall be...

2. Add a new paragraph before 8.3.5 [dcl.fct] paragraph 13:

A non-template function is a function that is not a function template specialization. [Note: A function template is not a function. —end note]

A declarator-id or abstract-declarator containing an ellipsis shall only be used...

3. Change the footnote in 13.3.1 [over.match.funcs] paragraph 7 as follows:

The process of argument deduction fully determines the parameter types of the function template specializations, i.e., the parameters of function template specializations contain no template parameter types. Therefore the, except where specified otherwise, function template specializations can be treated as normal (non-template) functions and non-template functions (8.3.5 [dcl.fct]) are treated equivalently for the remainder of overload resolution.

4. Change the final sub-bullet of 13.3.1.2 [over.match.oper] paragraph 3 as follows:

For a unary operator @...

• ...

• For the operator ,, the unary operator &, or the operator ->, the built-in candidates set...

• ...

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

5. Change the indicated bullet of the second bulleted list of 13.3.3 [over.match.best] paragraph 1 as follows:

• ...

• F1 is not a non-template function template specialization and F2 is a function template specialization, or, if not that,

• ...

6. Change 13.4 [over.over] paragraph 4 as follows:

If more than one function is selected, any function template specializations in the set are eliminated if the set also contains a non-template function that is not a function template specialization, and any given function template specialization F1 is eliminated

7. Change 14 [temp] paragraph 5 as follows:

A class template shall not have the same name as any other template, class, function, variable, enumeration, enumerator, namespace, or type in the same scope (3.3 [basic.scope]), except as specified in (14.5.5 [temp.class.spec]). Except that a function template can be overloaded either by (non-template) functions (8.3.5 [dcl.fct]) with the same name or by other function templates with the same name (14.8.3 [temp.over]), a template name declared in namespace scope or in class scope shall be unique in that scope.

8. Change 14.5.2 [temp.mem] paragraph 2 as follows:

A local class of non-closure type shall not have member templates. Access control rules (Clause 11 [class.access]) apply to member template names. A destructor shall not be a member template. A normal (non-template) member function (8.3.5 [dcl.fct]) with a given name and type and a member function template of the same name, which could be used to generate a specialization of the same type, can both be declared in a class. When both exist, a use of that name and type refers to the non-template member unless an explicit template argument list is supplied. [Example:

  template <class T> struct A {
    void f(int);
    template <class T2> void f(T2);
  };

  template <> void A<int>::f(int) { }               // non-template member function
  template <> template <> void A<int>::f<>(int) { } // template member function template specialization

  int main() {
    A<char> ac;
    ac.f(1);       // non-template
    ac.f('c');     // template
    ac.f<>(1);     // template
  }

—end example]

9. Change 14.5.4 [temp.friend] paragraph 1 as follows:

A friend of a class or class template can be a function template or class template, a specialization of a function template or class template, or an ordinary ( a non-template) function or class. For a friend function declaration that is not a template declaration:

• if the name of the friend is a qualified or unqualified template-id, the friend declaration refers to a specialization of a function template, otherwise,

• if the name of the friend is a qualified-id and a matching non-template function is found in the specified class or namespace, the friend declaration refers to that function, otherwise,

• if the name of the friend is a qualified-id and a matching function template is found in the specified class or namespace, the friend declaration refers to the deduced specialization of that function template (14.8.2.6 [temp.deduct.decl]), otherwise,

• the name shall be an unqualified-id that declares (or redeclares) an ordinary ( a non-template) function.

10. Change 14.5.4 [temp.friend] paragraph 4 as follows:

When a function is defined in a friend function declaration in a class template, the function is instantiated when the function is odr-used (3.2 [basic.def.odr]). The same restrictions...

11. Change 14.5.6 [temp.fct] paragraph 2 as follows:

A function template can be overloaded with other function templates and with normal (non-template) functions (8.3.5 [dcl.fct]). A normal non-template function is not related to a function template (i.e., it is never considered to be a specialization), even if it has the same name and type as a potentially generated function template specialization.¹⁴⁴

12. Change 14.8.1 [temp.arg.explicit] paragraph 4 as follows:

[Note: An empty template argument list can be used to indicate that a given use refers to a specialization of a function template even when a normal (i.e., non-template) function (8.3.5 [dcl.fct]) is visible that would otherwise be used. For example:...

1583. Incorrect example of unspecified behavior

[Moved to DR at the September, 2013 meeting.]

Currently, 1.9 [intro.execution] paragraph 3 says,

Certain other aspects and operations of the abstract machine are described in this International Standard as unspecified (for example, order of evaluation of arguments to a function).

However, the order of evaluation of function arguments is no longer “unspecified;” instead, their value computations are unsequenced. A better example of unspecified behavior is needed.

Proposed resolution (April, 2013):

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

Certain other aspects and operations of the abstract machine are described in this International Standard as unspecified (for example, order of evaluation of arguments to a function evaluation of expressions in a new-initializer if the allocation function fails to allocate memory (5.3.4 [expr.new])). Where possible...

1575. Incorrect definition of “strict pointer safety”

[Moved to DR at the September, 2013 meeting.]

According to 3.7.4.3 [basic.stc.dynamic.safety] paragraph 4,

an implementation may have strict pointer safety, in which case a pointer value that is not a safely-derived pointer value is an invalid pointer value unless the referenced complete object is of dynamic storage duration and has previously been declared reachable (20.7.4 [util.dynamic.safety]).

“Safely-derived pointer” is defined only with respect to dynamically-allocated storage. Presumably pointers to objects with automatic and static storage duration should also be considered valid.

Proposed resolution (April, 2013):

Change 3.7.4.3 [basic.stc.dynamic.safety] paragraph 4 as follows:

Alternatively, an implementation may have strict pointer safety, in which case a pointer value referring to an object with dynamic storage duration that is not a safely-derived pointer value is an invalid pointer value unless the referenced complete object is of dynamic storage duration and has previously been declared reachable (20.7.4 [util.dynamic.safety]). [Note:...

1601. Promotion of enumeration with fixed underlying type

[Moved to DR at the September, 2013 meeting.]

According to 4.5 [conv.prom] paragraph 4,

A prvalue of an unscoped enumeration type whose underlying type is fixed (7.2 [dcl.enum]) can be converted to a prvalue of its underlying type. Moreover, if integral promotion can be applied to its underlying type, a prvalue of an unscoped enumeration type whose underlying type is fixed can also be converted to a prvalue of the promoted underlying type.

Because both of these conversions have the same rank, a call like the following is ambiguous, even though conversion to the underlying type might seem better than conversion to int:

  enum E : char { e };
  void f(char);
  void f(int);
  void g() {
    f(e);      // ambiguous
  }

On the other hand, character types often have non-numeric semantics in programs, and programmers might use a character type just to set the size of the enumeration's object representation, not to imply character semantics for the enumeration. It might be better to leave the ambiguity in place in order to require programmers to make their intent explicit.

Proposed resolution (June, 2013):

Change 13.3.3.2 [over.ics.rank] paragraph 4 as follows:

...Two conversion sequences with the same rank are indistinguishable unless one of the following rules applies:

• A conversion that does not convert a pointer, a pointer to member, or std::nullptr_t to bool is better than one that does.

• A conversion that promotes an enumeration whose underlying type is fixed to its underlying type is better than one that promotes to the promoted underlying type, if the two are different.

• If class B is derived...

1576. Discarded-value volatile xvalues

[Moved to DR at the September, 2013 meeting.]

According to the current wording of 5 [expr] paragraph 11, the lvalue-to-rvalue conversion applies only to volatile lvalues in the listed contexts. Presumably it should apply to volatile xvalues as well.

Proposed resolution (June, 2013):

Change 5 [expr] paragraph 11 as follows:

...The lvalue-to-rvalue conversion (4.1 [conv.lval]) is applied if and only if the expression is an lvalue a glvalue of volatile-qualified type and it is one of the following:...

1648. thread_local vs block extern declarations

[Moved to DR at the September, 2013 meeting.]

According to 7.1.1 [dcl.stc] paragraph 4,

When thread_local is applied to a variable of block scope the storage-class-specifier static is implied if it does not appear explicitly.

This, presumably unintentionally, prohibits a declaration like

  void f() {
    extern thread_local int n;
  }

Proposed resolution (April, 2013):

When thread_local is applied to a variable of block scope the storage-class-specifier static is implied if it does not appear explicitly no other storage-class-specifier appears in the decl-specifier-seq.

1587. constexpr initialization and nested anonymous unions

[Moved to DR at the September, 2013 meeting.]

After the resolution of issue 1359, one of the requirements for constexpr constructors is:

if the class is a non-empty union, or for each non-empty anonymous union member of a non-union class, exactly one non-static data member shall be initialized;

This wording does not appear to handle nested anonymous unions. For example:

  struct S {
    union {
      union {
        int x = 1;
        float f;
      };
      void *p = nullptr;
    };
  }; 

Clearly here both S::x and S::p are initialized, but that does not appear to violate the new constraint.

Additional note (March, 2013):

It is not clear whether this example violates 9.5 [class.union] paragraph 5:

The member-specification of an anonymous union shall only define non-static data members. [Note: Nested types and functions cannot be declared within an anonymous union. —end note]

Is a nested anonymous union a “non-static data member” or a “nested type?”

See also issues 57, 1460, 1562, 1587, 1621, and 1623.

Proposed resolution (June, 2013):

Change 9.5 [class.union] paragraph 5 as follows:

...The member-specification of an anonymous union shall only define non-static data members. [Note: Nested types, anonymous unions, and functions cannot be declared within an anonymous union. —end note] The names of the members...

1595. Constructors “involved in” subobject initialization

[Moved to DR at the September, 2013 meeting.]

According to 7.1.5 [dcl.constexpr] paragraph 5

For a constexpr constructor, if no argument values exist such that after function invocation substitution, every constructor call and full-expression in the mem-initializers would be a constant expression (including conversions), the program is ill-formed; no diagnostic required.

However, paragraph 4 also says,

every constructor involved in initializing non-static data members and base class sub-objects shall be a constexpr constructor;

violation of which requires a diagnostic. The question is whether a constructor call appearing in a mem-initializer expression is “involved in” the initialization of X::m. Given the “no diagnostic required” status of constructor calls in paragraph 5, the intent of the “involved in” phrasing would appear to be referring to constructors of members with class types and of base-class subobjects, but the wording should be clarified. For example, in a constructor definition like

  constexpr X(): m(f(S())) { }

if S::S() is not constexpr, is a diagnostic required? For another example,

  struct S {
    constexpr S() {}
    S(int);
  };

  struct A { S s; };

  struct C {
    A x;
    constexpr C(): x{ 1 } {}
  }; 

Is S::S(int) “involved?”

Proposed resolution (August, 2013):

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

...In addition, either its function-body shall be = delete, or it shall satisfy the following constraints:

• ...

• for a non-delegating constructor, every constructor involved in initializing selected to initialize non-static data members and base class sub-objects shall be a constexpr constructor.;

• for a delegating constructor, the target constructor shall be a constexpr constructor.

1618. Gratuitously-unsigned underlying enum type

[Moved to DR at the September, 2013 meeting.]

In an enumeration whose underlying type is not fixed, the type of the first enumerator is unspecified if it has no initializer, meaning that an implementation could choose either a signed or an unsigned type. As a result, the values of one and two in this example could be either -1 and 0 or very large unsigned numbers:

  enum { zero, one = zero -1, two };

It would be better if 7.2 [dcl.enum] paragraph 5 specified the type of the first enumerator as a signed type.

Proposed resolution (August, 2013):

Change 7.2 [dcl.enum] paragraph 5 as follows:

...If the underlying type is not fixed, the type of each enumerator is the type of its initializing value:

• If an initializer is specified for an enumerator...

• If no initializer is specified for the first enumerator, the initializing value has an unspecified signed integral type.

• Otherwise...

1551. Wording problems in using-declaration specification

[Moved to DR at the September, 2013 meeting.]

There are at least a couple of problems with the current wording of 7.3.3 [namespace.udecl]. First is the use of the word “entity” to describe what the using-declaration represents. For example, in paragraph 1,

If a using-declaration names a constructor (3.4.3.1 [class.qual]), it implicitly declares a set of constructors in the class in which the using-declaration appears (12.9 [class.inhctor]); otherwise the name specified in a using-declaration is a synonym for the name of some entity declared elsewhere.

An overload set of functions and function templates is not an “entity,” according to 3 [basic] paragraph 3. A better phrasing might be something like, “...a synonym for a set of declarations in a different declarative region.”

The other problem is in paragraph 11:

The entity declared by a using-declaration shall be known in the context using it according to its definition at the point of the using-declaration. Definitions added to the namespace after the using-declaration are not considered when a use of the name is made.

This has the same problem with use of the term “entity,” and it also refers to “definitions” when presumably it means “declarations.”

Proposed resolution (October, 2012) [superseded]:

1. Add the following as a new paragraph after 3.3.2 [basic.scope.pdecl] paragraph 3:

The point of declaration for a class or class template first declared by a class-specifier is immediately after the identifier or simple-template-id (if any) in its class-head (Clause 9 [class]). The point of declaration for an enumeration is immediately after the identifier (if any) in either its enum-specifier (7.2 [dcl.enum]) or its first opaque-enum-declaration (7.2 [dcl.enum]), whichever comes first. The point of declaration of an alias or alias template immediately follows the type-id to which the alias refers.

The point of declaration of a using-declaration that does not name a constructor is immediately after the using-declaration (7.3.3 [namespace.udecl]).

2. Change 7.3.3 [namespace.udecl] paragraph 1 as follows:

...If a using-declaration names a constructor (3.4.3.1 [class.qual]), it implicitly declares a set of constructors in the class in which the using-declaration appears (12.9 [class.inhctor]); otherwise the name specified in a using-declaration is a synonym for the name of some entity declared elsewhere a set of declarations in another namespace or class.

3. Change 7.3.3 [namespace.udecl] paragraph 11 as follows:

The entity declared by a using-declaration shall be known in the context using it according to its definition at the point of the using-declaration. Definitions Declarations added to the namespace after the using-declaration are not considered when a use of the name is made. [Note: Thus, additional overloads and default arguments (8.3.6 [dcl.fct.default]) added after the using-declaration are ignored, but template specializations (14.5.5 [temp.class.spec], 14.7.3 [temp.expl.spec]) are considered. —end note] [Example:...

Additional note (October, 2012):

The note added by this resolution to 7.3.3 [namespace.udecl] paragraph 11 regarding the treatment of default arguments directly contradicts the normative statement of 8.3.6 [dcl.fct.default] paragraph 9:

When a declaration of a function is introduced by way of a using-declaration (7.3.3 [namespace.udecl]), any default argument information associated with the declaration is made known as well. If the function is redeclared thereafter in the namespace with additional default arguments, the additional arguments are also known at any point following the redeclaration where the using-declaration is in scope.

The issue has been returned to "review" status for reconciliation of these two passages.

Proposed resolution (June, 2013):

1. Insert a new paragraph following 3.3.2 [basic.scope.pdecl] paragraph 3, as follows

...whichever comes first. The point of declaration of an alias or alias template immediately follows the type-id to which the alias refers.

The point of declaration of a using-declaration that does not name a constructor is immediately after the using-declaration (7.3.3 [namespace.udecl]).

The point of declaration for an enumerator...

2. Change 7.3.3 [namespace.udecl] paragraph 1 as follows:

...If a using-declaration names a constructor (3.4.3.1 [class.qual]), it implicitly declares a set of constructors in the class in which the using-declaration appears (12.9 [class.inhctor]); otherwise the name specified in a using-declaration is a synonym for the name of some entity declared elsewhere a set of declarations in another namespace or class.

3. Change 7.3.3 [namespace.udecl] paragraph 11 as follows:

The entity declared by a using-declaration shall be known in the context using it according to its definition at the point of the using-declaration. Definitions Members added to the namespace after the using-declaration are not considered when a use of the name is made. [Note: Thus, additional overloads added after the using-declaration are ignored, but default function arguments (8.3.6 [dcl.fct.default]), default template arguments (14.1 [temp.param]), and template specializations (14.5.5 [temp.class.spec], 14.7.3 [temp.expl.spec]) are considered. —end note] [Example:

1417. Pointers/references to functions with cv-qualifiers or ref-qualifier

[Moved to DR at the September, 2013 meeting.]

It is not sufficiently clear from the existing wording that pointers and references to function types containing cv-qualifiers or a ref-qualifier are not permitted and thus would result in a deduction failure if created during template argument substitution. Normative wording to that effect should be added to, e.g., 8.3.5 [dcl.fct].

Proposed resolution (October, 2012) [SUPERSEDED]:

1. Change 8.3.1 [dcl.ptr] paragraph 4 as follows:

[Note: There are no pointers to references Forming a pointer to reference type is ill-formed; see 8.3.2 [dcl.ref]. Forming a pointer to a function type that has cv-qualifiers or a ref-qualifier is ill-formed; see 8.3.5 [dcl.fct]. Since the address of a bit-field (9.6 [class.bit]) cannot be taken, a pointer can never point to a bit-field. —end note]

2. Change 8.3.2 [dcl.ref] paragraph 6 as follows:

If a typedef typedef-name (7.1.3 [dcl.typedef]), a type template-parameter (14.3.1 [temp.arg.type]), 14.1 [temp.param]) or a decltype-specifier (7.1.6.2 [dcl.type.simple]) denotes a type TR that is a reference to a type T, an attempt to create...

3. Add the following as a new paragraph at the end of 8.3.2 [dcl.ref]:

[Note: Forming a reference to a function type that has cv-qualifiers or a ref-qualifier is ill-formed; see 8.3.5 [dcl.fct]. —end note]

4. Change 8.3.5 [dcl.fct] paragraph 6 as follows:

A function type with a cv-qualifier-seq or a ref-qualifier (including by typedef-name (7.1.3 [dcl.typedef], 14.1 [temp.param]) or decltype-specifier (7.1.6.2 [dcl.type.simple])) shall only be part of appear as:

• ...

• the type-id of a template-argument for a type-parameter (14.2 [temp.names] 14.3.1 [temp.arg.type]).

[Example:

   typedef int FIC(int) const;
   FIC f;       // ill-formed: does not declare a member function
   struct S {
    FIC f;      // OK
   };
   FIC S::*pm = &S::f; // OK

—end example]

The effect of a cv-qualifier-seq in a function declarator...

5. Delete the following text from 8.3.5 [dcl.fct] paragraph 10 (the example is moved to paragraph 6, as indicated in the preceding change):

A typedef of a function type whose declarator includes a cv-qualifier-seq shall be used only to declare the function type for a non-static member function, to declare the function type to which a pointer to member refers, or to declare the top-level function type of another function typedef declaration. [Example: ... —end example]

Additional note (March, 2013):

The issue is being returned to "review" status out of concern that 13.6 [over.built] paragraph 11 requires forming a reference to a function type that might have a cv-qualifier or ref-qualifier.

Proposed resolution (April, 2013):

1. Change 8.3.1 [dcl.ptr] paragraph 4 as follows:

[Note: There are no pointers to references Forming a pointer to reference type is ill-formed; see 8.3.2 [dcl.ref]. Forming a pointer to function type is ill-formed if the function type has cv-qualifiers or a ref-qualifier; see 8.3.5 [dcl.fct]. Since the address of a bit-field (9.6 [class.bit]) cannot be taken, a pointer can never point to a bit-field. —end note]

2. Change 8.3.2 [dcl.ref] paragraph 6:

If a typedef typedef-name (7.1.3 [dcl.typedef]), a type template-parameter (14.3.1 [temp.arg.type]), 14.1 [temp.param]) or a decltype-specifier (7.1.6.2 [dcl.type.simple]) denotes a type TR that is a reference to a type T, an attempt to create the type “lvalue reference to cv TR” creates the type “lvalue reference to T”, while an attempt to create the type “rvalue reference to cv TR" creates the type TR. [Example:...

3. Add the following as a new paragraph at the end of 8.3.2 [dcl.ref]:

[Note: Forming a reference to function type is ill-formed if the function type has cv-qualifiers or a ref-qualifier; see 8.3.5 [dcl.fct]. —end note]

4. Change 8.3.5 [dcl.fct] paragraph 6 as follows:

A function type with a cv-qualifier-seq or a ref-qualifier (including a type named by typedef-name (7.1.3 [dcl.typedef], 14.1 [temp.param])) shall appear only be part of as:

• the function type for a non-static member function,

• the function type to which a pointer to member refers,

• the top-level function type of a function typedef declaration or alias-declaration,

• the type-id in the default argument of a type-parameter (14.1 [temp.param]), or

• the type-id of a template-argument for a type-parameter (14.2 [temp.names] 14.3.1 [temp.arg.type]).

[Example:

   typedef int FIC(int) const;
   FIC f;              // ill-formed: does not declare a member function
   struct S {
     FIC f;            // OK
   };
   FIC S::*pm = &S::f; // OK

—end example] The effect of a cv-qualifier-seq...

5. Change 8.3.5 [dcl.fct] paragraph 10 as follows, moving the example to paragraph 6 as shown above:

...—end example] A typedef of a function type whose declarator includes a cv-qualifier-seq shall be used only to declare the function type for a non-static member function, to declare the function type to which a pointer to member refers, or to declare the top-level function type of another function typedef declaration. [Example: ... —end example]

6. Change 13.6 [over.built] paragraph 11 as follows:

For every quintuple (C1, C2, T, CV1, CV2), where C2 is a class type, C1 is the same type as C2 or is a derived class of C2, T is an object type or a function type, and CV1 and CV2 are cv-qualifier-seqs, there exist candidate operator functions of the form

CV12 T& operator->*(CV1 C1*, CV2 T C2::*);

where CV12 is the union of CV1 and CV2. The return type is shown for exposition only; see 5.5 [expr.mptr.oper] for the determination of the operator's result type.

1287. Direct initialization vs “implicit” conversion in reference binding

[Moved to DR at the September, 2013 meeting.]

In 8.5.4 [dcl.init.list] paragraph 5, both the cases in which a reference can be bound to the result of a conversion function use the phrase “can be implicitly converted to...” This is confusing, as it could be read as excluding explicit conversion functions. However, that appears not to be the intent, as 13.3.1.6 [over.match.ref], which is cited in these cases, allows explicit conversion functions for direct-initialization.

Proposed resolution (August, 2011) [SUPERSEDED]:

Change the two indicated (not contiguous) sub-bullets of 8.5.3 [dcl.init.ref] paragraph 5 as follows:

• has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be implicitly converted to an lvalue of type “cv3 T3,”...

• has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be implicitly converted to an xvalue, class prvalue, or function lvalue of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3” (see 13.3.1.6 [over.match.ref]),

Additional note, January, 2012:

Questions have been raised regarding the consistency of the treatment of class prvalues in this resolution with other types . The issue is thus being returned to "review" status for additional discussion.

Proposed resolution (February, 2012) [SUPERSEDED]:

1. 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:

• If the reference is an lvalue reference and the initializer expression

• is an lvalue (but is not a bit-field), and “cv1 T1” is reference-compatible with “cv2 T2,” or

• has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be implicitly converted to an lvalue of type “cv3 T3,” where “cv1 T1” is reference-compatible with “cv3 T3”¹⁰⁶ (this conversion is selected by enumerating the applicable conversion functions (13.3.1.6 [over.match.ref]) and choosing the best one through overload resolution (13.3 [over.match])),

then the reference is bound...

• Otherwise, the reference shall be...

• If the initializer expression

• is an xvalue, class prvalue, array prvalue or function lvalue and “cv1 T1” is reference-compatible with “cv2 T2”, or

• has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be implicitly converted to an xvalue, class prvalue, or function lvalue of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3” (see 13.3.1.6 [over.match.ref]),

then the reference is bound... [Example:

  struct A { };
  struct B : A { } b;
  extern B f();
  const A& rca2 = f();    // bound to the A subobject of the B rvalue.
  A&& rra = f();          // same as above
  struct X {
    operator B();
    operator int&();
  } x;
  const A& r = x;         // bound to the A subobject of the result of the conversion
  int i2 = 42;
  int&& rri = static_cast<int&&>(i2); // bound directly to i2
  B&& rrb = x;            // bound directly to the result of operator B
  int&& rri2 = X();       // error: lvalue-to-rvalue conversion applied to the
                          // result of operator int&

—end example]

• Otherwise, a temporary... [Example:

  const A& r = x;         // r refers to a temporary
  B&& rrb = x;            // rrb refers to a temporary

  const double& rcd2 = 2; // rcd2 refers to temporary with value 2.0
  double&& rrd = 2;       // rrd refers to temporary with value 2.0
  ...

2. Change 13.3.1.6 [over.match.ref] paragraph 1 as follows:

Under the conditions specified in 8.5.3 [dcl.init.ref], a reference can be bound directly to a glvalue or class prvalue that is the result of applying a conversion function...

• The conversion functions of S and its base classes are considered, except that for copy-initialization, only the non-explicit conversion functions are considered. Those that are not hidden within S and yield type “lvalue reference to cv2 T2” (when 8.5.3 [dcl.init.ref] requires an lvalue result) or “cv2 T2” or “rvalue reference to cv2 T2” (when 8.5.3 [dcl.init.ref] requires an rvalue result), where “cv1 T” is reference-compatible (8.5.3 [dcl.init.ref]) with “cv2 T2”, are candidate functions.

Note from the April, 2013 meeting:

Because of concerns about slicing and performance in the February, 2012 proposed resolution, CWG decided to return to the August, 2011 proposed resolution and split off the discussion about class prvalues into issue 1650.

Proposed resolution (April, 2013):

Change the two indicated (not contiguous) sub-bullets of 8.5.3 [dcl.init.ref] paragraph 5 as follows:

• has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be implicitly converted to an lvalue of type “cv3 T3,”...

• has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be implicitly converted to an xvalue, class prvalue, or function lvalue of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3” (see 13.3.1.6 [over.match.ref]),

1508. Template initializer-list constructors

[Moved to DR at the September, 2013 meeting.]

Can a constructor template ever be an initializer-list constructor without std::initializer_list (or an alias template specialization for it) appearing in the template signature? E.g., is there any way that the constructor in:

  struct S {
    template<typename T> S(T);
  };

can be an initializer-list constructor?

Proposed resolution (October, 2012) [superseded]:

Modify 8.5.4 [dcl.init.list] paragraph 2 as follows:

A constructor is an initializer-list constructor if its first parameter is of type std::initializer_list<E> or reference to possibly cv-qualified std::initializer_list<E> for some type E, and either there are no other parameters or else all other parameters have default arguments (8.3.6 [dcl.fct.default]). [Note: Initializer-list constructors are favored over other constructors in list-initialization (13.3.1.7 [over.match.list]). Given a class C, a constructor template such as template<class T> C(T) is never instantiated to produce an initializer-list constructor, because an initializer list argument causes the corresponding parameter to be a non-deduced context (14.8.2.1 [temp.deduct.call]). —end note] The template std::initializer_list is not predefined;...

Additional note (January, 2013):

The wording of the new note needs to be adjusted, because such a constructor template might have a default template argument that is a specialization of std::initializer_list. For example:

  struct D {
    template<typename T = std::initializer_list<int>> D(T);
  };
  D d{{1, 2, 3}};

Proposed resolution (June, 2013):

Change the note in 8.5.4 [dcl.init.list] paragraph 2 as follows:

[Note: Initializer-list constructors are favored over other constructors in list-initialization (13.3.1.7 [over.match.list]). Passing an initializer list as the argument to the constructor template template<class T> C(T) of a class C does not create an initializer-list constructor, because an initializer list argument causes the corresponding parameter to be a non-deduced context (14.8.2.1 [temp.deduct.call]). —end note]

1460. What is an empty union?

[Moved to DR at the September, 2013 meeting.]

When a similar question was raised in issue 413, the resolution was to remove the use of the term. The resolution of issue 1359 has now reintroduced the concept of an “empty” union, so there is once again the need to define it.

(See also issues 1562 and 1622.)

Proposed resolution (February, 2013) [superseded]:

Change 9.5 [class.union] paragraph 2 as follows:

...At most one non-static data member of a union may have a brace-or-equal-initializer. A union is an empty union if it has no non-static data members. [Note: If any...

Additional note (March, 2013):

The question was raised as to whether an example like

  union A {
    union {};
    union {};
    constexpr A() {}
  };
  A a = A(); 

is well-formed, which hinges on the question of whether A is an “empty union,” per 7.1.5 [dcl.constexpr] paragraph 4 bullet 5:

• if the class is a non-empty union, or for each non-empty anonymous union member of a non-union class, exactly one non-static data member shall be initialized;

Must one of the empty anonymous union members be initialized for A's constructor to be constexpr?

The issue is being returned to "review" status for discussion of this point.

See also issues 1562, 1587, 1621, and 1623.

Proposed resolution (August, 2013):

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

...In addition, either its function-body shall be = delete, or it shall satisfy the following constraints:

• ...

• if the class is a non-empty union, or for each non-empty anonymous union member of a non-union class, exactly one non-static data member shall be initialized;

• if the class is a union having variant members (9.5 [class.union]), exactly one of them shall be initialized;

• if the class is a union-like class, but is not a union, for each of its anonymous union members having variant members, exactly one of them shall be initialized;

• every constructor involved...

2. Change 9.5 [class.union] paragraph 2 as follows:

A union can have member functions (including constructors and destructors), but not virtual (10.3 [class.virtual]) functions. A union shall not have base classes. A union shall not be used as a base class. If a union contains a non-static data member of reference type the program is ill-formed. At most one non-static data member of a union may have a brace-or-equal-initializer. [Note: If any non-static data member...

3. Change 9.5 [class.union] paragraph 8 as follows:

A union-like class is a union or a class that has an anonymous union as a direct member. A union-like class X has a set of variant members. If X is a union its variant members are the non-static data members; otherwise, its variant members are the non-static data members of all anonymous unions that are members of X. If X is a union, a non-static data member of X that is not an anonymous union is a variant member of X. In addition, a non-static data member of an anonymous union that is a member of X is also a variant member of X. At most one variant member of a union may have a brace-or-equal-initializer. [Example:

  union U {
    int x = 0;
    union { };
    union {
      int z;
      int y = 1; // error: initialization for second variant member of U
    };
  };

—end example]

4. Change 12.6.2 [class.base.init] paragraph 8 as follows:

In a non-delegating constructor, if a given non-static data member or base class is not designated by a mem-initializer-id (including the case where there is no mem-initializer-list because the constructor has no ctor-initializer) and the entity is not a virtual base class of an abstract class (10.4 [class.abstract]), then

• if the entity is a non-static data member that has a brace-or-equal-initializer and either

• the constructor's class is a union (9.5 [class.union]), and no other variant member of that union is designated by a mem-initializer-id or

• the constructor's class is not a union, and, if the entity is a member of an anonymous union, no other member of that union is designated by a mem-initializer-id,

the entity is initialized as specified in 8.5 [dcl.init];

• otherwise, if the entity...

(This resolution also resolves issue 1562.)

1514. Ambiguity between enumeration definition and zero-length bit-field

[Moved to DR at the September, 2013 meeting.]

Consider an example like:

  struct S {
    typedef int T;
    enum E : T {};
    enum E : T {};    // #1
  };

The declaration at #1 is ambiguous: it could either be an invalid redefinition of enum E or a zero-length bit-field of type enum E (since T{} is zero-valued constant expression). The current Standard does not appear to have a rule to disambiguate the two.

Proposed resolution (October, 2012) [superseded]:

Change 7.2 [dcl.enum] paragraph 1 as follows:

...the attributes in that attribute-specifier-seq are thereafter considered attributes of the enumeration whenever it is named. In a member-specification, an ambiguity can arise from the similarity between the declaration of an enumeration with an enum-base and the declaration of a zero-length unnamed bit-field of enumeration type. The ambiguity appears as a choice between an enum-specifier and a member-declaration for a bit-field. The resolution is that a : following enum identifier is parsed as part of an enum-base. [Example:

  struct S {
    enum E : int {};
    enum E : int {};  // error: redeclaration of enumeration
  };

—end example]

Notes from the April, 2013 meeting:

The ambiguity does not occur only with an empty set of braces but also when there is a single identifier that could be taken as the name of a constant in a containing scope or the declaration of an enumerator.

The resolution above sounds as if it is to be applied only if an ambiguity occurs; it should instead be always applied.

Proposed resolution (June, 2013):

Change 7.2 [dcl.enum] paragraph 1 as follows:

...the attributes in that attribute-specifier-seq are thereafter considered attributes of the enumeration whenever it is named. A : following “enum identifier” is parsed as part of an enum-base. [Note: This resolves a potential ambiguity between the declaration of an enumeration with an enum-base and the declaration of an unnamed bit-field of enumeration type. [Example:

   struct S {
     enum E : int {};
     enum E : int {};  // error: redeclaration of enumeration
   };

—end example] —end note]

1562. Non-static data member initializers and union ctor-initializer

[Moved to DR at the September, 2013 meeting.]

The following example is ill-formed:

  union U {
    int a = 0;
    float f;
    U() {}               // ok, a initialized to 0
    U(float f) : f(f) {} // error, constructor initializes both a and f
  };

because of 12.6.2 [class.base.init] paragraph 8:

An attempt to initialize more than one non-static data member of a union renders the program ill-formed.

In non-union classes, a mem-initializer takes precedence over a non-static data member initializer, per paragraph 9:

If a given non-static data member has both a brace-or-equal-initializer and a mem-initializer, the initialization specified by the mem-initializer is performed, and the non-static data member's brace-or-equal-initializer is ignored.

It would be reasonable to treat union mem-initializers in an analogous fashion.

(See also issue 1460.)

Proposed resolution (March, 2013) [superseded]:

Change 12.6.2 [class.base.init] paragraph 8 as follows:

In a non-delegating constructor, if a given non-static data member or base class is not designated by a mem-initializer-id (including the case where there is no mem-initializer-list because the constructor has no ctor-initializer) and the entity is not a virtual base class of an abstract class (10.4 [class.abstract]), then

• if the entity is a non-static data member that has a brace-or-equal-initializer and, if the entity is a member of a union, no other non-static data member of that union is designated by a mem-initializer-id, the entity is initialized as specified in 8.5 [dcl.init];

• ...

See also issues 1460, 1587, 1621, and 1623.

Proposed resolution (August, 2013):

This issue is resolved by the resolution of issue 1460.

1649. Error in the syntax of mem-initializer-list

[Moved to DR at the September, 2013 meeting.]

The grammar in 12.6.2 [class.base.init] paragraph 1 for mem-initializer-list is incorrect:

mem-initializer-list:
mem-initializer ..._opt
mem-initializer , mem-initializer-list ..._opt

The ellipsis in the second production should be on mem-initializer, not on mem-initializer-list.

Proposed resolution (August, 2013):

Change the grammar in 12.6.2 [class.base.init] paragraph 1 as follows:

mem-initializer-list:
mem-initializer ..._opt
mem-initializer ..._opt , mem-initializer-list ..._opt

1593. “Parameter type” of special member functions

[Moved to DR at the September, 2013 meeting.]

Paragraphs 12 and 25 of 12.8 [class.copy] both say that the function

is trivial if it is not user-provided, its declared parameter type is the same as if it had been implicitly declared, and...

However, a non-user-provided function might have more than one parameter if default arguments are used. The phrasing would be better as something like “its parameter-type-list is equivalent to the parameter-type-list of an implicit declaration.” (For consistency, the same phrasing should be used in 12.1 [class.ctor] paragraph 5.)

Proposed resolution (June, 2013):

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

A copy/move constructor for class X is trivial if it is not user-provided, its declared parameter type is the same as if it had been implicitly declared parameter-type-list is equivalent to the parameter-type-list of an implicit declaration, and if...

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

A copy/move assignment operator for class X is trivial if it is not user-provided, its declared parameter type is the same as if it had been implicitly declared parameter-type-list is equivalent to the parameter-type-list of an implicit declaration, and if...

1567. Inheriting constructors and copy/move constructors

[Moved to DR at the September, 2013 meeting.]

According to 12.9 [class.inhctor] paragraph 3,

For each non-template constructor in the candidate set of inherited constructors other than a constructor having no parameters or a copy/move constructor having a single parameter, a constructor is implicitly declared with the same constructor characteristics unless there is a user-declared constructor with the same signature in the class where the using-declaration appears.

It seems that this should be suppressing constructors that would be copy/move constructors in the derived class rather than copy/move constructors in the base class. For example:

  struct B;
  struct A {
    A(const A&);
    A(const B&);
    A(int);
  };

  struct B: A {
    using A::A;
  };

If B::B(const B&) is an inheriting constructor, other subobjects of B will not be copied. Also, if A::A(const A&) is not inherited, B objects cannot be constructed from an A object.

Proposed resolution (April, 2013):

Change 12.9 [class.inhctor] paragraph 3 as follows:

For each non-template constructor in the candidate set of inherited constructors other than a constructor having no parameters or a copy/move constructor having a single parameter, a constructor is implicitly declared with the same constructor characteristics unless there is a user-declared constructor with the same signature in the class where the using-declaration appears or the constructor would be a default, copy, or move constructor for that class.

1608. Operator lookup in trailing return type

[Moved to DR at the September, 2013 meeting.]

There is an unfortunate disparity between the treatment of an example like

  struct S {
    int operator[](int);
    auto f() -> decltype(this->operator[](0));
  };

(which is permitted, cf 5.1.1 [expr.prim.general] paragraph 3), and

  struct S {
    int operator[](int);
    auto f() -> decltype((*this)[0]);
  };

which is not. The reason for rejecting the latter is 13.3.1.2 [over.match.oper] paragraph 3:

For a unary operator @ with an operand of a type whose cv-unqualified version is T1, and for a binary operator @ with a left operand of a type whose cv-unqualified version is T1 and a right operand of a type whose cv-unqualified version is T2, three sets of candidate functions, designated member candidates, non-member candidates and built-in candidates, are constructed as follows:

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

• ...

It would be desirable to update the latter specification to allow lookup of preceding declarations in a class currently being defined, analogously with the lookup performed in the function-notation case.

Proposed resolution (April, 2013):

Change 13.3.1.2 [over.match.oper] paragraph 3 bullet 1 as follows:

• If T1 is a complete class type or a class currently being defined, the set of member candidates is the result of the qualified lookup of T1::operator@ (13.3.1.1.1 [over.call.func]); otherwise, the set of member candidates is empty.

1307. Overload resolution based on size of array initializer-list

[Moved to DR at the September, 2013 meeting.]

In an example like

  void f(int const(&)[2]);
  void f(int const(&)[3]);

  int main() {
   f({1, 2, 3});
  }

the current overload resolution rules make no provision for different array sizes and thus treats the call as ambiguous, even though it seems obvious that the second f should be chosen in this case.

Rationale (August, 2011):

The implications of array temporaries for the language should be considered by the Evolution Working Group in a comprehensive fashion rather than on a case-by-case basis. See also issues 1300, 1326, and 1525.

Notes from the October, 2012 meeting:

CWG determined that this issue is unrelated to array temporaries and that a tiebreaker should be added for this case in overload resolution.

Proposed resolution, April, 2013:

1. Change 13.3.3.1.5 [over.ics.list] paragraph 2 as follows, adding a new paragraph (and moving the footnote to the new paragraph, as indicated):

If the parameter type is std::initializer_list<X> or “array of X” [Footnote: Since there are no parameters of array type, this will only occur as the underlying type of a reference parameter. —end footnote] and all the elements of the initializer list can be implicitly converted to X, the implicit conversion sequence is the worst conversion necessary to convert an element of the list to X. This conversion can be a user-defined conversion even in the context of a call to an initializer-list constructor. [Example: ... —end example]

Otherwise, if the parameter type is “array of N X” [Footnote: Since there are no parameters of array type, this will only occur as the underlying type of a reference parameter. —end footnote], if the initializer list has exactly N elements or if it has fewer than N elements and X is default-constructible, and if all the elements of the initializer list can be implicitly converted to X, the implicit conversion sequence is the worst conversion necessary to convert an element of the list to X.

[Drafting note: no other case in the remainder of the paragraph applies when the initializer list has more elements than the parameter array.]

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

Two implicit conversion sequences of the same form are indistinguishable conversion sequences unless one of the following rules applies:

• ...

• List-initialization sequence L1 is a better conversion sequence than list-initialization sequence L2 if L1 converts to std::initializer_list<X> for some X and L2 does not.

• L1 converts to std::initializer_list<X> for some X and L2 does not, or, if not that,

• L1 converts to type “array of N1 T,” L2 converts to type “array of N2 T”, and N1 is smaller than N2.

1570. Address of subobject as non-type template argument

[Moved to DR at the September, 2013 meeting.]

According to 14.3.2 [temp.arg.nontype] paragraph 1, the argument for a non-type template parameter of pointer or reference type must be

a constant expression (5.19 [expr.const]) that designates the address of an object with static storage duration and external or internal linkage or a function with external or internal linkage, including function templates and function template-ids but excluding non-static class members, expressed (ignoring parentheses) as & id-expression, except that the & may be omitted if the name refers to a function or array and shall be omitted if the corresponding template-parameter is a reference

In C++03, the requirement for an id-expression eliminated the use of “addresses of array elements and names or addresses of non-static class members,” as noted in paragraph 3 of that section. With the advent of generalized constant expressions, however, it is possible to satisfy the requirements and still address these subobjects. For example:

  extern constexpr int x[] = { 0, 1 };
  constexpr const int *p1 = x + 1;
  const int &r = *p1;

  template <const int *> struct A;
  template <> struct A<&r> { };

If this is intentional, the note in 14.3.2 [temp.arg.nontype] paragraph 3 should be revised or removed; if not, the normative wording of paragraph 1 must be revised.

Notes from the April, 2013 meeting:

CWG did not favor extending the range of non-type template arguments to include subobjects, feeling that they should continue to be restricted to the address of a complete object.

Proposed resolution (June, 2013):

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

A template-argument for a non-type, non-template template-parameter shall be one of:

• ...

• a constant expression (5.19 [expr.const]) that designates the address of an a complete object with static storage duration and external or internal linkage or a function with external or internal linkage, including function templates and function template-ids but excluding non-static class members, expressed (ignoring parentheses) as & id-expression, where the id-expression is the name of an object or function, except that the & may be omitted if the name refers to a function or array and shall be omitted if the corresponding template-parameter is a reference; or

• ...

1592. When do template parameters match?

[Moved to DR at the September, 2013 meeting.]

According to 14.3.3 [temp.arg.template] paragraph 3,

A template-argument matches a template template-parameter (call it P) when each of the template parameters in the template-parameter-list of the template-argument's corresponding class template or alias template (call it A) matches the corresponding template parameter in the template-parameter-list of P.

There does not appear to be a formal definition of the criteria for whether two template parameters “match,” however, and there is implementation variance in the treatment of an example like

  struct A {
    typedef int T1;
    typedef int T2;
  };
  template<template<typename T, typename T::T1 N> class U>
  struct B {
    U<A, 0> u;
  };
  template<typename T, typename T::T2 N>
  struct C {
  };
  B<C> b; // ok?

Proposed resolution (June, 2013):

Change 14.3.3 [temp.arg.template] paragraph 3 as follows:

A template-argument matches a template template-parameter (call it P) when each of the template parameters in the template-parameter-list of the template-argument's corresponding class template or alias template (call it A) matches the corresponding template parameter in the template-parameter-list of P. Two template parameters match if they are of the same kind (type, non-type, template), for non-type template-parameters, their types are equivalent (14.5.6.1 [temp.over.link]), and for template template-parameters, each of their corresponding template-parameters matches, recursively. When P's template-parameter-list contains a template parameter pack...

1569. Deducing a function parameter pack before ellipsis

[Moved to DR at the September, 2013 meeting.]

According to 14.8.2.5 [temp.deduct.type] paragraph 5, one of the non-deduced contexts is

A function parameter pack that does not occur at the end of the parameter-declaration-clause.

This would make the following example ill-formed:

  template <typename R, typename ...P>
  void foo(R (&)(P ..., ...)) { }

  void bar(int, ...) { }

  void zip() {
   foo(bar);
  }

It is not clear whether this is intentional; if the wording referred to parameter-declaration-list instead of parameter-declaration-clause, the example would be accepted.

Proposed resolution (June, 2013):

Change 14.8.2.5 [temp.deduct.type] paragraph 5 as follows

The non-deduced contexts are:

• ...

• A function parameter pack that does not occur at the end of the parameter-declaration-clause parameter-declaration-list.

1424. When must sub-object destructors be accessible?

[Moved to DR at the September, 2013 meeting.]

The current specification does not appear to say whether an implementation is permitted/required/forbidden to complain when a sub-object's destructor is inaccessible. In particular, if there is no possibility for an exception to be thrown following a given sub-object's construction, should an implementation issue an error if that sub-object's destructor is inaccessible?

Proposed resolution (February, 2013):

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

...A destructor for a class is odr-used as specified in if it is potentially invoked (12.4 [class.dtor]).

2. Change 5.3.4 [expr.new] paragraph 17 as follows:

If the new-expression creates an object or an array of objects of class type, access and ambiguity control are done for the allocation function, the deallocation function (12.5 [class.free]), and the constructor (12.1 [class.ctor]). If the new expression new-expression creates an array of objects of class type, access and ambiguity control are done for the destructor is potentially invoked (12.4 [class.dtor]).

3. Change 12.4 [class.dtor] paragraph 11 as follows:

Destructors are A destructor is invoked implicitly

• for a constructed objects with static storage duration (3.7.1 [basic.stc.static]) at program termination (3.6.3 [basic.start.term]),

• for a constructed objects with thread storage duration (3.7.2 [basic.stc.thread]) at thread exit,

• for a constructed objects with automatic storage duration (3.7.3 [basic.stc.auto]) when the block in which an object is created exits (6.7 [stmt.dcl]),

• for a constructed temporary objects when the its lifetime of a temporary object ends (12.2 [class.temporary]),.

• for constructed objects allocated by a new-expression (5.3.4 [expr.new]), through use of a delete-expression (5.3.5 [expr.delete]),

• in several situations due to the handling of exceptions (15.3 [except.handle]).

In each case, the context of the invocation is the context of the construction of the object. A destructor is also invoked implicitly through use of a delete-expression (5.3.5 [expr.delete]) for a constructed object allocated by a new-expression (5.3.4 [expr.new]); the context of the invocation is the delete-expression. [Note: An array of class type contains several subobjects for each of which the destructor is invoked. —end note] A destructor can also be invoked explicitly. A destructor is potentially invoked if it is invoked or as specified in 5.3.4 [expr.new] and 12.6.2 [class.base.init]. A program is ill-formed if an object of class type or array thereof is declared and the destructor for the class is not accessible at the point of the declaration a destructor that is potentially invoked is deleted or not accessible from the context of the invocation. Destructors can also be invoked explicitly.

4. Add the following as a new paragraph following 12.6.2 [class.base.init] paragraph 9:

If a given non-static data member has both...

In a non-delegating constructor, the destructor for each direct or virtual base class and for each non-static data member of class type is potentially invoked (12.4 [class.dtor]). [Note: This provision ensures that destructors can be called for fully-constructed sub-objects in case an exception is thrown (15.2 [except.ctor]). —end note]

In a non-delegating constructor, initialization proceeds...

Issues with "WP" Status

Issues with "CD1" Status

663. Valid Cyrillic identifier characters

[Voted into the WP at the June, 2008 meeting.]

The C99 and C++ Standards disagree about the validity of two Cyrillic characters for use in identifiers. C++ (_N2691_.E [extendid]) says that 040d is valid in an identifier but that 040e is not; C99 (Annex D) says exactly the opposite. In fact, both characters should be accepted in identifiers; see the Unicode chart.

Proposed resolution (February, 2008):

The reference in paragraph 2 should be changed to ISO/IEC TR 10176:2003 and the table should be changed to conform to the one in that document (beginning on page 34).

357. Definition of signature should include name

[Voted into WP at April, 2007 meeting.]

Section 1.3 [intro.defs], definition of "signature" omits the function name as part of the signature. Since the name participates in overload resolution, shouldn't it be included in the definition? I didn't find a definition of signature in the ARM, but I might have missed it.

Fergus Henderson: I think so. In particular, 17.6.4.3.2 [global.names] reserves certain "function signatures" for use by the implementation, which would be wrong unless the signature includes the name.

-2- Each global function signature declared with external linkage in a header is reserved to the implementation to designate that function signature with external linkage.

-5- Each function signature from the Standard C library declared with external linkage is reserved to the implementation for use as a function signature with both extern "C" and extern "C++" linkage, or as a name of namespace scope in the global namespace.

Other uses of the term "function signature" in the description of the standard library also seem to assume that it includes the name.

James Widman:

Names don't participate in overload resolution; name lookup is separate from overload resolution. However, the word “signature” is not used in clause 13 [over]. It is used in linkage and declaration matching (e.g., 14.5.6.1 [temp.over.link]). This suggests that the name and scope of the function should be part of its signature.

Proposed resolution (October, 2006):

1. Replace 1.3 [intro.defs] “signature” with the following:

the name and the parameter-type-list (8.3.5 [dcl.fct]) of a function, as well as the class or namespace of which it is a member. If a function or function template is a class member its signature additionally includes the cv-qualifiers (if any) on the function or function template itself. The signature of a function template additionally includes its return type and its template parameter list. The signature of a function template specialization includes the signature of the template of which it is a specialization and its template arguments (whether explicitly specified or deduced). [Note: Signatures are used as a basis for name-mangling and linking. —end note]

2. Delete paragraph 3 and replace the first sentence of 14.5.6.1 [temp.over.link] as follows:

The signature of a function template specialization consists of the signature of the function template and of the actual template arguments (whether explicitly specified or deduced).

The signature of a function template consists of its function signature, its return type and its template parameter list is defined in 1.3 [intro.defs]. The names of the template parameters are significant...

(See also issue 537.)

537. Definition of “signature”

[Voted into WP at April, 2007 meeting.]

The standard defines “signature” in two places: 1.3 [intro.defs] and 14.5.6.1 [temp.over.link] paragraphs 3-4. The former seems to be meant as a formal definition (I think it's the only place covering the nontemplate case), yet it lacks some bits mentioned in the latter (specifically, the notion of a “signature of a function template,” which is part of every signature of the associated function template specializations).

Also, I think the 1.3 [intro.defs] words “the information about a function that participates in overload resolution” isn't quite right either. Perhaps, “the information about a function that distinguishes it in a set of overloaded functions?”

Eric Gufford:

In 1.3 [intro.defs] the definition states that “Function signatures do not include return type, because that does not participate in overload resolution,” while 14.5.6.1 [temp.over.link] paragraph 4 states “The signature of a function template consists of its function signature, its return type and its template parameter list.” This seems inconsistent and potentially confusing. It also seems to imply that two identical function templates with different return types are distinct signatures, which is in direct violation of 13.3 [over.match]. 14.5.6.1 [temp.over.link] paragraph 4 should be amended to include verbiage relating to overload resolution.

Either return types are included in function signatures, or they're not, across the board. IMHO, they should be included as they are an integral part of the function declaration/definition irrespective of overloads. Then verbiage should be added about overload resolution to distinguish between signatures and overload rules. This would help clarify things, as it is commonly understood that overload resolution is based on function signature.

In short, the term “function signature” should be made consistent, and removed from its (implicit, explicit or otherwise) linkage to overload resolution as it is commonly understood.

James Widman:

The problem is that (a) if you say the return type is part of the signature of a non-template function, then you have overloading but not overload resolution on return types (i.e., what we have now with function templates). I don't think anyone wants to make the language uglier in that way. And (b) if you say that the return type is not part of the signature of a function template, you will break code. Given those alternatives, it's probably best to maintain the status quo (which the implementors appear to have rendered faithfully).

Proposed resolution (September, 2006):

This issue is resolved by the resolution of issue 357.

513. Non-class “most-derived” objects

[Voted into WP at April, 2006 meeting.]

The standard uses “most derived object” in some places (for example, 1.3 [intro.defs] “dynamic type,” 5.3.5 [expr.delete]) to refer to objects of both class and non-class type. However, 1.8 [intro.object] only formally defines it for objects of class type.

Possible fix: Change the wording in 1.8 [intro.object] paragraph 4 from

an object of a most derived class type is called a most derived object

to

an object of a most derived class type, or of non-class type, is called a most derived object

Proposed resolution (October, 2005):

Add the indicated words to 1.8 [intro.object] paragraph 4:

If a complete object, a data member (9.2 [class.mem]), or an array element is of class type, its type is considered the most derived class, to distinguish it from the class type of any base class subobject; an object of a most derived class type, or of a non-class type, is called a most derived object.

637. Sequencing rules and example disagree

[Voted into the WP at the September, 2008 meeting.]

In 1.9 [intro.execution] paragraph 16, the following expression is still listed as an example of undefined behavior:

    i = ++i + 1;

However, it appears that the new sequencing rules make this expression well-defined:

1. The assignment side-effect is required to be sequenced after the value computations of both its LHS and RHS (5.17 [expr.ass] paragraph 1).

2. The LHS (i) is an lvalue, so its value computation involves computing the address of i.

3. In order to value-compute the RHS (++i + 1), it is necessary to first value-compute the lvalue expression ++i and then do an lvalue-to-rvalue conversion on the result. This guarantees that the incrementation side-effect is sequenced before the computation of the addition operation, which in turn is sequenced before the assignment side effect. In other words, it yields a well-defined order and final value for this expression.

It should be noted that a similar expression

    i = i++ + 1;

is still not well-defined, since the incrementation side-effect remains unsequenced with respect to the assignment side-effect.

It's unclear whether making the expression in the example well-defined was intentional or just a coincidental byproduct of the new sequencing rules. In either case either the example should be fixed, or the rules should be changed.

Clark Nelson: In my opinion, the poster's argument is perfectly correct. The rules adopted reflect the CWG's desired outcome for issue 222. At the Portland meeting, I presented (and still sympathize with) Tom Plum's case that these rules go a little too far in nailing down required behavior; this is a consequence of that.

One way or another, a change needs to be made, and I think we should seriously consider weakening the resolution of issue 222 to keep this example as having undefined behavior. This could be done fairly simply by having the sequencing requirements for an assignment expression depend on whether it appears in an lvalue context.

James Widman: How's this for a possible re-wording?

In all cases, the side effect of the assignment expression is sequenced after the value computations of the right and left operands. Furthermore, if the assignment expression appears in a context where an lvalue is required, the side effect of the assignment expression is sequenced before its value computation.

Notes from the February, 2008 meeting:

There was no real support in the CWG for weakening the resolution of issue 222 and returning the example to having undefined behavior. No one knew of an implementation that doesn't already do the (newly) right thing for such an example, so there was little motivation to go out of our way to increase the domain of undefined behavior. So the proposed resolution is to change the example to one that definitely does have undependable behavior in existing practice, and undefined behavior under the new rules.

Also, the new formulation of the sequencing rules approved in Oxford contained the wording that by and large resolved issue 222, so with the resolution of this issue, we can also close issue 222.

Proposed resolution (March, 2008):

Change the example in 1.9 [intro.execution] paragraph 16 as follows:

    i = v[i++];             // the behavior is undefined
    i = 7, i++, i++;        // i becomes 9
    i = ++i i++ + 1;        // the behavior is undefined
    i = i + 1;              // the value of i is incremented

This resolution also resolves issue 222.

639. What makes side effects “different” from one another?

[Voted into the WP at the September, 2008 meeting.]

Is the behavior undefined in the following example?

    void f() {
         int n = 0;
         n = --n;
    }

1.9 [intro.execution] paragraph 16 says,

If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined.

It's not clear to me whether the two side-effects in n=--n are “different.” As far as I can tell, it seems that both side-effects involve the assignment of -1 to n, which in a sense makes them non-“different.” But I don't know if that's the intent. Would it be better to say “another” instead of “a different?”

On a related note, can we include this example to illustrate?

    void f( int, int );
    void g( int a ) { f( a = -1, a = -1 ); } // Undefined?

Proposed resolution (March, 2008):

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

...If a side effect on a scalar object is unsequenced relative to either a different another side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. [Example:

    void f(int, int);
    void g(int i, int* v) {
        i = v[i++];         // the behavior is undefined
        i = 7, i++, i++;    // i becomes 9

        i = ++i + 1;        // the behavior is undefined
        i = i + 1;          // the value of i is incremented

        f(i = -1, i = -1);  // the behavior is undefined
    }

—end example] When calling...

362. Order of initialization in instantiation units

[Voted into WP at March 2004 meeting.]

Should this program do what its author obviously expects? As far as I can tell, the standard says that the point of instantiation for Fib<n-1>::Value is the same as the point of instantiation as the enclosing specialization, i.e., Fib<n>::Value. What in the standard actually says that these things get initialized in the right order?

  template<int n>
  struct Fib { static int Value; };

  template <>
  int Fib<0>::Value = 0;

  template <>
  int Fib<1>::Value = 1;

  template<int n>
  int Fib<n>::Value = Fib<n-1>::Value + Fib<n-2>::Value;

  int f ()
  {
    return Fib<40>::Value;
  }

John Spicer: My opinion is that the standard does not specify the behavior of this program. I thought there was a core issue related to this, but I could not find it. The issue that I recall proposed tightening up the static initialization rules to make more cases well defined.

Your comment about point of instantiation is correct, but I don't think that really matters. What matters is the order of execution of the initialization code at execution time. Instantiations don't really live in "translation units" according to the standard. They live in "instantiation units", and the handling of instantiation units in initialization is unspecified (which should probably be another core issue). See 2.2 [lex.phases] paragraph 8.

Notes from October 2002 meeting:

We discussed this and agreed that we really do mean the the order is unspecified. John Spicer will propose wording on handling of instantiation units in initialization.

Proposed resolution (April 2003):

TC1 contains the following text in 3.6.2 [basic.start.init] paragraph 1:

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

This was revised by issue 270 to read:

Dynamic initialization of an object is either ordered or unordered. Explicit specializations and definitions of class template static data members have ordered initialization. Other class template static data member instances have unordered initialization. Other objects defined in namespace scope have ordered initialization. Objects defined within a single translation unit and with ordered initialization shall be initialized in the order of their definitions in the translation unit. The order of initialization is unspecified for objects with unordered initialization and for objects defined in different translation units.

This addresses this issue but while reviewing this issue some additional changes were suggested for the above wording:

Dynamic initialization of an object is either ordered or unordered. Definitions of explicitly specialized Explicit specializations and definitions of class template static data members have ordered initialization. Other class template static data members (i.e., implicitly or explicitly instantiated specializations) instances have unordered initialization. Other objects defined in namespace scope have ordered initialization. Objects defined within a single translation unit and with ordered initialization shall be initialized in the order of their definitions in the translation unit. The order of initialization is unspecified for objects with unordered initialization and for objects defined in different translation units.

558. Excluded characters in universal character names

[Moved to DR at October 2007 meeting.]

C99 and C++ differ in their approach to universal character names (UCNs).

Issue 248 already covers the differences in UCNs allowed for identifiers, but a more fundamental issue is that of UCNs that correspond to codes reserved by ISO 10676 for surrogate pair forms.

Specifically, C99 does not allow UCNs whose short names are in the range 0xD800 to 0xDFFF. I think C++ should have the same constraint. If someone really wants to place such a code in a character or string literal, they should use a hexadecimal escape sequence instead, for example:

    wchar_t  w1 = L'\xD900'; // Okay.
    wchar_t  w2 = L'\uD900'; // Error, not a valid character.

(Compare 6.4.3 paragraph 2 in ISO/IEC 9899/1999 with 2.3 [lex.charset] paragraph 2 in the C++ standard.)

Proposed resolution (October, 2007):

This issue is resolved by the adoption of paper J16/07-0030 = WG21 N2170.

505. Conditionally-supported behavior for unknown character escapes

[Voted into WP at the October, 2006 meeting.]

The current wording of 2.14.3 [lex.ccon] paragraph 3 states,

If the character following a backslash is not one of those specified, the behavior is undefined.

Paper J16/04-0167=WG21 N1727 suggests that such character escapes be ill-formed. In discussions at the Lillehammer meeting, however, the CWG felt that the newly-approved category of conditionally-supported behavior would be more appropriate.

Proposed resolution (April, 2006):

Change the next-to-last sentence of 2.14.3 [lex.ccon] paragraph 3 from:

If the character following a backslash is not one of those specified, the behavior is undefined.

to:

Escape sequences in which the character following the backslash is not listed in Table 6 are conditionally-supported, with implementation-defined semantics.

309. Linkage of entities whose names are not simply identifiers, in introduction

[Voted into the WP at the June, 2008 meeting.]

3 [basic] paragraph 8, while not incorrect, does not allow for linkage of operators and conversion functions. It says:

An identifier used in more than one translation unit can potentially refer to the same entity in these translation units depending on the linkage (3.5 [basic.link]) of the identifier specified in each translation unit.

Proposed Resolution (November, 2006):

This issue is resolved by the proposed resolution of issue 485.

485. What is a “name”?

[Voted into the WP at the June, 2008 meeting.]

Clause 3 [basic] paragraph 4 says:

A name is a use of an identifier (2.11 [lex.name]) that denotes an entity or label (6.6.4 [stmt.goto], 6.1 [stmt.label]).

Just three paragraphs later, it says

Two names are the same if

• they are identifiers composed of the same character sequence; or
• they are the names of overloaded operator functions formed with the same operator; or
• they are the names of user-defined conversion functions formed with the same type.

The last two bullets contradict the definition of name in paragraph 4 because they are not identifiers.

This definition affects other parts of the Standard, as well. For example, in 3.4.2 [basic.lookup.argdep] paragraph 1,

When an unqualified name is used as the postfix-expression in a function call (5.2.2 [expr.call]), other namespaces not considered during the usual unqualified lookup (3.4.1 [basic.lookup.unqual]) may be searched, and in those namespaces, namespace-scope friend function declarations (11.3 [class.friend]) not otherwise visible may be found.

With the current definition of name, argument-dependent lookup apparently does not apply to function-notation calls to overloaded operators.

Another related question is whether a template-id is a name or not and thus would trigger an argument-dependent lookup. Personally, I have always viewed a template-id as a name, just like operator+.

Proposed Resolution (November, 2006):

1. Change clause 3 [basic] paragraphs 3-8 as follows:

   3. An entity is a value, object, subobject, base class subobject, array element, variable, reference, function, instance of a function, enumerator, type, class member, template, template specialization, namespace, or parameter pack.

   4. A name is a use of an identifier identifier (2.11 [lex.name]), operator-function-id (13.5 [over.oper]), conversion-function-id (12.3.2 [class.conv.fct]), or template-id (14.2 [temp.names]) that denotes an entity or label (6.6.4 [stmt.goto], 6.1 [stmt.label]). A variable is introduced by the declaration of an object. The variable's name denotes the object.

   5. Every name that denotes an entity is introduced by a declaration. Every name that denotes a label is introduced either by a goto statement (6.6.4 [stmt.goto]) or a labeled-statement (6.1 [stmt.label]).

   1. A variable is introduced by the declaration of an object. The variable's name denotes the object.

   6. Some names denote types, classes, enumerations, or templates. In general, it is necessary to determine whether or not a name denotes one of these entities before parsing the program that contains it. The process that determines this is called name lookup (3.4 [basic.lookup]).

   7. Two names are the same if

      • they are identifiers identifiers composed of the same character sequence; or

      • they are the names of overloaded operator functions operator-function-ids formed with the same operator; or

      • they are the names of user-defined conversion functions conversion-function-ids formed with the same type., or

      • they are template-ids that refer to the same class or function (14.4 [temp.type]).

   8. An identifier A name used in more than one translation unit can potentially refer to the same entity in these translation units depending on the linkage (3.5 [basic.link]) of the identifier name specified in each translation unit.

2. Change 3.3.7 [basic.scope.class] paragraph 1 item 5 as follows:

   The potential scope of a declaration that extends to or past the end of a class definition also extends to the regions defined by its member definitions, even if the members are defined lexically outside the class (this includes static data member definitions, nested class definitions, member function definitions (including the member function body and any portion of the declarator part of such definitions which follows the identifier declarator-id, including a parameter-declaration-clause and any default arguments (8.3.6 [dcl.fct.default]).

   [Drafting note: This last change is not really mandated by the issue, but it's another case of “identifier” confusion.]

(This proposed resolution also resolves issue 309.)

261. When is a deallocation function "used?"

[Moved to DR at October 2002 meeting.]

3.2 [basic.def.odr] paragraph 2 says that a deallocation function is "used" by a new-expression or delete-expression appearing in a potentially-evaluated expression. 3.2 [basic.def.odr] paragraph 3 requires only that "used" functions be defined.

This wording runs afoul of the typical implementation technique for polymorphic delete-expressions in which the deallocation function is invoked from the virtual destructor of the most-derived class. The problem is that the destructor must be defined, because it's virtual, and if it contains an implicit reference to the deallocation function, the deallocation function must also be defined, even if there are no relevant new-expressions or delete-expressions in the program.

For example:

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

        struct D: B {
            void operator delete(void*);
            ~D() { }
        };

Is it required that D::operator delete(void*) be defined, even if no B or D objects are ever created or deleted?

Suggested resolution: Add the words "or if it is found by the lookup at the point of definition of a virtual destructor (12.4 [class.dtor])" to the specification in 3.2 [basic.def.odr] paragraph 2.

Notes from 04/01 meeting:

The consensus was in favor of requiring that any declared non-placement operator delete member function be defined if the destructor for the class is defined (whether virtual or not), and similarly for a non-placement operator new if a constructor is defined.

Proposed resolution (10/01):

In 3.2 [basic.def.odr] paragraph 2, add the indicated text:

An allocation or deallocation function for a class is used by a new expression appearing in a potentially-evaluated expression as specified in 5.3.4 [expr.new] and 12.5 [class.free]. A deallocation function for a class is used by a delete expression appearing in a potentially-evaluated expression as specified in 5.3.5 [expr.delete] and 12.5 [class.free]. A non-placement allocation or deallocation function for a class is used by the definition of a constructor of that class. A non-placement deallocation function for a class is used by the definition of the destructor of that class, or by being selected by the lookup at the point of definition of a virtual destructor (12.4 [class.dtor]). [Footnote: An implementation is not required to call allocation and deallocation functions from constructors or destructors; however, this is a permissible implementation technique.]

289. Incomplete list of contexts requiring a complete type

[Moved to DR at October 2002 meeting.]

3.2 [basic.def.odr] paragraph 4 has a note listing the contexts that require a class type to be complete. It does not list use as a base class as being one of those contexts.

Proposed resolution (10/01):

In 3.2 [basic.def.odr] paragraph 4 add a new bullet at the end of the note as the next-to-last bullet:

• a class with a base class of type T is defined (10 [class.derived]), or

433. Do elaborated type specifiers in templates inject into enclosing namespace scope?

[Voted into WP at March 2004 meeting.]

Consider the following translation unit:

  template<class T> struct S {
    void f(union U*);  // (1)
  };
  template<class T> void S<T>::f(union U*) {}  // (2)
  U *p;  // (3)

Does (1) introduce U as a visible name in the surrounding namespace scope?

If not, then (2) could presumably be an error since the "union U" in that definition does not find the same type as the declaration (1).

If yes, then (3) is OK too. However, we have gone through much trouble to allow template implementations that do not pre-parse the template definitions, but requiring (1) to be visible would change that.

A slightly different case is the following:

  template<typename> void f() { union U *p; }
  U *q;  // Should this be valid?

Notes from October 2003 meeting:

There was consensus that example 1 should be allowed. (Compilers already parse declarations in templates; even MSVC++ 6.0 accepts this case.) The vote was 7-2.

Example 2, on the other hand, is wrong; the union name goes into a block scope anyway.

Proposed resolution:

In 3.3.2 [basic.scope.pdecl] change the second bullet of paragraph 5 as follows:

for an elaborated-type-specifier of the form

   class-key identifier

if the elaborated-type-specifier is used in the decl-specifier-seq or parameter-declaration-clause of a function defined in namespace scope, the identifier is declared as a class-name in the namespace that contains the declaration; otherwise, except as a friend declaration, the identifier is declared in the smallest non-class, non-function-prototype scope that contains the declaration. [Note: These rules also apply within templates.] [Note: ...]

432. Is injected class name visible in base class specifier list?

[Voted into WP at March 2004 meeting.]

Consider the following example (inspired by a question from comp.lang.c++.moderated):

  template<typename> struct B {};
  template<typename T> struct D: B<D> {};

Most (all?) compilers reject this code because D is handled as a template name rather than as the injected class name.

9 [class]/2 says that the injected class name is "inserted into the scope of the class."

3.3.7 [basic.scope.class]/1 seems to be the text intended to describe what "scope of a class" means, but it assumes that every name in that scope was introduced using a "declarator". For an implicit declaration such as the injected-class name it is not clear what that means.

So my questions:

1. Should the injected class name be available in the base class specifiers?

   John Spicer: I do not believe the injected class name should be available in the base specifier. I think the semantics of injected class names should be as if a magic declaration were inserted after the opening "{" of the class definition. The injected class name is a member of the class and members don't exist at the point where the base specifiers are scanned.

2. Do you agree the wording should be clarified whatever the answer to the first question?

   John Spicer: I believe the 3.3.7 [basic.scope.class] wording should be updated to reflect the fact that not all names come from declarators.

Notes from October 2003 meeting:

We agree with John Spicer's suggested answers above.

Proposed Resolution (October 2003):

The answer to question 1 above is No and no change is required.

For question 1, change 3.3.7 [basic.scope.class] paragraph 1 rule 1 to:

1) The potential scope of a name declared in a class consists not only of the declarative region following the name's point of declaration declarator, but also of all function bodies, default arguments, and constructor ctor-initializers in that class (including such things in nested classes). The point of declaration of an injected-class-name (clause 9 [class]) is immediately following the opening brace of the class definition.

(Note that this change overlaps a change in issue 417.)

Also change 3.3.2 [basic.scope.pdecl] by adding a new paragraph 8 for the injected-class-name case:

The point of declaration for an injected-class-name (clause 9 [class]) is immediately following the opening brace of the class definition.

Alternatively this paragraph could be added after paragraph 5 and before the two note paragraphs (i.e. it would become paragraph 5a).

139. Error in friend lookup example

[Moved to DR at 10/01 meeting.]

The example in 3.4.1 [basic.lookup.unqual] paragraph 3 is incorrect:

    typedef int f;
    struct A {
        friend void f(A &);
        operator int();
        void g(A a) {
            f(a);
        }
    };

One possible repair of the example would be to make f a class with a constructor taking either A or int as its parameter.

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

Proposed resolution (04/01):

1. Change the example in 3.4.1 [basic.lookup.unqual] paragraph 3 to read:

       typedef int f;
       namespace N {
           struct A {
               friend int f(A &);
               operator int();
               void g(A a) {
                   int i = f(a);
                         // f is the typedef, not the friend function:
                         // equivalent to int(a)
               }
           };
       }
   

2. Delete the sentence immediately following the example:

   The expression f(a) is a cast-expression equivalent to int(a).

514. Is the initializer for a namespace member in the scope of the namespace?

[Voted into WP at the October, 2006 meeting.]

Is the following code well-formed?

    namespace N {
      int i;
      extern int j;
    }
    int N::j = i;

The question here is whether the lookup for i in the initializer of N::j finds the declaration in namespace N or not. Implementations differ on this question.

If N::j were a static data member of a class, the answer would be clear: both 3.4.1 [basic.lookup.unqual] paragraph 12 and 8.5 [dcl.init] paragraph 11 say that the initializer “is in the scope of the member's class.” There is no such provision for namespace members defined outside the namespace, however.

The reasoning given in 3.4.1 [basic.lookup.unqual] may be instructive:

A name used in the definition of a static data member of class X (9.4.2 [class.static.data]) (after the qualified-id of the static member) is looked up as if the name was used in a member function of X.

It is certainly the case that a name used in a function that is a member of a namespace is looked up in that namespace (3.4.1 [basic.lookup.unqual] paragraph 6), regardless of whether the definition is inside or outside that namespace. Initializers for namespace members should probably be looked up the same way.

Proposed resolution (April, 2006):

Add a new paragraph following 3.4.1 [basic.lookup.unqual] paragraph 12:

If a variable member of a namespace is defined outside of the scope of its namespace then any name used in the definition of the variable member (after the declarator-id) is looked up as if the definition of the variable member occurred in its namespace. [Example:

    namespace N {
      int i = 4;
      extern int j;
    }

    int i = 2;

    int N::j = i;	// N::j == 4

—end example]

143. Friends and Koenig lookup

[Moved to DR at 4/02 meeting.]

Paragraphs 1 and 2 of 3.4.2 [basic.lookup.argdep] say, in part,

When an unqualified name is used as the postfix-expression in a function call (5.2.2 [expr.call] )... namespace-scope friend function declarations (11.3 [class.friend] ) not otherwise visible may be found... the set of declarations found by the lookup of the function name [includes] the set of declarations found in the... classes associated with the argument types.

Consider the following example:

    namespace A {
	class S;
    };
    namespace B {
	void f(A::S);
    };
    namespace A {
	class S {
	    int i;
	    friend void B::f(S);
	};
    }
    void g() {
	A::S s;
	f(s); // should find B::f(A::S)
    }

Another interpretation is that, instead of finding the friend declarations in associated classes, one only looks for namespace-scope functions, visible or invisible, in the namespaces of which the the associated classes are members; the only use of the friend declarations in the associated classes is to validate whether an invisible function declaration came from an associated class or not and thus whether it should be included in the overload set or not. By this interpretation, the call f(s) in the example will fail, because B::f(A::S) is not a member of namespace A and thus is not found by the lookup.

Notes from 10/99 meeting: The second interpretation is correct. The wording should be revised to make clear that Koenig lookup works by finding "invisible" declarations in namespace scope and not by finding friend declarations in associated classes.

Proposed resolution (04/01): The "associated classes" are handled adequately under this interpretation by 3.4.2 [basic.lookup.argdep] paragraph 3, which describes the lookup in the associated namespaces as including the friend declarations from the associated classes. Other mentions of the associated classes should be removed or qualified to avoid the impression that there is a lookup in those classes:

1. In 3.4.2 [basic.lookup.argdep], change

   When an unqualified name is used as the postfix-expression in a function call (5.2.2 [expr.call]), other namespaces not considered during the usual unqualified lookup (3.4.1 [basic.lookup.unqual]) may be searched, and namespace-scope friend function declarations (11.3 [class.friend]) not otherwise visible may be found.

   to

   When an unqualified name is used as the postfix-expression in a function call (5.2.2 [expr.call]), other namespaces not considered during the usual unqualified lookup (3.4.1 [basic.lookup.unqual]) may be searched, and in those namespaces, namespace-scope friend function declarations (11.3 [class.friend]) not otherwise visible may be found.

2. In 3.4.2 [basic.lookup.argdep] paragraph 2, delete the words and classes in the following two sentences:

   If the ordinary unqualified lookup of the name finds the declaration of a class member function, the associated namespaces and classes are not considered. Otherwise the set of declarations found by the lookup of the function name is the union of the set of declarations found using ordinary unqualified lookup and the set of declarations found in the namespaces and classes associated with the argument types.

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

218. Specification of Koenig lookup

[Voted into WP at April, 2007 meeting.]

The original intent of the Committee when Koenig lookup was added to the language was apparently something like the following:

1. The name in the function call expression is looked up like any other unqualified name.
2. If the ordinary unqualified lookup finds nothing or finds the declaration of a (non-member) function, function template, or overload set, argument-dependent lookup is done and any functions found in associated namespaces are added to the result of the ordinary lookup.

This approach is not reflected in the current wording of the Standard. Instead, the following appears to be the status quo:

1. Lookup of an unqualified name used as the postfix-expression in the function call syntax always performs Koenig lookup (3.4.1 [basic.lookup.unqual] paragraph 3).
2. Unless ordinary lookup finds a class member function, the result of Koenig lookup always includes the declarations found in associated namespaces (3.4.2 [basic.lookup.argdep] paragraph 2), regardless of whether ordinary lookup finds a declaration and, if so, what kind of entity is found.
3. The declarations from associated namespaces are not limited to functions and template functions by anything in 3.4.2 [basic.lookup.argdep]. However, if Koenig lookup results in more than one declaration and at least one of the declarations is a non-function, the program is ill-formed (7.3.4 [namespace.udir], paragraph 4; although this restriction is in the description of the using-directive, the wording applies to any lookup that spans namespaces).

John Spicer: Argument-dependent lookup was created to solve the problem of looking up function names within templates where you don't know which namespace to use because it may depend on the template argument types (and was then expanded to permit use in nontemplates). The original intent only concerned functions. The safest and simplest change is to simply clarify the existing wording to that effect.

Bill Gibbons: I see no reason why non-function declarations should not be found. It would take a special rule to exclude "function objects", as well as pointers to functions, from consideration. There is no such rule in the standard and I see no need for one.

There is also a problem with the wording in 3.4.2 [basic.lookup.argdep] paragraph 2:

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

This implies that if the ordinary lookup of the name finds the declaration of a data member which is a pointer to function or function object, argument-dependent lookup is still done.

My guess is that this is a mistake based on the incorrect assumption that finding any member other than a member function would be an error. I would just change "class member function" to "class member" in the quoted sentence.

Mike Miller: In light of the issue of "short-circuiting" Koenig lookup when normal lookup finds a non-function, perhaps it should be written as "...finds the declaration of a class member, an object, or a reference, the associated namespaces..."?

Andy Koenig: I think I have to weigh in on the side of extending argument-dependent lookup to include function objects and pointers to functions. I am particularly concerned about [function objects], because I think that programmers should be able to replace functions by function objects without changing the behavior of their programs in fundamental ways.

Bjarne Stroustrup: I don't think we could seriously argue from first principles that [argument-dependent lookup should find only function declarations]. In general, C++ name lookup is designed to be independent of type: First we find the name(s), then, we consider its(their) meaning. 3.4 [basic.lookup] states "The name lookup rules apply uniformly to all names ..." That is an important principle.

Thus, I consider text that speaks of "function call" instead of plain "call" or "application of ()" in the context of koenig lookup an accident of history. I find it hard to understand how 5.2.2 [expr.call] doesn't either disallow all occurrences of x(y) where x is a class object (that's clearly not intended) or requires koenig lookup for x independently of its type (by reference from 3.4 [basic.lookup]). I suspect that a clarification of 5.2.2 [expr.call] to mention function objects is in order. If the left-hand operand of () is a name, it should be looked up using koenig lookup.

John Spicer: This approach causes otherwise well-formed programs to be ill-formed, and it does so by making names visible that might be completely unknown to the author of the program. Using-directives already do this, but argument-dependent lookup is different. You only get names from using-directives if you actually use using-directives. You get names from argument-dependent lookup whether you want them or not.

This basically breaks an important reason for having namespaces. You are not supposed to need any knowledge of the names used by a namespace.

But this example breaks if argument-dependent lookup finds non-functions and if the translation unit includes the <list> header somewhere.

    namespace my_ns {
        struct A {};
        void list(std::ostream&, A&);

        void f() {
            my_ns::A a;
            list(cout, a);
        }
    }

This really makes namespaces of questionable value if you still need to avoid using the same name as an entity in another namespace to avoid problems like this.

Erwin Unruh: Before we really decide on this topic, we should have more analysis on the impact on programs. I would also like to see a paper on the possibility to overload functions with function surrogates (no, I won't write one). Since such an extension is bound to wait until the next official update, we should not preclude any outcome of the discussion.

I would like to have a change right now, which leaves open several outcomes later. I would like to say that:

Koenig lookup will find non-functions as well. If it finds a variable, the program is ill-formed. If the primary lookup finds a variable, Koenig lookup is done. If the result contains both functions and variables, the program is ill-formed. [Note: A future standard will assign semantics to such a program.]

I myself are not comfortable with this as a long-time result, but it prepares the ground for any of the following long term solutions:

• Do overloading on mixed function/variable sets.
• Ignore variables on Koenig lookup.
• Don't do Koenig lookup if the primary lookup finds a variable.
• Find variables on Koenig lookup and give an error if there is a variable/function mix.

The note is there to prevent compiler vendors to put their own extensions in here.

(See also issues 113 and 143.)

Notes from 04/00 meeting:

Although many agreed that there were valid concerns motivating a desire for Koenig lookup to find non-function declarations, there was also concern that supporting this capability would be more dangerous than helpful in the absence of overload resolution for mixed function and non-function declarations.

A straw poll of the group revealed 8 in favor of Koenig lookup finding functions and function templates only, while 3 supported the broader result.

Notes from the 10/01 meeting:

There was unanimous agreement on one less controversial point: if the normal lookup of the identifier finds a non-function, argument-dependent lookup should not be done.

On the larger issue, the primary point of consensus is that making this change is an extension, and therefore it should wait until the point at which we are considering extensions (which could be very soon). There was also consensus on the fact that the standard as it stands is not clear: some introductory text suggests that argument-dependent lookup finds only functions, but the more detailed text that describes the lookup does not have any such restriction.

It was also noted that some existing implementations (e.g., g++) do find some non-functions in some cases.

The issue at this point is whether we should (1) make a small change to make the standard clear (presumably in the direction of not finding the non-functions in the lookup), and revisit the issue later as an extension, or (2) leave the standard alone for now and make any changes only as part of considering the extension. A straw vote favored option (1) by a strong majority.

Additional Notes (September, 2006):

Recent discussion of this issue has emphasized the following points:

1. The concept of finding function pointers and function objects as part of argument-dependent lookup is not currently under active discussion in the Evolution Working Group.

2. The major area of concern with argument-dependent lookup is finding functions in unintended namespaces. There are current proposals to deal with this concern either by changing the definition of “associated namespace” so that fewer namespaces are considered or to provide a mechanism for enabling or disabling ADL altogether. Although this concern is conceptually distinct from the question of whether ADL finds function pointers and function objects, it is related in the sense that the current rules are perceived as finding too many functions (because of searching too many namespaces), and allowing function pointers and function objects would also increase the number of entities found by ADL.

3. Any expansion of ADL to include function pointers and function objects must necessarily update the overloading rules to specify how they interact with functions and function templates in the overload set. Current implementation experience (g++) is not helpful in making this decision because, although it performs a uniform lookup and finds non-function entities, it diagnoses an error in overload resolution if non-function entities are in the overload set.

4. There is a possible problem if types are found by ADL: it is not clear that overloading between callable entities (functions, function templates, function pointers, and function objects) and types (where the postfix syntax means a cast or construction of a temporary) is reasonable or useful.

James Widman:

There is a larger debate here about whether ADL should find object names; the proposed wording below is only intended to answer the request for wording to clarify the status quo (option 1 above) and not to suggest the outcome of the larger debate.

Proposed Resolution (October, 2006):

1. Replace the normative text in 3.4.2 [basic.lookup.argdep] paragraph 3 with the following (leaving the text of the note and example unchanged):

   Let X be the lookup set produced by unqualified lookup (3.4.1 [basic.lookup.unqual]) and let Y be the lookup set produced by argument dependent lookup (defined as follows). If X contains

   • a declaration of a class member, or
   • a block-scope function declaration that is not a using-declaration, or
   • a declaration that is neither a function nor a function template

   then Y is empty. Otherwise Y is the set of declarations found in the namespaces associated with the argument types as described below. The set of declarations found by the lookup of the name is the union of X and Y.

2. Change 3.4.1 [basic.lookup.unqual] paragraph 4 as indicated:

   When considering an associated namespace, the lookup is the same as the lookup performed when the associated namespace is used as a qualifier (3.4.3.2 [namespace.qual]) except that:

   • Any using-directives in the associated namespace are ignored.
   • Any namespace-scope friend functions or friend function templates declared in associated classes are visible within their respective namespaces even if they are not visible during an ordinary lookup (11.3 [class.friend]).
   • All names except those of (possibly overloaded) functions and function templates are ignored.

403. Reference to a type as a template-id

[Voted into WP at March 2004 meeting.]

Spun off from issue 384.

3.4.2 [basic.lookup.argdep] says:

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

Proposed Resolution (October 2003):

In 3.4.2 [basic.lookup.argdep], paragraph 2, bullet 8, replace

If T is a template-id ...

If T is a class template specialization ...

557. Does argument-dependent lookup cause template instantiation?

[Voted into WP at the October, 2006 meeting.]

One might assume from 14.7.1 [temp.inst] paragraph 1 that argument-dependent lookup would require instantiation of any class template specializations used in argument types:

Unless a class template specialization has been explicitly instantiated (14.7.2 [temp.explicit]) or explicitly specialized (14.7.3 [temp.expl.spec]), the class template specialization is implicitly instantiated when the specialization is referenced in a context that requires a completely-defined object type or when the completeness of the class type affects the semantics of the program.

A complete class type is required to determine the associated classes and namespaces for the argument type (to determine the class's bases) and to determine the friend functions declared by the class, so the completeness of the class type certainly “affects the semantics of the program.”

This conclusion is reinforced by the second bullet of 3.4.2 [basic.lookup.argdep] paragraph 2:

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

A class template specialization is a class type, so the second bullet would appear to apply, requiring the specialization to be instantiated in order to determine its base classes.

However, bullet 8 of that paragraph deals explicitly with class template specializations:

• If T is a class template specialization its associated namespaces and classes are the namespace in which the template is defined; for member templates, the member template's class; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which any template template arguments are defined; and the classes in which any member templates used as template template arguments are defined.

Note that the class template specialization itself is not listed as an associated class, unlike other class types, and there is no mention of base classes. If bullet 8 were intended as a supplement to the treatment of class types in bullet 2, one would expect phrasing along the lines of, “In addition to the associated namespaces and classes for all class types...” or some such; instead, bullet 8 reads like a self-contained and complete specification.

If argument-dependent lookup does not cause implicit instantiation, however, examples like the following fail:

    template <typename T> class C {
        friend void f(C<T>*) { }
    };
    void g(C<int>* p) {
        f(p);    // found by ADL??
    }

Implementations differ in whether this example works or not.

Proposed resolution (April, 2006):

1. Change bullet 2 of 3.4.2 [basic.lookup.argdep] paragraph 2 as indicated:

   • If T is a class type (including unions), its associated classes are: the class itself; the class of which it is a member, if any; and its direct and indirect base classes. Its associated namespaces are the namespaces in of which its associated classes are defined members. Furthermore, if T is a class template specialization, its associated namespaces and classes also include: the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces of which any template template arguments are members; and the classes of which any member templates used as template template arguments are members. [Note: Non-type template arguments do not contribute to the set of associated namespaces. —end note]

2. Delete bullet 8 of 3.4.2 [basic.lookup.argdep] paragraph 2:

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

298. T::x when T is cv-qualified

[Voted into WP at April 2003 meeting.]

Can a typedef T to a cv-qualified class type be used in a qualified name T::x?

    struct A { static int i; };
    typedef const A CA;
    int main () {
      CA::i = 0;  // Okay?
    }

Suggested answer: Yes. All the compilers I tried accept the test case.

Proposed resolution (10/01):

In 3.4.3.1 [class.qual] paragraph 1 add the indicated text:

If the nested-name-specifier of a qualified-id nominates a class, the name specified after the nested-name-specifier is looked up in the scope of the class (10.2 [class.member.lookup]), except for the cases listed below. The name shall represent one or more members of that class or of one of its base classes (clause 10 [class.derived]). If the class-or-namespace-name of the nested-name-specifier names a cv-qualified class type, it nominates the underlying class (the cv-qualifiers are ignored).

Notes from 4/02 meeting:

There is a problem in that class-or-namespace-name does not include typedef names for cv-qualified class types. See 7.1.3 [dcl.typedef] paragraph 4:

Argument and text removed from proposed resolution (October 2002):

7.1.3 [dcl.typedef] paragraph 5:

Here's a good question: in this example, should X be used as a name-for-linkage-purposes (FLP name)?

  typedef class { } const X;

Because a type-qualifier is parsed as a decl-specifier, it isn't possible to declare cv-qualified and cv-unqualified typedefs for a type in a single declaration. Also, of course, there's no way to declare a typedef for the cv-unqualified version of a type for which only a cv-qualified version has a name. So, in the above example, if X isn't used as the FLP name, then there can be no FLP name. Also note that a FLP name usually represents a parameter type, where top-level cv-qualifiers are usually irrelevant anyway.

Data points: for the above example, Microsoft uses X as the FLP name; GNU and EDG do not.

My recommendation: for consistency with the direction we're going on this issue, for simplicity of description (e.g., "the first class-name declared by the declaration"), and for (very slightly) increased utility, I think Microsoft has this right.

If the typedef declaration defines an unnamed class type (or enum type), the first typedef-name declared by the declaration to be have that class type (or enum type) or a cv-qualified version thereof is used to denote the class type (or enum type) for linkage purposes only (3.5 [basic.link]). [Example: ...

Proposed resolution (October 2002):

3.4.4 [basic.lookup.elab] paragraphs 2 and 3:

This sentence is deleted twice:

... If this name lookup finds a typedef-name, the elaborated-type-specifier is ill-formed. ...

Note that the above changes are included in N1376 as part of the resolution of issue 245.

5.1.1 [expr.prim.general] paragraph 7:

This is only a note, and it is at least incomplete (and quite possibly inaccurate), despite (or because of) its complexity. I propose to delete it.

... [Note: a typedef-name that names a class is a class-name (9.1 [class.name]). Except as the identifier in the declarator for a constructor or destructor definition outside of a class member-specification (12.1 [class.ctor], 12.4 [class.dtor]), a typedef-name that names a class may be used in a qualified-id to refer to a constructor or destructor. ]

7.1.3 [dcl.typedef] paragraph 4:

My first choice would have been to make this the primary statement about the equivalence of typedef-name and class-name, since the equivalence comes about as a result of a typedef declaration. Unfortunately, references to class-name point to 9.1 [class.name], so it would seem that the primary statement should be there instead. To avoid the possiblity of conflicts in the future, I propose to make this a note.

[Note: A typedef-name that names a class type, or a cv-qualified version thereof, is also a class-name (9.1 [class.name]). If a typedef-name is used following the class-key in an elaborated-type-specifier (7.1.6.3 [dcl.type.elab]), or in the class-head of a class declaration (9 [class]), or is used as the identifier in the declarator for a constructor or destructor declaration (12.1 [class.ctor], 12.4 [class.dtor]), to identify the subject of an elaborated-type-specifier (7.1.6.3 [dcl.type.elab]), class declaration (clause 9 [class]), constructor declaration (12.1 [class.ctor]), or destructor declaration (12.4 [class.dtor]), the program is ill-formed. ] [Example: ...

7.1.6.3 [dcl.type.elab] paragraph 2:

This is the only remaining (normative) statement that a typedef-name can't be used in an elaborated-type-specifier. The reference to template type-parameter is deleted by the resolution of issue 283.

... If the identifier resolves to a typedef-name or a template type-parameter, the elaborated-type-specifier is ill-formed. [Note: ...

8 [dcl.decl] grammar rule declarator-id:

When I looked carefully into the statement of the rule prohibiting a typedef-name in a constructor declaration, it appeared to me that this grammar rule (inadvertently?) allows something that's always forbidden semantically.

declarator-id:
id-expression
::_opt nested-name-specifier_opt type-name class-name

9.1 [class.name] paragraph 5:

Unlike the prohibitions against appearing in an elaborated-type-specifier or constructor or destructor declarator, each of which was expressed more than once, the prohibition against a typedef-name appearing in a class-head was previously stated only in 7.1.3 [dcl.typedef]. It seems to me that that prohibition belongs here instead. Also, it seems to me important to clarify that a typedef-name that is a class-name is still a typedef-name. Otherwise, the various prohibitions can be argued around easily, if perversely ("But that isn't a typedef-name, it's a class-name; it says so right there in 9.1 [class.name].")

A typedef-name (7.1.3 [dcl.typedef]) that names a class type or a cv-qualified version thereof is also a class-name, but shall not be used in an elaborated-type-specifier; see also 7.1.3 [dcl.typedef]. as the identifier in a class-head.

12.1 [class.ctor] paragraph 3:

The new nonterminal references are needed to really nail down what we're talking about here. Otherwise, I'm just eliminating redundancy. (A typedef-name that doesn't name a class type is no more valid here than one that does.)

A typedef-name that names a class is a class-name (7.1.3 [dcl.typedef]); however, a A typedef-name that names a class shall not be used as the identifier class-name in the declarator declarator-id for a constructor declaration.

12.4 [class.dtor] paragraph 1:

The same comments apply here as to 12.1 [class.ctor].

... A typedef-name that names a class is a class-name (7.1.3); however, a A typedef-name that names a class shall not be used as the identifier class-name following the ~ in the declarator for a destructor declaration.

318. struct A::A should not name the constructor of A

[Voted into WP at April 2003 meeting.]

A use of an injected-class-name in an elaborated-type-specifier should not name the constructor of the class, but rather the class itself, because in that context we know that we're looking for a type. See issue 147.

Proposed Resolution (revised October 2002):

This clarifies the changes made in the TC for issue 147.

In 3.4.3.1 [class.qual] paragraph 1a replace:

If the nested-name-specifier nominates a class C, and the name specified after the nested-name-specifier, when looked up in C, is the injected class name of C (clause 9 [class]), the name is instead considered to name the constructor of class C.

with

In a lookup in which the constructor is an acceptable lookup result, if the nested-name-specifier nominates a class C and the name specified after the nested-name-specifier, when looked up in C, is the injected class name of C (clause 9 [class]), the name is instead considered to name the constructor of class C. [Note: For example, the constructor is not an acceptable lookup result in an elaborated type specifier so the constructor would not be used in place of the injected class name.]

Note that issue 263 updates a part of the same paragraph.

Append to the example:

  struct A::A a2;  // object of type A

400. Using-declarations and the "struct hack"

[Voted into WP at March 2004 meeting.]

Consider this code:

  struct A { int i; struct i {}; };
  struct B { int i; struct i {}; };
  struct D : public A, public B { using A::i; void f (); };
  void D::f () { struct i x; }

I can't find anything in the standard that says definitively what this means. 7.3.3 [namespace.udecl] says that a using-declaration shall name "a member of a base class" -- but here we have two members, the data member A::i and the class A::i.

Personally, I'd find it more attractive if this code did not work. I'd like "using A::i" to mean "lookup A::i in the usual way and bind B::i to that", which would mean that while "i = 3" would be valid in D::f, "struct i x" would not be. However, if there were no A::i data member, then "A::i" would find the struct and the code in D::f would be valid.

John Spicer: I agree with you, but unfortunately the standard committee did not.

I remembered that this was discussed by the committee and that a resolution was adopted that was different than what I hoped for, but I had a hard time finding definitive wording in the standard.

I went back though my records and found the paper that proposed a resolution and the associated committee motion that adopted the proposed resolution The paper is N0905, and "option 1" from that paper was adopted at the Stockholm meeting in July of 1996. The resolution is that "using A::i" brings in everything named i from A.

3.4.3.2 [namespace.qual] paragraph 2 was modified to implement this resolution, but interestingly that only covers the namespace case and not the class case. I think the class case was overlooked when the wording was drafted. A core issue should be opened to make sure the class case is handled properly.

Notes from April 2003 meeting:

This is related to issue 11. 7.3.3 [namespace.udecl] paragraph 10 has an example for namespaces.

Proposed resolution (October 2003):

Add a bullet to the end of 3.4.3.1 [class.qual] paragraph 1:

• the lookup for a name specified in a using-declaration (7.3.3 [namespace.udecl]) also finds class or enumeration names hidden within the same scope (3.3.10 [basic.scope.hiding]).

Change the beginning of 7.3.3 [namespace.udecl] paragraph 4 from

A using-declaration used as a member-declaration shall refer to a member of a base class of the class being defined, shall refer to a member of an anonymous union that is a member of a base class of the class being defined, or shall refer to an enumerator for an enumeration type that is a member of a base class of the class being defined.

to

In a using-declaration used as a member-declaration, the nested-name-specifier shall name a base class of the class being defined. Such a using-declaration introduces the set of declarations found by member name lookup (10.2 [class.member.lookup], 3.4.3.1 [class.qual]).

245. Name lookup in elaborated-type-specifiers

[Voted into WP at April 2003 meeting.]

I have some concerns with the description of name lookup for elaborated type specifiers in 3.4.4 [basic.lookup.elab]:

1. Paragraph 2 has some parodoxical statements concerning looking up names that are simple identifers:

   If the elaborated-type-specifier refers to an enum-name and this lookup does not find a previously declared enum-name, the elaborated-type-specifier is ill-formed. If the elaborated-type-specifier refers to an [sic] class-name and this lookup does not find a previously declared class-name... the elaborated-type-specifier is a declaration that introduces the class-name as described in 3.3.2 [basic.scope.pdecl]."

   It is not clear how an elaborated-type-specifier can refer to an enum-name or class-name given that the lookup does not find such a name and that class-name and enum-name are not part of the syntax of an elaborated-type-specifier.

2. The second sentence quoted above seems to suggest that the name found will not be used if it is not a class name. typedef-name names are ill-formed due to the sentence preceding the quote. If lookup finds, for instance, an enum-name then a new declaration will be created. This differs from C, and from the enum case, and can have surprising effects:

       struct S {
          enum E {
              one = 1
          };
          class E* p;     // declares a global class E?
       };
   

   Was this really the intent? If this is the case then some more work is needed on 3.4.4 [basic.lookup.elab]. Note that the section does not make finding a type template formal ill-formed, as is done in 7.1.6.3 [dcl.type.elab]. I don't see anything that makes a type template formal name a class-name. So the example in 7.1.6.3 [dcl.type.elab] of friend class T; where T is a template type formal would no longer be ill-formed with this interpretation because it would declare a new class T.

(See also issue 254.)

Notes from the 4/02 meeting:

This will be consolidated with the changes for issue 254. See also issue 298.

Proposed resolution (October 2002):

As given in N1376=02-0034. Note that the inserts and strikeouts in that document do not display correctly in all browsers; <del> --> <strike> and <ins> --> <b>, and the similar changes for the closing delimiters, seem to do the trick.

254. Definitional problems with elaborated-type-specifiers

[Voted into WP at April 2003 meeting.]

1. The text in 3.4.4 [basic.lookup.elab] paragraph 2 twice refers to the possibility that an elaborated-type-specifier might have the form

           class-key identifier ;
   

   However, the grammar for elaborated-type-specifier does not include a semicolon.

2. In both 3.4.4 [basic.lookup.elab] and 7.1.6.3 [dcl.type.elab], the text asserts that an elaborated-type-specifier that refers to a typedef-name is ill-formed. However, it is permissible for the form of elaborated-type-specifier that begins with typename to refer to a typedef-name.

   This problem is the result of adding the typename form to the elaborated-type-name grammar without changing the verbiage correspondingly. It could be fixed either by updating the verbiage or by moving the typename syntax into its own production and referring to both nonterminals when needed.

(See also issue 180. If this issue is resolved in favor of a separate nonterminal in the grammar for the typename forms, the wording in that issue's resolution must be changed accordingly.)

Notes from 04/01 meeting:

The consensus was in favor of moving the typename forms out of the elaborated-type-specifier grammar.

Notes from the 4/02 meeting:

This will be consolidated with the changes for issue 245.

Proposed resolution (October 2002):

As given in N1376=02-0034.

141. Non-member function templates in member access expressions

[Voted into the WP at the June, 2008 meeting.]

3.4.5 [basic.lookup.classref] paragraph 1 says,

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 or function template.

There do not seem to be any circumstances in which use of a non-member template function would be well-formed as the id-expression of a class member access expression.

Proposed Resolution (November, 2006):

Change 3.4.5 [basic.lookup.classref] paragraph 1 as follows:

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 or function template...

305. Name lookup in destructor call

[Voted into WP at the October, 2006 meeting.]

I believe this program is invalid:

    struct A {
    };

    struct C {
      struct A {};
      void f ();
    };

    void C::f () {
      ::A *a;
      a->~A ();
    }

The EDG front end does not issue an error about this program, though.

Am I reading the standardese incorrectly?

John Spicer: I think you are reading it correctly. I think I've been hoping that this would get changed. Unlike other dual lookup contexts, this is one in which the compiler already knows the right answer (the type must match that of the left hand of the -> operator). So I think that if either of the types found matches the one required, it should be sufficient. You can't say a->~::A(), which means you are forced to say a->::A::~A(), which disables the virtual mechanism. So you would have to do something like create a local typedef for the desired type.

See also issues 244, 399, and 466.

Proposed resolution (April, 2006):

1. Remove the indicated text from 3.4.5 [basic.lookup.classref] paragraph 2:

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

2. Change 3.4.5 [basic.lookup.classref] paragraph 3 as indicated:

   If the unqualified-id is ~type-name, the type-name is looked up in the context of the entire postfix-expression. and If the type T of the object expression is of a class type C (or of pointer to a class type C), the type-name is also looked up in the context of the entire postfix-expression and in the scope of class C. The type-name shall refer to a class-name. If type-name is found in both contexts, the name shall refer to the same class type. If the type of the object expression is of scalar type, the type-name is looked up in the scope of the complete postfix-expression. At least one of the lookups shall find a name that refers to (possibly cv-qualified) T. [Example:

   
       struct A { };
   
       struct B {
         struct A { };
         void f(::A* a);
       };
   
       void B::f(::A* a) {
         a->~A();  // OK, lookup in *a finds the injected-class-name
       }
   

   —end example]

[Note: this change also resolves issue 414.]

381. Incorrect example of base class member lookup

[Voted into WP at October 2004 meeting.]

The example in 3.4.5 [basic.lookup.classref] paragraph 4 is wrong (see 11.2 [class.access.base] paragraph 5; the cast to the naming class can't be done) and needs to be corrected. This was noted when the final version of the algorithm for issue 39 was checked against it.

Proposed Resolution (October 2003):

Remove the entire note at the end of 3.4.5 [basic.lookup.classref] paragraph 4, including the entire example.

414. Multiple types found on destructor lookup

[Voted into WP at the October, 2006 meeting.]

By 3.4.5 [basic.lookup.classref] paragraph 3, the following is ill-formed because the two lookups of the destructor name (in the scope of the class of the object and in the surrounding context) find different Xs:

  struct X {};
  int main() {
    X x;
    struct X {};
    x.~X();  // Error?
  }

This is silly, because the compiler knows what the type has to be, and one of the things found matches that. The lookup should require only that one of the lookups finds the required class type.

Proposed resolution (April, 2005):

This issue is resolved by the resolution of issue 305.

216. Linkage of nameless class-scope enumeration types

[Moved to DR at 10/01 meeting.]

A name having namespace scope has external linkage if it is the name of

• [...]
• a named enumeration (7.2 [dcl.enum]), or an unnamed enumeration defined in a typedef declaration in which the enumeration has the typedef name for linkage purposes (7.1.3 [dcl.typedef])

    typedef enum { e1 } *PE;
    void f(PE) {}  // Cannot declare a function (with linkage) using a 
		   // type with no linkage.

However, the same prohibition was not made for class scope types. Indeed, 3.5 [basic.link] paragraph 5 says:

In addition, a member function, static data member, class or enumeration of class scope has external linkage if the name of the class has external linkage.

That allows for:

    struct S {
       typedef enum { e1 } *MPE;
       void mf(MPE) {}
    };

My guess is that this is an unintentional consequence of 3.5 [basic.link] paragraph 5, but I would like confirmation on that.

Proposed resolution:

Change text in 3.5 [basic.link] paragraph 5 from:

In addition, a member function, static data member, class or enumeration of class scope has external linkage if the name of the class has external linkage.

In addition, a member function, a static data member, a named class or enumeration of class scope, or an unnamed class or enumeration defined in a class-scope typedef declaration such that the class or enumeration has the typedef name for linkage purposes (7.1.3 [dcl.typedef]), has external linkage if the name of the class has external linkage.

319. Use of names without linkage in declaring entities with linkage

[Voted into WP at October 2004 meeting.]

According to 3.5 [basic.link] paragraph 8, "A name with no linkage ... shall not be used to declare an entity with linkage." This would appear to rule out code such as:

  typedef struct {
    int i;
  } *PT;
  extern "C" void f(PT);

  static enum { a } e;

See issue 132, which dealt with a closely related issue.

Andrei Iltchenko submitted the same issue via comp.std.c++ on 17 Dec 2001:

Paragraph 8 of Section 3.5 [basic.link] contains the following sentences: "A name with no linkage shall not be used to declare an entity with linkage. If a declaration uses a typedef name, it is the linkage of the type name to which the typedef refers that is considered."

The problem with this wording is that it doesn't cover cases where the type to which a typedef-name refers has no name. As a result it's not clear whether, for example, the following program is well-formed:

#include <vector>

int  main()
{
   enum  {   sz = 6u   };
   typedef int  (* aptr_type)[sz];
   typedef struct  data  {
      int   i,  j;
   }  * elem_type;
   std::vector<aptr_type>   vec1;
   std::vector<elem_type>   vec2;
}

Suggested resolution:

My feeling is that the rules for whether or not a typedef-name used in a declaration shall be treated as having or not having linkage ought to be modelled after those for dependent types, which are explained in 14.6.2.1 [temp.dep.type].

Add the following text at the end of Paragraph 8 of Section 3.5 [basic.link] and replace the following example:

In case of the type referred to by a typedef declaration not having a name, the newly declared typedef-name has linkage if and only if its referred type comprises no names of no linkage excluding local names that are eligible for appearance in an integral constant-expression (5.19 [expr.const]). [Note: if the referred type contains a typedef-name that does not denote an unnamed class, the linkage of that name is established by the recursive application of this rule for the purposes of using typedef names in declarations.] [Example:

  void f()
  {
     struct A { int x; };        // no linkage
     extern A a;                 // ill-formed
     typedef A Bl
     extern B b;                 // ill-formed

     enum  {   sz = 6u   };
     typedef int  (* C)[sz];     // C has linkage because sz can
                                 // appear in a constant expression
  }

--end example.]

Additional issue (13 Jan 2002, from Andrei Iltchenko):

Paragraph 2 of Section 14.3.1 [temp.arg.type] is inaccurate and unnecessarily prohibits a few important cases; it says "A local type, a type with no linkage, an unnamed type or a type compounded from any of these types shall not be used as a template-argument for a template-parameter." The inaccuracy stems from the fact that it is not a type but its name that can have a linkage.

For example based on the current wording of 14.3.1 [temp.arg.type], the following example is ill-formed.

  #include <vector>
  struct  data  {
    int   i,  j;
  };
  int  main()
  {
    enum  {   sz = 6u   };
    std::vector<int(*)[sz]>   vec1; // The types 'int(*)[sz]' and 'data*'
    std::vector<data*>        vec2; // have no names and are thus illegal
                                    // as template type arguments.
  }

Suggested resolution:

Replace the whole second paragraph of Section 14.3.1 [temp.arg.type] with the following wording:

A type whose name does not have a linkage or a type compounded from any such type shall not be used as a template-argument for a template-parameter. In case of a type T used as a template type argument not having a name, T constitutes a valid template type argument if and only if the name of an invented typedef declaration referring to T would have linkage; see 3.5. [Example:

  template <class T> class X { /* ... */ };
  void f()
  {
    struct S { /* ... */ };
    enum  {   sz = 6u   };

    X<S> x3;                     // error: a type name with no linkage
                                 // used as template-argument
    X<S*> x4;                    // error: pointer to a type name with
                                 // no linkage used as template-argument
    X<int(*)[sz]> x5;            // OK: since the name of typedef int
                                 // (*pname)[sz] would have linkage
  }

--end example] [Note: a template type argument may be an incomplete type (3.9 [basic.types]).]

Proposed resolution:

This is resolved by the changes for issue 389. The present issue was moved back to Review status in February 2004 because 389 was moved back to Review.

389. Unnamed types in entities with linkage

[Voted into WP at October 2004 meeting.]

3.5 [basic.link] paragraph 8 says (among other things):

A name with no linkage (notably, the name of a class or enumeration declared in a local scope (3.3.3 [basic.scope.block])) shall not be used to declare an entity with linkage. If a declaration uses a typedef name, it is the linkage of the type name to which the typedef refers that is considered.

I would expect this to catch situations such as the following:

  // File 1:
  typedef struct {} *UP;
  void f(UP) {}

  // File 2:
  typedef struct {} *UP; // Or: typedef struct {} U, *UP;
  void f(UP);

The problem here is that most implementations must generate the same mangled name for "f" in two translation units. The quote from the standard above isn't quite clear, unfortunately: There is no type name to which the typedef refers.

A related situation is the following:

  enum { no, yes } answer;

Finally, these problems are much less relevant when declaring names with internal linkage. For example, I would expect there to be few problems with:

  typedef struct {} *UP;
  static void g(UP);

I recently tried to interpret 3.5 [basic.link] paragraph 8 with the assumption that types with no names have no linkage. Surprisingly, this resulted in many diagnostics on variable declarations (mostly like "answer" above).

I'm pretty sure the standard needs clarifying words in this matter, but which way should it go?

See also issue 319.

Notes from April 2003 meeting:

There was agreement that this check is not needed for variables and functions with extern "C" linkage, and a change there is desirable to allow use of legacy C headers. The check is also not needed for entities with internal linkage, but there was no strong sentiment for changing that case.

We also considered relaxing this requirement for extern "C++" variables but decided that we did not want to change that case.

We noted that if extern "C" functions are allowed an additional check is needed when such functions are used as arguments in calls of function templates. Deduction will put the type of the extern "C" function into the type of the template instance, i.e., there would be a need to mangle the name of an unnamed type. To plug that hole we need an additional requirement on the template created in such a case.

Proposed resolution (April 2003, revised slightly October 2003 and March 2004):

In 3.5 [basic.link] paragraph 8, change

A name with no linkage (notably, the name of a class or enumeration declared in a local scope (3.3.3 [basic.scope.block])) shall not be used to declare an entity with linkage. If a declaration uses a typedef name, it is the linkage of the type name to which the typedef refers that is considered.

to

A type is said to have linkage if and only if

• it is a class or enumeration type that is named (or has a name for linkage purposes (7.1.3 [dcl.typedef])) and the name has linkage; or
• it is a specialization of a class template (14 [temp]) [Footnote: a class template always has external linkage, and the requirements of 14.3.1 [temp.arg.type] and 14.3.2 [temp.arg.nontype] ensure that the template arguments will also have appropriate linkage]; or
• it is a fundamental type (3.9.1 [basic.fundamental]); or
• it is a compound type (3.9.2 [basic.compound]) other than a class or enumeration, compounded exclusively from types that have linkage; or
• it is a cv-qualified (3.9.3 [basic.type.qualifier]) version of a type that has linkage.

A type without linkage shall not be used as the type of a variable or function with linkage, unless the variable or function has extern "C" linkage (7.5 [dcl.link]). [Note: in other words, a type without linkage contains a class or enumeration that cannot be named outside of its translation unit. An entity with external linkage declared using such a type could not correspond to any other entity in another translation unit of the program and is thus not permitted. Also note that classes with linkage may contain members whose types do not have linkage, and that typedef names are ignored in the determination of whether a type has linkage.]

Change 14.3.1 [temp.arg.type] paragraph 2 from (note: this is the wording as updated by issue 62)

The following types shall not be used as a template-argument for a template type-parameter:

• a type whose name has no linkage
• an unnamed class or enumeration type that has no name for linkage purposes (7.1.3 [dcl.typedef])
• a cv-qualified version of one of the types in this list
• a type created by application of declarator operators to one of the types in this list
• a function type that uses one of the types in this list

to

A type without linkage (3.5 [basic.link]) shall not be used as a template-argument for a template type-parameter.

Once this issue is ready, issue 319 should be moved back to ready as well.

474. Block-scope extern declarations in namespace members

[Voted into WP at October 2005 meeting.]

Consider the following bit of code:

    namespace N {
      struct S {
        void f();
      };
    }
    using namespace N;
    void S::f() {
      extern void g();  // ::g or N::g?
    }

In 3.5 [basic.link] paragraph 7 the Standard says (among other things),

When a block scope declaration of an entity with linkage is not found to refer to some other declaration, then that entity is a member of the innermost enclosing namespace.

The question then is whether N is an “enclosing namespace” for the local declaration of g()?

Proposed resolution (October 2004):

Add the following text as a new paragraph at the end of 7.3.1 [namespace.def]:

The enclosing namespaces of a declaration are those namespaces in which the declaration lexically appears, except for a redeclaration of a namespace member outside its original namespace (e.g., a definition as specified in 7.3.1.2 [namespace.memdef]). Such a redeclaration has the same enclosing namespaces as the original declaration. [Example:

  namespace Q {
    namespace V {
      void f(); // enclosing namespaces are the global namespace, Q, and Q::V
      class C { void m(); };
    }
    void V::f() { // enclosing namespaces are the global namespace, Q, and Q::V
      extern void h(); // ... so this declares Q::V::h
    }
    void V::C::m() { // enclosing namespaces are the global namespace, Q, and Q::V
    }
  }

—end example]

270. Order of initialization of static data members of class templates

[Moved to DR at 4/02 meeting.]

The Standard does not appear to address how the rules for order of initialization apply to static data members of class templates.

Suggested resolution: Add the following verbiage to either 3.6.2 [basic.start.init] or 9.4.2 [class.static.data]:

Initialization of static data members of class templates shall be performed during the initialization of static data members for the first translation unit to have static initialization performed for which the template member has been instantiated. This requirement shall apply to both the static and dynamic phases of initialization.

Notes from 04/01 meeting:

Enforcing an order of initialization on static data members of class templates will result in substantial overhead on access to such variables. The problem is that the initialization be required as the result of instantiation in a function used in the initialization of a variable in another translation unit. In current systems, the order of initialization of static data data members of class templates is not predictable. The proposed resolution is to state that the order of initialization is undefined.

Proposed resolution (04/01, updated slightly 10/01):

Replace the following sentence in 3.6.2 [basic.start.init] paragraph 1:

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

with

Dynamic initialization of an object is either ordered or unordered. Explicit specializations and definitions of class template static data members have ordered initialization. Other class template static data member instances have unordered initialization. Other objects defined in namespace scope have ordered initialization. Objects defined within a single translation unit and with ordered initialization shall be initialized in the order of their definitions in the translation unit. The order of initialization is unspecified for objects with unordered initialization and for objects defined in different translation units.

Note that this wording is further updated by issue 362.

Note (07/01):

Brian McNamara argues against the proposed resolution. The following excerpt captures the central point of a long message on comp.std.c++:

I have a class for representing linked lists which looks something like

    template <class T>
    class List {
       ...  static List<T>* sentinel; ...
    };
 
    template <class T>
    List<T>* List<T>::sentinel( new List<T> ); // static member definition

The sentinel list node is used to represent "nil" (the null pointer cannot be used with my implementation, for reasons which are immaterial to this discussion). All of the List's non-static member functions and constructors depend upon the value of the sentinel. Under the proposed resolution for issue #270, Lists cannot be safely instantiated before main() begins, as the sentinel's initialization is "unordered".

(Some readers may propose that I should use the "singleton pattern" in the List class. This is undesirable, for reasons I shall describe at the end of this post at the location marked "[*]". For the moment, indulge me by assuming that "singleton" is not an adequate solution.)

Though this is a particular example from my own experience, I believe it is representative of a general class of examples. It is common to use static data members of a class to represent the "distinguished values" which are important to instances of that class. It is imperative that these values be initialized before any instances of the class are created, as the instances depend on the values.

In a comp.std.c++ posting on 28 Jul 2001, Brian McNamara proposes the following alternative resolution:

Replace the following sentence in 3.6.2 [basic.start.init] paragraph 1:

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

Objects with static storage duration defined in namespace scope shall be initialized in the order described below.

Dynamic initialization is either ordered or quasi-ordered. Explicit specializations of class template static data members have ordered initialization. Other class template static data member instances have quasi-ordered initialization. All other objects defined in namespace scope have ordered initialization. The order of initialization is specified as follows:

• Objects that are defined within a single translation unit and that have ordered initialization shall be initialized in the order of their definitions in the translation unit.
• Objects that are defined only within a single translation unit and that have quasi-ordered initialization shall also be initialized in the order of their definitions in the translation unit -- that is, as though these objects had ordered initialization.
• Objects that are defined within multiple translation units (which, therefore, must have quasi-ordered initialization) shall be initialized as follows: in exactly one translation unit (which one is unspecified), the object shall be treated as though it has ordered initialization; in the other translation units which define the object, the object will be initialized before all other objects that have ordered initialization in those translation units.
• For any two objects, "X" and "Y", with static storage duration and defined in namespace scope, if the previous bullets do not imply a relationship for the initialization ordering between "X" and "Y", then the relative initialization order of these objects is unspecified.

[ Note: The intention is that translation units can each be compiled separately with no knowledge of what objects may be re-defined in other translation units. Each translation unit can contain a method which initializes all objects (both quasi-ordered and ordered) as though they were ordered. When these translation units are linked together to create an executable program, all of these objects can be initialized by simply calling the initialization methods (one from each translation unit) in any order. Quasi-ordered objects require some kind of guard to ensure that they are not initialized more than once (the first attempt to initialize such an object should succeed; any subsequent attempts should simply be ignored). ]

Erwin Unruh replies: There is a point which is not mentioned with this posting. It is the cost for implementing the scheme. It requires that each static template variable is instantiated in ALL translation units where it is used. There has to be a flag for each of these variables and this flag has to be checked in each TU where the instantiation took place.

I would reject this idea and stand with the proposed resolution of issue 270.

There just is no portable way to ensure the "right" ordering of construction.

Notes from 10/01 meeting:

The Core Working Group reaffirmed its previous decision.

441. Ordering of static reference initialization

[Voted into WP at April 2005 meeting.]

I have a couple of questions about 3.6.2 [basic.start.init], "Initialization of non-local objects." I believe I recall some discussion of related topics, but I can't find anything relevant in the issues list.

The first question arose when I discovered that different implementations treat reference initialization differently. Consider, for example, the following (namespace-scope) code:

  int i;
  int& ir = i;
  int* ip = &i;

Zero-initialization and initialization with a constant expression are collectively called static initialization; all other initialization is dynamic initialization.

However, that does not mean that both ir and ip must be initialized at the same time:

Objects of POD types (3.9) with static storage duration initialized with constant expressions (5.19) shall be initialized before any dynamic initialization takes place.

Because "int&" is not a POD type, there is no requirement that it be initialized before dynamic initialization is performed, and implementations differ in this regard. Using a function called during dynamic initialization to print the values of "ip" and "&ir", I found that g++, Sun, HP, and Intel compilers initialize ir before dynamic initialization and the Microsoft compiler does not. All initialize ip before dynamic initialization. I believe this is conforming (albeit inconvenient :-) behavior.

So, my first question is whether it is intentional that a reference of static duration, initialized with a reference constant expression, need not be initialized before dynamic initialization takes place, and if so, why?

The second question is somewhat broader. As 3.6.2 [basic.start.init] is currently worded, it appears that there are no requirements on when ir is initialized. In fact, there is a whole category of objects -- non-POD objects initialized with a constant expression -- for which no ordering is specified. Because they are categorized as part of "static initialization," they are not subject to the requirement that they "shall be initialized in the order in which their definition appears in the translation unit." Because they are not POD types, they are not required to be initialized before dynamic initialization occurs. Am I reading this right?

My preference would be to change 3.6.2 [basic.start.init] paragraph 1 so that 1) references are treated like POD objects with respect to initialization, and 2) "static initialization" applies only to POD objects and references. Here's some sample wording to illustrate:

Suggested resolution:

Objects with static storage duration (3.7.1) shall be zero-initialized (8.5) before any other initialization takes place. Initializing a reference, or an object of POD type, of static storage duration with a constant expression (5.19) is called constant initialization. Together, zero-initialization and constant initialization are called static initialization; all other initialization is dynamic initialization. Static initialization shall be performed before any dynamic initialization takes place. [Remainder unchanged.]

Proposed Resolution:

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

Objects with static storage duration (3.7.1) shall be zero-initialized (8.5) before any other initialization takes place. Initializing a reference, or an object of POD type, of static storage duration with a constant expression (5.19) is called constant initialization. Together, zero-initialization and constant initialization are Zero-initialization and initialization with a constant expression are collectively called static initialization; all other initialization is dynamic initialization. Static initialization shall be performed Objects of POD types (3.9) with static storage duration initialized with constant expressions (5.19) shall be initialized before any dynamic initialization takes place.

688. Constexpr constructors and static initialization

[Voted into the WP at the September, 2008 meeting (resolution in paper N2757).]

Given this literal type,

    struct X {
        constexpr X() { }
    };

and this definition,

    static X x;

the current specification does not require that x be statically initialized because it is not “initialized with a constant expression” (3.6.1 [basic.start.main] paragraph 1).

Lawrence Crowl:

This guarantee is essential for atomics.

Jens Maurer:

Suggestion:

A reference with static storage duration or an object of literal type with static storage duration can be initialized with a constant expression (5.19 [expr.const]) or with a constexpr constructor; this is called constant initialization.

(Not spelling out “default constructor” makes it easier to handle multiple-parameter constexpr constructors, where there isn't “a” constant expression but several.)

Peter Dimov:

In addition, there is a need to enforce static initialization for non-literal types: std::shared_ptr, std::once_flag, and std::atomic_* all have nontrivial copy constructors, making them non-literal types. However, we need a way to ensure that a constexpr constructor called with constant expressions will guarantee static initialization, regardless of the nontriviality of the copy constructor.

Proposed resolution (April, 2008):

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

...A reference with static storage duration and an object of trivial or literal type with static storage duration can be initialized with a constant expression (5.19 [expr.const]); this If a reference with static storage duration is initialized with a constant expression (5.19 [expr.const]) or if the initialization of an object with static storage duration satisfies the requirements for the object being declared with constexpr (7.1.5 [dcl.constexpr]), that initialization is called constant initialization...

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

...A local object of trivial or literal type (3.9 [basic.types]) with static storage duration initialized with constant-expressions is initialized Constant initialization (3.6.2 [basic.start.init]) of a local entity with static storage duration is performed before its block is first entered...

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

A constexpr specifier used in an object declaration declares the object as const. Such an object shall be initialized, and every expression that appears in its initializer (8.5 [dcl.init]) shall be a constant expression. Every implicit conversion used in converting the initializer expressions and every constructor call used for the initialization shall be one of those allowed in a constant expression (5.19 [expr.const])...

4. Replace 8.5.1 [dcl.init.aggr] paragraph 14 as follows:

When an aggregate with static storage duration is initialized with a brace-enclosed initializer-list, if all the member initializer expressions are constant expressions, and the aggregate is a trivial type, the initialization shall be done during the static phase of initialization (3.6.2 [basic.start.init]); otherwise, it is unspecified whether the initialization of members with constant expressions takes place during the static phase or during the dynamic phase of initialization. [Note: The order of initialization for aggregates with static storage duration is specified in 3.6.2 [basic.start.init] and 6.7 [stmt.dcl]. —end note]

(Note: the change to 3.6.2 [basic.start.init] paragraph 1 needs to be reconciled with the conflicting change in issue 684.)

28. 'exit', 'signal' and static object destruction

[Voted into the WP at the June, 2008 meeting.]

The C++ standard has inherited the definition of the 'exit' function more or less unchanged from ISO C.

However, when the 'exit' function is called, objects of static extent which have been initialised, will be destructed if their types posses a destructor.

In addition, the C++ standard has inherited the definition of the 'signal' function and its handlers from ISO C, also pretty much unchanged.

The C standard says that the only standard library functions that may be called while a signal handler is executing, are the functions 'abort', 'signal' and 'exit'.

This introduces a bit of a nasty turn, as it is not at all unusual for the destruction of static objects to have fairly complex destruction semantics, often associated with resource release. These quite commonly involve apparently simple actions such as calling 'fclose' for a FILE handle.

Having observed some very strange behaviour in a program recently which in handling a SIGTERM signal, called the 'exit' function as indicated by the C standard.

But unknown to the programmer, a library static object performed some complicated resource deallocation activities, and the program crashed.

The C++ standard says nothing about the interaction between signals, exit and static objects. My observations, was that in effect, because the destructor called a standard library function other than 'abort', 'exit' or 'signal', while transitively in the execution context of the signal handler, it was in fact non-compliant, and the behaviour was undefined anyway.

This is I believe a plausible judgement, but given the prevalence of this common programming technique, it seems to me that we need to say something a lot more positive about this interaction.

Curiously enough, the C standard fails to say anything about the analogous interaction with functions registered with 'atexit' ;-)

Proposed Resolution (10/98):

The current Committee Draft of the next version of the ISO C standard specifies that the only standard library function that may be called while a signal handler is executing is 'abort'. This would solve the above problem.

[This issue should remain open until it has been decided that the next version of the C++ standard will use the next version of the C standard as the basis for the behavior of 'signal'.]

Notes (November, 2006):

C89 is slightly contradictory here: It allows any signal handler to terminate by calling abort, exit, longjmp, but (for asynchronous signals, i.e. not those produced by abort or raise) then makes calling any library function other than signal with the current signal undefined behavior (C89 7.7.1.1). For synchronous signals, C99 forbids calls to raise, but imposes no other restrictions. For asynchronous signals, C99 allows only calls to abort, _Exit, and signal with the current signal (C99 7.14.1.1). The current C++ WP refers to “plain old functions” and “conforming C programs” (18.10 [support.runtime] paragraph 6).

Proposed Resolution (November, 2006):

Change the footnote in 18.10 [support.runtime] paragraph 6 as follows:

In particular, a signal handler using exception handling is very likely to have problems. Also, invoking std::exit may cause destruction of objects, including those of the standard library implementation, which, in general, yields undefined behavior in a signal handler (see 1.9 [intro.execution]).

521. Requirements for exceptions thrown by allocation functions

[Voted into WP at the October, 2006 meeting.]

According to 3.7.4.1 [basic.stc.dynamic.allocation] paragraph 3,

Any other allocation function that fails to allocate storage shall only indicate failure by throwing an exception of class std::bad_alloc (18.6.2.1 [bad.alloc]) or a class derived from std::bad_alloc.

Shouldn't this statement have the usual requirements for an unambiguous and accessible base class?

Proposed resolution (April, 2006):

Change the last sentence of 3.7.4.1 [basic.stc.dynamic.allocation] paragraph 3 as indicated:

Any other allocation function that fails to allocate storage shall only indicate failure only by throwing an exception of class std::bad_alloc (18.6.2.1 [bad.alloc]) or a class derived from std::bad_alloc a type that would match a handler (15.3 [except.handle]) of type std::bad_alloc (18.6.2.1 [bad.alloc]).

220. All deallocation functions should be required not to throw

[Voted into the WP at the September, 2008 meeting (resolution in paper N2757).]

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

The default global operators delete are specified to not throw, but there is no requirement that replacement global, or class-specific, operators delete must not throw. That ought to be required.

In particular:

• 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2, at the end of the first sentence, should also require that no exceptions be thrown.
• 12.5 [class.free], including its examples, should require nonthrowing class-specific operator delete.
• 17.6.4.6 [replacement.functions] paragraph 2 should append throw() to the signature of each of the four operators delete.

We already require that all versions of an allocator's deallocate() must not throw, so that part is okay.

Rationale (04/00):

1. Replacement deallocation functions are already required not to throw an exception (cf 17.6.4.8 [res.on.functions] paragraph 2, as applied to 18.6.1.1 [new.delete.single] paragraph 12 and 18.6.1.2 [new.delete.array] paragraph 11).
2. Section 17.6.4.6 [replacement.functions] is describing the signatures of the functions to be replaced; exception specfications are not part of the signature.
3. There does not appear to be any pressing need to require that class member deallocation functions not throw.

Note (March, 2008):

The Evolution Working Group has accepted the intent of this issue and referred it to CWG for action for C++0x (see paper J16/07-0033 = WG21 N2173).

Proposed resolution (March, 2008):

Change 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 3 as follows:

A deallocation function shall not terminate by throwing an exception. The value of the first argument supplied to a deallocation function...

348. delete and user-written deallocation functions

[Voted into WP at October 2005 meeting.]

Standard is clear on behaviour of default allocation/deallocation functions. However, it is surpisingly vague on requirements to the behaviour of user-defined deallocation function and an interaction between delete-expression and deallocation function. This caused a heated argument on fido7.su.c-cpp newsgroup.

Resume:

It is not clear if user-supplied deallocation function is called from delete-expr when the operand of delete-expr is the null pointer (5.3.5 [expr.delete]). If it is, standard does not specify what user-supplied deallocation function shall do with the null pointer operand (18.6.1 [new.delete]). Instead, Standard uses the term "has no effect", which meaning is too vague in context given (5.3.5 [expr.delete]).

Description:

Consider statements

   char* p= 0; //result of failed non-throwing ::new char[]
   ::delete[] p;

Standard does NOT specify whether user-defined deallocation function should be called in this case, or not.

Specifically, standard says in 5.3.5 [expr.delete] paragraph 2:

...if the value of the operand of delete is the null pointer the operation has no effect.

Furthermore, in para 4 standard says on default deallocation function:

If the delete-expression calls the implementation deallocation function (3.7.4.2 [basic.stc.dynamic.deallocation]), if the operand of the delete expression is not the null pointer constant, ...

If "has no effect" is a requirement to the deallocation function, then it should be stated in 3.7.4.2 [basic.stc.dynamic.deallocation], or in 18.6.1.1 [new.delete.single] and 18.6.1.2 [new.delete.array], and it should be stated explicitly.

Furthermore, standard does NOT specify what actions shall be performed by user-supplied deallocation function if NULL is given (18.6.1.1 [new.delete.single] paragraph 12):

Required behaviour: accept a value of ptr that is null or that was returned by an earlier call to the default operator new(std::size_t) or operator new(std::size_t, const std::nothrow_t&).

The same corresponds to ::delete[] case.

Expected solution:

1. Make it clear that delete-expr will not call deallocation function if null pointer is given (in 5.3.5 [expr.delete]).
2. Specify what user deallocation function shall do when null is given (either in 3.7.4.2 [basic.stc.dynamic.deallocation], or in 18.6.1.1 [new.delete.single], and 18.6.1.2 [new.delete.array]).

Notes from October 2002 meeting:

We believe that study of 18.6.1.1 [new.delete.single] paragraphs 12 and 13, 18.6.1.2 [new.delete.array] paragraphs 11 and 12, and 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 3 shows that the system-provided operator delete functions must accept a null pointer and ignore it. Those sections also show that a user-written replacement for the system-provided operator delete functions must accept a null pointer. There is no requirement that such functions ignore a null pointer, which is okay -- perhaps the reason for replacing the system-provided functions is to do something special with null pointer values (e.g., log such calls and return).

We believe that the standard should not require an implementation to call a delete function with a null pointer, but it must allow that. For the system-provided delete functions or replacements thereof, the standard already makes it clear that the delete function must accept a null pointer. For class-specific delete functions, we believe the standard should require that such functions accept a null pointer, though it should not mandate what they do with null pointers.

5.3.5 [expr.delete] needs to be updated to say that it is unspecified whether or not the operator delete function is called with a null pointer, and 3.7.4.2 [basic.stc.dynamic.deallocation] needs to be updated to say that any deallocation function must accept a null pointer.

Proposed resolution (October, 2004):

1. Change 5.3.5 [expr.delete] paragraph 2 as indicated:

   If the operand has a class type, the operand is converted to a pointer type by calling the above-mentioned conversion function, and the converted operand is used in place of the original operand for the remainder of this section. In either alternative, if the value of the operand of delete is the null pointer the operation has no effect may be a null pointer value. If it is not a null pointer value, in 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 sub-object (1.8 [intro.object]) representing a base class of such an object (clause 10 [class.derived])...

2. Change 5.3.5 [expr.delete] paragraph 4 as follows (note that the old wording reflects the changes proposed by issue 442:

   The cast-expression in a delete-expression shall be evaluated exactly once. If the delete-expression calls the implementation deallocation function (3.7.4.2 [basic.stc.dynamic.deallocation]), and if the value of the operand of the delete expression is not a null pointer, the deallocation function will deallocate the storage referenced by the pointer thus rendering the pointer invalid. [Note: the value of a pointer that refers to deallocated storage is indeterminate. —end note]

3. Change 5.3.5 [expr.delete] paragraphs 6-7 as follows:

   The If the value of the operand of the delete-expression is not a null pointer value, the delete-expression will invoke the destructor (if any) for the object or the elements of the array being deleted. In the case of an array, the elements will be destroyed in order of decreasing address (that is, in reverse order of the completion of their constructor; see 12.6.2 [class.base.init]).

   The If the value of the operand of the delete-expression is not a null pointer value, the delete-expression will call a deallocation function (3.7.4.2 [basic.stc.dynamic.deallocation]). Otherwise, it is unspecified whether the deallocation function will be called. [Note: The deallocation function is called regardless of whether the destructor for the object or some element of the array throws an exception. —end note]

4. Change 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 3 as indicated:

   The value of the first argument supplied to one of the a deallocation functions provided in the standard library may be a null pointer value; if so, and if the deallocation function is one supplied in the standard library, the call to the deallocation function has no effect. Otherwise, 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.

[Note: this resolution also resolves issue 442.]

119. Object lifetime and aggregate initialization

[Moved to DR at 4/02 meeting.]

Jack Rouse: 3.8 [basic.life] paragraph 1 includes:

The lifetime of an object is a runtime property of the object. The lifetime of an object of type T begins when:

• storage with the proper alignment and size for type T is obtained, and
• if T is a class type with a non-trivial constructor (12.1 [class.ctor] ), the constructor call has completed.

    struct B {
        B( int = 0 );
        ~B();
    };

    struct S {
        B b1;
    };

    int main()
    {
        S s = { 1 };
        return 0;
    }

Mike Miller: I see a couple of ways of fixing the problem. One way would be to change "the constructor call has completed" to "the object's initialization is complete."

Another would be to add following "a class type with a non-trivial constructor" the phrase "that is not initialized with the brace notation (8.5.1 [dcl.init.aggr] )."

The first formulation treats aggregate initialization like a constructor call; even POD-type members of an aggregate could not be accessed before the aggregate initialization completed. The second is less restrictive; the POD-type members of the aggregate would be usable before the initialization, and the members with non-trivial constructors (the only way an aggregate can acquire a non-trivial constructor) would be protected by recursive application of the lifetime rule.

Proposed resolution (04/01):

In 3.8 [basic.life] paragraph 1, change

If T is a class type with a non-trivial constructor (12.1 [class.ctor]), the constructor call has completed.

to

If T is a class type with a non-trivial constructor (12.1 [class.ctor]), the initialization is complete. [Note: the initialization can be performed by a constructor call or, in the case of an aggregate with an implicitly-declared non-trivial default constructor, an aggregate initialization (8.5.1 [dcl.init.aggr]).]

274. Cv-qualification and char-alias access to out-of-lifetime objects

[Voted into WP at April 2003 meeting.]

The wording in 3.8 [basic.life] paragraph 6 allows an lvalue designating an out-of-lifetime object to be used as the operand of a static_cast only if the conversion is ultimately to "char&" or "unsigned char&". This description excludes the possibility of using a cv-qualified version of these types for no apparent reason.

Notes on 04/01 meeting:

The wording should be changed to allow cv-qualified char types.

Proposed resolution (04/01):

In 3.8 [basic.life] paragraph 6 change the third bullet:

• the lvalue is used as the operand of a static_cast (5.2.9 [expr.static.cast]) (except when the conversion is ultimately to char& or unsigned char&), or

• the lvalue is used as the operand of a static_cast (5.2.9 [expr.static.cast]) except when the conversion is ultimately to cv char& or cv unsigned char&, or

404. Unclear reference to construction with non-trivial constructor

[Voted into WP at March 2004 meeting.]

3.8 [basic.life] paragraph 1 second bullet says:

if T is a class type with a non-trivial constructor (12.1), the constructor call has completed.

This is confusing; what was intended is probably something like

if T is a class type and the constructor invoked to create the object is non-trivial (12.1), the constructor call has completed.

Proposed Resolution (October 2003):

As given above.

594. Coordinating issues 119 and 404 with delegating constructors

[Voted into the WP at the September, 2008 meeting.]

In ISO/IEC 14882:2003, the second bullet of 3.8 [basic.life] paragraph 1 reads,

if T is a class type with a non-trivial constructor (12.1 [class.ctor]), the constructor call has completed.

Issue 119 pointed out that aggregate initialization can be used with some classes with a non-trivial implicitly-declared default constructor, and that in such cases there is no call to the object's constructor. The resolution for that issue was to change the previously-cited wording to read,

If T is a class type with a non-trivial constructor (12.1 [class.ctor], the initialization is complete.

Later (but before the WP was revised with the wording from the resolution of issue 119), issue 404 changed the 2003 wording to read,

If T is a class type and the constructor invoked to create the object is non-trivial (12.1 [class.ctor]), the constructor call has completed.

thus reversing the effect of issue 119, whose whole purpose was to cover objects with non-trivial constructors that are not invoked.

Through an editorial error, the post-Redmond draft (N1905) still contained the original 2003 wording that should have been replaced by the resolution of issue 119, in addition to the new wording from the resolution:

if T is a class type and the constructor invoked to create the object is non-trivial (12.1 [class.ctor]), the constructor call has completed. the initialization is complete.

Finally, during the application of the edits for delegating constructors (N1986), this editing error was “fixed” by retaining the original 2003 wording (which was needed for the application of the change specified in N1986), so that the current draft (N2009) reads,

if T is a class type and the constructor invoked to create the object is non-trivial (12.1 [class.ctor]), the principal constructor call 12.6.2 [class.base.init]) has completed.

Because the completion of the call to the principal constructor corresponds to the point at which the object is “fully constructed” (15.2 [except.ctor] paragraph 2), i.e., its initialization is complete, I believe that the exact wording of the issue 119 resolution would be correct and should be restored verbatim.

Proposed resolution (June, 2008):

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

The lifetime of an object is a runtime property of the object. An object is said to have non-trivial initialization if it is of a class or aggregate type and it or one of its members is initialized by a constructor other than a trivial default constructor. [Note: Initialization by a trivial copy constructor is non-trivial initialization. —end note] The lifetime of an object of type T begins when:

• storage with the proper alignment and size for type T is obtained, and

• if T is a class type and the constructor invoked to create the object is non-trivial (12.1 [class.ctor]), the principal constructor call (12.6.2 [class.base.init]) has completed. [Note: the initialization can be performed by a constructor call or, in the case of an aggregate with an implicitly-declared non-trivial default constructor, an aggregate initialization 8.5.1 [dcl.init.aggr]. —end note] the object has non-trivial initialization, its initialization is complete.

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

644. Should a trivial class type be a literal type?

[Voted into the WP at the June, 2008 meeting.]

The original proposed wording for 3.9 [basic.types] paragraph 11 required a constexpr constructor for a literal class only “if the class has at least one user-declared constructor.” This wording was dropped during the review by CWG out of a desire to ensure that literal types not have any uninitialized members. Thus, a class like

    struct pixel {
        int x, y;
    };

is not a literal type. However, if an object of that type is aggregate-initialized or value-initialized, there can be no uninitialized members; the missing wording should be restored in order to permit use of expressions like pixel().x as constant expressions.

Proposed resolution (February, 2008):

Change 3.9 [basic.types] paragraph 10 as follows:

A type is a literal type if it is:

• a scalar type; or
• a class type (clause 9 [class]) with
• a trivial copy constructor,
• a trivial destructor,
• a trivial default constructor or at least one constexpr constructor other than the copy constructor,
• no virtual base classes, and
• all non-static data members and base classes of literal types; or
• an array of literal type.

158. Aliasing and qualification conversions

[Moved to DR at 4/02 meeting.]

3.10 [basic.lval] paragraph 15 lists the types via which an lvalue can be used to access the stored value of an object; using an lvalue type that is not listed results in undefined behavior. It is permitted to add cv-qualification to the actual type of the object in this access, but only at the top level of the type ("a cv-qualified version of the dynamic type of the object").

However, 4.4 [conv.qual] paragraph 4 permits a "conversion [to] add cv-qualifiers at levels other than the first in multi-level pointers." The combination of these two rules allows creation of pointers that cannot be dereferenced without causing undefined behavior. For instance:

    int* jp;
    const int * const * p1 = &jp;
    *p1;    // undefined behavior!

The reason that *p1 results in undefined behavior is that the type of the lvalue is const int * const", which is not "a cv-qualified version of" int*.

Since the conversion is permitted, we must give it defined semantics, hence we need to fix the wording in 3.10 [basic.lval] to include all possible conversions of the type via 4.4 [conv.qual].

Proposed resolution (04/01):

Add a new bullet to 3.10 [basic.lval] paragraph 15, following "a cv-qualified version of the dynamic type of the object:"

• A type similar (as defined in 4.4 [conv.qual]) to the dynamic type of the object,

649. Optionally ill-formed extended alignment requests

[Voted into the WP at the September, 2008 meeting.]

The requirements on an implementation when presented with an alignment-specifier not supported by that implementation in that context are contradictory: 3.11 [basic.align] paragraph 9 says,

If a request for a specific extended alignment in a specific context is not supported by an implementation, the implementation may reject the request as ill-formed. The implementation may also silently ignore the requested alignment.

In contrast, 7.6.2 [dcl.align] paragraph 2, bullet 4 says simply,

• if the constant expression evaluates to an extended alignment and the implementation does not support that alignment in the context of the declaration, the program is ill-formed

with no provision to “silently ignore” the requested alignment. These two passages need to be reconciled.

If the outcome of the reconciliation is to grant implementations the license to accept and ignore extended alignment requests, the specification should be framed in terms of mechanisms that already exist in the Standard, such as undefined behavior and/or conditionally-supported constructs; “ill-formed” is a category that is defined by the Standard, not something that an implementation can decide.

Notes from the February, 2008 meeting:

The consensus was that such requests should be ill-formed and require a diagnostic. However, it was also observed that an implementation need not reject an ill-formed program; the only requirement is that it issue a diagnostic. It would thus be permissible for an implementation to “noisily ignore” (as opposed to “silently ignoring”) an unsupported alignment request.

Proposed resolution (June, 2008):

Change 3.11 [basic.align] paragraph 9 as follows:

If a request for a specific extended alignment in a specific context is not supported by an implementation, the implementation may reject the request as program is ill-formed. The implementation may also silently ignore the requested alignment. [Note: aAdditionally, a request for runtime allocation of dynamic memory storage for which the requested alignment cannot be honored may shall be treated as an allocation failure. —end note]

519. Null pointer preservation in void* conversions

[Voted into WP at April, 2006 meeting.]

The C standard says in 6.3.2.3, paragraph 4:

Conversion of a null pointer to another pointer type yields a null pointer of that type. Any two null pointers shall compare equal.

C++ appears to be incompatible with the first sentence in only two areas:

    A *a = 0;
    void *v = a;

C++ (4.10 [conv.ptr] paragraph 2) says nothing about the value of v.

    void *v = 0;
    A *b = (A*)v; // aka static_cast<A*>(v)

C++ (5.2.9 [expr.static.cast] paragraph 10) says nothing about the value of b.

Suggested changes:

1. Add the following sentence to 4.10 [conv.ptr] paragraph 2:

The null pointer value is converted to the null pointer value of the destination type.

2. Add the following sentence to 5.2.9 [expr.static.cast] paragraph 10:

The null pointer value (4.10 [conv.ptr]) is converted to the null pointer value of the destination type.

Proposed resolution (October, 2005):

1. Add the indicated words to 4.10 [conv.ptr] paragraph 2:

An rvalue of type “pointer to cv T,” where T is an object type, can be converted to an rvalue of type “pointer to cv void”. The result of converting a “pointer to cv T” to a “pointer to cv void” points to the start of the storage location where the object of type T resides, as if the object is a most derived object (1.8 [intro.object]) of type T (that is, not a base class subobject). The null pointer value is converted to the null pointer value of the destination type.

2. Add the indicated words to 5.2.9 [expr.static.cast] paragraph 11:

An rvalue of type “pointer to cv1 void” can be converted to an rvalue of type “pointer to cv2 T,” where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. The null pointer value is converted to the null pointer value of the destination type. A value of type pointer to object converted to “pointer to cv void” and back, possibly with different cv-qualification, shall have its original value...

654. Conversions to and from nullptr_t

[Voted into the WP at the June, 2008 meeting as paper N2656.]

In the interest of promoting use of nullptr instead of the integer literal 0 as the null pointer constant, the proposal accepted by the Committee does not provide for converting a zero-valued integral constant to type std::nullptr_t. However, this omission reduces the utility of the feature for use in the library for smart pointers. In particular, the addition of that conversion (along with a converting constructor accepting a std::nullptr_t) would allow smart pointers to be used just like ordinary pointers in expressions like:

    if (p == 0) { }
    if (0 == p) { }
    if (p != 0) { }
    if (0 != p) { }
    p = 0;

The existing use of the “unspecified bool type” idiom supports this usage, but being able to use std::nullptr_t instead would be simpler and more elegant.

Jason Merrill: I have another reason to support the conversion as well: it seems to me very odd for nullptr_t to be more restrictive than void*. Anything we can do with an arbitrary pointer, we ought to be able to do with nullptr_t as well. Specifically, since there is a standard conversion from literal 0 to void*, and there is a standard conversion from void* to bool, nullptr_t should support the same conversions.

This changes two of the example lines in the proposal as adopted:

    if (nullptr) ;      // error, no conversion to bool
    if (nullptr == 0) ; // error

become

    if (nullptr) ;      // evaluates to false
    if( nullptr == 0 ); // evaluates to true

And later,

    char* ch3 = expr ? nullptr : nullptr; // ch3 is the null pointer value
    char* ch4 = expr ? 0 : nullptr;       // ch4 is the null pointer value
    int n3 = expr ? nullptr : nullptr;    // error, nullptr_t can't be converted to int
    int n4 = expr ? 0 : nullptr;          // error, nullptr_t can't be converted to int

I would also allow reinterpret_cast from nullptr_t to integral type, with the same semantics as a reinterpret_cast from the null pointer value to integral type.

Basically, I would like nullptr_t to act like a void* which is constrained to always be (void*)0.

480. Is a base of a virtual base also virtual?

[Voted into WP at the October, 2006 meeting.]

When the Standard refers to a virtual base class, it should be understood to include base classes of virtual bases. However, the Standard doesn't actually say this anywhere, so when 4.11 [conv.mem] (for example) forbids casting to a derived class member pointer from a virtual base class member pointer, it could be read as meaning:

  struct B {};
  struct D : public B {};
  struct D2 : virtual public D {};

  int B::*p;
  int D::*q;

  void f() {
    static_cast<int D2::*>(p);  // permitted
    static_cast<int D2::*>(q);  // forbidden
  }

Proposed resolution (October, 2005):

1. Change 4.11 [conv.mem] paragraph 2 as indicated:

...If B is an inaccessible (clause 11 [class.access]), ambiguous (10.2 [class.member.lookup]) or virtual (10.1 [class.mi]) base class of D, or a base class of a virtual base class of D, a program that necessitates this conversion is ill-formed...

2. Change 5.2.9 [expr.static.cast] paragraph 2 as indicated:

...and B is not neither a virtual base class of D nor a base class of a virtual base class of D...

3. Change 5.2.9 [expr.static.cast] paragraph 9 as indicated:

...and B is not neither a virtual base class of D nor a base class of a virtual base class of D...

222. Sequence points and lvalue-returning operators

[Voted into the WP at the September, 2008 meeting.]

I believe that the committee has neglected to take into account one of the differences between C and C++ when defining sequence points. As an example, consider

    (a += b) += c;

where a, b, and c all have type int. I believe that this expression has undefined behavior, even though it is well-formed. It is not well-formed in C, because += returns an rvalue there. The reason for the undefined behavior is that it modifies the value of `a' twice between sequence points.

Expressions such as this one are sometimes genuinely useful. Of course, we could write this particular example as

    a += b; a += c;

but what about

    void scale(double* p, int n, double x, double y) {
        for (int i = 0; i < n; ++i) {
            (p[i] *= x) += y;
        }
    }

All of the potential rewrites involve multiply-evaluating p[i] or unobvious circumlocations like creating references to the array element.

One way to deal with this issue would be to include built-in operators in the rule that puts a sequence point between evaluating a function's arguments and evaluating the function itself. However, that might be overkill: I see no reason to require that in

    x[i++] = y;

the contents of `i' must be incremented before the assignment.

A less stringent alternative might be to say that when a built-in operator yields an lvalue, the implementation shall not subsequently change the value of that object as a consequence of that operator.

I find it hard to imagine an implementation that does not do this already. Am I wrong? Is there any implementation out there that does not `do the right thing' already for (a += b) += c?

5.17 [expr.ass] paragraph 1 says,

The result of the assignment operation is the value stored in the left operand after the assignment has taken place; the result is an lvalue.

What is the normative effect of the words "after the assignment has taken place"? I think that phrase ought to mean that in addition to whatever constraints the rules about sequence points might impose on the implementation, assignment operators on built-in types have the additional constraint that they must store the left-hand side's new value before returning a reference to that object as their result.

One could argue that as the C++ standard currently stands, the effect of x = y = 0; is undefined. The reason is that it both fetches and stores the value of y, and does not fetch the value of y in order to compute its new value.

I'm suggesting that the phrase "after the assignment has taken place" should be read as constraining the implementation to set y to 0 before yielding the value of y as the result of the subexpression y = 0.

Francis Glassborow:

My understanding is that for a single variable:

1. Multiple read accesses without a write are OK
2. A single read access followed by a single write (of a value dependant on the read, so that the read MUST happen first) is OK
3. A write followed by an actual read is undefined behaviour
4. Multiple writes have undefined behaviour

It is the 3) that is often ignored because in practice the compiler hardly ever codes for the read because it already has that value but in complicated evaluations with a shortage of registers, that is not always the case. Without getting too close to the hardware, I think we both know that a read too close to a write can be problematical on some hardware.

So, in x = y = 0;, the implementation must NOT fetch a value from y, instead it has to "know" what that value will be (easy because it has just computed that in order to know what it must, at some time, store in y). From this I deduce that computing the lvalue (to know where to store) and the rvalue to know what is stored are two entirely independent actions that can occur in any order commensurate with the overall requirements that both operands for an operator be evaluated before the operator is.

Erwin Unruh:

C distinguishes between the resulting value of an assignment and putting the value in store. So in C a compiler might implement the statement x=y=0; either as x=0;y=0; or as y=0;x=0; In C the statement (x += 5) += 7; is not allowed because the first += yields an rvalue which is not allowed as left operand to +=. So in C an assignment is not a sequence of write/read because the result is not really "read".

In C++ we decided to make the result of assignment an lvalue. In this case we do not have the option to specify the "value" of the result. That is just the variable itself (or its address in a different view). So in C++, strictly speaking, the statement x=y=0; must be implemented as y=0;x=y; which makes a big difference if y is declared volatile.

Furthermore, I think undefined behaviour should not be the result of a single mentioning of a variable within an expression. So the statement (x +=5) += 7; should NOT have undefined behaviour.

In my view the semantics could be:

1. if the result of an assignment is used as an rvalue, its value is that of the variable after assignment. The actual store takes place before the next sequence point, but may be before the value is used. This is consistent with C usage.
2. if the result of an assignment is used as an lvalue to store another value, then the new value will be stored in the variable before the next sequence point. It is unspecified whether the first assigned value is stored intermediately.
3. if the result of an assignment is used as an lvalue to take an address, that address is given (it doesn't change). The actual store of the new value takes place before the next sequence point.

Jerry Schwarz:

My recollection is different from Erwin's. I am confident that the intention when we decided to make assignments lvalues was not to change the semantics of evaluation of assignments. The semantics was supposed to remain the same as C's.

Ervin seems to assume that because assignments are lvalues, an assignment's value must be determined by a read of the location. But that was definitely not our intention. As he notes this has a significant impact on the semantics of assignment to a volatile variable. If Erwin's interpretation were correct we would have no way to write a volatile variable without also reading it.

Lawrence Crowl:

For x=y=0, lvalue semantics implies an lvalue to rvalue conversion on the result of y=0, which in turn implies a read. If y is volatile, lvalue semantics implies both a read and a write on y.

The standard apparently doesn't state whether there is a value dependence of the lvalue result on the completion of the assignment. Such a statement in the standard would solve the non-volatile C compatibility issue, and would be consistent with a user-implemented operator=.

Another possible approach is to state that primitive assignment operators have two results, an lvalue and a corresponding "after-store" rvalue. The rvalue result would be used when an rvalue is required, while the lvalue result would be used when an lvalue is required. However, this semantics is unsupportable for user-defined assignment operators, or at least inconsistent with all implementations that I know of. I would not enjoy trying to write such two-faced semantics.

Erwin Unruh:

The intent was for assignments to behave the same as in C. Unfortunately the change of the result to lvalue did not keep that. An "lvalue of type int" has no "int" value! So there is a difference between intent and the standard's wording.

So we have one of several choices:

• live with the incompatibility (and the problems it has for volatile variables)
• make the result of assignment an rvalue (only builtin-assignment, maybe only for builtin types), which makes some presently valid programs invalid
• introduce "two-face semantics" for builtin assignments, and clarify the sequence problematics
• make a special rule for assignment to a volatile lvalue of builtin type

I think the last one has the least impact on existing programs, but it is an ugly solution.

Andrew Koenig:

Whatever we may have intended, I do not think that there is any clean way of making

    volatile int v;
    int i;

    i = v = 42;

Indeed, if v is volatile, I cannot imagine a conscientious programmer writing a statement such as this one. Instead, I would expect to see

    v = 42;
    i = v;

    v = 42;
    i = 42;

What I do want is to ensure that expressions such as ``i = v = 42'' have well-defined semantics, as well as expressions such as (i = v) = 42 or, more realistically, (i += v) += 42 .

I wonder if the following resolution is sufficient:

Append to 5.17 [expr.ass] paragraph 1:

There is a sequence point between assigning the new value to the left operand and yielding the result of the assignment expression.

I believe that this proposal achieves my desired effect of not constraining when j is incremented in x[j++] = y, because I don't think there is a constraint on the relative order of incrementing j and executing the assignment. However, I do think it allows expressions such as (i += v) += 42, although with different semantics from C if v is volatile.

Notes on 10/01 meeting:

There was agreement that adding a sequence point is probably the right solution.

Notes from the 4/02 meeting:

The working group reaffirmed the sequence-point solution, but we will look for any counter-examples where efficiency would be harmed.

For drafting, we note that ++x is defined in 5.3.2 [expr.pre.incr] as equivalent to x+=1 and is therefore affected by this change. x++ is not affected. Also, we should update any list of all sequence points.

Notes from October 2004 meeting:

Discussion centered around whether a sequence point “between assigning the new value to the left operand and yielding the result of the expression” would require completion of all side effects of the operand expressions before the value of the assignment expression was used in another expression. The consensus opinion was that it would, that this is the definition of a sequence point. Jason Merrill pointed out that adding a sequence point after the assignment is essentially the same as rewriting

    b += a

as

    b += a, b

Clark Nelson expressed a desire for something like a “weak” sequence point that would force the assignment to occur but that would leave the side effects of the operands unconstrained. In support of this position, he cited the following expression:

    j = (i = j++)

With the proposed addition of a full sequence point after the assignment to i, the net effect is no change to j. However, both g++ and MSVC++ behave differently: if the previous value of j is 5, the value of the expression is 5 but j gets the value 6.

Clark Nelson will investigate alternative approaches and report back to the working group.

Proposed resolution (March, 2008):

This issue is resolved by the adoption of the sequencing rules and the resolution of issue 637.

351. Sequence point error: unspecified or undefined?

[Voted into WP at March 2004 meeting.]

I have found what looks like a bug in clause 5 [expr], paragraph 4:

Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined. Example:

        i = v[i++];                     // the behavior is unspecified
        i = 7, i++, i++;                // i becomes 9

        i = ++i + 1;                    // the behavior is unspecified
        i = i + 1;                      // the value of i is incremented

--end example]

So which is it, unspecified or undefined?

Notes from October 2002 meeting:

We should find out what C99 says and do the same thing.

Proposed resolution (April 2003):

Change the example in clause 5 [expr], paragraph 4 from

[Example:

i = v[i++];                     //  the behavior is unspecified
i = 7, i++, i++;                //   i  becomes  9

i = ++i + 1;                    //  the behavior is unspecified
i = i + 1;                      //  the value of  i  is incremented

--- end example]

to (changing "unspecified" to "undefined" twice)

[Example:

i = v[i++];                     //  the behavior is undefined
i = 7, i++, i++;                //   i  becomes  9

i = ++i + 1;                    //  the behavior is undefined
i = i + 1;                      //  the value of  i  is incremented

--- end example]

451. Expressions with invalid results and ill-formedness

[Voted into WP at October 2005 meeting.]

Clause 5 [expr] par. 5 of the standard says:

If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined, unless such an expression is a constant expression (5.19), in which case the program is ill-formed.

Well, we do know that except in some contexts (e.g. controlling expression of a #if, array bounds), a compiler is not required to evaluate constant-expressions in compile time, right?

Now, let us consider, the following simple snippet:

  if (a && 1/0)
      ...

I think the intent is actually the latter, so I propose the following rewording of the quoted section:

If an expression is evaluated but its result is not mathematically defined or not in the range of representable values for its type the behavior is undefined, unless such an expression is a constant expression (5.19) that shall be evaluated during program translation, in which case the program is ill-formed.

Rationale (March, 2004):

We feel the standard is clear enough. The quoted sentence does begin "If during the evaluation of an expression, ..." so the rest of the sentence does not apply to an expression that is not evaluated.

Note (September, 2004):

Gennaro Prota feels that the CWG missed the point of his original comment: unless a constant expression appears in a context that requires a constant expression, an implementation is permitted to defer its evaluation to runtime. An evaluation that fails at runtime cannot affect the well-formedness of the program; only expressions that are evaluated at compile time can make a program ill-formed.

The status has been reset to “open” to allow further discussion.

Proposed resolution (October, 2004):

Change paragraph 5 of 5 [expr] as indicated:

If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined, unless such an expression is a constant expression appears where an integral constant expression is required (5.19 [expr.const]), in which case the program is ill-formed.

122. template-ids as unqualified-ids

[Moved to DR at 10/01 meeting.]

5.1.1 [expr.prim.general] paragraph 11 reads,

A template-id shall be used as an unqualified-id only as specified in 14.7.2 [temp.explicit] , 14.7 [temp.spec] , and 14.5.5 [temp.class.spec] .

What uses of template-ids as unqualified-ids is this supposed to prevent? And is the list of referenced sections correct/complete? For instance, what about 14.8.1 [temp.arg.explicit], "Explicit template argument specification?" Does its absence from the list in 5.1.1 [expr.prim.general] paragraph 11 mean that "f<int>()" is ill-formed?

This is even more confusing when you recall that unqualified-ids are contained in qualified-ids:

qualified-id: ::_opt nested-name-specifier template_opt unqualified-id

Is the wording intending to say "used as an unqualified-id that is not part of a qualified-id?" Or something else?

Proposed resolution (10/00):

Remove the referenced sentence altogether.

125. Ambiguity in friend declaration syntax

[Voted into WP at March 2004 meeting.]

The example below is ambiguous.

    struct A{
      struct B{};
    };

    A::B C();

    namespace B{
      A C();
    }

    struct Test {
      friend A::B ::C();
    };

The ambiguity arises since both the simple-type-specifier (7.1.6.2 [dcl.type.simple] paragra 1) and an init-declararator (8 [dcl.decl] paragraph 1) contain an optional :: and an optional nested-name-specifier (5.1.1 [expr.prim.general] paragraph 1). Therefore, two different ways to analyse this code are possible:

simple-type-specifier = A::B
init-declarator = ::C()
simple-declaration = friend A::B ::C();

simple-type-specifier = A
init-declarator = ::B::C()
simple-declaration = friend A ::B::C();

Suggested Resolution: In the definition of nested-name-specifier, add a sentence saying that a :: token immediately following a nested-name-specifier is always considered as part of the nested-name-specifier. Under this interpretation, the example is ill-formed, and should be corrected as either

    friend A (::B::C)();   //or
    friend A::B (::C)();

An alternate suggestion — changing 7.1 [dcl.spec] to say that

The longest sequence of tokens that could possibly be a type name is taken as the decl-specifier-seq of a declaration.

— is undesirable because it would make the example well-formed rather than requiring the user to disambiguate the declaration explicitly.

Proposed resolution (04/01):

(See below for problem with this, from 10/01 meeting.)

In 5.1.1 [expr.prim.general] paragraph 7,

1. Before the grammar for qualified-id, start a new paragraph 7a with the text

   A qualified-id is an id-expression that contains the scope resolution operator ::.

2. Following the grammar fragment, insert the following:

   The longest sequence of tokens that could form a qualified-id constitutes a single qualified-id. [Example:

       // classes C, D; functions F, G, namespace N; non-class type T
       friend C ::D::F();   // ill-formed, means friend (C::D::F)();
       friend C (::D::F)(); // well-formed
       friend N::T ::G();   // ill-formed, means friend (N::T::G)();
       friend N::T (::G)(); // well-formed
   

   —end example]

3. Start a new paragraph 7b following the example.

(This resolution depends on that of issue 215.)

Notes from 10/01 meeting:

It was pointed out that the proposed resolution does not deal with cases like X::Y where X is a type but not a class type. The working group reaffirmed its decision that the disambiguation should be syntactic only, i.e., it should depend only on whether or not the name is a type.

At the Seattle meeting, I suggested that a solution might be to change the class-or-namespace-name in the nested-name-specifier rule to just be "identifier"; there was some resistance to this idea. FWIW, I've tried this in g++. I had to revise the idea so that only the second and subsequent names were open to being any identifier, but that seems to work just fine.

So, instead of

nested-name-specifier:
class-or-namespace-name :: nested-name-specifier_opt
class-or-namespace-name :: template nested-name-specifier

it would be

nested-name-specifier:
type-or-namespace-name :: (per issue 215)
nested-name-specifier identifier ::
nested-name-specifier template template-id ::

Or some equivalent but right-associative formulation, if people feel that's important, but it seems irrelevant to me.

Clark Nelson :

Personally, I prefer the left-associative rule. I think it makes it easier to understand. I was thinking about this production a lot at the meeting, considering also some issues related to 301. My formulation was getting kind of ugly, but with a left-associative rule, it gets a lot nicer.

Your proposal isn't complete, however, as it doesn't allow template arguments without an explicit template keyword. You probably want to add an alternative for:

nested-name-specifier type-or-namespace-name ::

There is admittedly overlap between this alternative and

nested-name-specifier identifier ::

but I think they're both necessary.

Notes from the 4/02 meeting:

The changes look good. Clark Nelson will merge the two proposals to produce a single proposed resolution.

Proposed resolution (April 2003):

nested-name-specifier is currently defined in 5.1.1 [expr.prim.general] paragraph 7 as:

nested-name-specifier:
class-or-namespace-name :: nested-name-specifier_opt
class-or-namespace-name :: template nested-name-specifier
class-or-namespace-name:
class-name
namespace-name

The proposed definition is instead:

nested-name-specifier:
type-name ::
namespace-name ::
nested-name-specifier identifier ::
nested-name-specifier template_opt template-id ::

Issue 215 is addressed by using type-name instead of class-name in the first alternative. Issue 125 (this issue) is addressed by using identifier instead of anything more specific in the third alternative. Using left association instead of right association helps eliminate the need for class-or-namespace-name (or type-or-namespace-name, as suggested for issue 215).

It should be noted that this formulation also rules out the possibility of A::template B::, i.e. using the template keyword without any template arguments. I think this is according to the purpose of the template keyword, and that the former rule allowed such a construct only because of the difficulty of formulation of a right-associative rule that would disallow it. But I wanted to be sure to point out this implication.

Notes from April 2003 meeting:

See also issue 96.

The proposed change resolves only part of issue 215.

113. Visibility of called function

[Moved to DR at 10/01 meeting.]

Christophe de Dinechin: In 5.2.2 [expr.call] , paragraph 2 reads:

If no declaration of the called function is visible from the scope of the call the program is ill-formed.

Mike Miller: "The called function" is unfortunate phraseology; it makes it sound as if it's referring to the function actually called, as opposed to the identifier in the postfix expression. It's wrong with respect to Koenig lookup, too (the declaration need not be visible if it can be found in a class or namespace associated with one or more of the arguments).

In fact, this paragraph should be a note. There's a general rule that says you have to find an unambiguous declaration of any name that is used (3.4 [basic.lookup] paragraph 1); the only reason this paragraph is here is to contrast with C's implicit declaration of called functions.

Proposed resolution:

If no declaration of the called function is visible from the scope of the call the program is ill-formed.

[Note: if a function or member function name is used, and name lookup (3.4 [basic.lookup]) does not find a declaration of that name, the program is ill-formed. No function is implicitly declared by such a call. ]

(See also issue 218.)

118. Calls via pointers to virtual member functions

[Voted into the WP at the June, 2008 meeting.]

Martin O'Riordan: Having gone through all the relevant references in the IS, it is not conclusive that a call via a pointer to a virtual member function is polymorphic at all, and could legitimately be interpreted as being static.

Consider 5.2.2 [expr.call] paragraph 1:

The function called in a member function call is normally selected according to the static type of the object expression (clause 10 [class.derived] ), but if that function is virtual and is not specified using a qualified-id then the function actually called will be the final overrider (10.3 [class.virtual] ) of the selected function in the dynamic type of the object expression.

Yet other references such as 5.5 [expr.mptr.oper] paragraph 4:

If the dynamic type of the object does not contain the member to which the pointer refers, the behavior is undefined.

If the result of .* or ->* is a function, then that result can be used only as the operand for the function call operator (). [Example:

        (ptr_to_obj->*ptr_to_mfct)(10);

calls the member function denoted by ptr_to_mfct for the object pointed to by ptr_to_obj. ]

Andy Sawyer: Assuming the resolution is what I've assumed it is for the last umpteen years (i.e. it does the polymorphic thing), then the follow on to that is "Should there also be a way of selecting the non-polymorphic behaviour"?

Mike Miller: It might be argued that the current wording of 5.2.2 [expr.call] paragraph 1 does give polymorphic behavior to simple calls via pointers to members. (There is no qualified-id in obj.*pmf, and the IS says that if the function is not specified using a qualified-id, the final overrider will be called.) However, it clearly says the wrong thing when the pointer-to-member itself is specified using a qualified-id (obj.*X::pmf).

Bill Gibbons: The phrase qualified-id in 5.2.2 [expr.call] paragraph 1 refers to the id-expression and not to the "pointer-to-member expression" earlier in the paragraph:

For a member function call, the postfix expression shall be an implicit (9.3.1 [class.mfct.non-static] , 9.4 [class.static] ) or explicit class member access (5.2.5 [expr.ref] ) whose id-expression is a function member name, or a pointer-to-member expression (5.5 [expr.mptr.oper] ) selecting a function member.

Mike Miller: To be clear, here's an example:

    struct S {
	virtual void f();
    };
    void (S::*pmf)();
    void g(S* sp) {
	sp->f();         // 1: polymorphic
	sp->S::f();      // 2: non-polymorphic
	(sp->S::f)();    // 3: non-polymorphic
	(sp->*pmf)();    // 4: polymorphic
	(sp->*&S::f)();  // 5: polymorphic
    }

Notes from October 2002 meeting:

This was moved back to open for lack of a champion. Martin O'Riordan is not expected to be attending meetings.

Proposed resolution (February, 2008):

1. Change 5.2.2 [expr.call] paragraph 1 as follows:

   ... For a member function call, the postfix expression shall be an implicit (9.3.1 [class.mfct.non-static], 9.4 [class.static]) or explicit class member access (5.2.5 [expr.ref]) whose id-expression is a function member name, or a pointer-to-member expression (5.5 [expr.mptr.oper]) selecting a function member. The first expression in the postfix expression is then called the object expression, and; the call is as a member of the object pointed to or referred to by the object expression (5.2.5 [expr.ref], 5.5 [expr.mptr.oper]). In the case of an implicit class member access, the implied object is the one pointed to by this. [Note: a member function call of the form f() is interpreted as (*this).f() (see 9.3.1 [class.mfct.non-static]). —end note] If a function or member function name is used, the name can be overloaded (clause 13 [over]), in which case the appropriate function shall be selected according to the rules in 13.3 [over.match]. The function called in a member function call is normally selected according to the static type of the object expression (clause 10 [class.derived]), but if that function is virtual and is not specified using a qualified-id then the function actually called will be the final overrider (10.3 [class.virtual]) of the selected function in the dynamic type of the object expression If the selected function is non-virtual, or if the id-expression in the class member access expression is a qualified-id, that function is called. Otherwise, its final overrider (10.3 [class.virtual]) in the dynamic type of the object expression is called. ...

2. Change 5.5 [expr.mptr.oper] paragraph 4 as follows:

   The first operand is called the object expression. If the dynamic type of the object expression does not contain the member to which the pointer refers, the behavior is undefined.

506. Conditionally-supported behavior for non-POD objects passed to ellipsis

[Voted into WP at the October, 2006 meeting.]

The current wording of 5.2.2 [expr.call] paragraph 7 states:

When there is no parameter for a given argument, the argument is passed in such a way that the receiving function can obtain the value of the argument by invoking va_arg (18.10 [support.runtime]). The lvalue-to-rvalue (4.1 [conv.lval]), array-to-pointer (4.2 [conv.array]), and function-to-pointer (4.3 [conv.func]) standard conversions are performed on the argument expression. After these conversions, if the argument does not have arithmetic, enumeration, pointer, pointer to member, or class type, the program is ill-formed. If the argument has a non-POD class type (clause 9 [class]), the behavior is undefined.

Paper J16/04-0167=WG21 N1727 suggests that passing a non-POD object to ellipsis be ill-formed. In discussions at the Lillehammer meeting, however, the CWG felt that the newly-approved category of conditionally-supported behavior would be more appropriate.

Proposed resolution (October, 2005):

Change 5.2.2 [expr.call] paragraph 7 as indicated:

...After these conversions, if the argument does not have arithmetic, enumeration, pointer, pointer to member, or class type, the program is ill-formed. If the argument has a non-POD class type (clause 9), the behavior is undefined. Passing an argument of non-POD class type (clause 9) with no corresponding parameter is conditionally-supported, with implementation-defined semantics.

634. Conditionally-supported behavior for non-POD objects passed to ellipsis redux

[Voted into the WP at the September, 2008 meeting.]

Issue 506 changed passing a non-POD class type to an ellipsis from undefined behavior to conditionally-supported behavior. As a result, an implementation could conceivably reject code like the following:

    struct two {char _[2];};

    template <class From, class To>
    struct is_convertible
    {
    private:
            static From f;

            template <class U> static char test(const U&);
            template <class U> static two test(...);
    public:
            static const bool value = sizeof(test<To>(f)) == 1;
    };

    struct A
    {
         A();
    };

    int main()
    {
         const bool b = is_convertible<A,int>::value;  // b == false
    }

This technique has become popular in template metaprogramming, and no non-POD object is actually passed at runtime. Concepts will eliminate much (perhaps not all) of the need for this kind of programming, but legacy code will persist.

Perhaps this technique should be officially supported by allowing implementations to reject passing a non-POD type to ellipsis only if it appears in a potentially-evaluated expression?

Notes from the July, 2007 meeting:

The CWG agreed with the suggestion to allow such calls in unevaluated contexts.

Proposed resolution (September, 2007):

Change 5.2.2 [expr.call] paragraph 7 as follows:

...Passing an a potentially-evaluated argument of non-trivial class type (clause 9 [class]) with no corresponding parameter is conditionally-supported, with implementation-defined semantics...

466. cv-qualifiers on pseudo-destructor type

[Voted into WP at April, 2006 meeting.]

5.2.4 [expr.pseudo] paragraph 2 says both:

The type designated by the pseudo-destructor-name shall be the same as the object type.

The cv-unqualified versions of the object type and of the type designated by the pseudo-destructor-name shall be the same type.

See also issues 305 and 399.

Proposed resolution (October, 2005):

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

The left-hand side of the dot operator shall be of scalar type. The left-hand side of the arrow operator shall be of pointer to scalar type. This scalar type is the object type. The type designated by the pseudo-destructor-name shall be the same as the object type. The cv-unqualified versions of the object type and of the type designated by the pseudo-destructor-name shall be the same type. Furthermore, the two type-names in a pseudo-destructor-name of the form

::_opt nested-name-specifier_opt type-name ::~ type-name

shall designate the same scalar type. The cv-unqualified versions of the object type and of the type designated by the pseudo-destructor-name shall be the same type.

421. Is rvalue.field an rvalue?

[Voted into WP at March 2004 meeting.]

Consider

  typedef
    struct {
      int a;
    } A;

  A f(void)
  {
    A a;
    return a;
  }

  int main(void)
  {
    int* p = &f().a;   // #1
  }

Should #1 be rejected? The standard is currently silent.

Mike Miller: I don't believe the Standard is silent on this. I will agree that the wording of 5.2.5 [expr.ref] paragraph 4 bullet 2 is unfortunate, as it is subject to misinterpretation. It reads,

If E1 is an lvalue, then E1.E2 is an lvalue.

Notes from October 2003 meeting:

We agree the reference should be an rvalue, and a change along the lines of that recommended by Mike Miller is reasonable.

Proposed Resolution (October 2003):

Change the second bullet of 5.2.5 [expr.ref] paragraph 4 to read:

If E1 is an lvalue, then E1.E2 is an lvalue; otherwise, it is an rvalue.

492. typeid constness inconsistent with example

[Voted into WP at April, 2006 meeting.]

There is an inconsistency between the normative text in section 5.2.8 [expr.typeid] and the example that follows.

Here is the relevant passage (starting with paragraph 4):

When typeid is applied to a type-id, the result refers to a std::type_info object representing the type of the type-id. If the type of the type-id is a reference type, the result of the typeid expression refers to a std::type_info object representing the referenced type.

The top-level cv-qualifiers of the lvalue expression or the type-id that is the operand of typeid are always ignored.

and the example:

    typeid(D) == typeid(const D&); // yields true

The second paragraph above says the “type-id that is the operand”. This would be const D&. In this case, the const is not at the top-level (i.e., applied to the operand itself).

By a strict reading, the above should yield false.

My proposal is that the strict reading of the normative test is correct. The example is wrong. Different compilers here give different answers.

Proposed resolution (April, 2005):

Change the second sentence of 5.2.8 [expr.typeid] paragraph 4 as follows:

If the type of the type-id is a reference to a possibly cv-qualified type, the result of the typeid expression refers to a std::type_info object representing the cv-unqualified referenced type.

54. Static_cast from private base to derived class

[Voted into WP at October 2004 meeting.]

Is it okay to use a static_cast to cast from a private base class to a derived class? That depends on what the words "valid standard conversion" in paragraph 8 mean — do they mean the conversion exists, or that it would not get an error if it were done? I think the former was intended — and therefore a static_cast from a private base to a derived class would be allowed.

Rationale (04/99): A static_cast from a private base to a derived class is not allowed outside a member from the derived class, because 4.10 [conv.ptr] paragraph 3 implies that the conversion is not valid. (Classic style casts work.)

Reopened September 2003:

Steve Adamczyk: It makes some sense to disallow the inverse conversion that is pointer-to-member of derived to pointer-to-member of private base. There's less justification for the pointer-to-private-base to pointer-to-derived case. EDG, g++ 3.2, and MSVC++ 7.1 allow the pointer case and disallow the pointer-to-member case. Sun disallows the pointer case as well.

  struct B {};
  struct D : private B {};
  int main() {
    B *p = 0;
    static_cast<D *>(p);  // Pointer case: should be allowed
    int D::*pm = 0;
    static_cast<int B::*>(pm);  // Pointer-to-member case: should get error
  }

There's a tricky case with old-style casts: because the static_cast interpretation is tried first, you want a case like the above to be considered a static_cast, but then issue an error, not be rejected as not a static cast; if you did the latter, you would then try the cast as a reinterpret_cast.

Ambiguity and casting to a virtual base should likewise be errors after the static_cast interpretation is selected.

Notes from the October 2003 meeting:

There was lots of sentiment for making things symmetrical: the pointer case should be the same as the pointer-to-member case. g++ 3.3 now issues errors on both cases.

We decided an error should be issued on both cases. The access part of the check should be done later; by some definition of the word the static_cast is valid, and then later an access error is issued. This is similar to the way standard conversions work.

Proposed Resolution (October 2003):

Replace paragraph 5.2.9 [expr.static.cast]/6:

The inverse of any standard conversion sequence (clause 4 [conv]), other than the lvalue-to-rvalue (4.1 [conv.lval]), array-to-pointer (4.2 [conv.array]), function-to-pointer (4.3 [conv.func]), and boolean (4.12 [conv.bool]) conversions, can be performed explicitly using static_cast. The lvalue-to-rvalue (4.1 [conv.lval]), array-to-pointer (4.2 [conv.array]), and function-to-pointer (4.3 [conv.func]) conversions are applied to the operand. Such a static_cast is subject to the restriction that the explicit conversion does not cast away constness (5.2.11 [expr.const.cast]), and the following additional rules for specific cases:

with two paragraphs:

The inverse of any standard conversion sequence (clause 4 [conv]), other than the lvalue-to-rvalue (4.1 [conv.lval]), array-to-pointer (4.2 [conv.array]), function-to-pointer (4.3 [conv.func]), and boolean (4.12 [conv.bool]) conversions, can be performed explicitly using static_cast. A program is ill-formed if it uses static_cast to perform the inverse of an ill-formed standard conversion sequence.[Example:

struct B {};
struct D : private B {};
void f() {
  static_cast<D*>((B*)0); // Error: B is a private base of D.
  static_cast<int B::*>((int D::*)0); // Error: B is a private base of D.
}

--- end example]

The lvalue-to-rvalue (4.1 [conv.lval]), array-to-pointer (4.2 [conv.array]), and function-to-pointer (4.3 [conv.func]) conversions are applied to the operand. Such a static_cast is subject to the restriction that the explicit conversion does not cast away constness (5.2.11 [expr.const.cast]), and the following additional rules for specific cases:

In addition, modify the second sentence of 5.4 [expr.cast]/5. The first two sentences of 5.4 [expr.cast]/5 presently read:

The conversions performed by

• a const_cast (5.2.11),
• a static_cast (5.2.9),
• a static_cast followed by a const_cast,
• a reinterpret_cast (5.2.10), or
• a reinterpret_cast followed by a const_cast,

can be performed using the cast notation of explicit type conversion. The same semantic restrictions and behaviors apply.

Change the second sentence to read:

The same semantic restrictions and behaviors apply, with the exception that in performing a static_cast in the following situations the conversion is valid even if the base class is inaccessible:

• a pointer to an object of derived class type or an lvalue of derived class type may be explicitly converted to a pointer or reference to an unambiguous base class type, respectively;
• a pointer to member of derived class type may be explicitly converted to a pointer to member of an unambiguous non-virtual base class type;
• a pointer to an object of an unambiguous non-virtual base class type, an lvalue of an unambiguous non-virtual base class type, or a pointer to member of an unambiguous non-virtual base class type may be explicitly converted to a pointer, a reference, or a pointer to member of a derived class type, respectively.

Remove paragraph 5.4 [expr.cast]/7, which presently reads:

In addition to those conversions, the following static_cast and reinterpret_cast operations (optionally followed by a const_cast operation) may be performed using the cast notation of explicit type conversion, even if the base class type is not accessible:

• a pointer to an object of derived class type or an lvalue of derived class type may be explicitly converted to a pointer or reference to an unambiguous base class type, respectively;
• a pointer to member of derived class type may be explicitly converted to a pointer to member of an unambiguous non-virtual base class type;
• a pointer to an object of non-virtual base class type, an lvalue of non-virtual base class type, or a pointer to member of non-virtual base class type may be explicitly converted to a pointer, a reference, or a pointer to member of a derived class type, respectively.

427. static_cast ambiguity: conversion versus cast to derived

[Voted into WP at October 2004 meeting.]

Consider this code:

  struct B {};

  struct D : public B { 
    D(const B&);
  };

  extern B& b;

  void f() {
    static_cast<const D&>(b);
  }

The rules for static_cast permit the conversion to "const D&" in two ways:

1. D is derived from B, and b is an lvalue, so a cast to D& is OK.
2. const D& t = b is valid, using the constructor for D. [Ed. note: actually, this should be parenthesized initialization.]

The first alternative is 5.2.9 [expr.static.cast]/5; the second is 5.2.9 [expr.static.cast]/2.

Presumably the first alternative is better -- it's the "simpler" conversion. The standard does not seem to make that clear.

Steve Adamczyk: I take the "Otherwise" at the beginning of 5.2.9 [expr.static.cast]/3 as meaning that the paragraph 2 interpretation is used if available, which means in your example above interpretation 2 would be used. However, that's not what EDG's compiler does, and I agree that it's not the "simpler" conversion.

Proposed Resolution (October 2003):

Move paragraph 5.2.9/5:

An lvalue of type ``cv1 B'', where B is a class type, can be cast to type ``reference to cv2 D'', where D is a class derived (clause 10 [class.derived]) from B, if a valid standard conversion from ``pointer to D'' to ``pointer to B'' exists (4.10 [conv.ptr]), cv2 is the same cv-qualification as, or greater cv-qualification than, cv1, and B is not a virtual base class of D. The result is an lvalue of type ``cv2 D.'' If the lvalue of type ``cv1 B'' is actually a sub-object of an object of type D, the lvalue refers to the enclosing object of type D. Otherwise, the result of the cast is undefined. [Example:

  struct B {};
  struct D : public B {};
  D d;
  B &br = d;

  static_cast<D&>(br);            //  produces lvalue to the original  d  object

--- end example]

before paragraph 5.2.9 [expr.static.cast]/2.

Insert Otherwise, before the text of paragraph 5.2.9 [expr.static.cast]/2 (which will become 5.2.9 [expr.static.cast]/3 after the above insertion), so that it reads:

Otherwise, an expression e can be explicitly converted to a type T using a static_cast of the form static_cast<T>(e) if the declaration "T t(e);" is well-formed, for some invented temporary variable t (8.5 [dcl.init]). The effect of such an explicit conversion is the same as performing the declaration and initialization and then using the temporary variable as the result of the conversion. The result is an lvalue if T is a reference type (8.3.2 [dcl.ref]), and an rvalue otherwise. The expression e is used as an lvalue if and only if the initialization uses it as an lvalue.

439. Guarantees on casting pointer back to cv-qualified version of original type

[Voted into WP at April 2005 meeting.]

Paragraph 5.2.9 [expr.static.cast] paragraph 10 says that:

A value of type pointer to object converted to "pointer to cv void" and back to the original pointer type will have its original value.

That guarantee should be stronger. In particular, given:

  T* p1 = new T;
  const T* p2 = static_cast<const T*>(static_cast<void *>(p1));
  if (p1 != p2)
    abort ();

A value of type pointer to object converted to "pointer to cv void" and back to the original pointer type (or a variant of the original pointer type that differs only in the cv-qualifiers applied to the object type) will have its original value. [Example:

T* p1 = new T;
const T* p2 = static_cast<const T*>(static_cast<void *>(p1));
bool b = p1 == p2; // b will have the value true.

---end example.]

Proposed resolution:

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

A value of type pointer to object converted to "pointer to cv void" and back to the original pointer type, possibly with different cv-qualification, will have its original value. [Example:

  T* p1 = new T;
  const T* p2 = static_cast<const T*>(static_cast<void *>(p1));
  bool b = p1 == p2; // b will have the value true.

---end example]

Rationale: The wording "possibly with different cv-qualification" was chosen over the suggested wording to allow for changes in cv-qualification at different levels in a multi-level pointer, rather than only at the object type level.

671. Explicit conversion from a scoped enumeration type to integral type

[Voted into the WP at the September, 2008 meeting.]

There appears to be no provision in the Standard for explicit conversion of a value of a scoped enumeration type to an integral type, even though the inverse conversion is permitted. That is,

    enum class E { e };
    static_cast<E>(0);       // #1: OK
    static_cast<int>(E::e);  // #2: error

This is because values of scope enumeration types (intentionally) cannot be implicitly converted to integral types (4.5 [conv.prom] and 4.7 [conv.integral]) and 5.2.9 [expr.static.cast] was not updated to permit #2, although #1 is covered by paragraph 8.

Proposed resolution (June, 2008):

Add the following as a new paragraph following 5.2.9 [expr.static.cast] paragraph 8:

A value of a scoped enumeration type (7.2 [dcl.enum]) can be explicitly converted to an integral type. The value is unchanged if the original value can be represented by the specified type. Otherwise, the resulting value is unspecified.

195. Converting between function and object pointers

[Voted into WP at April 2005 meeting.]

It is currently not permitted to cast directly between a pointer to function type and a pointer to object type. This conversion is not listed in 5.2.9 [expr.static.cast] and 5.2.10 [expr.reinterpret.cast] and thus requires a diagnostic to be issued. However, if a sufficiently long integral type exists (as is the case in many implementations), it is permitted to cast between pointer to function types and pointer to object types using that integral type as an intermediary.

In C the cast results in undefined behavior and thus does not require a diagnostic, and Unix C compilers generally do not issue one. This fact is used in the definition of the standard Unix function dlsym, which is declared to return void* but in fact may return either a pointer to a function or a pointer to an object. The fact that C++ compilers are required to issue a diagnostic is viewed as a "competitive disadvantage" for the language.

Suggested resolution: Add wording to 5.2.10 [expr.reinterpret.cast] allowing conversions between pointer to function and pointer to object types, if the implementation has an integral data type that can be used as an intermediary.

Several points were raised in opposition to this suggestion:

1. Early C++ supported this conversion and it was deliberately removed during the standardization process.
2. The existence of an appropriate integral type is irrelevant to whether the conversion is "safe." The condition should be on whether information is lost in the conversion or not.
3. There are numerous ways to address the problem at an implementation level rather than changing the language. For example, the compiler could recognize the specific case of dlsym and omit the diagnostic, or the C++ binding to dlsym could be changed (using templates, for instance) to circumvent the violation.
4. The conversion is, in fact, not supported by C; the dlsym function is simply relying on non-mandated characteristics of C implementations, and we would be going beyond the requirements of C compatibility in requiring (some) implementations to support the conversion.
5. This issue is in fact not a defect (omitted or self-contradictory requirements) in the current Standard; the proposed change would actually be an extension and should not be considered until the full review of the IS.
6. dlsym appears not to be used very widely, and the declaration in the header file is not problematic, only calls to it. Since C code generally requires some porting to be valid C++ anyway, this should be considered one of those items that requires porting.

Martin O'Riordan suggested an alternative approach:

• Do not allow the conversions to be performed via old-style casts.
• Allow reinterpret_cast to perform the conversions with the C-style semantics (undefined behavior if not supported).
• Allow dynamic_cast to perform the conversions with well-defined behavior: the result would be a null pointer if the implementation could not support the requested conversion.

The advantage of this approach is that it would permit writing portable, well-defined programs involving such conversions. However, it breaks the current degree of compatibility between old and new casts, and it adds functionality to dynamic_cast which is not obviously related to its current meaning.

Notes from 04/00 meeting:

Andrew Koenig suggested yet another approach: specify that "no diagnostic is required" if the implementation supports the conversion.

Later note:

It was observed that conversion between function and data pointers is listed as a "common extension" in C99.

Notes on the 10/01 meeting:

It was decided that we want the conversion defined in such a way that it always exists but is always undefined (as opposed to existing only when the size relationship is appropriate, and being implementation-defined in that case). This would allow an implementation to issue an error at compile time if the conversion does not make sense.

Bill Gibbons notes that the definitions of the other similar casts are inconsistent in this regard. Perhaps they should be updated as well.

Proposed resolution (April 2003):

After 5.2.10 [expr.reinterpret.cast] paragraph 6, insert:

A pointer to a function can be explicitly converted to a pointer to a function of a different type. The effect of calling a function through a pointer to a function type (8.3.5 [dcl.fct]) that is not the same as the type used in the definition of the function is undefined. Except that converting an rvalue of type ``pointer to T1'' to the type ``pointer to T2'' (where T1 and T2 are function types) and back to its original type yields the original pointer value, the result of such a pointer conversion is unspecified. [Note: see also 4.10 [conv.ptr] for more details of pointer conversions. ] It is implementation defined whether a conversion from pointer to object to pointer to function and/or a conversion from pointer to function to pointer to object exist.

An lvalue expression of type T1 can be cast to the type ``reference to T2'' if T1 and T2 are object types and an expression of type ``pointer to T1'' can be explicitly converted to the type ``pointer to T2'' using a reinterpret_cast. That is, a reference cast reinterpret_cast< T& >(x) has the same effect as the conversion *reinterpret_cast< T* >(&x) with the built-in & and * operators. The result is an lvalue that refers to the same object as the source lvalue, but with a different type. No temporary is created, no copy is made, and constructors (12.1 [class.ctor]) or conversion functions (12.3 [class.conv]) are not called.

Drafting Note:

If either conversion exists, the implementation already has to define the behavior (paragraph 3).

Notes from April 2003 meeting:

The new consensus is that if the implementation allows this cast, pointer-to-function converted to pointer-to-object converted back to the original pointer-to-function should work; anything else is undefined behavior. If the implementation does not allow the cast, it should be ill-formed.

Tom Plum is investigating a new concept, that of a "conditionally-defined" feature, which may be applicable here.

Proposed Resolution (October, 2004):

(See paper J16/04-0067 = WG21 N1627 for background material and rationale for this resolution. The resolution proposed here differs only editorially from the one in the paper.)

1. Insert the following into 1.3 [intro.defs] and renumber all following definitions accordingly:

   1.3.2  conditionally-supported behavior

   behavior evoked by a program construct that is not a mandatory requirement of this International Standard. If a given implementation supports the construct, the behavior shall be as described herein; otherwise, the implementation shall document that the construct is not supported and shall treat a program containing an occurrence of the construct as ill-formed (1.3 [intro.defs]).

2. Add the indicated words to 1.4 [intro.compliance] paragraph 2, bullet 2:

   • If a program contains a violation of any diagnosable rule, or an occurrence of a construct described herein as “conditionally-supported” or as resulting in “conditionally-supported behavior” when the implementation does not in fact support that construct, a conforming implementation shall issue at least one diagnostic message, except that

3. Insert the following as a new paragraph following 5.2.10 [expr.reinterpret.cast] paragraph 7:

   Converting a pointer to a function to a pointer to an object type or vice versa evokes conditionally-supported behavior. In any such conversion supported by an implementation, converting from an rvalue of one type to the other and back (possibly with different cv-qualification) shall yield the original pointer value; mappings between pointers to functions and pointers to objects are otherwise implementation-defined.

4. Change 7.4 [dcl.asm] paragraph 1 as indicated:

   The meaning of an An asm declaration evokes conditionally-supported behavior. If supported, its meaning is implementation-defined.

5. Change 7.5 [dcl.link] paragraph 2 as indicated:

   The string-literal indicates the required language linkage. The meaning of the string-literal is implementation-defined. A linkage-specification with a string that is unknown to the implementation is ill-formed. This International Standard specifies the semantics of C and C++ language linkage. Other values of the string-literal evoke conditionally-supported behavior, with implementation-defined semantics. [Note: Therefore, a linkage-specification with a string-literal that is unknown to the implementation requires a diagnostic. When the string-literal in a linkage-specification names a programming language, the spelling of the programming language's name is implementation-defined. [Note: It is recommended that the spelling be taken from the document defining that language, for example Ada (not ADA) and Fortran or FORTRAN (depending on the vintage). The semantics of a language linkage other than C++ or C are implementation-defined. ]

6. Change 14 [temp] paragraph 4 as indicated:

   A template, a template explicit specialization (14.7.3 [temp.expl.spec]), or a class template partial specialization shall not have C linkage. If the linkage of one of these is something other than C or C++, the behavior is implementation-defined result is conditionally-supported behavior, with implementation-defined semantics.

463. reinterpret_cast<T*>(0)

[Voted into WP at April, 2006 meeting.]

Is reinterpret_cast<T*>(null_pointer_constant) guaranteed to yield the null pointer value of type T*?

I think a committee clarification is needed. Here's why: 5.2.10 [expr.reinterpret.cast] par. 8 talks of "null pointer value", not "null pointer constant", so it would seem that

  reinterpret_cast<T*>(0)

However a little note to 5.2.10 [expr.reinterpret.cast] par. 5 says:

Converting an integral constant expression (5.19) with value zero always yields a null pointer (4.10), but converting other expressions that happen to have value zero need not yield a null pointer.

SUGGESTED RESOLUTION: I think it would be better to drop the footnote #64 (and thus the special case for ICEs), for two reasons:

a) it's not normative anyway; so I doubt anyone is relying on the guarantee it hints at, unless that guarantee is given elsewhere in a normative part

b) users expect reinterpret_casts to be almost always implementation dependent, so this special case is a surprise. After all, if one wants a null pointer there's static_cast. And if one wants reinterpret_cast semantics the special case requires doing some explicit cheat, such as using a non-const variable as intermediary:

   int v = 0;
   reinterpret_cast<T*>(v); // implementation defined

   reinterpret_cast<T*>(0); // null pointer value of type T*
   const int w = 0;
   reinterpret_cast<T*>(w); // null pointer value of type T*

It seems that not only that's providing a duplicate functionality, but also at the cost to hide what seems the more natural one.

Notes from October 2004 meeting:

This footnote was added in 1996, after the invention of reinterpret_cast, so the presumption must be that it was intentional. At this time, however, the CWG feels that there is no reason to require that reinterpret_cast<T*>(0) produce a null pointer value as its result.

Proposed resolution (April, 2005):

1. Delete the footnote in 5.2.10 [expr.reinterpret.cast] paragraph 5 reading,

   Converting an integral constant expression (5.19 [expr.const]) with value zero always yields a null pointer (4.10 [conv.ptr]), but converting other expressions that happen to have value zero need not yield a null pointer.

2. Add the indicated note to 5.2.10 [expr.reinterpret.cast] paragraph 8:

   The null pointer value (4.10 [conv.ptr]) is converted to the null pointer value of the destination type. [Note: A null pointer constant, which has integral type, is not necessarily converted to a null pointer value. —end note]

324. Can "&" be applied to assignment to bit-field?

[Voted into WP at October 2003 meeting.]

An assignment returns an lvalue for its left operand. If that operand refers to a bit field, can the "&" operator be applied to the assignment? Can a reference be bound to it?

  struct S { int a:3; int b:3; int c:3; };

  void f()
  {
    struct S s;
    const int *p = &(s.b = 0);     // (a)
    const int &r = (s.b = 0);      // (b)
          int &r2 = (s.b = 0);     // (c)
  }

Notes from the 4/02 meeting:

The working group agreed that this should be an error.

Proposed resolution (October 2002):

In 5.3.2 [expr.pre.incr] paragraph 1 (prefix "++" and "--" operators), change

The value is the new value of the operand; it is an lvalue.

The result is the updated operand; it is an lvalue, and it is a bit-field if the operand is a bit-field.

In 5.16 [expr.cond] paragraph 4 ("?" operator), add the indicated text:

If the second and third operands are lvalues and have the same type, the result is of that type and is an lvalue and it is a bit-field if the second or the third operand is a bit-field, or if both are bit-fields.

In 5.17 [expr.ass] paragraph 1 (assignment operators) add the indicated text (the original text is as updated by issue 221, which is DR but not in TC1):

The assignment operator (=) and the compound assignment operators all group right-to-left. All require a modifiable lvalue as their left operand and return an lvalue with the type and value of the left operand after the assignment has taken place. The result in all cases is a bit-field if the left operand is a bit-field.

Note that issue 222 adds (non-conflicting) text at the end of this same paragraph (5.17 [expr.ass] paragraph 1).

In 5.18 [expr.comma] paragraph 1 (comma operator), change:

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.

The type and value of the result are the type and value of the right operand; the result is an lvalue if the right operand is an lvalue, and is a bit-field if the right operand is an lvalue and a bit-field.

Relevant related text (no changes required):

5.3.1 [expr.unary.op] paragraph 4:

The operand of & shall not be a bit-field.

8.5.3 [dcl.init.ref] paragraph 5, bullet 1, sub-bullet 1 (regarding binding a reference to an lvalue):

... is an lvalue (but is not a bit-field) ...

256. Overflow in size calculations

[Voted into the WP at the September, 2008 meeting.]

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

(See also issue 476.)

The size requested by an array allocation is computed by multiplying the number of elements requested by the size of each element and adding an implementation-specific amount for overhead. It is possible for this calculation to overflow. Is an implementation required to detect this situation and, for instance, throw std::bad_alloc?

On one hand, the maximum allocation size is one of the implementation limits specifically mentioned in Annex B [implimits], and, according to 1.4 [intro.compliance] paragraph 2, an implementation is only required to "accept and correctly execute" programs that do not violate its resource limits.

On the other hand, it is difficult or impossible for user code to detect such overflows in a portable fashion, especially given that the array allocation overhead is not fixed, and it would be a service to the user to handle this situation gracefully.

Rationale (04/01):

Each implementation is required to document the maximum size of an object (Annex B [implimits]). It is not difficult for a program to check array allocations to ensure that they are smaller than this quantity. Implementations can provide a mechanism in which users concerned with this problem can request extra checking before array allocations, just as some implementations provide checking for array index and pointer validity. However, it would not be appropriate to require this overhead for every array allocation in every program.

(See issue 624 for a request to reconsider this resolution.)

Note (March, 2008):

The Evolution Working Group has accepted the intent of this issue and referred it to CWG for action for C++0x (see paper J16/07-0033 = WG21 N2173).

Proposed resolution (September, 2008):

This issue is resolved by the resolution of issue 624, given in paper N2757.

299. Conversion on array bound expression in new

[Voted into WP at October 2005 meeting.]

In 5.3.4 [expr.new], the standard says that the expression in an array-new has to have integral type. There's already a DR (issue 74) that says it should also be allowed to have enumeration type. But, it should probably also say that it can have a class type with a single conversion to integral type; in other words the same thing as in 6.4.2 [stmt.switch] paragraph 2.

Suggested resolution:

In 5.3.4 [expr.new] paragraph 6, replace "integral or enumeration type (3.9.1 [basic.fundamental])" with "integral or enumeration type (3.9.1 [basic.fundamental]), or a class type for which a single conversion function to integral or enumeration type exists".

Proposed resolution (October, 2004):

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

Every constant-expression in a direct-new-declarator shall be an integral constant expression (5.19 [expr.const]) and evaluate to a strictly positive value. The expression in a direct-new-declarator shall have be of integral type, or enumeration type (3.9.1), or a class type for which a single conversion function to integral or enumeration type exists (12.3 [class.conv]). If the expression is of class type, the expression is converted by calling the conversion function, and the result of the conversion is used in place of the original expression. The value of the expression shall bewith a non-negative value. [Example: ...

Proposed resolution (April, 2005):

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

Every constant-expression in a direct-new-declarator shall be an integral constant expression (5.19 [expr.const]) and evaluate to a strictly positive value. The expression in a direct-new-declarator shall have integral or enumeration type (3.9.1 [basic.fundamental]) with a non-negative value be of integral type, enumeration type, or a class type for which a single conversion function to integral or enumeration type exists (12.3 [class.conv]). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. If the value of the expression is negative, the behavior is undefined. [Example: ...

429. Matching deallocation function chosen based on syntax or signature?

[Voted into WP at October 2004 meeting.]

What does this example do?

  #include <stdio.h>
  #include <stdlib.h>

  struct A {
        void* operator new(size_t alloc_size, size_t dummy=0) {
                printf("A::operator new()\n");
                return malloc(alloc_size);
        };

        void operator delete(void* p, size_t s) {
                printf("A::delete %d\n", s);
        };


        A()  {printf("A constructing\n"); throw 2;};

  };

  int
  main() {
    try {
        A* ap = new A;
        delete ap;
    }
    catch(int) {printf("caught\n"); return 1;}
  }  

The fundamental issue here is whether the deletion-on-throw is driven by the syntax of the new (placement or non-placement) or by signature matching. If the former, the operator delete would be called with the second argument equal to the size of the class. If the latter, it would be called with the second argument 0.

Core issue 127 (in TC1) dealt with this topic. It removed some wording in 15.2 [except.ctor] paragraph 2 that implied a syntax-based interpretation, leaving wording in 5.3.4 [expr.new] paragraph 19 that is signature-based. But there is no accompanying rationale to confirm an explicit choice of the signature-based approach.

EDG and g++ get 0 for the second argument, matching the presumed core issue 127 resolution. But maybe this should be revisited.

Notes from October 2003 meeting:

There was widespread agreement that the compiler shouldn't just silently call the delete with either of the possible values. In the end, we decided it's smarter to issue an error on this case and force the programmer to say what he means.

Mike Miller's analysis of the status quo: 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2 says that "operator delete(void*, std::size_t)" is a "usual (non-placement) deallocation function" if the class does not declare "operator delete(void*)." 3.7.4.1 [basic.stc.dynamic.allocation] does not use the same terminology for allocation functions, but the most reasonable way to understand the uses of the term "placement allocation function" in the Standard is as an allocation function that has more than one parameter and thus can (but need not) be called using the "new-placement" syntax described in 5.3.4 [expr.new]. (In considering issue 127, the core group discussed and endorsed the position that, "If a placement allocation function has default arguments for all its parameters except the first, it can be called using non-placement syntax.")

5.3.4 [expr.new] paragraph 19 says that any non-placement deallocation function matches a non-placement allocation function, and that a placement deallocation function matches a placement allocation function with the same parameter types after the first -- i.e., a non-placement deallocation function cannot match a placement allocation function. This makes sense, because non-placement ("usual") deallocation functions expect to free memory obtained from the system heap, which might not be the case for storage resulting from calling a placement allocation function.

According to this analysis, the example shows a placement allocation function and a non-placement deallocation function, so the deallocation function should not be invoked at all, and the memory will just leak.

Proposed Resolution (October 2003):

Add the following text at the end of 5.3.4 [expr.new] paragraph 19:

If the lookup finds the two-parameter form of a usual deallocation function (3.7.4.2 [basic.stc.dynamic.deallocation]), and that function, considered as a placement deallocation function, would have been selected as a match for the allocation function, the program is ill-formed. [Example:

struct S { 
  // Placement allocation function:
  static void* operator new(std::size_t, std::size_t); 

  // Usual (non-placement) deallocation function:
  static void operator delete(void*, std::size_t); 
}; 

S* p = new (0) S; // ill-formed: non-placement deallocation function matches 
                  // placement allocation function 

--- end example]

624. Overflow in calculating size of allocation

[Voted into the WP at the September, 2008 meeting (resolution in paper N2757).]

Issue 256 was closed without action, principally on the the grounds that an implementation could provide a means (command-line option, #pragma, etc.) for requesting that the allocation size be checked for validity, but that “it would not be appropriate to require this overhead for every array allocation in every program.”

This rationale may be giving too much weight to the overhead such a check would add, especially when compared to the likely cost of actually doing the storage allocation. In particular, the test essentially amounts to something like

    if (max_allocation_size / sizeof(T) < num_elements)
        throw std::bad_alloc();

(noting that max_allocation_size/sizeof(T) is a compile-time constant). It might make more sense to turn the rationale around and require the check, assuming that implementations could provide a mechanism for suppressing it if needed.

Suggested resolution:

In 5.3.4 [expr.new] paragraph 7, add the following words before the example:

If the value of the expression is such that the size of the allocated object would exceed the implementation-defined limit, an exception of type std::bad_alloc is thrown and no storage is obtained.

Note (March, 2008):

The Evolution Working Group has accepted the intent of issue 256 and referred it to CWG for action for C++0x (see paper J16/07-0033 = WG21 N2173).

Proposed resolution (March, 2008):

As suggested.

Notes from the June, 2008 meeting:

The CWG felt that this situation should not be treated like an out-of-memory situation and thus an exception of type std::bad_alloc (or, alternatively, returning a null pointer for a throw() allocator) would not be appropriate.

Proposed resolution (June, 2008):

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

If the value of the expression in a direct-new-declarator 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::length_error (19.2.4 [length.error]). Otherwise, if When the value of the that expression in a direct-new-declarator is zero, the allocation function is called to allocate an array with no elements.

[Drafting note: std::length_error is thrown by std::string and std::vector and thus appears to be the right choice for the exception to be thrown here.]

288. Misuse of "static type" in describing pointers

[Voted into the WP at the June, 2008 meeting.]

For delete expressions, 5.3.5 [expr.delete] paragraph 1 says

The operand shall have a pointer type, or a class type having a single conversion function to a pointer type.

However, paragraph 3 of that same section says:

if the static type of the operand is different from its dynamic type, the static type shall be a base class of the operand's dynamic type and the static type shall have a virtual destructor or the behavior is undefined.

Since the operand must be of pointer type, its static type is necessarily the same as its dynamic type. That clause is clearly referring to the object being pointed at, and not to the pointer operand itself.

Correcting the wording gets a little complicated, because dynamic and static types are attributes of expressions, not objects, and there's no sub-expression of a delete-expression which has the relevant types.

Suggested resolution:

then there is a static type and a dynamic type that the hypothetical expression (* const-expression) would have. If that static type is different from that dynamic type, then that static type shall be a base class of that dynamic type, and that static type shall have a virtual destructor, or the behavior is undefined.

There's precedent for such use of hypothetical constructs: see 5.10 [expr.eq] paragraph 2, and 8.1 [dcl.name] paragraph 1.

10.3 [class.virtual] paragraph 3 has a similar problem. It refers to

the type of the pointer or reference denoting the object (the static type).

The type of the pointer is different from the type of the reference, both of which are different from the static type of '*pointer', which is what I think was actually intended. Paragraph 6 contains the exact same wording, in need of the same correction. In this case, perhaps replacing "pointer or reference" with "expression" would be the best fix. In order for this fix to be sufficient, pointer->member must be considered equivalent to (*pointer).member, in which case the "expression" referred to would be (*pointer).

if a delete-expression is used to deallocate a class object whose static type has...

This should be changed to

if a delete-expression is used to deallocate a class object through a pointer expression whose dereferenced static type would have...

The same problem occurs later, when it says that the

static and dynamic types of the object shall be identical

In this case you could replace "object" with "dereferenced pointer expression".

Footnote 104 says that

5.3.5 [expr.delete] requires that ... the static type of the delete-expression's operand be the same as its dynamic type.

This would need to be changed to

the delete-expression's dereferenced operand

Proposed resolution (December, 2006):

1. Change 5.3.5 [expr.delete] paragraph 3 as follows:

In the first alternative (delete object), if the static type of the operand object to be deleted is different from its dynamic type, the static type shall be a base class of the operand's dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined. In the second alternative (delete array) if the dynamic type of the object to be deleted differs from its static type, the behavior is undefined.

2. Change the footnote in 12.5 [class.free] paragraph 4 as follows:

A similar provision is not needed for the array version of operator delete because 5.3.5 [expr.delete] requires that in this situation, the static type of the delete-expression's operand object to be deleted be the same as its dynamic type.

3. Change the footnote in 12.5 [class.free] paragraph 5 as follows:

If the static type in the delete-expression of the object to be deleted is different from the dynamic type and the destructor is not virtual the size might be incorrect, but that case is already undefined; see 5.3.5 [expr.delete].

[Drafting notes: No change is required for 10.3 [class.virtual] paragraph 7 because “the type of the pointer” includes the pointed-to type. No change is required for 12.5 [class.free] paragraph 4 because “...used to deallocate a class object whose static type...” already refers to the object (and not the operand expression).]

353. Is deallocation routine called if destructor throws exception in delete?

[Voted into WP at April 2003 meeting.]

In a couple of comp.std.c++ threads, people have asked whether the Standard guarantees that the deallocation function will be called in a delete-expression if the destructor throws an exception. Most/all people have expressed the opinion that the deallocation function must be called in this case, although no one has been able to cite wording in the Standard supporting that view.

#include <new.h>
#include <stdio.h>
#include <stdlib.h>

static int flag = 0;

inline 
void operator delete(void* p) throw() 
{
   if (flag)
        printf("in deallocation function\n");
   free(p);
}

struct S {
    ~S() { throw 0; }
};

void f() {
    try {
        delete new S;
    }
    catch(...) { }
}

int main() {
       flag=1;
       f();
       flag=0;
       return 0;
}

Proposed resolution (October 2002):

Add to 5.3.5 [expr.delete] paragraph 7 the highlighted text:

The delete-expression will call a deallocation function (3.7.4.2 [basic.stc.dynamic.deallocation]) [Note: The deallocation function is called regardless of whether the destructor for the object or some element of the array throws an exception. ]

442. Incorrect use of null pointer constant in description of delete operator

[Voted into WP at October 2005 meeting.]

After some discussion in comp.lang.c++.moderated we came to the conclusion that there seems to be a defect in 5.3.5 [expr.delete]/4, which says:

The cast-expression in a delete-expression shall be evaluated exactly once. If the delete-expression calls the implementation deallocation function (3.7.3.2), and if the operand of the delete expression is not the null pointer constant, the deallocation function will deallocate the storage referenced by the pointer thus rendering the pointer invalid. [Note: the value of a pointer that refers to deallocated storage is indeterminate. ]

In the second sentence, the term "null pointer constant" should be changed to "null pointer". In its present form, the passage claims that the deallocation function will deallocate the storage refered to by a null pointer that did not come from a null pointer constant in the delete expression. Besides, how can the null pointer constant be the operand of a delete expression, as "delete 0" is an error because delete requires a pointer type or a class type having a single conversion function to a pointer type?

See also issue 348.

Proposed resolution:

Change the indicated sentence of 5.3.5 [expr.delete] paragraph 4 as follows:

If the delete-expression calls the implementation deallocation function (3.7.4.2 [basic.stc.dynamic.deallocation]), and if the value of the operand of the delete expression is not the a null pointer constant, the deallocation function will deallocate the storage referenced by the pointer thus rendering the pointer invalid.

Notes from October 2004 meeting:

This wording is superseded by, and this issue will be resolved by, the resolution of issue 348.

Proposed resolution (April, 2005):

This issue is resolved by the resolution of issue 348.

659. Alignment of function types