C++ Logo

std-proposals

Advanced search

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

From: André Offringa <offringa_at_[hidden]>
Date: Wed, 29 Apr 2026 16:31:07 +0200
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é

Received on 2026-04-29 14:31:12