C99 Compatibility : __func__ and predeclared identifiers

1. Intent

This feature is used capture function names as string literals, to assist diagnostic libraries. This small change seems preferable to changing the preprocessor to provide equivalent functionality, educating it to parse function definitions in along the way.

Although it would seem expensive to introduce a string literal for every function, it should be relatively simple to optimise the literal away in the majority of cases where the function never refers to it. Likewise the proposal mandates that the literal is simply the unqualified name of the function, so overload sets could all share the same representation of the literal.

In writing up the proposal the format of the literal has been deliberately specified, as an implementation defined string is less helpful in when trying to write a portable diagnostic library facility. The unadorned function name seems the least controversial representation. It is the lowest common denominator and has the benefit of being the same format as would be emitted by a C99 compiler. Awkward cases such as constuctors, destructors and conversion operators are addressed explicitly.

It would be quite possible for vendors to offer additional predefined identifiers using similarly reserved names (eg using double underscores) This would allow vendors to supply more information about the signature if they preferred, namespace or class idenfiers etc. While such extensions would be conforming, they are not a required by for this proposal.

The final point of note is that the library text for the C99 assert macro was updated to require the value of __func__, as will as __FILE__ and __LINE__. As C++ includes the C90 standard and C99 standard library by reference no further changes are necessary.

2. Proposed wording

Add a new paragraph after 3.3.1 basic.scope.pdecl paragraph 7:

The point of declaration for a function-local predefined variable (8.4 dcl.fct.def) is immediately before the function-body of a function definition.

The potential scope of a function parameter name or of a function-local predefined variable in a function definition (8.4 dcl.fct.def) begins at its point of declaration. If the function has a function-try-block the potential scope of a parameter or function-local predefined variable ends at the end of the last associated handler, else it ends at the end of the outermost block of the function definition. ...

In the function-body, the function-local predefined variable __func__ denotes a local object of static storage duration as if a definition of the form

static const char __func__[] = "simple-function-name";

had been provided, where simple-function-name is the simple name of the function as specified below. [ Footnote: Implementations are encouraged to provide additional predefined variables with names that are reserved to the implementation (17.4.3.1.2 global.names), for example a function-local predefined variable that reflects a function's signature (1.3.11 defns.signature). If a predefined variable is not used, its string value should not be present in the program image. ] [ Note: The name __func__ is in scope throughout the function-body (3.3.2 basic.scope.local), because a user-declared entity cannot have the same name (17.4.3.1.2 global.names). ]

• The simple name of a function is the simple name of its declarator-id.
• The simple name of a declarator-id is the simple name of its unqualified-id.
• The simple name of an identifier is that identifier.
• The simple name of an operator-function-id is that operator-function-id with intervening white-space removed.
• The simple name of a simple-template-id is the simple name of its template-name.
• The simple name of an unqualified-id that is of the form ~ class-name is the simple name of that class-name, prefixed by "~". [ Note: The class-name, in turn, is an identifier or a simple-template-id. ]
• The simple name of a template-id is the simple name of its simple-template-id or of its operator-function-id.
• The simple name of a conversion-function-id is the string literal "conversion operator"

The simple-function-name is encoded as if the definition had been written in the source character set and then translated into the execution character set as specified by translation phase 5 (2.1 lex.phases).

[ Example:

namespace N { void f(); }
void N::f() { }                 // __func__ is "f"

struct S {
  S() : s(__func__) { }         // ok, s points to "S"
  ~S() { }                      // __func__ is "~S"
  operator int() { }            // __func__ is "conversion operator"
  template<class T> int g();
  const char *s;
};
S operator +(S,S) { }           // __func__ is "operator+"
template<> int S::g<int>() { }  // __func__ is "g"

]