Do Destructors Have Names According To The Standard?

Question

Do class destructors have names in the pedantic sense according to the Standard?

Recall that constructors explicitly do not have names:

12.1.1 :

Constructors do not have names. A special declarator syntax using an optional sequence of function-specifiers (7.1.2) followed by the constructor’s class name followed by a parameter list is used to declare or define the constructor. In such a declaration, optional parentheses around the constructor class name are ignored.

The Standard does not explicitly state that destructors do or do not have names, but there are many references to how to refer to and declare a destructor using special language, none of which refer directly to the destructor's name. The issue seems to be skirted around in various places:

12.4.1:

A special declarator syntax using an optional function-specifier (7.1.2) followed by ~ followed by the destructor’s class name followed by an empty parameter list is used to declare the destructor in a class definition.

5.2.4.1:

The use of a pseudo-destructor-name after a dot . or arrow -> operator represents the destructor for the non-class type named by type-name. The result shall only be used as the operand for the function call operator (), and the result of such a call has type void. The only effect is the evaluation of the postfix-expression before the dot or arrow.

12.4.12 :

In an explicit destructor call, the destructor name appears as a ~ followed by a type-name that names the destructor’s class type. The invocation of a destructor is subject to the usual rules for member functions (9.3), that is, if the object is not of the destructor’s class type and not of a class derived from the destructor’s class type, the program has undefined behavior (except that invoking delete on a null pointer has no effect).

This last case (12.4.12) seems to be the most direct reference to the destructor's name, but it still avoids saying that the destructor has a name, and is quite ambigious about this. 12.4.12 could be interpreted as "blah is the destructor's name" or as "destructors don't have names, but you can refer to the destructor as blah."

So, do destructors have names or not?

Answer 1

Your question doesn't really make a lot of sense. What do you mean by a 'name'? If you're going to go pedantic definitions are important.

Answer 2

First of all, the Standard is ambivalent on the use of "name", i think. First, it says (added the other forms of names below, as corrected by the C++0x draft)

A name is a use of an identifier (2.11), operator-function-id (13.5), conversion-function-id (12.3.2), or template-id (14.2) that denotes an entity or label (6.6.4, 6.1).

Then in parts of the Standard it uses "name" as if it would contain qualifier portions like foo::bar. And in other parts, it excludes such portions from a "name". One paragraph even says that a name prefixed by :: refers to a global name. But in our example, bar was prefixed by such a token, even though its intentionally not referring to a global name.

The construct in our example is not a name, i think, but rather two names, one qualifying the other. A destructor is referenced by the construct ~ class-name (see 3.4.5/3 and 3.4.3/6). Such a construct consists of a ~ token and a name, refering to the constructor's class. It's conventional to call it the destructor's "name" (just like the Standard at 3.4.3.1/2 talks about a "constructor name") - but pedantically, it isn't a name.

So, if you are pedantical, you would say that a destructor does not have an own name, but rather special mechanisms are used for referring to it. Likewise for constructors, special constructs are used to refer to them (otherwise, you couldn't declare a constructor out of class - the declaration has to refer to it!). And in C++0x using declarations have to be able to refer to them too, using the special constructs provided (see 3.4.3.1/2 for how you can refer to a constructor).

The destructor lookup is quite convoluted, and has quite a few bugs in the Standard. See this issue report for further details.