As Thiago has strongly intimated, how about limiting this new thing to be
only possible in modules?

In that way, we get to limit where the new thing can be used, declared,
etc. to only where it is safe.

How about simple allowing new methods to be declared inside of a "private
module fragment?"

On Sun, Jun 21, 2026, 15:12 Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Jun 21, 2026 at 12:25 PM Thiago Macieira via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Sunday, 21 June 2026 10:20:56 Eastern Daylight Time Rhidian De Wit
>> wrote:
>> > I think the original path of PEMs being tied to 1 TU is more natural to
>> the
>> > idea of a private method. In that regard, I also believe it to be then
>> only
>> > natural for a PEM to have internal linkage. PEMs can be defined in a
>> header
>> > and included in a TU, so long the PEM is only defined & used in 1 TU.
>> >
>> > Future work for PEMs should be to have Protected Extension Methods, and
>> > moreso, Public Extension Methods.
>> >
>> > Those 2 should have external linkage and are allowed to be shared across
>> > TUs, unlike PEMs, which cannot be shared at all.
>>
>> Except that if you were to return a pointer to a private extension method
>> from
>> a public/protected one, it is shared and cannot be internal linkage.
>>
>
> Pointer *values* don't have linkage at all. It's totally fine to take the
> address of a `static` function or variable.
>
> I owe a blog post on the original topic of this thread at some point. As
> far as I'm concerned, the only thing at issue here, and the only point of a
> proposal, is the current inconsistency that C++ permits me to write this
> C-style code:
> // c-style-api.h
> struct S {
> int i_;
> friend int S_public_api(const S *self, bool b);
> };
> // c-style-impl.cpp
> #include <c-api.h>
> static int S_private_helper(const S *self) { return self->i_; }
> int S_public_api(const S *self, bool b) { return b ?
> S_private_helper(self) : 42; }
>
> but C++ does not permit me to write this C++-style code:
> // cpp-style-api.h
> struct S {
> int i_;
> int public_api(bool b) const;
> };
> // cpp-style-impl.cpp
> #include <cpp-api.h>
> static int S::private_helper() const { return this->i_; } *// [sic],
> fantasy syntax*
> int S::public_api(bool b) const { return b ? this->private_helper() :
> 42; }
>
> As a member function, today, `S::private_helper` must be exposed in the .h
> file (API exposure) and (as far as I recall off the top of my head) also in
> the symbol table (ABI exposure).
> As a non-member function, today, `private_helper(const S*)` needn't be
> exposed in the .h file and can use internal linkage so it's not exposed in
> the ABI — *but* then it can't use C++'s nice OOP syntax.
> So you can have "nice OOP syntax" or "proper encapsulation/hiding of
> details" individually, but not both at the same time. Not for any
> *technical* reason AFAICT, but just because we lack a good *syntax* for
> defining such a "private helper method" within the implementation .cpp file.
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>