Also modules should not _by default_ allow private access to its exported classes for the whole module. Modules are wider in scope than a single class (in general) and the classes should have _by default_ their access separated. So even inside modules we would need _explicit_ syntax (e.g. your proposal).   One could argue that it should not be possible to add private functions to an (only) imported module, but it has to be done within the exporting module.   -----Ursprüngliche Nachricht----- Von:Simon Schröder via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 26.04.2026 20:15 Betreff:Re: [std-proposals] Translation-unit-local functions that access private class fields An:std-proposals_at_[hidden]; CC:Simon Schröder <dr.simon.schroeder_at_[hidden]>; std-proposals_at_[hidden]; > On Apr 26, 2026, at 7:47 PM, André Offringa via Std-Proposals <std-proposals_at_[hidden]> wrote: > > - There is some mentioning that modules (at that time, 2013) could provide a better solution Before we had modules everybody (probably not truly everybody because then we would have it) thought that modules would be solving these kinds of problems. Intuitively, one assumes that we compile a module and then we just need to #import that module and don’t need a header file or similar anymore. And the module file (now known as the BMI) would certainly not contain the private symbols. However, this is not what we got with the current modules. We still need some of the source files for the module (I guess only the ones with the module exports). This, again, shows the implementation of your classes to the user of them. So, this point is moot and your proposal still valid. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals