It can be all 2 or more:   a) Restricting to a TU: Internal linkage b) Can only be called from the class itself (from existing member functions and initializers for member variables)   c) The caller has to mark the transfer of the right to access private member variables d) The class declaration has to be opened again/be extended   Whereas     e) Demanding that all TUs implementing the class should know the complete set of private member functions would be contra to the proposal. Some member functions definitions are part of the header, so it would extend to all TUs using the class, which is the existing state of C++.   -----Ursprüngliche Nachricht----- Von:Steve Weinrich via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 30.04.2026 17:49 Betreff:Re: [std-proposals] Translation-unit-local functions that access private class fields An:std-proposals_at_[hidden]; CC:Steve Weinrich <weinrich.steve_at_[hidden]>; Simon,  You are correct that a PEM in another TU could not be called outside of the class members.  But it will compile.  It seems to me that restricting the PEM to a particular TU might be worth it.  Just my opinion.  Steve On Thu, Apr 30, 2026, 07:39 Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: czw., 30 kwi 2026 o 12:21 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > napisał(a): > > Yes, a class does *not* have a single specific TU it resides in. > > > > Several TUs may include the declaration. > > The definitions of member functions and variables  can be distributed over several TUs. > > Template member functions and inlined functions can be generated by multiple TUs and the linker removes the multiple equal symbols. > > > > (Given: There are TUs, which have the above elements, and there are TUs, which don't.) > > > > C++ does not have a strong relationship between TU and classes, other languages do. (E.g. in Java typically the .java source files are called like the Classes and the directories signify the package). > > But we have modules where you could assign a specific TU or at least a group of it as module can be partitioned. > > > > > -----Ursprüngliche Nachricht----- > Von: Rhidian De Wit via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > > Gesendet: Do 30.04.2026 10:49 > Betreff: Re: [std-proposals] Translation-unit-local functions that access private class fields > An: std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> ; > CC: Rhidian De Wit <rhidiandewit_at_[hidden] <mailto:rhidiandewit_at_[hidden]> >; > > > > > > I did this mistake sometime at the beginning of this discussion as well: There is some sort of permission control: some public function needs to call your private function directly or indirectly (i.e. through other protected/private functions). It does not matter if you add private functions if they cannot be called. So, yes anybody can add a private function anywhere in the source code. No, they can’t use it (without some weird tricks that might be possible even right now). The only place where this makes sense is in the implementation TU of the class. We need to at least declare the hidden private functions before they can be accessed by other member functions of the class. > > > > > > This could be a mandate: That PEMs are only part of the translation unit of the class they’re extending. So, declaring a PEM in a header becomes impossible, but then how would one create PEMs for template classes? As those are just in headers and will be part of multiple TUs. > > Would it not be possible for the compiler to consider the PEM functions via ADL? Assuming that overloaded PEM functions (ergo: no conflict with the originally declared member-functions) are not allowed. > > > > -- > Std-Proposals mailing list > Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals