Document number:  J16/06-0195 = WG21 N2125
Date:  2006-11-05
Project:  Programming Language C++
Reference:  ISO/IEC IS 14882:2003
Reply to:  William M. Miller
 Edison Design Group, Inc.
 wmm@edg.com


C++ Standard Core Language Active Issues, Revision 44


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

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

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

Issues represent potential defects in the ISO/IEC IS 14882:2003 document and corrected defects in the earlier ISO/IEC 14882:1998 document; they are not necessarily formal ISO Defect Reports (DRs). While some issues will eventually be elevated to DR status, others will be disposed of in other ways. (See Issue Status below.)

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

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


Revision History

Issue status

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

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

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

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

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

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

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

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

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

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

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

Issues with "Ready" Status

357. Definition of signature should include name

Section: 1.3.10  defns.signature     Status: ready     Submitter: Steve Clamage     Date: 26 May 2002

Section 1.3.10  defns.signature, 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.4.3.1.2  lib.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.5.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.10  defns.signature with the following:

    2. 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.5.1  temp.over.link as follows:

    3. 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.10  defns.signature. The names of the template parameters are significant...

(See also issue 537.)



537. Definition of “signature”

Section: 1.3.10  defns.signature     Status: ready     Submitter: Daveed Vandevoorde     Date: 12 October 2005

The standard defines “signature” in two places: 1.3.10  defns.signature and 14.5.5.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.10  defns.signature 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.10  defns.signature the definition states that “Function signatures do not include return type, because that does not participate in overload resolution,” while 14.5.5.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.5.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.



218. Specification of Koenig lookup

Section: 3.4.2  basic.lookup.argdep     Status: ready     Submitter: Hyman Rosen     Date: 28 Mar 2000

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:

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.4  class.friend).
    • All names except those of (possibly overloaded) functions and function templates are ignored.
      •



520. Old-style casts between incomplete class types

Section: 5.4  expr.cast     Status: ready     Submitter: comp.std.c++     Date: 19 May 2005

5.4  expr.cast paragraph 6 says,

The operand of a cast using the cast notation can be an rvalue of type “pointer to incomplete class type”. The destination type of a cast using the cast notation can be “pointer to incomplete class type”. In such cases, even if there is a inheritance relationship between the source and destination classes, whether the static_cast or reinterpret_cast interpretation is used is unspecified.

The wording seems to allow the following:

  1. casting from void pointer to incomplete type

    2.     struct A;
    struct B;

    void *v;
    A *a = (A*)v; // allowed to choose reinterpret_cast

  2. variant application of static or reinterpret casting

    3.     B *b = (B*)a;    // compiler can choose static_cast here
    A *aa = (A*)b;   // compiler can choose reinterpret_cast here
    assert(aa == a); // might not hold

  3. ability to somehow choose static_cast

    4. It's not entirely clear how a compiler can choose static_cast as 5.4  expr.cast paragraph 6 seems to allow. I believe the intent of 5.4  expr.cast paragraph 6 is to force the use of reinterpret_cast when either are incomplete class types and static_cast iff the compiler knows both types and there is a non-ambiguous hierarchy-traversal between that cast (or maybe not, core issue 242 talks about this). I cannot see any other interpretation because it isn't intuitive, every compiler I've tried agrees with me, and neither standard pointer conversions (4.10  conv.ptr paragraph 3) nor static_cast (5.2.9  expr.static.cast paragraph 5) talk about incomplete class types. If the committee agrees with me, I would like to see 4.10  conv.ptr paragraph 3 and 5.2.9  expr.static.cast paragraph 5 explicitly disallow incomplete class types and the wording of 5.4  expr.cast paragraph 6 changed to not allow any other interpretation.

Proposed resolution (April, 2006):

Change 5.4  expr.cast paragraph 6 as indicated:

The operand of a cast using the cast notation can be an rvalue of type “pointer to incomplete class type.” The destination type of a cast using the cast notation can be “pointer to incomplete class type.” In such cases, even if there is a inheritance relationship between the source and destination classes, whether the static_cast or reinterpret_cast interpretation is used is unspecified. If both the operand and destination types are class types and one or both are incomplete, it is unspecified whether the static_cast or the reinterpret_cast interpretation is used, even if there is an inheritance relationship between the two classes. [Note: For example, if the classes were defined later in the translation unit, a multi-pass compiler would be permitted to interpret a cast between pointers to the classes as if the class types were complete at that point. —end note]


397. Same address for string literals from default arguments in inline functions?

Section: 7.1.2  dcl.fct.spec     Status: ready     Submitter: Mark Mitchell     Date: 13 Jan 2003

Are string literals from default arguments used in extern inlines supposed to have the same addresses across all translation units?

  void f(const char* = "s")
  inline g() {
    f();
  }

Must the "s" strings be the same in all copies of the inline function?

Steve Adamczyk: The totality of the standard's wisdom on this topic is (7.1.2  dcl.fct.spec paragraph 4):

A string literal in an extern inline function is the same object in different translation units.

I'd hazard a guess that a literal in a default argument expression is not "in" the extern inline function (it doesn't appear in the tokens of the function), and therefore it need not be the same in different translation units.

I don't know that users would expect such strings to have the same address, and an equally valid (and incompatible) expectation would be that the same string literal would be used for every expansion of a given default argument in a single translation unit.

Notes from April 2003 meeting:

The core working group feels that the address of a string literal should be guaranteed to be the same only if it actually appears textually within the body of the inline function. So a string in a default argument expression in a block extern declaration inside the body of a function would be the same in all instances of the function. On the other hand, a string in a default argument expression in the header of the function (i.e., outside of the body) would not be the same.

Proposed resolution (April 2003):

Change the last sentence and add the note to the end of 7.1.2  dcl.fct.spec paragraph 4:

A string literal in the body of an extern inline function is the same object in different translation units. [Note: A string literal that is encountered only in the context of a function call (in the default argument expression of the called function), is not “in” the extern inline function.]

Notes from October 2003 meeting:

We discussed ctor-initializer lists and decided that they are also part of the body. We've asked Clark Nelson to work on syntax changes to give us a syntax term for the body of a function so we can refer to it here. See also issue 452, which could use this term.

(October, 2005: moved to “review” status in concert with issue 452. With that resolution, the wording above needs no further changes.)

Proposed resolution (April, 2006):

Change the last sentence and add the note to the end of 7.1.2  dcl.fct.spec paragraph 4:

A string literal in the body of an extern inline function is the same object in different translation units. [Note: A string literal appearing in a default argument expression is not considered to be “in the body” of an inline function merely by virtue of the expression’s use in a function call from that inline function. —end note]


491. Initializers for empty-class aggregrate members

Section: 8.5.1  dcl.init.aggr     Status: ready     Submitter: Nathan Sidwell     Date: 15 Dec 2004

The current wording of 8.5.1  dcl.init.aggr paragraph 8 requires that

An initializer for an aggregate member that is an empty class shall have the form of an empty initializer-list {}.

This is overly constraining. There is no reason that the following should be ill-formed:

    struct S { };
    S s;
    S arr[1] = { s };

Mike Miller: The wording of 8.5.1  dcl.init.aggr paragraph 8 is unclear. “An aggregate member” would most naturally mean “a member of an aggregate.” In context, however, I think it must mean “a member [of an aggregate] that is an aggregate”, that is, a subaggregate. Members of aggregates need not themselves be aggregates (cf paragraph 13 and 12.6.1  class.expl.init); it cannot be the case that an object of an empty class with a user-declared constructor must be initialized with {} when it is a member of an aggregate. This wording should be clarified, regardless of the decision on Nathan's point.

Proposed resolution (October, 2005):

This issue is resolved by the resolution of issue 413.



327. Use of "structure" without definition

Section: 9  class     Status: ready     Submitter: James Kanze     Date: 9 Dec 2001

In 9  class paragraph 4, the first sentence says "A structure is a class definition defined with the class-key struct". As far as I know, there is no such thing as a structure in C++; it certainly isn't listed as one of the possible compound types in 3.9.2  basic.compound. And defining structures opens the question of whether a forward declaration is a structure or not. The parallel here with union (which follows immediately) suggests that structures and classes are really different things, since the same wording is used, and classes and unions do have some real differences, which manifest themselves outside of the definition. It also suggests that since one can't forward declare union with class and vice versa, the same should hold for struct and class -- I believe that the intent was that one could use struct and class interchangeably in forward declaration.

Suggested resolution:

I suggest something like the following:

If a class is defined with the class-key class, its members and base classes are private by default. If a class is defined with the class-key struct, its members and base classes are public by default. If a class is defined with the class-key union, its members are public by default, and it holds only one data member at a time. Such classes are called unions, and obey a number of additional restrictions, see 9.5  class.union.

Proposed resolution (April, 2006):

This issue is resolved by the resolution of issue 538.



413. Definition of "empty class"

Section: 9  class     Status: ready     Submitter: Pete Becker     Date: 30 Apr 2003

The proposal says that value is true if "T is an empty class (10)". Clause 10 doesn't define an empty class, although it has a note that says a base class may "be of zero size (clause 9)" 9/3 says "Complete objects and member subobjects of class type shall have nonzero size." This has a footnote, which says "Base class subobjects are not so constrained."

The standard uses the term "empty class" in two places (8.5.1  dcl.init.aggr), but neither of those places defines it. It's also listed in the index, which refers to the page that opens clause 9, i.e. the nonzero size stuff cited above.

So, what's the definition of "empty class" that determines whether the predicate is_empty is true?

The one place where it's used is 8.5.1  dcl.init.aggr paragraph 8, which says (roughly paraphrased) that an aggregate initializer for an empty class must be "{}", and when such an initializer is used for an aggregate that is not an empty class the members are default-initialized. In this context it's pretty clear what's meant. In the type traits proposal it's not as clear, and it was probably intended to have a different meaning. The boost implementation, after it eliminates non-class types, determines whether the trait is true by comparing the size of a class derived from T to the size of an otherwise-identical class that is not derived from T.

Howard Hinnant: is_empty was created to find out whether a type could be derived from and have the empty base class optimization successfully applied. It was created in part to support compressed_pair which attempts to optimize away the space for one of its members in an attempt to reduce spatial overhead. An example use is:

  template <class T, class Compare = std::less<T> >
  class SortedVec
  {
  public:
  ...
  private:
    T* data_;
    compressed_pair<Compare, size_type> comp_;

    Compare&       comp()       {return comp_.first();}
    const Compare& comp() const {return comp_.first();}
    size_type&     sz()         {return comp_.second();}
    size_type      sz() const   {return comp_.second();}
  };

Here the compare function is optimized away via the empty base optimization if Compare turns out to be an "empty" class. If Compare turns out to be a non-empty class, or a function pointer, the space is not optimized away. is_empty is key to making this work.

This work built on Nathan's article: http://www.cantrip.org/emptyopt.html.

Clark Nelson: I've been looking at issue 413, and I've reached the conclusion that there are two different kinds of empty class. A class containing only one or more anonymous bit-field members is empty for purposes of aggregate initialization, but not (necessarily) empty for purposes of empty base-class optimization.

Of course we need to add a definition of emptiness for purposes of aggregate initialization. Beyond that, there are a couple of questions:

  1. Should the definition of emptiness used by the is_empty predicate be defined in a language clause or a library clause?
  2. Do we need to open a new core issue pointing out the fact that the section on aggregate initialization does not currently say that unnamed bit-fields are skipped?

Notes from the October, 2005 meeting:

There are only two places in the Standard where the phrase “empty class” appears, both in 8.5.1  dcl.init.aggr paragraph 8. Because it is not clear whether the definition of “empty for initialization purposes” is suitable for use in defining the is_empty predicate, it would be better just to avoid using the phrase in the language clauses. The requirements of 8.5.1  dcl.init.aggr paragraph 8 appear to be redundant; paragraph 6 says that an initializer-list must have no more initializers than the number of elements to initialize, so an empty class already requires an empty initializer-list, and using an empty initializer-list with a non-empty class is covered adequately by paragraph 7's description of the handling of an initializer-list with fewer initializers than the number of members to initialize.

Proposed resolution (October, 2005):

  1. Change 8.5.1  dcl.init.aggr paragraph 5 by inserting the indicated text:

    2. Static data members and anonymous bit fields are not considered members of the class for purposes of aggregate initialization. [Example: 

        struct A {
        int i;
        static int s;
        int j;
        int :17;
        int k;
    } a = { 1 , 2 , 3 };

    Here, the second initializer 2 initializes a.j and not the static data member A::s, and the third initializer 3 initializes a.k and not the padding before it. —end example]

  2. Delete 8.5.1  dcl.init.aggr paragraph 8:

    3. An initializer for an aggregate member that is an empty class shall have the form of an empty initializer-list {}. [Example: 

        struct S { };
    struct A {
        S s;
        int i;
    } a = { { } , 3 };

    —end example] An empty initializer-list can be used to initialize any aggregate. If the aggregate is not an empty class, then each member of the aggregate shall be initialized with a value of the form T() (5.2.3  expr.type.conv), where T represents the type of the uninitialized member.

This resolution also resolves issue 491.

Additional note (October, 2005):

Deleting 8.5.1  dcl.init.aggr paragraph 8 altogether may not be a good idea. It would appear that, in its absence, the initializer elision rules of paragraph 11 would allow the initializer for a in the preceding example to be written { 3 } (because the empty-class member s would consume no initializers from the list).

Proposed resolution (October, 2006):

