> Yes, that post seems to suggest improving granularity for friendship
> declarations. In particular:
>
> class A {
> int x = 0;
> int y = 0;
> friend [[selective_access(x)]] class B; // access of x only
> };
>
> Should be the proposed syntax to handle my use case. Still, a bit
> problematic in presence of overloads: maybe a per member attribute
> would be a better pick, even though more verbose in some cases (eg.
> declaring the friendship with the same external class for many
> members).

I think you can achieve something like this by creating separate classes for the
members which can each individually use friend:

#include<iostream>
class X{
    friend struct A;
    int x;
};
class Y{
    friend struct A;
    friend struct D;
    int y;
};
struct A:X,Y{
    A(){
        x=1;
        y=2;
    }
};
struct D{
    static void test(){
        A a;
        std::cout<<a.x<<'\n';//invalid
        std::cout<<a.y<<'\n';//OK
    }
};

x and y are now in classes that can selectively choose which other classes and
functions have access.

On Mon, Nov 11, 2024 at 8:06 AM Francesco Pretto via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Mon, 11 Nov 2024 at 12:48, Sebastian Wittmeier via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> > is your intention to improve the code (by limiting visibility or access) within your library or the outside interface.
> >
>
> Using regular class/struct friendship is already allowing me to
> successfully reduce the API surface of the library from a API consumer
> perspective. Improvements to granularity of friendship, or (possibly)
> having a module scoped accessibility modifier would allow me to
> restore intended encapsulation within library boundary. I now realize
> I improperly referred to "visibility" in the previous email : yes, I
> actually meant "accessibility".
>
> > Problem: "within the library compilation boundaries, some classes tend to loose proper encapsulation"
> >
> > Solution B: "or (if it makes any sense at all) having an equivalent C++ module visibility modifier"
> >
> > Does your library comprise different (intended/possible) modules? And the current friendships span those boundaries and should be reduced? (Many small libraries would perhaps be just one module.)
>
> Admittedly I have no first hand experience with C++ modules yet: if
> and when I would start using modules, my library would probably
> consist of a single module. If the C++ compiler can track usage of
> symbols spanning different compilation units within the same module,
> similarly to what happens in C# where the compiler can track usage of
> symbols within the same assembly[1], then I believe a "module"
> accessibility modifier could make sense in C++ as well, and would
> provide an option to solve the "Problem". If it really can't and I'm
> misunderstanding actual module capabilities, then sorry for mentioning
> it as a possible language solution.
>
> > Solution A:
> >
> > For the more granular friends approach without modules, this discussion could be interesting:
> >
> > https://groups.google.com/a/isocpp.org/g/std-proposals/c/wtkDvujmjug
> >
> > "Improving Friends with Attributes"
> >
> > Sadly the paper seems to be not available anymore at the old location.
> >
>
> Yes, that post seems to suggest improving granularity for friendship
> declarations. In particular:
>
> class A {
> int x = 0;
> int y = 0;
> friend [[selective_access(x)]] class B; // access of x only
> };
>
> Should be the proposed syntax to handle my use case. Still, a bit
> problematic in presence of overloads: maybe a per member attribute
> would be a better pick, even though more verbose in some cases (eg.
> declaring the friendship with the same external class for many
> members).
>
> [1] https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/internal
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals