On 4/26/26 1:08 PM, Sebastian Wittmeier via Std-Proposals wrote:
> AW: [std-proposals] Translation-unit-local functions that access
> private class fields
>
> Please look at N3863 and its discussions on this list:
>
> https://github.com/mateofio/stdcxx-privext
>
>

Thanks, I was not aware of this proposal. Interesting to see that it
proposes the same feature as that I was proposing, including the use of
the keyword private for it. The only difference I see is that the
proposal would not by default make the private extension methods have
internal linkage, whereas I'm proposing to do that. In the mailing lists
from 2013 I see there's mostly support for the feature. People prefer
internal linkage as default, which makes it the same as what I'm proposing.


I had a look at the examples that Sebastian mailed, but I don't think
that any of them work to circumvent the privateness of class fields.
That said, in the proposal there is an example way to abuse private
methods to break private access, but the method is quite contrived. It
also mentions that there are already other ways to break private access.
The proposal discusses why adding an extra (contrived) way of breaking
private access isn't a showstopper.


Unless I missed parts of the thread, I don't see strong arguments or
opinions against it. Does anyone know why the proposal didn't progress?
Counter arguments that were mentioned in the mailing list (and mostly
discussed already in that proposal) :

- Provides new ways of breaking private access
- There is some mentioning that modules (at that time, 2013) could
provide a better solution
- Preference seems generally to be to make it default internal linkage
(as I propose), thereby avoid the need for another meaning of static as
the old proposal did. The author of the proposal mentions somewhere in
the mailing thread that they will update the proposal with that, but
that seems not to have happened (?).
- I see one mail about that it adds complexity to compilers. I say
that's a fair counter argument, but could be explored.
- There are alternative approaches to reach something similar, though I
think none are a perfect substitute.
- Someone preferred the ability to reopen class scope. This seems to me
a more intrusive option, though could indeed be used to reach the goal.
- There's discussion on the syntax for making a private method have
external linkage. I think that's more niche. Maybe it would be better to
scope the proposal to not include that for now but only mention it as a
future possible addition.

Regards,

André


> -----Ursprüngliche Nachricht-----
> *Von:* André Offringa via Std-Proposals
> <std-proposals_at_[hidden]>
> *Gesendet:* Sa 25.04.2026 22:46
> *Betreff:* [std-proposals] Translation-unit-local functions that
> access private class fields
> *An:* std-proposals_at_[hidden];
> *CC:* André Offringa <offringa_at_[hidden]>;
> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>