First of all, an attribute is the wrong solution because attributes are (still?) ignorable. This would make the code non-portable.

One disadvantage of friend classes is that you give access to all private members. It is much better to use the passkey idiom instead. I haven’t revisited this idiom myself, but it could help with inherited classes as well. If I’m right about that then the proposal should be about making more people aware of the passkey idiom. All teaching material should mention this idiom when teaching about friend classes.

One caveat with the original passkey idiom: It again uses a friend class. The solutions to that: 1) Use a public templated constructor with enable_if/requires to only allow classes derived from B. 2) Use a protected factory member function in B to create the key. C will have access through public inheritance. (And we would still write friend classes B; in the key class.)

Furthermore, (future) reflection might provide a solution. How about [[=inheritable]] instead of [[inheritable]]? This would require that reflection can inject friend declarations into a class. This would preferably be done through some form of metaclasses.

On Oct 22, 2026, at 9:20 PM, 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