Maybe I missed it or maybe it is too obvious, but I didn't see any
discussion about how these issues with __func__ do or don't apply to
std::source_location::current().function_name(), which is usable in
constexpr context. While __func__ being an array is its own unique problem,
as far as I can see, the other issues discussed seem to apply just as much
to the modern version. For example is this function expected to return the
same pointer value in every TU?

constexpr const char* foo() { return
std::source_location::current().function_name(); }

How does that ODR issue differ from the __func__ one?

While I know there are cases where __func__ and source_location mean
different things (auto tricky() {return [](const char* name =
DUNDERFUNC_OR_SRCLOC_FUNC_NAME) { return name; };}), it seems like a
reasonable rule of thumb would be to have it behave like either __FILE__ or
source_location wherever possible, rather than having a third, different
behavior.

Tangential note: should we be specifying the storage duration of the NTBSs
in source_location, or is that implicit due to some other rule:
http://eel.is/c++draft/support.srcloc#class-2. I assume the intention is
that they are static storage duration.

On Tue, Apr 28, 2020 at 8:11 PM JF Bastien via Ext <ext_at_[hidden]>
wrote:

> 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
>
>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2020/04/13417.php
>