Hi all,

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.

I don’t think there are a lot of upsides to PEMs (private ones) being able
to be defined & used across TUs and it only adds a significant layer of
complexity to a (relatively) simple feature. Not implying that this will be
easy, but just that it is a simple concept.


Rhidian De Wit
Software Engineer - Barco

Op zo 21 jun 2026 om 14:02 schreef Thiago Macieira <thiago_at_[hidden]>

> On Sunday, 21 June 2026 01:29:09 Eastern Daylight Time Simon Schröder
> wrote:
> > > On Jun 20, 2026, at 10:46 PM, Thiago Macieira via Std-Proposals
> > > <std-proposals_at_[hidden]> wrote:>
> > Well, we already have special rules for member functions that are defined
> > inline. We could see PEMs the same way.
>
> I agree so long as they are the same rules: functions whose
> implementations
> are inside of the class body. If the implementation is outside, then it
> shouldn't be inline and should not therefore have internal linkage.
>
> Why do we want different rules? What's the gain? What are we trying to
> solve?
> And at what cost, given that it increases complexity if they are different
> from
> the main class?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
>