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
>