On Tue, Apr 28, 2020, 20:11 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
>
>
One is the name of a function, one is the name the current function, both
of which are useful.
Note that the name of a function is both insufficient and unnecessary once
we get reflection. Using names to reflect on function is brittle over time,
unless we can also reflect on overload sets, which also hardly works as
overload sets can mutate within a single translation unit.

source_location attempst to fight hyrum's law by being purposefully
unspecific about any of its value including the function name such that an
implementation could change these values over time.

In the more general case, I think we should be very careful about what
flexibility will be lost with reflection.
In particular I think mangling concerns, etc should never appear in the
strings returned by the reflection APIs.
I have expressed in the past my concerns over the ability to reflect on
parameters names.

So, I think that given source_location and the reflection API, we have
enough to better support the things people might have been trying to use
__func__ for (logging or a poor person's reflection facility)

I am generally unsympathetic with C compatibility concerns as this is
unlikely to be use at API boundaries.

So at the very least, I think both these issues have a very low priority,
and in particular should not take precedence over any reflection work.

Just my two cents!

Corentin

>
> 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
>