C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Translation-unit-local functions that access private class fields

From: Steve Weinrich <weinrich.steve_at_[hidden]>
Date: Wed, 29 Apr 2026 11:24:12 -0600
Just curious, did anyone have any thoughts on my idea proposed earlier?

On Wed, Apr 29, 2026, 10:01 Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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_at_[hidden]>
> *Gesendet:* Mi 29.04.2026 16:31
> *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 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_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
>

Received on 2026-04-29 17:24:28