On 24 March 2025 05:32:59 GMT, Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> wrote:
>I like the idea in principle, but a proposal would have to figure out
>many nuanced issues.
>
>Firstly, attributes are ignorable, and perhaps, we would want a
>program to be straight up ill-formed if it takes the address of a
>function we've marked as non-addressable. I don't see a compelling
>reason to keep this an attribute. Rather, a contextual keyword like
>the following makes sense:
>
>> void f() no_address;

I like the attribute. It allows adding to existing 3rd party library functions without breaking the world. The language keyword kinda forces a major version bump. The attribute can also be applied to previous language standards.

>
>Secondly, we would presumably want to add this attribute or keyword to
>existing standard library functions that are non-addressable. How much
>code would that break or affect in practice? In theory, taking the
>address of standard library functions is not supported, but all
>compilers permit it anyway, and there is no warning for it either. It
>would be very weird if we didn't add this to standard library
>functions, but if we did, we'd also need to know what impact that has
>in practice.

This language addition, whether keyword or attribute, only really affects user code, not the standard library.

Implementations could add vendor attribute/keyword for this and use that, they don't need the help of the standard to diagnose taking the address of a nonaddressable standard library function.

>
>Thirdly, how does this interact with lambdas? Could this be used to
>disallow converting lambdas to function pointers?

It should just apply to the member operator(), IMO. Or we could just disallow it on lambdas as a first approximation if it's confusing.

>
>Anyhow, I like the idea, but it's harder to standardize than it looks.

I think we could start by gaining implementation experience from a vendor attribute.

Cheers,
Lénárd