Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CWG1962 Type of __func__ #1375

Open
jfbastien opened this issue Nov 24, 2022 · 0 comments
Open

CWG1962 Type of __func__ #1375

jfbastien opened this issue Nov 24, 2022 · 0 comments
Labels
EWG Evolution needs-revision Paper needs changes before it can proceed

Comments

@jfbastien
Copy link
Collaborator

jfbastien commented Nov 24, 2022

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.

@jfbastien jfbastien added EWG Evolution needs-revision Paper needs changes before it can proceed labels Nov 24, 2022
@jensmaurer jensmaurer added this to the 2023-telecon milestone Jan 25, 2023
@jensmaurer jensmaurer removed this from the 2023-telecon milestone Mar 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
EWG Evolution needs-revision Paper needs changes before it can proceed
Projects
None yet
Development

No branches or pull requests

2 participants