pon., 24 mar 2025 o 10:13 Jonathan Wakely via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
>
>
> 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).

But for me it is right, as enforcing can be done by "clang format"
when you push changes to a public repo.
Or by other tools like PVS-Studio, or by only the developer of header
library (if attributes affect self use in header) and his compiler,
all user can use older compilers that are not aware of the attribute
but still indirectly benefit from it.


>
> I agree that getting usage experience with a vendor attribute first makes sense.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals