On Mon, 24 Mar 2025, 09:27 Peter Bindels, <dascandy_at_[hidden]> wrote:

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

Maybe allow [[not addressable]] on a namespace and then [[addressable]] on
specific functions if needed?

I don't think the attribute grammar allows the `not` operator there though,
so maybe [[addressable(bool)]].