This is not even remotely true.

In most implementations weak linking is used for all inline functions where the implementation chooses not to inline, or in which a pointer to the function is taken.

It is also used for all instantiation of functions.

John.



> On Oct 20, 2025, at 3:39 PM, Lisa Lippincott <lisa.e.lippincott_at_[hidden]> wrote:
>
>
>> On Oct 20, 2025, at 8:52 AM, John Spicer via SG21 <sg21_at_[hidden]> wrote:
>>
>> The problem is that the language does not provide a way to allow people to protect themselves from this situation. I would not say it is mistake because it could involve libraries written by people that have never met one another.
>>
>> IMO, it *should* be possible to lock down a semantic to a function or a “component” but it is not possible with P2900, so you have a feature with very sharp edges that are hard for people to understand.
>
>
> I think you may be overlooking the fact that, in almost all* usage, weak linking is an optimization technique, not a requirement. If users are clamoring for weak linking to be limited in some way, implementations are free to respond. An implementation that limits its use of weak linking may be easier for some users to understand, and may also provide inter-procedural optimizations that are unavailable when using weak linking.
>
> In P2900, we chose to continue to make allowances allow for weak linking, and that does have an effect on the design. But we did nothing to require weak linking where there was no requirement before; it’s still largely optional.
>
>
> *In the one situation where weak linking is essentially required — comparison of pointers to nonmember functions defined in more than one translation unit — my understanding is that some implementations, particularly those using dynamic linking, are routinely nonconforming anyway. IMHO, we would be better off relaxing the pointer comparison rules, but I’m not planning to write that paper.
>
> —Lisa
>