I feel like adding a new keyword is a possibility, but we'd be adding a
keyword that doesn't do much.
A PEM (Private Extension Method) is merely a method that can access private
members of a class without the need to declare it as a friend.
I think re-using the *private* keyword brings a lot of benefits with it,
while not bringing a lot of downsides with it (the main one being
teachability: For a beginner it will be very unclear *why* a PEM might be
useful).

I think re-opening the class scope is indeed a bad idea, a class is
declared in 1 place and that's it. Private (and to an extent, protected)
functions are not part of a class' public declaration, and I don't need
someone using my public API to be 100% aware of all the private helper
methods I created that just clutter the header.

By re-using the *private* keyword the feature is opt-in by default; you
cannot currently use the proposed syntax without getting compiler errors.


Not sure I understand. Is this what you mean?
> class Foo {
> public:
> Foo() {
> F(5); // Calls double overload
> }
> private:
> void F(double) { }
> };
> private void Foo::F(int) { }
> As I'm trying to word it in the proposal, the call to F would resolve to
> the double overload because F(int) is not yet declared at that point.
> Though if Foo were a templated class and instantiated after F(int) is
> available, F(int) would participate in overload resolution. I don't quite
> understand why you refer to this as ODR violations ?
> Regards,
> André


I think that makes sense? If the call to *F()* could resolve to
*F(int)* instead
of *F(double)* we'd be more talking about re-opening the class scope (an
entirely different beast) rather than just *adding* a *private* method to
the class.

Maybe PEM's should not be allowed to be overloaded with non-static member
functions of the class? As in, the *private void Foo::F(int) {}* declaration
would give a compiler error as it overloads a non-static member function of
*Foo*. This would avoid confusion with programmers (and make teaching this
more simple) as otherwise there'd be the need to explain why *F(5)* is
resolving to *F(double)* rather than *F(int)*, which is the better fitting
match.

Best,

Rhidian


Op do 30 apr 2026 om 00:41 schreef Steve Weinrich via Std-Proposals <
std-proposals_at_[hidden]>:

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

-- 
Rhidian De Wit
Software Engineer - Barco