Thanks for taking a look! Glad we had the same basic thought.

It seemed to me that what the OP wants is simply impossible because
extending a class must require the classes permission. Either through
access control or some new mechanism. A new mechanism must not permit
access from everywhere!

I can't really comment on Modules as I haven't become versed in them as
yet. But if you are correct, it seems we have at least half the solution
done already.

Cheers,
Steve

On Wed, Apr 29, 2026, 16:59 Máté Ték via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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