Thank you for explaining. So the reason is for compiped static or dynamic libraries and different versions of the API, so mostly in the realm in the implementation.   However the fix is simply within the standard to disallow taking the address.   As the positive effect of not taking the address is implementation defined (e.g. how do compiled libraries handle overload resolution in the presence of ODR violations or similar), an attribute would not be totally wrong depending on how strict the ignorability of an attribute is seen? Can only the implementation decide to ignore or not to ignore an an attribute, or should 3rd party tooling always be able to strip any attributes? As far as I understand the ignorability is only true for standard attributes, not for implementation defined attributes. So 3rd party tooling should not have the freedom to remove that attribute. So an attribute would also be okay beside a context-sensitive keyword.   -----Ursprüngliche Nachricht----- Von:Lénárd Szolnoki via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 24.03.2025 08:59 Betreff:Re: [std-proposals] Floating an idea: [[no_address]] for functions. An:std-proposals_at_[hidden]; CC:Lénárd Szolnoki <cpp_at_[hidden]>; On 24 March 2025 07:25:22 GMT, Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> wrote: >Could you (or others) add some motivation to disallow taking the address? > >The standard library could implement some of the features without a function, but user libraries? > >Does it improve safety? It's possible to alter overload sets and maintain API stability for calling the functions, while breaking API for taking the address of members from the set. Marking functions as not addressable anounces that the latter API is not intended to be stable, and misuse gets checked by the compiler. The standard library also has the somewhat unique property that the same interface is implemented by multiple vendors. The interface is also only specified for calling, and not for taking the address, and the instability for the latter can manifest in user cide not being portable. So in short, the concern is compatibility, either across versions or platforms. I don't think there is a safety impact. It seems like in the same ballpark as marking not inherently unsafe functions as [[deprecated]]. > >-----Ursprüngliche Nachricht----- >Von:李 秋逸 via Std-Proposals <std-proposals_at_[hidden]> >Gesendet:Mo 24.03.2025 06:15 >Betreff:[std-proposals] Floating an idea: [[no_address]] for functions. >An:std-proposals_at_[hidden]; >CC:李 秋逸 <QiuyiLi1023_at_[hidden]>; > >Since C++20, it is forbidden to get the address of almost all of the functions in the standard library. Is it a good idea to allow the third-part library to do the same thing? > >  获取Outlook for Android > > > >-- > Std-Proposals mailing list > Std-Proposals_at_[hidden] > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals > > > -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals