Sorry, I missed it.

Personally I find it interesting, and I think it is worth investigating,
because I had the exact same idea initially.
That is, instead of finding a 'subtle' way to inject this feature into the
language by making use of existing mechanisms as much as possible, we could
just create a completely new mechanism, make it very explicit in syntax,
and make it a purely optional opt-in feature, but not all of us seem to
think this is the right direction.
^^^ It might be interesting to group and/or evaluate the various solutions
based on how 'disruptive' they are.

I was met with resistance when I suggested defining new keywords/attributes.

I don't see how your proposal would allow creating new functions that can
be implemented and invoked with the same syntax as regular class member
functions, which the original author is looking for. He wants a solution
where you don't have to pass "*this" by hand to the function and can refer
to class member variables without "obj.". Or maybe I am missing something?

Also, if I am not mistaken, your proposal only allows a single TU to be
'designated' as the "class private implementation TU", but the author wants
a solution which works in multiple TUs.
^^^ We could also categorize solutions by this aspect.

Actually, modules kind of do this automatically to a degree, no? The home
module of the class IS its designated private implementation code unit.

Steve Weinrich via Std-Proposals <std-proposals_at_[hidden]> ezt írta
(időpont: 2026. ápr. 29., Sze 19:24):

>
> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>