Add friend class in c#

[mdmozibur]

This is something I frequently feel the necessity of in c#. In many cases, I want to make the member of a class accessible to another class, which has no relationship of hierarchy. Most probably this feature is available in c++.

[Happypig375]

Why can't you just nest one class in another?

[Kokorska-okurka]

In Unity, only normal classes with MonoBehaviur parents are allowed to use them as scripts. When you need some MonoBehaviur based class to be friend of another class, this is not an option.

[HaloFour]

I'd suggest that nested classes are the appropriate way to express that relationship, especially since the CLR supports providing access to the private members. The CLR doesn't support any special relationship beyond that point so the best you can do is have the compiler enforce custom rules based on internal members, which would potentially open up a further can of worms. For example, if these friend members were actually internal to the CLR, then neither the compiler nor the CLR could prevent other assemblies privileged via InternalsVisibleToAttribute from also calling those members.

[mdmozibur]

      Why can't you just nest one class in another?

If I could it in an easy way, I wouldn't ask for it. Having a feature is always nice.

[MgSam]

InternalsVisibleToAttribute is your best best.

[mdmozibur]

InternalsVisibleToAttribute is your best best.

but they are at assembly level, I want it in class level

[MgSam]

Then maybe you either need to refactor code into separate assemblies, or ask yourself who/what you're trying to protect some classes from but not others.

[dsaf]

It's worth exploring, related: #2062.

[ichensky]

@Muziburrahman
You can create nested class:

    class A
    {
        private int _x;
        public class B
        {
            public B() {
                var x = new A()._x;
            }
        }
    }

From class B you can access any private fields from class A and class B has no relationship of hierarchy to class A.

[mdmozibur]

@ichensky thanks for your suggestion.

[ttutisani]

Nested classes increase the file size and number of lines inside a single class.

This is a typical situation: you create a folder for a feature and all feature-related classes are in it. Some of the classes are supposed to be used only within the feature (i.e., other classes under the same folder) and not from outside, while only a few of the classes are exposed to the outside world. Just like modules export only a few members (BTW, why not simply support modules?).
Friend class concept would help with such organizations a lot. It would be the step towards modular design, which is missing in c# clearly.

Yes, we could consider creating a class library in such situations, but then we will have too many class libraries per solution, and they would be too granular. So a module (set of classes and rules about what's exposed and what's not) or friend classes would be more appropriate and useful to develop functional modules within the class libraries.

[HaloFour]

Nested classes increase the file size and number of lines inside a single class.

You can split the class definition over multiple files using partial classes:

// MyClass.cs

public partial class MyClass {
    private int value;

    public string M() {
        var helper = new NestedHelper(this);
        return helper.DoWork();
    }
}

// MyClass.NestedHelper.cs

public partial class MyClass {
    private class NestedHelper {
        private readonly MyClass instance;

        public NestedHelper(MyClass instance) =>
            this.instance = instance;

        public string DoWork() =>
            $"The value is {instance.value}.";
    }
}

Friend class concept would help with such organizations a lot. It would be the step towards modular design, which is missing in c# clearly.

Friend classes aren't a requirement for modularity. Plenty of CLR-based libraries have no issues with modularity.

Friend classes are something that doesn't exist in the CLR. The relationship between nested and parent classes are as close as you get. The only ways that C# could emulate this behavior is either by making the members in question actually internal instead of private, or by nesting the classes, which could only work if the class is a friend to only one other class. And since you can nest classes manually I see little reason for the compiler to try to fake any further relationship.

[ttutisani]

It's normal that compiler does things that developers don't have to do manually. I would say that's a good reason to implement this feature, not the blocker. e.g., we could probably define delegate classes ourselves but instead, we can get away with lambdas.

I understand the CLR limitation and now I will consider nesting of classes if that's what the compiler would do. I just wish that I could keep them in separate files and separate classes too. Partial classes will not help if I conceptually see the classes being separate. UPDATE ON THIS: I just realized you meant to put the nested class in another file of the partial class. That's not so bad. Thanks for the hint!

I don't know how plenty of CLR-based libraries don't have issues with modularity. I'd say that's probably because modularity is not so well understood. I don't think that node.js or other modular javascript frameworks/runtimes would be the same without modules.

Thank you!

[ttutisani]

@HaloFour out of curiosity, is there any hint that would allow me to achieve the friend class association in one-to-many fashion? Specifically, I want a single helper class only to be used from a couple of other classes and nowhere else. Partial class solves this problem for one-to-one relation only.

[HaloFour]

@ttutisani

No. The special relationship in the CLR only exists between nested classes and their parent class.

[theunrepentantgeek]

If the "other" classes share a common ancestor, you could nest the helper class in that ancestor using the protected modifier:

using System;
public abstract class Foo
{
    protected class Helper
    {
    }
}

public class Bar : Foo
{
    private readonly Helper _helper = new Helper();   
}

public class Baz : Foo
{
	private readonly Helper _helper = new Helper();
}

public class Snuff 
{
    // private readonly Helper _helper = new Helper();  // Helper is inaccessible
    // private readonly Foo.Helper _helper = new Helper();  // Helper is inaccessible
}

But, while this works, it's a maintenance nightmare for anyone having to work on the code in the future.

[eric-777]

People say it didn't break encapsulation because you made the two class interdependent. In my POV it change nothinks it break encapsulation since encapsulation in my POV is not only avoid some random class to access private it's the reason behind. I explain it in my next point.

Friend cannot pry open some random class. Like public, friend can only be used by a class to intentionally grant access. Under no circumstances can friend be used to invade the privates of an unsuspecting class.

Friend and public also have the following symmetry:

• Public selects specific members to be visible to all other classes.
• Friend selects specific other classes to have visibility to all members.

The need for public is glaring and unmistakable. The need for friend is much less common, but no less rational.

• Public : Must always work with a standard it validate it's input and context before processing to failed in a standard way and do only what it's supposed to do and nothings less or more. Must avoid signature change when possible.
• Internal : Used in a library to share a public method that must not be used outside the environment. May not work on some case (Based on the context of the library) and can have some signature change.
• Protected : May not validate it's input or context has was already been validate by the public method but must validate it's context to failed in a standard way and do only what it's supposed to do and nothinks less or more
• Private : May not validate it's input or context has already been validate by the public method. It may not always work as the caller as access to it's code.

I agree with all of this on encapsulation. If every encapsulated system could be represented by a single class then there would be no rationale for friend. Friend allows one to create a perfectly encapsulated, indivisible system that spans more than one class without leaking any private state to unintended classes. These must be tested together as a unit, or the test is meaningless. The involved classes are collectively providing a single, indivisible interface. 2 classes in a friend network are not modular with respect to each other, any more than 2 private members inside a single class are modular with respect to each other.

[Frozenthia]

A few observations about the stated workarounds (and a few others I pondered over)

• internal does not work the same way as friend. From the C++ docs (for those who don't know): The friend declaration appears in a class body and grants a function or another class access to private and protected members of the class where the friend declaration appears. internal is assembly wide.
• InternalsVisibleTo doesn't just expose visibility to an entire assembly. It exposes visibility of its own entire assembly to the other entire assembly. That makes a total of three annoyances, not one. With the desired goal that only Contoso.Foo.CollectionItem can access Contoso.Foo.Collection inside of a neat and organized feature space, we must create a new assembly, expose all internals, and have it be exposed to the whole assembly. Neither one of our goals was actualized.
• IgnoresAccessChecksTo (which is the reverse of InternalsVisibleTo and honoured by the runtime) may be more useful for some situations, but has about the same drawbacks as InternalsVisibleTo.
• EditorBrowsableAttribute is visual only. One could imagine an overload on it like EditorBrowsableAttribute(params Type[] friends) that would act as a whitelist for public members. I don't know enough about people's use cases for this to have an opinion on this beyond that. It's also not friendship.
• Source Generators would aid in wiring together partials and (re: performance) could even generate helpers or proxies with the same members with redirected runtime handles. However, I can think of no combination of Source Generator / Analyzer where friend would be less suitable. No matter how you slice it, any implementation would have some minor annoyance, such as leaving types partial and/or unsealed. AOT could not solve this. However, those generated types can at least have their visibility constrained and other types wouldn't be able to use them. New features like shapes and type classes may have some interesting implications here should friendship be utilized through Source Generators.
• With the above suggestion, one could imagine [Friend(typeof(Bar))] over public class Foo to easily drive this, however as always a standard for friendship would be really great for reflection/metadata or for compilers.

A quick note from the C++ docs as well to support the response to the possible critique of encapsulation:

Friendship is not transitive (a friend of your friend is not your friend).
Friendship is not inherited (your friend's children are not your friends).
Access specifiers have no effect on the meaning of friend declarations (they can appear in private: or in public: sections, with no difference).

I also cannot think of a way where it would allow access for a specific method or function.

[timcassell]

Friend and public also have the following symmetry:

• Public selects specific members to be visible to all other classes.
• Friend selects specific other classes to have visibility to all members.

I like that symmetry, and that also answers my 2 questions about friending specific members (not supported).

Friendship is not inherited (your friend's children are not your friends).

C++'s restriction for friendship like this also answers my other question (and was what I was leaning towards anyway). If you want a friend's children to be friends, you must explicitly declare them so.

[ttutisani]

I have not been here for a while, but I found another compelling (for me) reason to have friend classes support in c# - Law of Demeter (https://en.wikipedia.org/wiki/Law_of_Demeter). I'm sure you know what this is about, but let me clarify for everybody.

Suppose you have a class that holds instances of other classes within and exposes them via a property. e.g., Company class has Addresses property and each of the values is an Address class. Now, you are a designer of the Company class, and you want to disallow calling a certain method on the Address directly and allow doing so only through the Company's method. This is a typical situation if you follow DDD for instance and want to control the entire aggregate's consistency via its root class (Company).

If there were friend classes, I would make the method of Address that I want to hide friend towards Company, and thus it would not be callable from the outside of the Company aggregate. And I would define the method on the company that calls the "hidden"/friend method. Without the friend class, I am forced to make the method on the Address public just to call it from the Company. However, I am also exposing the hidden method with that to the outside world. I don't like that, it does not allow me to design classes based on the Law of Demeter cleanly.

I know now somebody will ask for an example. Here it is:

class Company
{
    public IReadOnlyCollection<Address> Addresses { get; }

    //Hint because friend classes are not supported in c#: I hope that you will call this method when you need to associate addresses.
    public void AssociateAddresses(int index1, int index2)
    {
        this.Addresses[index1].AssociateWith(this.Addresses[index2]);
        //and, other way around too! otherwise the aggregate consistency is violated.
        this.Addresses[index2].AssociateWith(this.Addresses[index1]);
    }
}

class Address
{
    //Hint because friend classes are not supported in c#: don't call this method directly, call Company.AssociateAddresses instead.
    //if you call this without associating both ways, aggregate consistency is violated.
    public void AssociateWith(Address otherAddress)
    {
        this._assocaitedAddresses.Add(otherAddress.Id);
    }
}

Maybe there is a workaround that does not come to me immediately?

[AartBluestoke]

may i ask what the hangup on 'the runtime won't enforce this' is, concerning 'friends' - reflection means that the runtime doesn't actually enforce any level of private-ness.

[theunrepentantgeek]

It's the difference between having a balcony handrail (runtime enforcement) and leaping over the handrail (reflection).

Your option to do something clever/stupid by using reflection doesn't negate the usefulness of having runtime enforcement in place the rest of the time.

[ttutisani]

All right, we all get it - there are workarounds for specific cases, which could somewhat mimic the friend class intention. However, we all can agree that these workarounds are not as clean and convenient as the friend class. This whole thread has become a debate and push-back. I guess there needs to be a page on Microsoft docs called "How to achieve what friend classes would achieve," and we all could be redirected there. And please, on that page, list all fair use cases without focusing on a "push-back" like in this thread. Just list all the friend classes' usefulness and how to achieve the same effect without them.

I would be satisfied to go and read that page rather than participate in these debates. Please, Microsoft!

Otherwise, for once, can we have a response that attempts to take the consumers' position, and list on behalf of us (consumers) the use-cases that friend classes help achieve? And then, for those use-cases, explain how to deal with them in C#'s current state, without awkward designs and unnecessary complications! Thank you!

[HaloFour]

All right, we all get it - there are workarounds for specific cases, which could somewhat mimic the friend class intention.

The goal of the language is to provide a solution to the problem, not to provide a specific solution. Not being your preferred solution doesn't make it a "workaround".

I'm having trouble finding any OOP language other than C++ that has implemented "friend" types or members. If anything it seems like "friend" was a workaround for the lack of module-based accessibility in C++.

This whole thread has become a debate and push-back.

Language design is a messy process and is by nature quite conservative. Every language proposal meets pushback and debate. Considering the different problems and use cases and the existing ways in which they could be solved is the very first step. It's about trying to determine the ROI knowing that the I is very high for even the "simplest" of language features. Debate is a healthy and necessary part of the process.

[theunrepentantgeek]

@ttutisani wrote:

However, we all can agree that these workarounds are not as clean and convenient as the friend class.

Be careful with the sweeping statements. I disagree intensely with this one.

Objectively, use of "friend" visibility creates an extremely tight coupling that directly impairs the code. It makes the code harder to comprehend (because any maintainer now needs to understand both classes before addressing any change or bug fix), and makes the code significantly harder to unit test.

Subjectively (that is, in my opinion) the C# techniques detailed in this thread aren't workarounds for a limitation of the C# language, they're useful techniques that are superior precisely because they make developers think about what they're doing.

[Ziflin]

@theunrepentantgeek

Be careful with the sweeping statements. I disagree intensely with this one.

It's kind of crazy how polarized people are about this issue. I agree intensely with @ttutisani. Maybe it's a difference in backgrounds, but I would strongly disagree that any of the workarounds in this thread completely solve the functionality that friend does as cleanly. The cases where we desire friend use do not "impair" the code and instead make it considerably easier to understand by those maintaining the code. The "public" never need to concern themselves.

[theunrepentantgeek]

It's kind of crazy how polarized people are about this issue.

😀 People with mild opinions don't tend to hang out here because they just don't care.

I think you've made an important point:

would strongly disagree that any of the workarounds in this thread completely solve the functionality that friend does

I'm not sure anyone has said there's one true way to achieve the same thing.

For each place where friend might be useful, there's a way to achieve much the same result (not an identical one) using existing capabilities. There's no one approach that achieves all the same results, and that's perfectly fine.

I'd love to see an example where having friend is unambiguously better than the approaches already supported.

[timcassell]

I'd love to see an example where having friend is unambiguously better than the approaches already supported.

I believe the only 2 suggested solutions here are explicit interface implementations and nested types.

Nested types can only have a 1-way friend relationship, making it already inferior to friend. It also doesn't look great to the public if you logically wanted the 2 types to sit next to each other in their namespace and not be nested.

Interfaces, as I already mentioned before, have a performance impact (friend accessibility should have the same performance as private). They also add (what would be) unnecessary clutter to the code, aka namespace pollution, for each isolated friend relationship.

While some argue that interfaces are more maintainable than friends, I vehemently disagree thanks to all the extra boilerplate code needed just for that purpose. Saying that you will have to understand both classes before changing one doesn't mean that's still not the case when using interfaces for this purpose, it's just more convoluted that way. Seeing a friend declaration makes that plainly obvious.

So without an explicit example, I believe friend is unambiguously better than other approaches when friendship is the goal (not for other goals).

---

As an aside, I like C# because it chose not to restrict things that might be abused, unlike Java. And I think friend has much less potential for abuse than other features (I mean, that's like abusing public, which people do all the time).

[HaloFour]

If friend classes were an unambiguously better solution there'd probably be more than one language to implement the feature. Even in Rust it was determined that the recently added crate/module accessibility modifiers eliminate the need for friend classes.

[timcassell]

I'm not familiar with rust, I assume that's akin to the internal keyword?

Yes, I believe friend is unambiguously better than interfaces and nested classes, but I did forget about internal for this. While that's not really unambiguously better, I think some other people have stated reasons why it's not ideal (creating extra assemblies and/or maintenance within an assembly).

[ttutisani]

Let me state what I was trying to say again.

Just as it's difficult to sell a thing to a person who does not need it, it is almost (or rather without "almost") impossible to convince people who are responsible for C# language design to have "friend" classes. I would like to hear an opinion of a person responsible for the C# language (the resisting side so far) who has tried to walk in our shoes. No arguing, no debate, just an opinion that will indicate that you heard us. Am I asking for a too hard thing to do?

Imagine (imagine) that you need the friend class functionality. Come up with realistic use cases that require the friend class. List them all. For each use case, describe how you would do that without the friend class support. Create a GitHub wiki or Docs page explaining the approaches, as well as pros and cons. If you cannot imagine that you really need the friend class, maybe you cannot create a good document, and we need somebody else.

The major difference between those asking for the friend class and those who respond, claiming it's not necessary, is that those who asked for it have been on both sides (used C# as is, found a need for the friend class, tried to solve problems without the friend class, and broke their neck). On the other hand, those who are responding seem to have not tried to "like" the friend class. Try to explain its proper usages, and then describe how C# (not having the friend class) can still nicely and cleanly achieve the same results.

I did hear a good point about ROI, and maybe that needs to be emphasized. Maybe indeed, building and supporting the friend class feature would cost more than the satisfaction it delivers to its consumers. I can live with that answer. Product development needs to prioritize requirements based on their impact. So maybe that is what we are receiving here. Not enough impact potential.

Alternatively, I am thinking, maybe the friend classes (or modularity) is not a language feature but rather a technology built upon it? Currently, there is no way to build modular code with C#. Yes, assemblies somewhat allow doing so, but can you make them so cheap that having 100s (or 1000s) of assemblies per solution would load fine? Maybe this is the answer? I know that assemblies will not allow the granular control on the member level (member of a class is in the friend's visibility so that makes things harder), but still, something.

Do you see it? I am trying to find the answer. I am not arguing. I am not pushing, just trying to figure out how to do what I need to do with reasonable costs. Can you do the same and help us out, please? It does not have to be so hard. There are other ways, and you (those who know C# language product priorities, roadmap and abilities) can point us in the right direction much easier than I would. Otherwise, tell us that you don't have the answer, but ROI is too low to even think about it. Fine, I will keep this in the notes and come back to it when time allows (or other smarter folks will do so sooner).

Again, now I will receive many quoted answers explaining how each statement I made is not how it's supposed to be. And again, I will take that as coming from a person who has not walked in my shoes. Need a different perception from me, try a different answer. Thank you!

[ttutisani]

And, BTW, I believe that modular architecture is becoming more common nowadays as people move more into JS and TypeScript. I know that C# was born as an alternative to Java (or maybe I'm biased), but I don't think it should stay like that. Either way, strictly my personal opinion.

[HaloFour]

And yes, I want to have many modules under the solution.

I'd imagine that you'd have much more trouble with Visual Studio (or whatever IDE) than you will with actual deployments. I don't see why a .NET app would have trouble loading that many individual assemblies.

And, BTW, I believe that modular architecture is becoming more common nowadays as people move more into JS and TypeScript.

These languages have vastly different ideas as to what modules are. A JS/TS app is little more than a bunch of loose script files sprayed into a directory with no concept of linking. The module declarations fill the need for that lack of linking by making the dependencies between the files explicit. A compiled language has no such need because there is an explicit linking phase and the dependencies can be defined/shipped as units. Whether you call those units "modules" or "assemblies" or "libraries" or "crates" or "packages" isn't relevant.

I seriously doubt that the JS/TS/python approach to modularization will come to C#, or any other compiled language. There really isn't that much need for it. And where those compiled languages do have modules, they're usually a lot less granular than what you're suggesting.

It's funny you mention Java because Java specifically did need to add modules to the language and runtime because otherwise Java apps were little more than a bunch of loose class files sprayed into a directory structure. That was never a problem in C# due to having assemblies and proper internal accessibility.

In any case I don't think modularity has anything to do with "friend" classes. Again, it seems that OOP languages with modules haven't found "friend" classes to be necessary.

[ttutisani]

I'd imagine that you'd have much more trouble with Visual Studio (or whatever IDE) than you will with actual deployments.

I actually meant the IDE when loading so many projects, not the deployment or the runtime. Having too many projects (to use them as modules) seems impractical due to the IDE. And that is what I asked as one way to solve this problem - to make assemblies cheaper to load in Visual Studio.

As for the relation between the friend classes and modules, I personally could settle with one or another feature. I do see them helping me achieve cohesiveness between classes.

Perhaps cohesiveness is the right way to describe what the friend classes achieve. There is a blurry line between where the cohesiveness ends and where the tight coupling starts, but I assume developers know that. Naturally, in OOP (and especially in design patterns), there are cohesive classes. Implementing them is hard in C#. e.g., a Factory creates a class, and it must be the only means of creating that class. How do you achieve that without nesting the class inside the factory or the other way around? And even that is not scalable. Another example - Low of Demeter - a clean way of defining clusters of classes. Without the friend concept, it is not easy, requires boilerplate code or constant discipline enforcement.

In JS/TS, a file can be considered a module, allowing the definition of a cluster of classes and exporting only what's necessary to the outside world. So the granularity is much higher than in C# and other compiled languages. The added modules you mentioned perhaps refer to the specific libraries such as Angular (which adds modules on top). That is why the modularity may not be the C# feature but an added technology on top of it. I once wanted to create a framework that would allow doing so, but time is limited. Maybe somebody will create it someday.

So as for the C# as a language, maybe asking for modules is too much. However, constructs for defining cohesive clusters of classes are clearly missing. And same is true in other languages. Lack of them thereof, in my opinion, is not an indication that they are not necessary. They were not necessary earlier maybe, but times change. We speak about many ancient languages, and comparing C# with them is not what I want to do.

[svick]

@timcassell

I don't think multiple languages adopting a feature should be a pre-requisite to any feature. After all, didn't C# champion async/await?

It's definitely not a prerequisite. But if you look at the history of those two features, you'll see that async-await spread fairly quickly from C# to several unrelated languages. On the other hand, friend didn't spread from C++, even though it had more time and languages that were effectively successors of C++. To me, that strongly indicates async-await is a widely useful feature, while friend isn't.

[ttutisani]

Well, I can't say for sure what will happen in the future, but history also holds facts when somebody tried something too early, and it did not take off. Later, somebody else tried the same thing, and it worked out. We all know stories of touchscreen-enabled smartphones, ipads, and electric cars. I just wanted to leave this comment here for when things change. 😉

[CyrusNajmabadi]

Fwiw, I run into cases where I think friends might be useful about once every two to three years. However, when that happens I often after back and look at what I'm creating and think that there's often something fishy about the design. This often leads to a rethinking of what I want this component to provide, and how I should organize it differently to encapsulate the functionality I want to be public and what should not be.

In the end, I've always found a nicer approach that has precluded the need for 'friend'. As such, I've never found this an area worth championing, or something that I would really support on the ldm.

[Richiban]

I know it's a bit of a cliché by now, but an analyser combined with internal visibility and a FriendAttribute would give you all of the safety you want and would allow you to finely tune the exact behaviour according to your requirements.

I can see why the language team is resistant to adding this to the language. Most language suggestions could be implemented with some combination of source generators and analysers; those that get upgraded to language features must meet the following bar:

• Must have a clear benefit, enabling something that used to be impossible, difficult, or overly repetitive given its frequency
• Must not have too niche a use case
• Must be difficult-to-impossible to implement with analyzers / source generators
• Must be difficult-to-impossible to simply work around
• Must be as difficult as possible to misuse

If you meet most of these criteria you stand a chance of becoming a language feature, but I don't think friend classes meets this bar. It's a bit too niche, it's easily implemented with an analyser, and I can easily see that with its use library designers can easily tie themselves up into knots.

[CyrusNajmabadi]

I don't see it as a cliche :) It's effectively exactly what we mention as the use case for analyzers. A way to limit what is currently legal but you don't want in a particular case :)

[Flavelius]

I've had may times where i needed that feature and always just found my way back here. For me it's using game engines that suggest or dictate a certain way of working with scripts, assemblies and inheritance.
In unity for example assembly names are by default user-definable/editor editable (asmdef) and typically change throughout the project lifetime. This makes it an easy source of errors if one was to use InternalsVisibleTo with the need to sometimes even adjust/modify thirdparty sources which is very undesired.
In godot which by default expects there to be just one game-code assembly, this is not even possible.
But even if it was possible, i wouldn't want to create a separate assembly for every class that needs the friend functionality/behaviour, just to not also expose other internals undirectedly.
Nesting there is also no option, as engine provided basetypes-inheriting classes are expected to be (/will only work when) un-nested and placed in specifically named files.

[CyrusNajmabadi]

@FyiurAmron as mentioned, if you want to discuss moderation further, please take to discord. It is off topic here.

[DavidArno]

@Flavelius,

You're right, that was what i was trying to say with these examples. In my understanding, a (programming-) language adapts to problems that users have.

Absolutely. I may have phrased my question badly, but it was a genuine question: should we expect the language to change in those cases, or should the frameworks change?

On the one hand, Unity is mono-based, with C# being a key language used to develop Unity games. If there are issues between that game engine and C# itself, there is a good argument for saying that the game engine needs to change, not the language. However, on the other hand, there are things like default interface methods, as you mention. One of the driving forces of that change was to enable C# to better align with mixin-like features of iOS and Android APIs. Tthere is precedence here for anticipating that the language will change to meet the framework needs therefore.

To my mind, the default position should be "if the framework/API can change to conform to the language and tooling then it should. If it can't, and there's enough user demand, the language should change".

[HaloFour]

On the one hand, Unity is mono-based, with C# being a key language used to develop Unity games.

Based on a number of proposals to this repo it would seem that Unity maps somewhat awkwardly to Mono/C# in general which creates friction points and gotchas. Even basic stuff like null checking works very differently.

I agree, though, that in general these cases are better solved in the framework or runtime than in the language, especially where the established idiom is considered to work well across the rest of the ecosystem.

[CyrusNajmabadi]

@mdmozibur this discussion has few upvotes and lots of down votes. Length of time is not relevant here. If this isn't a good idea for her language then it won't be done, regardless of how long it has been.

Currently this has no champion, meaning no one on the ldm views this as something that feel is worthwhile to move forward on.

[mdmozibur]

Few upvotes? Look at the first proposal champion and how many upvotes it got.

[CyrusNajmabadi]

What champion are you referring to?

[mdmozibur]

6300 ?

[CyrusNajmabadi]

#6300 is about implicit parameters. I'm not seeing how that's relevant to this discussion.

[helviett]

The problem with nested classes is that I normally would like outer class to access properties of the inner class but not the other way around. For example, here is class Text and class Line. Text consist of Lines. If I would like (and it's easy to imagine why) Text to access some private parts of Line than I should nest Text in the Line which is semantically ridiculous. So I would really like to have some way to allow access of private field of certain class because it's helpful and internal has too wide range (entire assembly). And I think that the best way of doing it to upgrade the type visibility options. internal is too wide, so the problem may be solved with this proposal #6794.

[seanofw]

For what it's worth, I run into a need for friend about two or three times per year. Different projects, different scopes, different purposes, different industries, millions of lines of code — all arriving at the same answer. Maybe that's because I did fifteen years of C++ before fifteen more years of C#, so I may recognize the problem more readily than those that haven't done much C++, but I keep bumping into a need for this, over and over and over again, so I thought I'd finally talk about it.

There are certain semantics that seem to be common to every case where I've encountered it:

• The declaring class is always public, with private innards that need to be shared with something else.
• Changing those innards to be public is too public; the goal is still to have the class still be tightly encapsulated and to protect itself from misuse.
• Keeping them private is too private; some other class genuinely needs privileged access. (FooManager needs to manage Foos, but nothing else should.)
• protected doesn't help, because there's almost never an inheritance chain involved. (Builder pattern, for example.)
• Nested classes don't help, because the would-be friend class needs to exist in a namespace as visible as the class that befriends it. (Unit tests are a good example; they're rarely even in the same assembly, much less nested within the parent.)
• internal interface complicates the code enough that it's impractical to use: The befriender class needs to add complicated declarations and complicated calls everywhere throughout its own code just to be able to expose its innards to its would-be friend, and that exposure is granted to anyone who knows how to cast: It's really no different than public, just with some obscurity.
• internal is too public: The goal is to privilege one or two special classes, not a whole assembly.
  • In some cases, the assembly is a big blob of legacy code, and it can't be broken up, so internal exposes the innards of the class to a mountain of other code that should not have access to it.
  • In other cases, it's typically a package being consumed by something else, and consumer expects a single DLL, not a tree of multiple DLLs.
    internal couples a language keyword to a deployment concern, and not infrequently, you can't break up that assembly just to have access controls between two or three classes via internal. friend is very narrow in scope: To counter what some have said above, when I see internal in code, I often see a situation where friend would have been better-used instead!

(Example use cases, among others: Builder patterns, validator patterns, serializer patterns, manager/owner patterns, unit-test patterns, and a whole raft of others: There are lots and lots and lots more I've encountered.)

This is arguably the only feature of C++ I wish existed in C#. For those who've said, "Well, other languages don't have it," that's a pretty bad argument: Many languages didn't have garbage collection in 1995, but that didn't make GC a bad idea. Many languages didn't have lambdas or lexical closures in 2001, but that didn't make lambdas a bad idea. Many languages don't have true continuations today, but that doesn't make them a bad idea either. Languages build on top of each others' work, and even if friend hasn't spread outside of C++, that lack of spread doesn't necessarily make it a bad idea. Paul Graham's argument about the language continuum continues to hold: You can only ever look down the mountain, not up.

Access controls are a lot like keys to doors in a building. In some cases, you always leave the doors unlocked and public (a train station, for example). In some cases, you only allow certain groups of internal people to use the doors (businesses may require employees to carry keycards to get in the building). protected is that situation where a manager unlocks a door only for the employees in his part of the org tree. But friend covers that case where you give a special key to only one or two people, and there can be good reasons for doing it: Just because you let employees into the building doesn't mean you also let them into the server room or into the corporate finance offices; in real life, I can hire a third-party accountant by-the-hour and give him a key only to the corporate finance office.

There's no good answer every time I've run into this, and it keeps coming up: The language insists that when I draw Venn diagrams for access control, the circles may only fully contain other circles, and may never have partial overlap. So I'm forced to usually just declare methods to be internal and then add a big scary "Warning: This is intended for use only by class X" message on top of each of them. It's a shame there still isn't a proper, formal solution, especially considering similar warning messages show up in the .NET framework classes themselves — the need has existed for a long time, and even within Microsoft too, but the language still hasn't met it.

[CyrusNajmabadi]

@DavidArno file access wouldn't comfortably cover the many, many use cases where the friend class was located in another namespace,

It actually would cover the case of being in a different namespace. :)

or even in another assembly.

It would not help there. But the analyzer approach certainly would.

[seanofw]

@DavidArno I pointed out several different patterns where this problem tends to show up, and there are plenty more. I don't know where you draw the line for "many, many use cases," but I encounter a need for friend a lot more often than I need some features that got included in C#.

[CyrusNajmabadi]

Could you enumerate those cases? That's critical to know if there are existing workarounds, as well as to candidate that some particular solution would actually work out for you in the end. For example, if a potential friend solution did not work across assemblies, that would break one of hte caes you mentioned. But without having that case listed, that would not have been realized.

[seanofw]

The list is really long, but here are some notable examples:

• Builder patterns. The output of FooBuilder should be an immutable Foo. There are lots of ways to implement this (including the nice new with keyword), many of which make intermediate copies. But a way that you can't implement it without friend is allowing FooBuilder to have direct write access to Foo's fields before returning an immutable result to everyone else. (Notice how the implementation of String, for example, actually does this exact pattern in the framework: It uses hackery to access the array under the hood to populate it before returning an immutable object. Some of the String methods would work better as builder classes, but they can't without a performance hit, because friend doesn't exist.)

• Serializer patterns. This is somewhat like a builder pattern in reverse: I have a Foo that should have limited access from the outside, but I'd like to provide convenient ways for turning it into raw data or creating it from raw data, especially considering that ordinary users of Foo don't even know about some of the data stored inside it. (For example, I might have a JpegImage that retains the original coefficients, which I do not want to expose to callers who'd badly break them — but I do want to expose safe and convenient Rotate() methods, which internally require those coefficients.) I'll expose ToBytes(), FromBytes(), ToWonkyNewDataFormat(), FromWonkyNewDataFormat(). Sure, I can make Foo a partial and embed some of the serialization logic inside it, but it would be far cleaner to make WonkyNewDataFormatSerializer its own class that just has direct access to Foo's privates — as well as those of loosely-related classes Bar and Baz.

• Manager patterns. I have a Foo, and a big FooManager that orchestrates lots of Foos. It constructs them, maintains them in its own internal collections, and it's vitally important that only it has access to most of Foo, even if I'd like others to be able to hold direct references to the Foos — anybody else changing the Foo innards could break things in bad ways. (Consider, say, a TcpMultiplexer that shares virtual channels to callers, but needs to ensure they're all properly sharing the correct real TCP connection. Or a RedBlackTree that would like to share its RedBlackTreeNodes with the world, but others should definitely not be allowed to set IsBlack to true!)

• Unit-test patterns. I have a Foo that performs computation in memory and needs to be properly tested. FooTests don't belong in the same assembly — we don't want to deploy them to production! They need to still have privileged access to that class to prove its correctness — but they should also not have privileged access to Bar, which just happens to be in the same assembly as Foo. (Example: ParserTests should have access to Parser, and LexerTests should have access to Lexer, but not vice-versa. But you still want to distribute Lexer and Parser as a single assembly, because neither is really useful without the other.)

In every one of these cases, internal works fine — as long as Foo is the only thing in its assembly, as long as access control is tightly constrained around just the one class. But as soon as you say, "I want FooManager to be part of the Foo Framework," or "I want JpegImage to be part of the image library," or "I want FooTests to have access to Foo, and BarTests to have access to Bar, but not the other way around," you have no choice but to either split up the code in unnatural ways or simply give up and make everything public or internal and hope nobody will misuse your code.

---

And one addendum that's important to note: The examples I gave above are patterns, not instances. They're whole separate categories of cases where this problem shows up, and some of them even appear as instances in the .NET standard libraries themselves. For example, consider how Task exposes many properties as internal that really should only be used by the rest of the task-management logic, but that are still used elsewhere in the framework classes; I doubt that Stream writing to Task.m_TaskScheduler is really something the designers of Task would consider ideal: friend would have ensured that TaskScheduler, TaskContinuation, and TaskAwaiter were the only ones touching that. As long as misuse is possible, misuse will happen in any sufficiently large codebase.

[seanofw]

@DavidArno One other thought: The use cases for friend tend to show up a lot more in architecture, not business logic. Yes, I only encounter a need to write friend two or three times per year — but it's always in frameworky code that lots of other code will depend on. Everything else would depend on the security friend would provide, if it existed. But instead of a locked door and a barbed-wire fence, the best I can do is set up a red-velvet rope and hope that everyone walking by chooses not to jump over it.

[DavidArno]

Unit tests are a good example; they're rarely even in the same assembly, much less nested within the parent.

I disagree on the validity of this specific point. Unit tests should test the public surface of an assembly. If your unit test class needs to fiddle with the internals of the code under test then you have designed either the tests or the code badly.

[CyrusNajmabadi]

Here's a problem encountered in many different use cases and is trivially solved with language feature X

I reject that this is "Trivially solved with a language feature". At the very least, it will cost 4-5 orders of magnitude more than doing an analyzer here.

This will involve likely > 1 dozen people working for weeks on a design that is sufficient for all use cases, is appropriate for the future of the language, fits into the entire .net ethos and ecosystem, etc. etc. etc.

Write and test a thousand lines of code

I would estimate it at a couple hundred lines yes.

in a custom Visual Studio extension

No need for a VS extension. Roslyn analyzers are bog-standard nuget packages that you can use.

that everyone on your team needs to install

You can trivially make that part of your build-system and have it happen when your packages restore locally for a user.

and that only fixes the problem for those who are using it"?

Your build system (even the one running locally) will automatically use this. Your users would have to do work to not have this run.

Just to be sure, your recommended solutio

Yes. This is 100% my recommended solution. It can be done by a single person, in an hour or so. Works today. Works downlevel to several prior versions of the compiler. Can run quickly. Can already work with all major tools in the .net ecosystem (VS, VS4Mac, OmniSharp, Rider/Resharper). etc. etc.

ANd, as per above is likely 10k-100k times less costly than doing a lang feature here.

--

Finally, i would say that any place where something is possible today, but the request is to just add 'guardrails', is exactly the place where analyzers is a really good choice.

[DavidArno]

@DavidArno To put a proper point on it, then, you've got a compiler with 100,000 lines of code in it, and your way of testing it is compile.exe somefile.yourlang inside every unit test? compile.exe is the only top-level interface that your end users will see, after all.

I would be very sad if I had 100,000 lines of code in a single project. And if that code were spread over multiple assemblies, then each would have public APIs (methods, properties, constructors etc) and each of those APIs is a test point. Everything that isn't public is an implementation detail and unit testing 101 is "test the behaviour, not the implementation" so they do not want to be tested.

Do you test a million lines of web browser code by putting URLs into it, one for each test case, and making sure you then get the right pixels out? That's the top-level interface too.

If I had a million lines of code in a single project, I'd be very very sad. And if that code were spread over multiple assemblies, then see above.

I feel this is going off at a tangent though and isn't really relevant to the discussion around friend classes. I personally feel that your desire to use friend classes to implement your listed patterns sits firmly in the anti-pattern space, but I'm not an arbiter of your code. If you wish to implement things that way, then as Cyrus has explained, you can easily achieve this with a simple analyzer that errors if any type but MyFriend attempts to access a type annotated with [ExposeToFriend(typeof(MyFriend))].

[seanofw]

@DavidArno I've worked in several real-world systems where there were upwards of a half-million lines of complex business logic in a single assembly, and the entire solution had several million. It happens. Often. At many companies.

But my real point was that "top-level interface" is really determined just by where you choose to draw the cutoff line. The top-level interface for a single math function is the call itself. That FastSqrt() used by a 3D renderer has a top-level interface that starts at DrawPolygon(). That same 3D renderer used by a game engine has a top-level interface that starts at RenderScene(). That game engine has a top-level interface that starts at gamepad input. It can keep going up, too, way beyond user input: A web browser has millions of lines of code; it may be used by a test-automation suite that has millions of lines of code in it; and that automation suite may be parallelizing thousands of web browser instances in the cloud using the millions of lines of code in Kubernetes and Terraform and Docker.

Each one of those layers treats the others as a black box, so where do you call the top? Is it at 10 lines of code or 10 million? If you only ever look at the top brick of a pyramid, how can you be even remotely certain that what holds it up is stone, not sticks?

[CyrusNajmabadi]

how can you be even remotely certain that what holds it up is stone, not sticks?

All that vice most eventually be exposed to clients through some api. Test that api. Now you are certain.

But, again, of you really want to do this, nothing stops you.

Finally, if you are testing these levels, then why do you need friend? They're so well tested that they can clearly safely be used by any of your code. Hiding it isn't necessary. And, if you do really want to unnecessarily block using it, then use an analyzer, that's what they're there for.

[RikkiGibson]

I would be very sad if I had 100,000 lines of code in a single project.

Here's the CLOC output for Microsoft.CodeAnalysis.CSharp (C# compiler implementation). :)

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C#                            1073          66943          54807         371701
XML                             17            909            943         175507
Text                             3              0              0           6070
ANTLR Grammar                    1            294              1           1120
XSD                              2              0              0            286
MSBuild script                   1              3              9             73
DOS Batch                        1             21              3             66
-------------------------------------------------------------------------------
SUM:                          1098          68170          55763         554823
-------------------------------------------------------------------------------

IMO, the decision on whether to split assemblies is a question of consumption/deployment. If the library does a complex task, it might need a lot of code for it. Doesn't necessarily mean there's a reasonable way to split it.

The compiler makes fairly judicious use of InternalsVisibleTo. We use it for testing. It's important to us to test parts of our internal surface as well as our public surface. However, I would echo the point about it being beneficial to test entry points, or members which are likely to retain a similar shape for a long time. One time your tests are especially valuable is when you swap out down-layer components or private members, and the test results from the same suite give you confidence in the correctness of that substitution, without having to deeply refactor the tests (which ends up introducing doubt as to whether the tests themselves are still correct).

[liyou54]

I encountered this situation...
`interface Command {
void Excute();
}

class CommandMgr(){
public ExcuetCommand(Command cmd){
// must do something before
cmd.Excute();
// must do something after
}
}`
As shown in the code above, I need to use the command manager when executing commands, but I can't guarantee this.

[iam3yal]

@liyou54 Your case can be easily addressed through events, though other solutions are also viable but I'm not sure how this issue solves your problem?

class CommandMgr() {
    public ExcuetCommand(Command cmd) {
        OnPreCommandExecute(cmd); // Raises the event PreCommandExecute
        cmd.Excute();
        OnPostCommandExecute(cmd); // Raises the event PostCommandExecute
    }
}