There are several existing languages, where the interface is clearly separated from even multiple implementations.

The interface and the implementation can be in different files and the interface does not name the implementation.

The primary name is the interface name, not the implementation name, even for creating, only the interface name is specified.

structure in the following:

public interface

--------

private implementation (different file)

--------

creation of object

VHDL

entity publicName is

end entity publicName;

------

architecture privateImpl of publicName is

end architecture privateImpl;

------

u0 : entity work.publicName

u1: entity work.publicName (privateImpl)

Modula-3

INTERFACE publicName;

END publicName.

------

MODULE privateImpl EXPORTS publicName;

BEGIN

END privateImpl.

-------

IMPORT publicName

VAR X := publicName.New();

Ada

package publicName is

    type T is limited interface;

end publicName;

------

package body publicName is

    type privateImpl is limited new T with record

    end record;

end publicName;

---------

with publicName;

procedure Client is

    X : publicName.Ref := publicName.New_Instance;

OCaml

type t

------

type privateImpl =  {

}

type t = privateImpl

------

let x = publicName.create ()

-----Ursprüngliche Nachricht-----
Von: Steve Weinrich via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Do 30.04.2026 17:49
Betreff: Re: [std-proposals] Translation-unit-local functions that access private class fields
An: std-proposals@lists.isocpp.org;
CC: Steve Weinrich <weinrich.steve@gmail.com>;

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@lists.isocpp.org> wrote:

czw., 30 kwi 2026 o 12:21 Sebastian Wittmeier via Std-Proposals
<std-proposals@lists.isocpp.org> 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@lists.isocpp.org>
> Gesendet: Do 30.04.2026 10:49
> Betreff: Re: [std-proposals] Translation-unit-local functions that access private class fields
> An: std-proposals@lists.isocpp.org;
> CC: Rhidian De Wit <rhidiandewit@gmail.com>;
>
>
>
>
>
> 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@lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

-- 
 Std-Proposals mailing list
 Std-Proposals@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals