You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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
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.
The text was updated successfully, but these errors were encountered: