I think, you are right, templates with an instantiation wherever they are used, are more critical. Inlined functions are less of a problem (and only those outside the declaration) .   I just put it for completeness sake here:   There still is the possibility that member function definitions, which are loaded from a header file could be affected, but the circumstances are quite (too?) special:     If the TU has the declarations and definition in this order:     #include <classdefinition.h>   declaring our private extension methods   #include <inlinepublicimplementation.h>       ========================================     classdefinition.h: class Foo {  public:   Foo();   }  private:   void F(double) { }; };     private extension method declaration:   private void Foo::F(int) { };     inlinepublicimplementation.h:   Foo::Foo() {     F(5); }   -----Ursprüngliche Nachricht----- Von:André Offringa via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 29.04.2026 13:46 Betreff:Re: [std-proposals] Translation-unit-local functions that access private class fields An:std-proposals_at_[hidden]; CC:André Offringa <offringa_at_[hidden]>; On 4/29/26 09:18, Sebastian Wittmeier via Std-Proposals wrote: Hi André, I think you got the point itself. As Thiago pointed out, it does not have to be necessarily templates. It probably is enough, if the member function is defined inside the header file, e.g. directly within the declaration of the class or marked as inline.   Then overload resolution could differ even for calls (to private member functions) within the class. Not sure I understand. Is this what you mean? class Foo {  public:   Foo() {     F(5); // Calls double overload   }  private:   void F(double) { } }; private void Foo::F(int) { } As I'm trying to word it in the proposal, the call to F would resolve to the double overload because F(int) is not yet declared at that point. Though if Foo were a templated class and instantiated after F(int) is available, F(int) would participate in overload resolution. I don't quite understand why you refer to this as ODR violations ? Regards, André   Currently there are already possible ODR violations for calls outside the class, if a different (e.g. free) function is called.   Internal linkage, which should protect the class encapsulation could give the wrong picture about those private extension functions. Shifting the image from unique and declared upfront per class to declared per TU and not only private in the class, but also exclusive to the TU.   The mental picture should still be that all private functions are clearly separate from each other (even over several TUs). And if they have the same name/signature, then they should not be called by any of the functions defined in a header file: templates, functions defined in the declaration and inlined functions.     -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals