On Mon, Mar 24, 2025 at 10:13 AM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Mon, 24 Mar 2025, 08:24 Sebastian Wittmeier via Std-Proposals, <
> std-proposals_at_[hidden]> 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?