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