On Tue, Apr 28, 2020 at 1:46 PM Gabriel Dos Reis <gdr_at_[hidden]> wrote:

> Leave it alone.
>

Can you please provide a rationale for your position?



> -- Gaby
> ------------------------------
> *From:* Ext <ext-bounces_at_[hidden]> on behalf of JF Bastien via
> Ext <ext_at_[hidden]>
> *Sent:* Tuesday, April 28, 2020 11:10:02 AM
> *To:* Evolution Working Group mailing list <ext_at_[hidden]>;
> sg7_at_[hidden] <sg7_at_[hidden]>
> *Cc:* JF Bastien <cxx_at_[hidden]>
> *Subject:* [isocpp-ext] CWG1962+CWG2362 type of __func__ / __func__
> should be constexpr
>
> Hello EWG and Reflection,
>
> We looked at CWG1962
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2FCWG1962&data=02%7C01%7Cgdr%40microsoft.com%7C6fa50edb57a242ec13fb08d7eb9f704f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637236942331277397&sdata=sMH9qHFT%2BRN%2FZY8uvWWYx6WtWTmQlmapyxeN3aF4DdE%3D&reserved=0> and
> CWG2362
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2FCWG2362&data=02%7C01%7Cgdr%40microsoft.com%7C6fa50edb57a242ec13fb08d7eb9f704f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637236942331277397&sdata=J7Kqt0JplzN9A5FFXK5jOMni7hl4S2VJ3iQyfkMKP1o%3D&reserved=0>
> during our telecon (notes here
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.edg.com%2Fbin%2Fview%2FWg21summer2020%2FEWG-IssueProcessing-23-Apr-2020&data=02%7C01%7Cgdr%40microsoft.com%7C6fa50edb57a242ec13fb08d7eb9f704f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637236942331287357&sdata=58%2F9dSrCmy%2FSyzFLliuDPDA02%2FJQj4MSNA4GoII3Iu8%3D&reserved=0>).
> 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
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2FP1240&data=02%7C01%7Cgdr%40microsoft.com%7C6fa50edb57a242ec13fb08d7eb9f704f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637236942331287357&sdata=xzMtVqaRCp8O%2BwO3MBbp7EnEe9%2F8IQNtfd5%2Bn%2BKVxJA%3D&reserved=0>
> 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
>
>
>