Yes, there is and always was a high-level view and low-level view, what header files are for and how they are used.   High-level: (shared) declarations into the header file Low-level: Lines from a header file are inserted as if they are from the cpp file     IMHO I would not start to fundamentally change/remove the low-level meaning of #include for the PEM. We have modules for a higher-level packaging concept. That would either break too much or possibly make reasoning more involved.   Nevertheless it is fair to design PEM for a usage not in header files. These are the possibilities coming to mind:   A) Write into the standard that all the tokens of a PEMs declaration have to come from the highest level C++ file and not from tokens included by #include. How about preprocessor macros? May the whole PEM or parts of it / single identifiers or constants come from a #define?   B) The PEMs have external linkage. A redefinition with the same or different code leads to a linker error. That would also affect PEMs, which are just replicated, but would have the exact same code. So a PEM name (although they are meant to be private and local) would not be allowed to be reused anywhere. That affects helper functions.   C) The PEM has internal linkage. While a redefinition (or putting it into a header) is not advised due to code duplication, it works just fine in practice or is even efficient with link-time-optimization.   D) Like C, but redefining it is "ill-formed, no diagnostic required". Could work in practice, but the standard forbids it to disencentivize the programming practice.     I would see C) as the best solution. And really think about, what the uses and mis-uses of PEMs in (included from) headers would be. I would not be the only one having the idea to put them there. Even if they are not intended to be there.   -----Ursprüngliche Nachricht----- Von:Steve Weinrich via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 20.06.2026 00:23 Betreff:Re: [std-proposals] Translation-unit-local functions that access private class fields An:std-proposals_at_[hidden]; CC:Steve Weinrich <weinrich.steve_at_[hidden]>; Yes, currently there is no distinction between different types of input files to the compiler.  But there could be.  As to the preprocessor,  I believe they have long disappeared.   Yes, there is a phase of the compiler that does this, but it is no longer a separate executable.  Thus, there is information that could be used.  It just currently is not.