Introduce a "direct" access modifier to methods to allow only immediate children to call them

[mbhvl]

Rewritten summary of original at https://developercommunity.visualstudio.com/t/Add-an-access-modifier-direct-to-re/804559 :

PROPOSAL:

1. Introduce "direct" access modifier to methods to allow only immediate child-classes to call them. Grandchild classes etc. cannot call them.
2. Introduce "parent" keyword to make the intention clear when calling such a method (where "this" won't). Alternative: reuse "direct".

USE-CASE:

1. Instances of child-classes created by null constructors or by Activator.CreateInstance (in reflection) need to be initialized correctly where there is a chain of Initializers up multiple layers of an inhertance hierarchy.
2. Ditto for any other method e.g. Dispose pattern

RATIONALE:

• A child class can incorrectly (inadvertently) call an initializer in a grandparent class instead of a parent class; this proposal enforces correct chaining of initializers up the inheritance hierarchy.

IMPLEMENTATION:

• The direct modifier extends the parent-only restriction on constructors (where child class constructors can only call the constructor in an immediate parent class) to methods.
• The parent keyword makes explicit the intention of calling a direct parent method

PSEUDOCODE EXAMPLE:

public GrandparentClass
{
    public GrandparentClass(<grandparent class parameters>)
    {
        // call GrandparentClass' initializer
        this.Initialize(<grandparent class parameters>);
    }

    direct void Initialize(<grandparent class parameters>)
    {
        // initialize grandparent class correctly
        ...
    }
    
    // only ParentClass can call this due to direct keyword; ChildClass cannot
    **direct** void Dispose()
    {
        // dispose external references in GrandparentClass
        ...
    }
}

public ParentClass
{
    public ParentClass(<grandparent class parameters>, <parent class parameters>)
    {
        // call ParentClass' initializer
        this.Initialize(<grandparent class parameters>, <parent class parameters>);
    }

    // direct keyword restricts access to this method to ParentClass and (below) ChildClass - no other class can invoke it
    **direct** void Initialize(<grandparent class parameters>, <parent class parameters>)
    {
        // Invoke GrandparentClass.Initialize
        parent.Initialize(<grandparent class parameters>);

        // ALTERNATIVELY use "direct"
        direct.Initialize(<grandparent class parameters>);

        // initialize parent class correctly (initialize parent class local members)
        ...
    }

    **direct** void Dispose()
    {
        // Invoke GrandparentClass.Dispose() - this.Dispose() would be ambiguous
        parent.Dispose();
        // or direct.Dispose();
        
        // dispose external references in ParentClass
        ...
    }
}

public ChildClass
{
    public ChildClass(<grandparent class parameters>, <parent class parameters>, <child class parameters>)
    {
        // invoke ChildClass.Initialize()
        this.Initialize(<grandparent class parameters>, <parent class parameters>, <child class parameters>);
    }

    direct void Initialize(<grandparent class parameters>, <parent class parameters>, <child class parameters>)
    {
        // **FAILS TO COMPILE** - ChildClass **cannot** call any **direct** method in GrandparentClass
        parent.Initialize(<grandparent class parameters>); 
        // or direct.Initialize(<grandparent class parameters>); also fails

        // Compiles fine - ChildClass **can** call **direct** method in ParentClass
        parent.Initialize(<grandparent class parameters>, <parent class parameters>);
        // or direct.Initialize(<grandparent class parameters>, <parent class parameters>);

        // Initialize ChildClass - assign <child class parameters> to local ChildClass varilables
        ...
    }

    **direct** void Dispose()
    {
        // Very specifically invokes Parent.Dispose().  Does not invoke Grandparent.Dispose() as it cannot see it.
        parent.Dispose()
        // or direct.Dispose()

        // 
    }

}

DESIRED BEHAVIOR:

1. Incorrect chaining ChildClass.Initialize() => GrandparentClass.Initialize() causes a compiler error.
2. Correct chaining ChildClass.Initialize() => ParentClass.Initialize() => GrandparentClass.Initialize() enforced.

BENEFITS:

1. Non-breaking change via a new keyword.
2. Solve inheritance chaining & debugging issues comprehensively.
3. Enforce structured Dispose()

[huoyaoyuan]

This can technically be done via an attribute and analyzer reporting error. The pattern isn't common enough for language support.

Generally, anything shrinks accessibility will probably be rejected as language feature.

[mbhvl]

Interested to learn more about "attribute and analyzer reporting error". Got any more info on that?

[mbhvl]

Not sure I understand the idea "Generally, anything shrinks accessibility will probably be rejected as language feature."

First, child-classes can only call parent-class constructors; that's by design. And the language already has keywords such as a private.

Secondly, in the field of security we like code to be secure by design. So this simply extends that idea, in an optional way.

Always good to get feedback so please continue if you can.

[huoyaoyuan]

And the language already has keywords

It's in fact not the language's. It's accessibility in IL and CLR. The language just provides a syntax mapping the the underlying feature.

Secondly, in the field of security we like code to be secure by design.

Accessibility can be easily bypassed in many ways, like reflection. CoreCLR doesn't have any restriction on that.

[mbhvl]

The C# language specification defines "private" & "base" as reserved keywords:
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/

So if I understand your comment correctly, IL/CLR could be updated first and the C# syntax enlarged to map to it. But if just a C# syntax change is needed, why can't that be done on its own?

I take your point about reflection; but my objective is to respect accessibility strictly not to bypass it.

[HaloFour]

There is nothing in the runtime that prevents a direct call to any method in the hierarchy. In fact being able to statically call any base method is required to enable base calls to work at all. Even if C# were to implement such a restriction it could not be enforced against any of the other several dozen .NET languages unless every compiler also implemented such a feature, and it would still be trivially bypassed via reflection or IL.

[mbhvl]

Thanks for the response. That's a little beyond my level of understanding. My request is for C# syntax, rather than fundamental change to IL or CLR. Does your answer mean this would or would not be possible, as C# syntax?