Limit protected inheritance tree to their n-th children

[Daynvheur]

Hello,

At the moment, there are only two ways of (not/)sharing fields and methods through inheritance:

• Either not sharing anything by marking them as private
• Or sharing with the entire inheritance tree via protected (not mentionning internal and public, as they extend beyond inheritance tree)

Would it be possible to have an n-th inheritance level, something like protectedX to mark the field as inheritable by their X descendants (if not overwritten by said descendant).

public class M1
{
    protected2 int i = 0;
}
public class M2 : M1 {} // M2.i == 0
public class M3 : M2 {} // M3.i == 0
public class M4 : M3 {} //CS0117: 'M4' does not contain a definition for 'i'

This is an open discussion, I'd like to have your pov on those:

• Having the field suddenly disapear from inheritance may be surprising;
• Knowing what quantity of "remaining inheritance is left" is a concern;
  • Overwriting may still be allowed as in M3 : M2 { protected new int i => base.i; } to reset inheritance
• Changing inheritance order may actually break things M4 : M2 {} // M4.i == 0, but that may not differ from actual inheritance fonctionnality;
• Keeping the actual "infinite" protected keyword action is crucial;

Have a nice day.

[teo-tsirpanis]

You can use the private protected access modifier to somehow limit which subclasses can access methods of the base class.

[YairHalberstadt]

What is the usecase for this?

[Daynvheur]

I don't really know. It's more of a thinking than a profound need.
Is a usecase required?

[YairHalberstadt]

Yes. Nothing is ever going to be changed unless there's a strong usecase for it.

[teo-tsirpanis]

For a .NET feature, especially in the C# language of course a use case is required.

If you want to limit access to a member of your class to subclasses that are declared in your assembly only you can mark it as private protected. Is that acceptable for you?

[Daynvheur]

I had a look at your answer, and this is valid if I want to catter my inheritance tree within multiple assemblies.
I'm not doing that, but I'm actually having to figure out a usecase, thus it's an option.

[WispArchitecture]

I see this as similar in some ways to friend (one of my top 3 Missing in C#'s), and more generally as associative visibility - the ability to control visibility based on associations and relationships. In this case the relationship is the inheritance hierarchy. With friend it is an association. My typical use case is implementing Components and Interfaces (not interface). They are bi-directionally navigable, and
each requires (compositionally) the other. You can't do this in C# (circular) so one must become dominant (uses constructor to get value), and the other must expose a (public) acquire method. So, a (designed/normally private readonly) method that is used once (at creation) by one class must be made public and nullable.

A general "VisibleTo" construct could provide a foundation for friend, and cascade relationships.

public class Interface {
    [VisibleTo<Component>]
    private void SetComponent(){}
}

private class Component : VisibleTo<SomeClass> {
    [VisibleTo<Interface>]
    private void SetInterface(){ }   

    [VisibleToDescendents(1)]
    protected void FirstChildOperation() { }
}

[danmoseley]

Probably best discussed in csharplang, moving it..