(Drafting note: this resolution also cleans up incorrect references to syntactic non-terminals in the nearby paragraphs.)

  1. Change 8.5.1  dcl.init.aggr paragraph 4 as indicated:

    An array of unknown size initialized with a brace-enclosed initializer-list containing n initializers initializer-clauses, where n shall be greater than zero... An empty initializer list {} shall not be used as the initializer initializer-clause for an array of unknown bound.

  2. Change 8.5.1  dcl.init.aggr paragraph 5 by inserting the indicated text:

    Static data members and anonymous bit fields are not considered members of the class for purposes of aggregate initialization. [Example: 

        struct A {
        int i;
        static int s;
        int j;
        int :17;
        int k;
    } a = { 1 , 2 , 3 };

    Here, the second initializer 2 initializes a.j and not the static data member A::s, and the third initializer 3 initializes a.k and not the anonymous bit field before it. —end example]

  3. Change 8.5.1  dcl.init.aggr paragraph 6 as indicated:

    An initializer-list is ill-formed if the number of initializers initializer-clauses exceeds the number of members...

  4. Change 8.5.1  dcl.init.aggr paragraph 7 as indicated:

    If there are fewer initializers initializer-clauses in the list than there are members...

  5. Replace 8.5.1  dcl.init.aggr paragraph 8:

    An initializer for an aggregate member that is an empty class shall have the form of an empty initializer-list {}. [Example: 

        struct S { };
    struct A {
        S s;
        int i;
    } a = { { } , 3 };

    —end example] An empty initializer-list can be used to initialize any aggregate. If the aggregate is not an empty class, then each member of the aggregate shall be initialized with a value of the form T() (5.2.3  expr.type.conv), where T represents the type of the uninitialized member.

    with:

    If an aggregate class C contains a subaggregate member m that has no members for purposes of aggregate initialization, the initializer-clause for m shall not be omitted from an initializer-list for an object of type C unless the initializer-clauses for all members of C following m are also omitted. [Example: 

        struct S { } s;
    struct A {
        S s1;
        int i1;
        S s2;
        int i2;
        S s3;
        int i3;
    } a = {
        { },   // Required initialization
        0,
        s,     // Required initialization
        0
    };         // Initialization not required for A::s3 because A::i3 is also not initialized

    —end example]

  6. Change 8.5.1  dcl.init.aggr paragraph 10 as indicated:

    When initializing a multi-dimensional array, the initializers initializer-clauses initialize the elements...

  7. Change 8.5.1  dcl.init.aggr paragraph 11 as indicated:

    Braces can be elided in an initializer-list as follows. If the initializer-list begins with a left brace, then the succeeding comma-separated list of initializers initializer-clauses initializes the members of a subaggregate; it is erroneous for there to be more initializers initializer-clauses than members. If, however, the initializer-list for a subaggregate does not begin with a left brace, then only enough initializers initializer-clauses from the list are taken to initialize the members of the subaggregate; any remaining initializers initializer-clauses are left to initialize the next member of the aggregate of which the current subaggregate is a member. [Example:...

  8. Change 8.5.1  dcl.init.aggr paragraph 12 as indicated:

    All implicit type conversions (clause 4  conv) are considered when initializing the aggregate member with an initializer from an initializer-list assignment-expression. If the initializer assignment-expression can initialize a member, the member is initialized. Otherwise, if the member is itself a non-empty subaggregate, brace elision is assumed and the initializer assignment-expression is considered for the initialization of the first member of the subaggregate. [Note: As specified above, brace elision cannot apply to subaggregates with no members for purposes of aggregate initialization; an initializer-clause for the entire subobject is required. —end note] [Example:... Braces are elided around the initializer initializer-clause for b.a1.i...

  9. Change 8.5.1  dcl.init.aggr paragraph 15 as indicated:

    When a union is initialized with a brace-enclosed initializer, the braces shall only contain an initializer initializer-clause for the first member of the union...

  10. Change 8.5.1  dcl.init.aggr paragraph 16 as indicated:

    [Note: as As described above, the braces around the initializer initializer-clause for a union member can be omitted if the union is a member of another aggregate. —end note]

(Note: this resolution also resolves issue 491.)



538. Definition and usage of structure, POD-struct, POD-union, and POD class

Section: 9  class     Status: ready     Submitter: Alisdair Meredith     Date: 10 August 2005

There are several problems with the terms defined in 9  class paragraph 4:

A structure is a class defined with the class-key struct; its members and base classes (clause 10  class.derived) are public by default (clause 11  class.access). A union is a class defined with the class-key union; its members are public by default and it holds only one data member at a time (9.5  class.union). [Note: aggregates of class type are described in 8.5.1  dcl.init.aggr. —end note] A POD-struct is an aggregate class that has no non-static data members of type non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-declared copy assignment operator and no user-declared destructor. Similarly, a POD-union is an aggregate union that has no non-static data members of type non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-declared copy assignment operator and no user-declared destructor. A POD class is a class that is either a POD-struct or a POD-union.

  1. Although the term structure is defined here, it is used only infrequently throughout the Standard, often apparently inadvertently and consequently incorrectly:

    There does not appear to be a reason for defining the term structure. The one reference where it is arguably useful, in the note in 5.2.5  expr.ref, could be rewritten as something like, “'class objects' may be defined using the class, struct, or union class-keys; see clause 9  class.”

  2. Based on its usage later in the paragraph and elsewhere, “POD-struct” appears to be intended to exclude unions. However, the definition of “aggregate class” in 8.5.1  dcl.init.aggr paragraph 1 includes unions. Furthermore, the name itself is confusing, leading to the question of whether it was intended that only classes defined using struct could be POD-structs or if class-classes are included. The definition should probably be rewritten as, “A POD-struct is an aggregate class defined with the class-key struct or the class-key class that has no...

  3. In most references outside clause 9  class, POD-struct and POD-union are mentioned together and treated identically. These references should be changed to refer to the unified term, “POD class.”

  4. Noted in passing: 18.1  lib.support.types paragraph 4 refers to the undefined terms “POD structure” and (unhyphenated) “POD union;” the pair should be replaced by a single reference to “POD class.”

Proposed resolution (April, 2006):

  1. Change 9  class paragraph 4 as indicated:

    A structure is a class defined with the class-key struct; its members and base classes (clause 10  class.derived) are public by default (clause 11  class.access). A union is a class defined with the class-key union; its members are public by default and it holds only one data member at a time (9.5  class.union). [Note: aggregates of class type are described in 8.5.1  dcl.init.aggr. —end note] A POD-struct is an aggregate class that has no non-static data members of type non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-declared copy assignment operator and no user-declared destructor. Similarly, a POD-union is an aggregate union that has no non-static data members of type non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-declared copy assignment operator and no user-declared destructor. A POD class is a class that is either a POD-struct or a POD-union. A POD class is an aggregate class that has no non-static data members of non-POD type (or array of such a type) or reference, and has no user-declared copy assignment operator and no user-declared destructor. A POD-struct is a POD class defined with the class-key struct or the class-key class. A POD-union is a POD class defined with the class-key union.

  2. Change 11.2  class.access.base paragraph 2 as indicated:

    In the absence of an access-specifier for a base class, public is assumed when the derived class is declared defined with the class-key struct and private is assumed when the class is declared defined with the class-key class. [Example:...

  3. Delete the note in 5.2.5  expr.ref paragraph 4:

    [Note: “class objects” can be structures (9.2  class.mem) and unions (9.5  class.union). Classes are discussed in clause 9  class. —end note]

  4. Change the commentary in the example in 9.2  class.mem paragraph 11 as indicated:

    ...an integer, and two pointers to similar structures objects of the same type. Once this definition...

    ...the count member of the structure object to which sp points; s.left refers to the left subtree pointer of the structure object s; and...

  5. Change 17.1.8  defns.iostream.templates as indicated:

    ...the argument traits is a structure class which defines additional characteristics...

  6. Change 18.4  lib.support.dynamic paragraph 4 as indicated:

    If type is not a POD structure or a POD union POD class (clause 9), the results are undefined.

  7. Change the third bullet of B  limits paragraph 2 as indicated:

  8. Change the nineteenth bullet of B  limits paragraph 2 as indicated:

  9. Change the twenty-first bullet of B  limits paragraph 2 as indicated:

  10. Change C.2  diff.library paragraph 6 as indicated:

    The C++ Standard library provides 2 standard structures structs from the C library, as shown in Table 126.

  11. Change the last sentence of 3.9  basic.types paragraph 10 as indicated:

    Scalar types, POD-struct types, POD-union types POD classes (clause 9  class), arrays of such types and cv-qualified versions of these types (3.9.3  basic.type.qualifier) are collectively called POD types.

    Drafting note: Do not change 3.9  basic.types paragraph 11, because it's a note and the definition of “layout-compatible” is separate for POD-struct and POD-union in 9.2  class.mem.

(This resolution also resolves issue 327.)



215. Template parameters are not allowed in nested-name-specifiers

Section: 14.1  temp.param     Status: ready     Submitter: Martin von Loewis     Date: 13 Mar 2000

According to 14.1  temp.param paragraph 3, the following fragment is ill-formed:

    template <class T>
    class X{
      friend void T::foo();
    };

In the friend declaration, the T:: part is a nested-name-specifier (8  dcl.decl paragraph 4), and T must be a class-name or a namespace-name (5.1  expr.prim paragraph 7). However, according to 14.1  temp.param paragraph 3, it is only a type-name. The fragment should be well-formed, and instantiations of the template allowed as long as the actual template argument is a class which provides a function member foo. As a result of this defect, any usage of template parameters in nested names is ill-formed, e.g., in the example of 14.6  temp.res paragraph 2.

Notes from 04/00 meeting:

The discussion at the meeting revealed a self-contradiction in the current IS in the description of nested-name-specifiers. According to the grammar in 5.1  expr.prim paragraph 7, the components of a nested-name-specifier must be either class-names or namespace-names, i.e., the constraint is syntactic rather than semantic. On the other hand, 3.4.3  basic.lookup.qual paragraph 1 describes a semantic constraint: only object, function, and enumerator names are ignored in the lookup for the component, and the program is ill-formed if the lookup finds anything other than a class-name or namespace-name. It was generally agreed that the syntactic constraint should be eliminated, i.e., that the grammar ought to be changed not to use class-or-namespace-name.

A related point is the explicit prohibition of use of template parameters in elaborated-type-specifiers in 7.1.5.3  dcl.type.elab paragraph 2. This rule was the result of an explicit Committee decision and should not be unintentionally voided by the resolution of this issue.

Proposed resolution (04/01):

Change 5.1  expr.prim paragraph 7 and A.4  gram.expr from

to

This resolution depends on the resolutions for issues 245 (to change the name lookup rules in elaborated-type-specifiers to include all type-names) and 283 (to categorize template type-parameters as type-names).

Notes from 10/01 meeting:

There was some sentiment for going with simply identifier in front of the "::", and stronger sentiment for going with something with a more descriptive name if possible. See also issue 180.

Notes from April 2003 meeting:

This was partly resolved by the changes for issue 125. However, we also need to add a semantic check in 3.4.3  basic.lookup.qual to allow T::foo and we need to reword the first sentence of 3.4.3  basic.lookup.qual.

Proposed resolution (October, 2004):

Change 3.4.3  basic.lookup.qual paragraph 1 as follows:

The name of a class or namespace member can be referred to after the :: scope resolution operator (5.1  expr.prim) applied to a nested-name-specifier that nominates its class or namespace. During the lookup for a name preceding the :: scope resolution operator, object, function, and enumerator names are ignored. If the name found is not a class-name (clause 9  class) or namespace-name (7.3.1  namespace.def) does not designate a class or namespace, the program is ill-formed. [...]

Notes from the April, 2005 meeting:

The 10/2004 resolution does not take into account the fact that template type parameters do not designate class types in the context of the template definition. Further drafting is required.

Proposed resolution (April, 2006):

Change 3.4.3  basic.lookup.qual paragraph 1 as follows:

The name of a class or namespace member can be referred to after the :: scope resolution operator (5.1  expr.prim) applied to a nested-name-specifier that nominates its class or namespace. During the lookup for a name preceding the :: scope resolution operator, object, function, and enumerator names are ignored. If the name found is not a class-name (clause 9  class) or namespace-name (7.3.1  namespace.def) does not designate a namespace or a class or dependent type, the program is ill-formed. [...]


582. Template conversion functions

Section: 14.5.2  temp.mem     Status: ready     Submitter: PremAnand Rao     Date: 23 May 2006

The wholesale replacement of the phrase “template function” by the resolution of issue 105 seems to have overlooked the similar phrase “template conversion function.” This phrase appears a number of times in 13.3.3.1.2  over.ics.user paragraph 3, 14.5.2  temp.mem paragraphs 5-8, and 14.8.2  temp.deduct paragraph 1. It should be systematically replaced in similar fashion to the resolution of issue 105.

Proposed resolution (October, 2006):

  1. Change 13.3.3.1.2  over.ics.user paragraph 3 as follows:

    2. If the user-defined conversion is specified by a template conversion function specialization of a conversion function template, the second standard conversion sequence must have exact match rank.

  2. Change 14.5.2  temp.mem paragraph 5 as follows:

    3. A specialization of a template conversion function conversion function template is referenced in the same way as a non-template conversion function that converts to the same type.

  3. Change 14.5.2  temp.mem paragraph 6 as follows:

    4. A specialization of a template conversion function conversion function template is not found by name lookup. Instead, any template conversion functions conversion function templates visible in the context of the use are considered.

  4. Change 14.5.2  temp.mem paragraph 7 as follows:

    5. A using-declaration using-declaration in a derived class cannot refer to a specialization of a template conversion function conversion function template in a base class.

  5. Change 14.5.2  temp.mem paragraph 8 as follows:

    6. Overload resolution (13.3.3.2  over.ics.rank) and partial ordering (14.5.5.2  temp.func.order) are used to select the best conversion function among multiple template conversion functions specializations of conversion function templates and/or non-template conversion functions.

  6. Change 14.8.2.3  temp.deduct.conv paragraph 1 as follows:

    7. Template argument deduction is done by comparing the return type of the template conversion function conversion function template (call it P) with the type that is required as the result of the conversion (call it A) as described in 14.8.2.5  temp.deduct.type.


488. Local types, overload resolution, and template argument deduction

Section: 14.8.2  temp.deduct     Status: ready     Submitter: Mark Mitchell     Date: 24 Nov 2004

It is not clear how to handle the following example:

    struct S {
        template <typename T> S(const T&);
    };
    void f(const S&);
    void f(int);
    void g() {
        enum E { e };
        f(e);    // ill-formed?
    }

Three possibilities suggest themselves:

  1. Fail during overload resolution. In order to perform overload resolution for the call to f, the declaration of the required specialization of the S constructor must be instantiated. This instantiation uses a local type and is thus ill-formed (14.3.1  temp.arg.type paragraph 2), rendering the example as a whole ill-formed, as well.

  2. Treat this as a type-deduction failure. Although it is not listed currently among the causes of type-deduction failure in 14.8.2  temp.deduct paragraph 2, it could plausibly be argued that instantiating a function declaration with a local type as a template type-parameter falls under the rubric of “If a substitution in a template parameter or in the function type of the function template results in an invalid type” and thus should be a type-deduction failure. The result would be that the example is well-formed because f(const S&) would be removed from the list of viable functions.

  3. Fail only if the function selected by overload resolution requires instantiation with a local type. This approach would require that the diagnostic resulting from the instantiation of the function type during overload resolution be suppressed and either regenerated or regurgitated once overload resolution is complete. (The example would be well-formed under this approach because f(int) would be selected as the best match.)

(See also issue 489.)

Notes from the April, 2005 meeting:

The question in the original example was whether there should be an error, even though the uninstantiable template was not needed for calling the best-matching function. The broader issue is whether a user would prefer to get an error or to call a “worse” non-template function in such cases. For example:

    template<typename T> void f(T);
    void f(int);
    void g() {
        enum E { e };
        f(e);    // call f(int) or get an error?
    }

It was observed that the type deduction rules are intended to model, albeit selectively, the other rules of the language. This would argue in favor of the second approach, a type-deduction failure, and the consensus of the group was that the incremental benefit of other approaches was not enough to outweigh the additional complexity of specification and implementation.

Proposed resolution (October, 2005):

Add a new sub-bullet following bullet 3, sub-bullet 7 ("Attempting to give an invalid type to a non-type template parameter") of 14.8.2  temp.deduct paragraph 2:

Additional note (December, 2005):

The Evolution Working Group is currently considering an extension that would effectively give linkage to some (but perhaps not all) types that currently have no linkage. If the proposed resolution above is adopted and then later a change along the lines that the EWG is considering were also adopted, the result would be a silent change in the result of overload resolution, because the newly-acceptable specializations would become part of the overload set. It is not clear whether that possibility is sufficient reason to delay adoption of this resolution or not.





Issues with "Review" Status

572. Standard conversions for non-built-in types

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

4  conv paragraph 1 says,

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

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

Proposed resolution (October, 2006):

Change 4  conv paragraph 1 as follows:

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


342. Terminology: "indirection" versus "dereference"

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

Split off from issue 315.

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

Proposed resolution (October, 2006):

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

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

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

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

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

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

  4. Change Table 45 in 20.4.7.4 [lib.meta.trans.ptr] as follows:

    5. The member typedef type shall be the same as T, except any top level indirection dereferencing has been removed.

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

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



288. Misuse of "static type" in describing pointers

Section: 5.3.5  expr.delete     Status: review     Submitter: James Kuyper     Date: 19 May 2001

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

12.5  class.free paragraph 4 says that
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 (October, 2006):

  1. Change 5.3.5  expr.delete paragraph 3 as follows:

    2. In the first alternative (delete object), if the static type of the dereferenced (5.3.1  expr.unary.op) operand is different from its dynamic type, the static type shall be a base class of the dereferenced operand’s dynamic type 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:

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

    4. 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).]



569. Spurious semicolons at namespace scope should be allowed

Section: 7  dcl.dcl     Status: review     Submitter: Matt Austern     Date: 20 March 2006

The grammar in 7  dcl.dcl paragraph 1 says that a declaration-seq is either declaration or declaration-seq declaration. Some declarations end with semicolons and others (e.g. function definitions and namespace declarations) don't. This means that users who put a semicolon after every declaration are technically writing ill-formed code. The trouble is that in this respect the standard is out of sync with reality. It's convenient to allow semicolons after every declaration, and there's no implementation difficulty in doing so. All existing compilers accept this, except in extra-pedantic mode. When all implementations disagree with the standard, it's time for the standard to change.

Suggested resolution:

In the grammar in 7  dcl.dcl paragraph 11, change the second line in the definition of declaration-seq to

Proposed resolution (October, 2006):

  1. Add the indicated lines to the grammar definitions in 7  dcl.dcl paragraph 1:

    2. declaration:

    ...

    static_assert-declaration:


    empty-declaration:
      ;

  2. Add the following as a new paragraph after 7  dcl.dcl paragraph 4:

    3. An empty-declaration has no effect.


482. Qualified declarators in redeclarations

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

According to 8.3  dcl.meaning paragraph 1,

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

This restriction prohibits examples like the following:

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

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

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

Notes from the April, 2006 meeting:

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

Proposed resolution (October, 2006):

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

...An unqualified-id occurring in a declarator-id shall be a simple identifier except for the declaration of some special functions (12.3  class.conv, 12.4  class.dtor, 13.5  over.oper) and for the declaration of template specializations or partial specializations (). A declarator-id shall not be qualified except for the definition of a member function (9.3  class.mfct) or static data member (9.4  class.static) outside of its class, the definition or explicit instantiation of a function or variable member of a namespace outside of its namespace, or the definition of a previously declared explicit specialization outside of its namespace, or the declaration of a friend function that is a member of another class or namespace (11.4  class.friend). When the declarator-id is qualified, the declaration shall refer to a previously declared member of the class or namespace to which the qualifier refers, and the member shall not have been introduced by a using-declaration in the scope of the class or namespace nominated by the nested-name-specifier of the declarator-id...

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



542. Value initialization of arrays of POD-structs

Section: 12.6  class.init     Status: review     Submitter: Alisdair Meredith     Date: 27 October 2005

12.6  class.init paragraph 2 says,

When an array of class objects is initialized (either explicitly or implicitly), the constructor shall be called for each element of the array, following the subscript order;

That implies that, given

    struct POD {
      int x;
    };

    POD data[10] = {};

this should call the implicitly declared default ctor 10 times, leaving 10 uninitialized ints, rather than value initialize each member of data, resulting in 10 initialized ints (which is required by 8.5.1  dcl.init.aggr paragraph 7).

I suggest rephrasing along the lines:

When an array is initialized (either explicitly or implicitly), each element of the array shall be initialized in turn, following the subscript order;

This would allow for PODs and other classes with a dual nature under value/default initialization, and cover copy initialization for arrays too.

Proposed resolution (October, 2006):

Change 12.6  class.init paragraph 3 as follows:

When an array of class objects is initialized (either explicitly or implicitly) and the elements are initialized by constructor, the constructor shall be called for each element of the array, following the subscript order; see 8.3.4  dcl.array.


588. Searching dependent bases of classes local to function templates

Section: 14.6.2  temp.dep     Status: review     Submitter: James Widman     Date: 21 June 2006

14.6.2  temp.dep paragraph 3 reads,

In the definition of a class template or a member of a class template, if a base class of the class template depends on a template-parameter, the base class scope is not examined during unqualified name lookup either at the point of definition of the class template or member or during an instantiation of the class template or member.

This wording applies only to definitions of class templates and members of class templates. That would make the following program ill-formed (but it probably should be well-formed):

    struct B{ void f(int); };

    template<class T> struct D: B { };

    template<class T> void g() {
       struct B{ void f(); };
       struct A: D<T> {
           B m;
       };
       A a;
       a.m.f(); // Presumably, we want ::g()::B::f(), not ::B::f(int)
    }

    int main () {
       g<int>();
       return 0;
    }

I suspect the wording should be something like

In the definition of a class template or a class defined (directly or indirectly) within the scope of a class template or function template, if a base class...

That should also include deeply nested classes in templates, local classes of non-template member functions of member classes of class templates, etc.

Proposed resolution (October, 2006):

Change 14.6.2  temp.dep paragraph 3 as follows:

In the definition of a class or class template or a member of a class template, if a base class of the class template depends on a template-parameter, the base class scope is not examined during unqualified name lookup either at the point of definition of the class template or member or during an instantiation of the class template or member.


575. Criteria for deduction failure

Section: 14.8.2  temp.deduct     Status: review     Submitter: James Widman     Date: 19 April 2006

The last two sentences of 14.8.2  temp.deduct paragraph 5 read:

When all template arguments have been deduced or obtained from default template arguments, all uses of template parameters in non-deduced contexts are replaced with the corresponding deduced or default argument values. If the substitution results in an invalid type, as described above, type deduction fails.

Shouldn't the substitution occur for all uses of the parameters, so that any of them could result in deduction failure?

Proposed resolution (October, 2006):

Change 14.8.2  temp.deduct paragraph 5 as follows:

...When all template arguments have been deduced or obtained from default template arguments, all uses of template parameters in non-deduced contexts the function type are replaced with the corresponding deduced or default argument values. If the substitution results in an invalid type, as described above, type deduction fails.


499. Throwing an array of unknown size

Section: 15.1  except.throw     Status: review     Submitter: Mike Miller     Date: 19 Jan 2005

According to 15.1  except.throw paragraph 3,

The type of the throw-expression shall not be an incomplete type, or a pointer to an incomplete type other than (possibly cv-qualified) void.

This disallows cases like the following, because str has an incomplete type (an array of unknown size):

    extern const char str[];
    void f() {
        throw str;
    }

The array-to-pointer conversion is applied to the operand of throw, so there's no problem creating the exception object, which is the reason for the restriction on incomplete types. I believe this case should be permitted.

Notes from the April, 2005 meeting:

The CWG agreed that the example should be permitted. Note that the reference to throw-expression in the cited text is incorrect; a throw-expression includes the throw keyword and is always of type void. This wording problem is addressed in the proposed resolution for issue 475.

Proposed resolution (October, 2006)

Change 15.1  except.throw paragraph 3 as indicated:

...The type of the throw-expression shall not If the type of the exception object would be an incomplete type, or a pointer to an incomplete type other than (possibly cv-qualified) void the program is ill-formed...


592. Exceptions during construction of local static objects

Section: 15.2  except.ctor     Status: review     Submitter: Alisdair Meredith     Date: 30 August 2006

According to 15.2  except.ctor paragraph 2,

An object that is partially constructed or partially destroyed will have destructors executed for all of its fully constructed subobjects, that is, for subobjects for which the principal constructor (12.6.2  class.base.init) has completed execution and the destructor has not yet begun execution. Similarly, if the non-delegating constructor for an object has completed execution and a delegating constructor for that object exits with an exception, the object's destructor will be invoked. Should a constructor for an element of an automatic array throw an exception, only the constructed elements of that array will be destroyed.

The requirement for destruction of array elements explicitly applies only to automatic arrays, and one might conclude from the context that only automatic class objects are in view as well, although that is not explicitly stated. What about local static arrays and class objects? Are they intended also to be subject to the requirement that fully-constructed subobjects are to be destroyed?

Proposed resolution (October, 2006):

Change 15.2  except.ctor paragraph 2 as follows:

An object that is partially constructed or partially destroyed will have destructors executed for all of its fully constructed subobjects, that is, for subobjects for which the principal constructor (12.6.2  class.base.init) has completed execution and the destructor has not yet begun execution. Similarly, if the non-delegating constructor for an object has completed execution and a delegating constructor for that object exits with an exception, the object’s destructor will be invoked. Should a constructor for an element of an automatic array throw an exception, only the constructed elements of that array will be destroyed. If the object or array was allocated in a new-expression, the matching deallocation function (3.7.3.2  basic.stc.dynamic.deallocation, 5.3.4  expr.new, 12.5  class.free), if any, is called to free the storage occupied by the object.


533. Special treatment for C-style header names

Section: 16.2  cpp.include     Status: review     Submitter: Jens Maurer     Date: 4 October 2005

In language imported directly from the C Standard, 16.2  cpp.include paragraph 5 says,

The implementation provides unique mappings f