Hello EWG and Reflection,

We looked at CWG1962 <http://wg21.link/CWG1962> and CWG2362
<http://wg21.link/CWG2362> during our telecon (notes here
<http://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020>).
We agree that there's a language issue.

Using the details below, I'd like y'all to consider: *do we want to fix
this issue, or leave it as-is because better mechanisms will eventually
lead us to deprecate __func__?*

Richard summarized both issues thusly: 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).

Consulting with Hana, it indeed seems like Reflection
<http://wg21.link/P1240> can replace __func__:

namespace std::meta {
  consteval auto name_of(info entity)->std::string {...};
  consteval auto display_name_of(info entity)->std::string {...};
}
consteval auto current_function()->info {...}


Further, Hana points out that C++20 has the following:

std::source_location::function_name


Cherry on top: I don't think WG14 will adopt either of these soon. If we
deprecate __func__ we're creating extra divergence between C and C++.

Given these facts: do we want to spend time fixing __func__, or do we want
to leave it alone?

Thanks,

JF