Ok, I’m going to back up Thiago a little bit. If we think of a typical class with PEM, we would have a header file with the class declaration and an implementation file with the PEMs and the definitions of the regular member functions from the header file. Just two files. We don’t really care if we have internal or external linkage of PEMs.

If we happen to have a large class, we might (without PEMs) split the implementation into several implementation files. In the same way we might want to handle PEMs. Maybe, we want one implementation file for the declarations from the public header and keep the implementation of the PEMs in a separate file (one public implementation file and one private implementation file). Surely, we would also have a private header file with the PEM declarations so they can be shared between the public and the private implementation file. This would require external linkage.

For hiding PEMs it doesn’t really matter if linkage is internal or external. Only member functions can access PEMs. It doesn’t matter if they are visible to other code. The best hiding you can do is to have PEMs just in a single implementation file or in a private header file that is usually not included in other code. Functions that are not visible during function call resolution cannot be called independent of linkage. And private functions also cannot be called independent of linkage. The program will just not compile.

I don’t see an advantage for internal linkage anymore. There is only the disadvantage of code organization: I’d be restricted to a single implementation file and certainly could not try to separate the public and private implementation into separate files.

> On Jun 21, 2026, at 6:25 PM, Thiago Macieira <thiago_at_[hidden]> wrote:
>
> On Sunday, 21 June 2026 10:20:56 Eastern Daylight Time Rhidian De Wit wrote:
>> I think the original path of PEMs being tied to 1 TU is more natural to the
>> idea of a private method. In that regard, I also believe it to be then only
>> natural for a PEM to have internal linkage. PEMs can be defined in a header
>> and included in a TU, so long the PEM is only defined & used in 1 TU.
>>
>> Future work for PEMs should be to have Protected Extension Methods, and
>> moreso, Public Extension Methods.
>>
>> Those 2 should have external linkage and are allowed to be shared across
>> TUs, unlike PEMs, which cannot be shared at all.
>
> Except that if you were to return a pointer to a private extension method from
> a public/protected one, it is shared and cannot be internal linkage.
>
> I ask you to consider if you are painting yourself in a corner by insisting on
> internal linkage, in addition to creating new rules that add to the
> complexity, all of this for little to no gain. LTO solves most of the problems
> of unnecessarily emitting methods.
>
> Not all. For example, if a class is exported and has friends, the compiler may
> have no choice but to emit all non-inline methods, even if it has inlined
> everything, and even in LTO mode. But if this problem needs solving (and I'd
> argue it does), it applies to current code too and therefore deserves a
> solution independent of the private extension methods.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> <signature.asc>