Could template member functions, declared in the class together with private extension functions, which change overload resolution, be a small issue? The template member function expects to call an existing private member function and now calls an overloaded one? Does it depend on the local overload environment the template function is instantiated in? Are there ODR violations, if different TUs have different function overloads, which the I instantiated template member functions call?   -----Ursprüngliche Nachricht----- Von:André Offringa via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 28.04.2026 22:48 Betreff:Re: [std-proposals] Translation-unit-local functions that access private class fields An:std-proposals_at_[hidden]; CC:André Offringa <offringa_at_[hidden]>; Hi all, In follow-up on the discussion about private extension methods, I updated the original draft from 2013 with results from discussion then and now and placed it here: https://github.com/aroffringa/stdcxx-privext-2026/blob/main/proposal/draft.md Feedback welcome. I've sent a mail to the original author notifying them about this discussion. Regards, André On 4/25/26 10:46 PM, André Offringa wrote: > Hi all, > > I was wondering what people think of the following idea. The problem > I'm trying to address is that if we want to introduce a helper method > for a class, we have to declare this helper function in the class, > e.g. assume this situation: > > == Header file: == > > class Foo { > public: >   void A(); > > private: >   void Helper(); > >   int value_; > }; > > == Unit file: == > > void Foo::A() { >   ... >   Helper(); >   ... > } > > void Foo::Helper() { >   ... >   value_ = ...; >   ... > } > > I think it would be useful if there would be a way to skip the > declaration of the Helper method inside the class (in the header > file), and make it translation local just like a static function or > function inside an anonymous namespace would be. From the compiler's > point of view, it could then act as a translation-unit-local function, > except with the possibility to access (private) class fields. > > The benefit is that the method is no longer part of the "interface" of > the class, and this is useful because it is, after all, an > implementation detail of the class. This makes it also no longer > necessary to have the parameter types and return value type declared > in the header file, which decreases dependencies between files. > > An example of how this could look like, could be to use the keyword > 'private' and let it act as an identifier for declaring such a > function, e.g.: > > == Header file: == > > class Foo { > public: >   void A(); > > private: >   int value_; > } > > == Unit file: == > > private void Foo::Helper() { >   ... >   value_ = ...; >   ... > } > > void Foo::A() { >   ... >   Helper(); >   ... > } > > Of course the syntax is open for discussion. The idea is that Helper() > is now a private translation-unit-local function that receives the > 'this' pointer and access to private fields. The function itself acts > in name lookup as a free function, to avoid participating in member > lookup, but is only visible inside class member functions or other > private translation-unit-local functions, and is not accessible > outside of that. This makes it somewhat between a member function and > a free function. With such an approach, it can not be used to access > private fields from a scope that does not allow access to those > fields. Hence, the class data remains encapsulated. It should not > modify the layout of the class and not change its ABI. There are more > details to think through. > > Thinking of alternatives, another direction to solve this would be to > change the standard such that friend functions can be declared as > friend outside of the class definition, instead of by introducing a > function with special visibility rules. They would then behave as > normal functions, which simplify some details. This makes private data > too widely usable, so I don't see a good solution in that direction. > > Syntax aside, the problem I'm trying to solve is to have a function that: > - has access to private members > - is defined only in the unit file > - does not require any declaration in the header > - does not become part of the class interface > > I think the best existing alternative for this situation is to declare > a static free function in the unit file that takes as parameter the > class members it needs. In complex situations, this is not as nice. In > pimpl implementations it is a reasonable solution, but a pimpl pattern > is not always desired. > > I'm curious to hear what people think about the idea of private > translation-unit-local functions. > > Kind regards, > André Offringa > -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals