C++ has 2 important boundaries  - translation unit: internal vs. external linkage and   - classes   - together with namespaces (a class cannot be in two sibling namespaces at the same time)     [Orthogonal concepts:  - block scopes have to be inside both    - With the preprocessor one TU can have several headers, but one header can also be in several TUs  - similar modules]     With templates and inline code TUs are a bad protection for encapsulation. So creating public member functions outside the declaration is a bad idea, even if limited to TU.   -----Ursprüngliche Nachricht----- Von:Máté Ték via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 28.04.2026 20:08 Betreff:Re: [std-proposals] Translation-unit-local functions that access private class fields An:Rhidian De Wit <rhidiandewit_at_[hidden]>; CC:Máté Ték <eppenpontaz_at_[hidden]>; std-proposals_at_[hidden]; I didn't mean 'breaking change' literally. I was only trying to make a point. A new feature that immediately applies to all existing classes sounds a bit unnerving to me. Even if it should not break anything in theory. I might just be unnecessary cautious. Having said that, I still prefer my proposed syntax for multiple reasons. Here's a quote from "The C++ Programming Language" (Fourth Edition) from Bjarne: There are several benefits to be obtained from restricting access to a data structure to an explicitly declared list of functions. For example, any error causing a Date to take on an illegal value (for example, December 36, 2016) must be caused by code in a member function. This implies that the first stage of debugging – localization – is completed before the program is even run.[...] Another advantage is that a potential user need examine only the definitions of the member functions in order to learn to use a class.  Personally I would be delighted to see the 'bouquet of private methods' listed explicitly on the implementation side too. Mainly because I, and a lot of other C++ engineers out there, am working with someone else's code. Even 'my own modules' (codes I am responsible for) I have written less than 0.1% of the code. Therefore, in my case, all arguments for a tidy public interface also apply to the private interface. Especially if that interface consists of > 30 methods. It would force us to be somewhat tidy, and I think that's a good thing.  It would also solve the issue of predeclaration of these methods.  It wouldn't require repeating the 'private' keyword and the class name:  private void MyClass::foo(); private void MyClass::bar(); private void MyClass::baz();  vs  class [[implementation]] MyClass { private:     void foo();     void bar();     void baz(); };  This would also make the transition easier for existing code.  I discussed this with a colleague today, and he said (to my proposed syntax) 'why restrict ourselves to private member functions', and I think he's onto something. My proposal allows for this without breaking encapsulation:  // Header: class [[exposition]] MyClass { public:     MyClass(Precious&);     void Foo(); };  // .cpp class [[implementation]] MyClass { public:     // Only visible in this translation unit:     MyClass();     std::uint64_t MyHash() const; };  // Needs hashable type, creates instance with std::make_shared auto prototypeObj = ::RegisterMyPrototype<MyClass>();  Now whether this is an antipattern or a legitimate use case is up for debate.  Just some things to consider. I mean no competition or criticism. I am just trying to explore the solution space. I agree with the core idea 100%. Sincerely, Matthew On Tue, 28 Apr 2026 at 12:10, Rhidian De Wit <rhidiandewit_at_[hidden] <mailto:rhidiandewit_at_[hidden]> > wrote: The original proposal isn’t breaking though. It suggests to re-use the private keyword in function declarations, something that is currently not allowed.  I don’t think it’s a good idea to make every language change via attributes, as it will become overly saturated, while in this case re-using the private keyword makes syntactically and meaning-wise sense.  A private extension function is a “private” function, in essence very similar to a friend function without the requirement to pollute the header file Rhidian De Wit Software Engineer - Barco   Op di 28 apr 2026 om 10:52 schreef Máté Ték via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > Hi,  I am late to this discussion, but this issue is very fascinating.  Disclaimer: I can't type this mail, I am on my way to work, so I'll use ChatGPT voice-to-text to phrase my thoughts, so if it feels AI-generated, it's because it is, but they are very much my thoughts. Also keep in mind that I am no authority here, I am just a regular C++ enthusiast, and this is just my opinion.  I think to understand the deeper issue here, we have to transcend C++ for a bit and be a bit philosophical about classes. A class is essentially a collection of data members and member functions. Each member—both functions and variables—has a visibility: public, protected, or private. The issue is that we need multiple different renditions of this abstract class. In a way, just like a person presents different aspects of themselves depending on context, a class also has different “faces.” It is still the same entity, but we expose different parts of it depending on who is interacting with it. In software, this means the same class must have a public exposition for its users. They need to see the public (and possibly protected) members so they can use them. They also need to see all data members—including private ones—because those contribute to the physical memory layout of the class. This is already a point of friction: private members are not accessible, yet they must still be visible for layout reasons. That’s simply a consequence of how physical computers work, and we must accept that. But we should ask: is this also true for private member functions? It seems the answer is no. They do not seem to affect layout, so they don’t strictly need to be declared in the header. In that sense, the proposal is well-founded. If we continue this idea of multiple renditions, we arrive at the need for:  - a public exposition of the class, and  - a rendition for the implementation. A naïve approach—having two completely separate interface declarations—would require duplicating all public members and data members in two places. That is clearly unacceptable, because any change to the public interface would need to be made twice. A more viable approach is to let the implementation-side declaration specify only the delta—i.e., what is added on top of the public interface.  Now, one open question I have is about private virtual functions. Even though they don’t affect the object layout directly, they do contribute entries to the vtable. I’m not sure whether they can be omitted from the exposition without issues. I’d appreciate input from someone with deeper expertise in this area.  From a syntax perspective, we should also be careful. This feature would need to coexist with existing code, and it could be confusing if a reader suddenly sees private member functions “missing” from the class definition and moved elsewhere. For that reason, I think a clear, opt-in mechanism would be important—for both humans and tooling. One possible direction would be to introduce new standard attributes. For example:  // header class [[exposition]] MyClass { public:     void foo();  private:     int data; };  // .cpp class [[implementation]] MyClass { private:     void helper(); // only visible here };  This makes the intent explicit: the header provides the exposition, the source file provides the implementation extension. It would be immediately clear to readers that the class opts into this model, and IDEs could also take advantage of this structure. >From a tooling and language perspective, this would require compiler and linker support. The rule could be that all translation units see the same public exposition of the class, just like today. However, if this opt-in feature is used, there must be exactly one implementation definition of the class. If it is missing, that would be a link-time error; if multiple implementations exist, that would also be a linker error. This is completely analogous to how ordinary functions behave, so it seems realistically supportable. This model should also work naturally with modules: only the [[exposition]] interface would be exported, while the [[implementation]] part can remain internal to the module.  IMO this sould be a purely optional, opt-in feature—more of an extension than a 'breaking' language change.  Sincerely, Matthew Steve Weinrich via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > ezt írta (időpont: 2026. ápr. 28., Ke 6:50): Hi André, IMHO, the only way to achieve what you are looking for (in something of a secure manner) is to invent a new rule for the compiler.  Something like, “One of the constructors for a class may be marked with a new attribute [[KEY]].  All methods marked with the [[FRIEND class-name]] attribute within the same compilation unit as the class constructor containing the [[KEY]] attribute will be granted friend access to the specified class.”  Note that I am using attributes here, but they could not be used like this as the code must be able to be compiled without support for particular attributes.  This is just presenting a notion. I hope that helps. Chers, Steve   From: Std-Proposals <std-proposals-bounces_at_[hidden] <mailto:std-proposals-bounces_at_[hidden]> > On Behalf Of André Offringa via Std-Proposals Sent: Monday, April 27, 2026 1:21 AM To: std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> Cc: André Offringa <offringa_at_[hidden] <mailto:offringa_at_[hidden]> > Subject: Re: [std-proposals] Translation-unit-local functions that access private class fields   Hi Steve, Thanks for the feedback. You're suggesting helper friend classes as an alternative, but there are some issues with a helper friend class to enable translation-unit-local functions. First of all, to make the functions translation-unit-local, it must be placed in an anonymous namespace. To do this, it must be done so before the befriending, so something like this: == header file == namespace { struct FooFriend; } class Foo {   int a;   friend FooFriend; }; == cpp file == namespace { struct FooFriend {   static void SetA(Foo& foo) {     foo.a = 3;   } }; } I think this is an awkward construct. The Google C++ style explicitly forbids this, as it doesn't allow unnamed namespaces in header files. The SetA() function is also now publicly available, and even though that is limited to a single translation unit, it is still easy to accidentally break a class invariant in this way. The classname of FooFriend is leaked out of the scope of the unit file (style guides often mandate to put it in yet another subnamespace like 'details' in that case). Finally, the syntax of the call and use of private variables is more verbose. Compare it to: == header file == class Foo {   int a; }; == cpp file == private Foo::SetA() {   a = 3; }   So, while there are alternatives for private functions, I don't think the friend classes are really a solution for the issue that the proposal tries to solve. Kind regards, André On 4/26/26 11:05 PM, Steve Weinrich via Std-Proposals wrote: This is purely subjective, but I don't find that a single line, "friend class Helper;" is clutter.  It can be put at the very bottom of the class.  It gives Helper full access for whatever purpose.  No committee required!   Cheers, Steve   On Sun, Apr 26, 2026, 00:17 André Offringa via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: On 4/25/26 10:56 PM, Steve Weinrich via Std-Proposals wrote: I may have missed something,  but one can declare:   class Foo {   friend class Helper;     friend void FooHelper (Foo *); };   Both the class Helper and the function FooHelper() can access all private members of Foo.  Thus, only the names and/or the function signature is declared in the interface.   What I'm trying to solve: - Wen using friend declarations, these clutters the class with implementation details that do not affect the layout of the class. - For FooHelper(), it would require the return and parameters types to be available at the place of the friend declaration, creating extra dependencies. Your example takes only Foo*, but I think it's common for a helper function to use other parameters (and/or have a return value), which causes the dependencies. Regards, André     On Sat, Apr 25, 2026, 14:46 André Offringa via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > 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] <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] <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