On 4/25/26 10:56 PM, Steve Weinrich via Std-Proposals wrote:
> I may have missed something, but one can declare:
>
> class Foo
> {
> friend class Helper;
>
> friend void FooHelper (Foo *);
> };
>
> Both the class Helper and the function FooHelper() can access all
> private members of Foo. Thus, only the names and/or the function
> signature is declared in the interface.


What I'm trying to solve:

- Wen using friend declarations, these clutters the class with
implementation details that do not affect the layout of the class.

- For FooHelper(), it would require the return and parameters types to
be available at the place of the friend declaration, creating extra
dependencies. Your example takes only Foo*, but I think it's common for
a helper function to use other parameters (and/or have a return value),
which causes the dependencies.

Regards,
André


>
> On Sat, Apr 25, 2026, 14:46 André Offringa via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
> Hi all,
>
> I was wondering what people think of the following idea. The
> problem I'm
> trying to address is that if we want to introduce a helper method
> for a
> class, we have to declare this helper function in the class, e.g.
> assume
> this situation:
>
> == Header file: ==
>
> class Foo {
> public:
> void A();
>
> private:
> void Helper();
>
> int value_;
> };
>
> == Unit file: ==
>
> void Foo::A() {
> ...
> Helper();
> ...
> }
>
> void Foo::Helper() {
> ...
> value_ = ...;
> ...
> }
>
> I think it would be useful if there would be a way to skip the
> declaration of the Helper method inside the class (in the header
> file),
> and make it translation local just like a static function or function
> inside an anonymous namespace would be. From the compiler's point of
> view, it could then act as a translation-unit-local function, except
> with the possibility to access (private) class fields.
>
> The benefit is that the method is no longer part of the
> "interface" of
> the class, and this is useful because it is, after all, an
> implementation detail of the class. This makes it also no longer
> necessary to have the parameter types and return value type
> declared in
> the header file, which decreases dependencies between files.
>
> An example of how this could look like, could be to use the keyword
> 'private' and let it act as an identifier for declaring such a
> function,
> e.g.:
>
> == Header file: ==
>
> class Foo {
> public:
> void A();
>
> private:
> int value_;
> }
>
> == Unit file: ==
>
> private void Foo::Helper() {
> ...
> value_ = ...;
> ...
> }
>
> void Foo::A() {
> ...
> Helper();
> ...
> }
>
> Of course the syntax is open for discussion. The idea is that
> Helper()
> is now a private translation-unit-local function that receives the
> 'this' pointer and access to private fields. The function itself
> acts in
> name lookup as a free function, to avoid participating in member
> lookup,
> but is only visible inside class member functions or other private
> translation-unit-local functions, and is not accessible outside of
> that.
> This makes it somewhat between a member function and a free function.
> With such an approach, it can not be used to access private fields
> from
> a scope that does not allow access to those fields. Hence, the class
> data remains encapsulated. It should not modify the layout of the
> class
> and not change its ABI. There are more details to think through.
>
> Thinking of alternatives, another direction to solve this would be to
> change the standard such that friend functions can be declared as
> friend
> outside of the class definition, instead of by introducing a function
> with special visibility rules. They would then behave as normal
> functions, which simplify some details. This makes private data too
> widely usable, so I don't see a good solution in that direction.
>
> Syntax aside, the problem I'm trying to solve is to have a
> function that:
> - has access to private members
> - is defined only in the unit file
> - does not require any declaration in the header
> - does not become part of the class interface
>
> I think the best existing alternative for this situation is to
> declare a
> static free function in the unit file that takes as parameter the
> class
> members it needs. In complex situations, this is not as nice. In
> pimpl
> implementations it is a reasonable solution, but a pimpl pattern
> is not
> always desired.
>
> I'm curious to hear what people think about the idea of private
> translation-unit-local functions.
>
> Kind regards,
> André Offringa
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>