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