Just as food for thought to view it from a different angle:

Alternative syntax with an explicit object parameter.

void func(this MyClass& object)

or is this a mix-up with something unrelated?

The private extension member functions are somewhat a free function, which has access to the object.

So it would get a this MyClass& (explicit object) parameter.

Instead of being inside the class MyClass::func() - note MyClass.: is missing above.

-----Ursprüngliche Nachricht-----
Von: André Offringa via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Mi 29.04.2026 16:31
Betreff: Re: [std-proposals] Translation-unit-local functions that access private class fields
An: std-proposals@lists.isocpp.org;
CC: André Offringa <offringa@gmail.com>;

On 4/29/26 11:51, Máté Ték via Std-Proposals wrote:

[..]
With all of this in mind, I came up with the following solution:
[..]

Obviously the MyClass_private.hpp header can be omitted if all private implementation details are confined to a single .cpp file.
To me this way of doing it feels less 'divergent' from the current standard.
It looks and feels more familiar to the C++ I know.
IMHO it is easier to explain to a newcomer, because the rules are exactly the same for regular class definitions.

I'm not sure I agree. Reopening the class would have very specific rules, i.e., don't change the ABI or interface. That's quite different from a regular class definition, so I'm not sure it is a benefit that it looks similar.

Moreover, I think as proposed now, it is similar to another already existing functionality: static free functions.

[..]

Isn't the originally proposed way essentially the same?

Somewhat, yes... I think that private extension member functions can be thought of as a way of "reopening" the class. However, reopening the class gives the notion of more freedom, which isn't there, hence my preference is to use private extension member functions. Sections have been added to the proposal discussing this.

Regards.
André

-- 
 Std-Proposals mailing list
 Std-Proposals@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals