Simon,

You are correct that a PEM in another TU could not be called outside of the
class members. But it will compile. It seems to me that restricting the
PEM to a particular TU might be worth it. Just my opinion.

Steve

On Thu, Apr 30, 2026, 07:39 Marcin Jaczewski via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> czw., 30 kwi 2026 o 12:21 Sebastian Wittmeier via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
> >
> > Yes, a class does *not* have a single specific TU it resides in.
> >
> >
> >
> > Several TUs may include the declaration.
> >
> > The definitions of member functions and variables can be distributed
> over several TUs.
> >
> > Template member functions and inlined functions can be generated by
> multiple TUs and the linker removes the multiple equal symbols.
> >
> >
> >
> > (Given: There are TUs, which have the above elements, and there are TUs,
> which don't.)
> >
> >
> >
> > C++ does not have a strong relationship between TU and classes, other
> languages do. (E.g. in Java typically the .java source files are called
> like the Classes and the directories signify the package).
> >
> >
>
> But we have modules where you could assign a specific TU or at least a
> group of it as module can be partitioned.
>
> >
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Rhidian De Wit via Std-Proposals <std-proposals_at_[hidden]>
> > Gesendet: Do 30.04.2026 10:49
> > Betreff: Re: [std-proposals] Translation-unit-local functions that
> access private class fields
> > An: std-proposals_at_[hidden];
> > CC: Rhidian De Wit <rhidiandewit_at_[hidden]>;
> >
> >
> >
> >
> >
> > I did this mistake sometime at the beginning of this discussion as well:
> There is some sort of permission control: some public function needs to
> call your private function directly or indirectly (i.e. through other
> protected/private functions). It does not matter if you add private
> functions if they cannot be called. So, yes anybody can add a private
> function anywhere in the source code. No, they can’t use it (without some
> weird tricks that might be possible even right now). The only place where
> this makes sense is in the implementation TU of the class. We need to at
> least declare the hidden private functions before they can be accessed by
> other member functions of the class.
> >
> >
> >
> >
> >
> > This could be a mandate: That PEMs are only part of the translation unit
> of the class they’re extending. So, declaring a PEM in a header becomes
> impossible, but then how would one create PEMs for template classes? As
> those are just in headers and will be part of multiple TUs.
> >
> > Would it not be possible for the compiler to consider the PEM functions
> via ADL? Assuming that overloaded PEM functions (ergo: no conflict with the
> originally declared member-functions) are not allowed.
> >
> >
> >
> > --
> > 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
>