On Tue, Apr 28, 2020 at 2:21 PM Keane, Erich via Ext
<ext_at_[hidden]> wrote:
>
> By my reading of the C11 spec (latest I have), I would say it is only saying that what assert prints is consistent with __func__, not that it need be implemented in terms of:
>
> “the assert macro writes information about the particular call that
> failed (including the text of the argument, the name of the source file, the source line
> number, and the name of the enclosing function — the latter are respectively the values of
> the preprocessing macros _ _FILE_ _ and _ _LINE_ _ and of the identifier
> _ _func_ _) on the standard error stream in an implementation-defined format.”
>
> I would be in preference of deprecation of __func__, it’s the wrong kind of magic for the language, and now that there is a good replacement, I don’t see reason to keep it around.

Given that __func__ appears in header files that are shared between C
and C++, I would be opposed to deprecating __func__ as this makes
mixed-language programming needlessly harder.

~Aaron

>
>
>
> From: Ext <ext-bounces_at_[hidden]> On Behalf Of Alisdair Meredith via Ext
> Sent: Tuesday, April 28, 2020 11:14 AM
> To: Evolution Working Group mailing list <ext_at_[hidden]>
> Cc: Alisdair Meredith <alisdairm_at_[hidden]>; sg7_at_[hidden]
> Subject: Re: [isocpp-ext] CWG1962+CWG2362 type of __func__ / __func__ should be constexpr
>
>
>
> Note that the C99 definition of the ‘assert’ macro also uses __func__.
>
>
>
> Hopefully we can deprecate <cassert> in favor of the eventual output of
>
> SG21, but we should consider the impact on this macro of deprecation
>
> in the meantime. Perhaps we provide a C++ specific definition that no
>
> longer relies on ‘__func”__’?
>
>
>
> AlisdairM
>
>
>
> On Apr 28, 2020, at 19:10, JF Bastien via Ext <ext_at_[hidden]> wrote:
>
>
>
> Hello EWG and Reflection,
>
>
>
> We looked at CWG1962 and CWG2362 during our telecon (notes here). 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 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
>
>
>
> _______________________________________________
> 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/13419.php