I would also argue that this is not a build-system optimization. It
*could* lead
to better build-times, but that's just a side benefit we get along, not the
core issue we're trying to tackle.

For me the core issue is the fact that header files can easily be polluted
with unnecessary things (which *can* worsen build times, but again, not the
main concern IMO). It's the fact that when defining public API's or
libraries we don't need to expose internals.
I also want to explicitly support header files and not only modules,
because plenty of large codebases do not work on modules and could benefit
from PEMs.

I don't advocate for re-opening the class-scope, I think that would present
more problems than we would get solutions. I'd love the PEMs to be a simple
feature with simple rules:

A PEM can only be accessible to 1 TU (meaning that they should always have
internal linkage) and is able to access the private members of the class it
extends.
It is not allowed to overload with member functions of the class it extends.

Perhaps, if this goes well, it could in the future be expanded to just
re-opening the class scope? But I don't think this is the correct time to
do such a thing however

Op do 14 mei 2026 om 09:21 schreef Simon Schröder via Std-Proposals <
std-proposals_at_[hidden]>:

>
>
> > On May 14, 2026, at 12:12 AM, Máté Ték via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> > I did some more thinking and I think this proposal is really a build
> system optimization disguised as a language feature.
>
> You are right that this could improve build times. However, for the main
> point would rather be that the header file (which is read by users of my
> class) is not trashed with private methods that no user of my class needs
> to know about. If there were a way to just have public methods (and public
> member variables) inside the header file I would even advocate for that.
> But so far, the compiler needs all member variables to know the class
> layout.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
Rhidian De Wit
Software Engineer - Barco