> Date: Thu, 22 Oct 2026 20:20:11 +0100
> From: Theoden Cook <theodenabarker_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: [std-proposals] opt-in inheritable friendship
> Message-ID:
> <CAB8pzsO=BkLiX0CY8qLN6mQutFHhuRsiteU9r-L9joWOadxAYA_at_[hidden]>
> 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