On 4/28/2020 4:46 PM, Gabriel Dos Reis via Ext wrote:
> Leave it alone.

+1

Stability/compatibility is a major feature.


>
> -- 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
>
>
>
> _______________________________________________
> 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/13425.php