It is not possible for a PEM to access the private members of more than one class type (if they are not ancestor types)?   The access is direct? Not over an object? Or *this->* or similar?   If the PEM is needed in more TUs, it would have to be #included? And the code probably would exist several times in the compiped program? (no optimization)   -----Ursprüngliche Nachricht----- Von:Rhidian De Wit via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 14.05.2026 15:00 Betreff:Re: [std-proposals] Translation-unit-local functions that access private class fields An:std-proposals_at_[hidden]; CC:Rhidian De Wit <rhidiandewit_at_[hidden]>; 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] <mailto:std-proposals_at_[hidden]> >: > On May 14, 2026, at 12:12 AM, Máté Ték via Std-Proposals <std-proposals_at_[hidden] <mailto: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] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals   -- Rhidian De Wit Software Engineer - Barco -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals