Date: Thu, 22 Oct 2026 20:20:11 +0100
From: Theoden Cook <theodenabarker@gmail.com>
To: std-proposals@lists.isocpp.org
Subject: [std-proposals] opt-in inheritable friendship
Message-ID:
    <CAB8pzsO=BkLiX0CY8qLN6mQutFHhuRsiteU9r-L9joWOadxAYA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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.
......
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 🙂

It's nice but besides `friend`s, there's only little "friend-friendly" design in the standard library. `is_xxx_v` traits block all friend and access context. `xxxable` concepts when containing raw requires expression behave inconsistently across different compilers and different versions (for example, GCC and Clang 22/earlier allows concepts to access non-public members, Clang 23/after bans it except for raw requires expression).

Too many uses of `friend` will either pollute the concept caches (or even trait class member in Clang 22/earlier), or get rejected by constraints in template libraries. However, there is a possibility that the standard library makes many changes to be friendly with `friend`, but that'll be a huge impact to Clang 23/after and standard wordings (`is_nothrow_move_constructible_v`, for example, will be replaced with raw requires expression to avoid friend hacking/pollution and friend-unfriendly trait template).

Besides all these, there're subtle implementation bugs concerning friends. What I want to express is that compiler developers might can't afford more advanced friend features, either by fantasy-template (as in O'Dwyer's reply), or by attributes.

Above all, I really can't think of a situation where inheritable friendships are *really** useful, I believe it's rather a brainstorm like "friend-friendly" Iterator Library that doesn't exist (and will be disastrous for library developer to make one).


But I don't mean this idea is totally meaningless. Consider the feature itself, it's a bit too partial. Look at that example:

```

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
    }
};

```

Do you mean "Your father's friends are your friends"? Then what about the case "Your friend's friends are your friends" and the case "Your son's friends are your friends"? If that feature is approved, then we also need to consider a universal "X's friends are Y's friends" feature.

When things have nothing to do with template parameters, "X's friends are Y's friends" can be achieved manually or by customized third-party tool. Only when metaprogramming/template libraries need "X's friends are Y's friends" is this feature really worth considering. Currently <meta> library lacks functionality similar to "friends_of" function. That, with "annotations_of", is a more practical path to synthesizing "X's friends are Y's friends" feature in generic code.


Bingzhi