On Mon, Mar 24, 2025 at 10:13 AM Jonathan Wakely via Std-Proposals <std-proposals@lists.isocpp.org> wrote:


On Mon, 24 Mar 2025, 08:24 Sebastian Wittmeier via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:

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.


I don't think it has anything to do with compiled code. It's about source compatibility not ABI compatibility. 

 

However the fix is simply within the standard to disallow taking the address.


That doesn't help user libraries that want to mark an API as "this might evolve to be an overload set instead of a single function, or might have additional defaulted arguments added, so you can't rely on its signature".

 

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.


Yes, it seems appropriate as an attribute to me (but then I think the rule that attributes must be ignorable and can't change semantics is silly anyway).

I agree that getting usage experience with a vendor attribute first makes sense.

This idea reminds me of [[fallthrough]]; the default should be that you do not take the address of functions, and there should be an annotation to indicate that *this* function is suitable for it. Then, if we have sufficient use of that annotation (like, nonzero in the file that it comes from) we can warn on taking the address of a function without that attribute.

Sadly, unlike fallthrough, this attribute should be on the *declaration* of that function. Which means this won't work quite as well; you'd get warnings on taking the address of functions from other libraries, and we likely don't want to "inspire" people to copy over the declaration to add an attribute - or maybe we do, in this case, as the function signature shouldn't change, because of taking the address?