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.