I believe there are a few issues in your proposal:
1. As Bo persoon said, it will allow uninvited classes in.
2.It will make the code look rather unclean, since its a somewhat language level construct.
My proposed alternative is a library template singleton class named handle, whose instantiation has to be declared as a friend, and can be used by any one who wants to as long as the handle itself is invited.
One can further add predicates to make sure that access is restricted to a hierarchy of classes or what ever it is that you find convenient. This is a simple example of what something like that might look like in its implementation:
https://godbolt.org/z/rGPWzqExj


On Fri, Oct 23, 2026 at 12:20 AM Theoden Cook via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Hello,

I have an idea for a potential C++ language feature. I'd appreciate feedback on whether it would be worth pursuing as a proposal.

The idea: opt-in inheritable friendship
Currently in C++, friendship is neither inherited nor transitive. If a class is declared as a friend of another class, its derived classes do not inherit that friendship.

I'd like to propose an opt-in mechanism that allows a class to explicitly declare a friendship relationship as inheritable.

For example, the syntax could look similar to this:
```
class A {
    [[inheritable]] friend class B;

private:
    void internal_operation() {}
};

class B {};

class C : public B {
public:
    void run(A& a) {
        a.internal_operation(); // Would be permitted
    }
};
```

The [[inheritable]] syntax is illustrative. I'm open to alternatives :).

The intended semantics would be that explicitly granting inheritable friendship to B also grants the same access privileges to classes derived from B, potentially across multiple levels of inheritance. Ordinary friendship would retain its current behavior unless explicitly marked as inheritable. 

The motivation is to make friendship compose more naturally with inheritance, without requiring the granting class to explicitly friend every derived class, or expose additional public/protected interface solely to accommodate those classes.

I believe this could be a relatively focused change to the language's access-control semantics.

I'd appreciate feedback on a few questions:

  • Is this a useful core language proposal?
  • Are there existing proposals or language features that address this problem?
  • What semantic issues would need to be resolved before drafting a format paper?
  • Would an attribute be an appropriate syntax, or would a dedicated language construct be preferable?
If the idea seems worth pursing, I would be interested in devloping it into a more formal WG21 proposal.

Thank you for your time :)
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals