Being able to "impose friendship" would create a maintenance nightmare for everyone who writes libraries. Not only would the publicly-visible surface of the library need to be maintained but the internals couldn't change because any consumer of the library could have "imposed friendship" and now be depending on the precise inner workings of the class. It's the ABI compatibility nightmare except arguably worse.

While it's frustrating when third party libraries don't offer the functionality or control one desires this seems like a solution that creates more problems than it solves.

Forking the library and making the necessary modifications (as it seems was done in the motivating case) is one approach. Contributing back to the library the needed changes is another. In both these cases the new workflow becomes bona fide to one degree or another rather than being a difficult or impossible to maintain ad hoc addition.

--Robert
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Sent: Sunday, July 17, 2022 14:05
To: std-proposals <std-proposals_at_[hidden]>
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Subject: [std-proposals] Impose friendship when needed

Recently I was working with an RS232 library when programming a microcontroller in C++. I needed a little finer control over the library's inner workings, more control than the library provided. I had to edit the library's header file to change the visibility of one of the class's member variables, I changed it from 'private' to 'public', and also I made one of the member functions 'public'. Alternatively I could have added one line at the end of the class definition:

    friend class MyOwnClass;

and then I could have accessed all the private members through static member functions belonging to MyOwnClass.

I propose that we should be able to "impose friendship" without editing the library's header files. For example:

    class Foo { int monkey; };

    int main(void)
    {
        Foo obj;

        using friend Foo;

        obj.monkey = 5;
    }

The statement "using friend Foo" only has an effect within 'main', similar to how "using namespace std" would have limited scope here.

Alternatively, the syntax could be on an access-by-access basis, something like as follows:

    int main(void)
    {
        Foo obj;

        friend<obj>.monkey = 5;
    }

or the syntax could be:

    friend<obj.monkey> = 5;

or maybe:

    std::friend(obj, monkey) = 5;

or:

    friend >> obj.monkey = 5;

Some of you might be thinking: "Why affirm such subterfuge when the author of the library obviously didn't want you messing around in there?", well computer programming isn't an exact science. Indeed we have paradigms and design patterns, but really at the end of the day we're trying to get things done, and this might mean following the instructions from Step 1 to Step 9 but then deviating at Step 10.

Being able to manually impose friendship when and where you need it, would mean not needing to edit the 3rd party library's header file.