Skip to content

CWG1962 Type of __func__ #1375

@jfbastien

Description

@jfbastien

Migrating from https://isocpp.org/files/papers/P1018R18.html#issues
CWG1962

Section: 9.5.1 [dcl.fct.def.general] Status: extension Submitter: Steve Clamage Date: 2014-07-04
Two questions have arisen regarding the treatment of the type of the func built-in variable. First, some implementations accept

  void f() {
    typedef decltype(__func__) T;
    T x = __func__;
  }

even though T is specified to be an array type.

In a related question, it was noted that func is implicitly required to be unique in each function, and that not only the value but the type of func are implementation-defined; e.g., in something like

  inline auto f() { return &__func__; }

the function type is implementation-specific. These concerns could be addressed by making the value a prvalue of type const char* instead of an array lvalue.

Notes from the May, 2015 meeting:

CWG agreed with the suggested direction.

Rationale (November, 2018):

See also issue 2362, which asks for the ability to use func in a constexpr function. These two goals are incompatible, so EWG input is requested.

The deep question here is about func and the ODR. Does EWG want implementations to somehow behave as if func is the same in all copies of an inline function (in which case it can have an array type and be usable in constant expressions, but the demangling algorithm used to construct it becomes part of the ABI), or does EWG want implementations to behave as if func may differ between copies, so is in effect not known until runtime (in which case it must have either pointer or incomplete array type, and its value is not usable in constant expressions -- but its address could still be usable).

Note: C++20 has std::source_location::function_name.

Meeting: (notes 2020-04-23) We should discuss this with WG14. This is indeed a language issue. No objection to unanimous consent. We’ll need a paper, potentially considering what Reflection could do, JF brought it up on the mailing list.

We probably need a paper to disentangle this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    EWGEvolutionneeds-revisionPaper needs changes before it can proceed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions