On 4/27/26 5:02 AM, Sebastian Wittmeier via Std-Proposals wrote:
> AW: [std-proposals] Translation-unit-local functions that access
> private class fields
>
> As far as I understood the main purpose was to call the helpers from
> other class member functions of the class, as is typically done for
> private member functions.
>

That is indeed the intention.


> So having access to as programmer (and changing existing member
> functions) is necessary anyway, isn't it?
>

To make good use of the proposed feature, yes indeed. However, if the
proposed feature would allow (aside of its intended goal) to e.g. easily
take an existing class (for which the implementation may not be
available), and easily get access to private variables outside of the
class, it would be an issue. I thought this was what you were trying to
demonstrate, but as I mentioned your examples don't do this, as the
methods still need to be called somehow to leak private data, and since
the methods are private they can't be.


As an example, say I'm extending std::vector with a private function
without changing the class definition. If it would then be very simple
to e.g. change the capacity of the vector and thereby break the class
invariant, it would be bad. However, the proposal does not allow this
(easily). It is possible to extend vector with a private method that
changes the capacity, but it wouldn't be possible to call that method,
since the new method is still private.



> Or is your aim to just have outside access to private members? That
> would change the philosophy of the proposal.
>

That is not the aim.


> Or is it just the order of the calls?
>

Also not the intention.


> But helpers are normally called by the private function, which is
> called by a public function?
>

If you mean with 'helpers' the new private functions I'm proposing, then
they can be called by any method (private, protected, public) from the
class, but not from outside the class. In terms of access they behave
thus exactly as private methods.


Regards,
André


>
> -----Ursprüngliche Nachricht-----
> *Von:* André Offringa via Std-Proposals
> <std-proposals_at_[hidden]>
> *Gesendet:* So 26.04.2026 22:19
> *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/26/26 8:44 PM, Sebastian Wittmeier via Std-Proposals wrote:
>
>> I would agree, if you say the examples are too cumbersome, etc.
>>
>> But why shouldn't they work?
>>
> Maybe I misunderstood you — I thought they were examples of where
> having a private function would leak the private data, and if they
> were to be declared out of class it would be a loophole to access
> a private member from a class, outside the class definition. (If
> not, then I'm not sure what it then shows? It's not a loophole to
> access private members without it being inside the class -- the
> class must explicitly make it available.)
>
> Why I think these private functions would by itself not create a
> loophole; If I look at your first example, your private function
> looks like this:
>
> void Cube::innocentPrivateFunction() {
> CubeHelper::getWidth = [](Cube& cube) {
> return cube.width;
> };
> [..]
> }
>
> If the private function would be called, it would indeed make the
> private members available via the helper. However, in my proposal
> and the one from 2013, it is not possible to call the private
> function without first having private access. So, in that example,
> if the private function would be an out-of-class definition for a
> private member function of an already existing class, it can never
> be called. The same holds for your second and third example where
> you use pointers instead of lambdas. So, if that private function
> would be definable out-of-class, it wouldn't break private access.
>
> (but apologies if I misunderstood the intention of your examples).
>
> However, it is possible to leak data, basically by triggering the
> instantiation of a templated class inside the private function
> (see example in the 2013 proposal). If the class has static
> variables, they will be initialized, and this causes code to run
> merely by having the function without it being called, and via
> decltype it is then possible to run code that has access to the
> private data. So, very involved...
>
> Regards,
>
> André
>
>> [I had abbreviated some for clearer presentation. E.g. declared
>> function pointers have to be defined or some code has to be in a
>> different order (complete ancestor class visible), or a
>> constructor has to be created. So they were not copy&paste.]
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* André Offringa via Std-Proposals
>> <std-proposals_at_[hidden]>
>> <mailto:std-proposals_at_[hidden]>
>> *Gesendet:* So 26.04.2026 19:47
>> *Betreff:* Re: [std-proposals] Translation-unit-local
>> functions that access private class fields
>> *An:* std-proposals_at_[hidden];
>> *CC:* André Offringa <offringa_at_[hidden]>
>> <mailto:offringa_at_[hidden]>;
>>
>> On 4/26/26 1:08 PM, Sebastian Wittmeier via Std-Proposals wrote:
>>>
>>> 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]>
>>> <mailto: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]>
>>> <mailto: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
>>>
>>>
>> -- Std-Proposals mailing listStd-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
>
>
>