Why can't I access C# protected members except like this?

Question

This code:

abstract class C
{
    protected abstract void F(D d);
}

class D : C
{
    protected override void F(D d) { }

    void G(C c)
    {
        c.F(this);
    }
}

Generates this error:

Cannot access protected member 'C.F(D)' via a qualifier of type 'C'; the qualifier must be of type 'D' (or derived from it)

What in the world were they thinking? (Would altering that rule break something?) And is there a way around that aside from making F public?

---

Edit: I now get the reason for why this is (Thanks Greg) but I'm still a bit perplexed as to the rational; given:

class E : C
{
    protected override void F(D d) { }
}

Why shouldn't D be able to be able to call E.F?

---

The error message is edited so I might have put a typo in there.

Answer 1

The "protected" keyword means that only a type and types that derive from that type can access the member. D has no relationship to C therefore cannot access the member.

You have a couple of options if you want to be able to access that member

• Make it public
• Make it internal. This will allow any types to access the member within the same assembly (or other assemblies should you add friend's)
• Derive D from C

EDIT

This scenario is called out in section 3.5.3 of the C# spec.

The reason this is not allowed is because it would allow for cross hierarchy calls. Imagine that in addition to D, there was another base class of C called E. If your code could compile it would allow D to access the member E.F. This type of scenario is not allowed in C# (and I believe the CLR but I don't 100% know).

EDIT2 Why this is bad

Caveat, this is my opinion

The reason this is now allowed is it makes it very difficult to reason about the behavior of a class. The goal of access modifiers is to give the developer control over exactly who can access specific methods. Imagine the following class

sealed class MyClass : C {
  override F(D d) { ... } 
}

Consider what happens if F is a somewhat time critical function. With the current behavior I can reason about the correctness of my class. After all there are only two cases where MyClass.F will be called.

1. Where it's invoked in C
2. Where I explicitly invoke it in MyClass

I can examine these calls and come to a reasonable conclusion about how MyClass functions.

Now, if C# does allow cross hierarchy protected access I can make no such guarantee. Anyone in a completely different assembly can come by and derive from C. Then they can call MyClass.F at will. This makes it completely impossible to reason about the correctness of my class.

Answer 2

The reason this doesn't work is because C# doesn't allow cross-hierarchy calling of protected methods. Say there was a class E that also derived from C:

  C
 / \
D   E

Then the reference you're trying to call the method on could actually be an instance of type E and thus the method could resolve at runtime to E.F. This is not permitted in C# as D cannot call E's protected methods, because E is in another branch of the hierarchy, i.e.

var d = new D();
var e = new E();
d.G(e); // oops, now this will call E.F which isn't allowed from D

This makes sense because the keyword protected means the member "is accessible within its class and by derived class instances" and E.F is not a member of D.

Answer 3

Even though D is inherits from C, D cannot access C's protected members. D can access D's protected (and private!) members, so if you put another instance of D in there instead of C everything would work. But as Greg stated, C could really be something completely different, and because the compiler doesn't know what C really is, it has to prevent D from accessing something D may not actually be able to access.

A series of posts explaining this from the C# compiler's perspective:

• Why Can't I Access A Protected Member From A Derived Class
• Why Can't I Access A Protected Member From A Derived Class, Part Two: Why Can I?

Answer 4

To understand why this kind of behavior makes sense let's consider why we need access modifiers at all in object oriented programming languages. We need them to limit a scope where a particular class member can be used. And that in turn simplifies searching for the usages.

To summarize:

• to find all usages of public member one needs to search through entire project (and this is not enough in case of library that is used by independent developers)
• to find all usages of protected member one needs to search through the container class and all its subclasses
• to find all usages of private member one needs to search through the container class.

So if the compiler allowed to call protected method from superclass in the described way we could end up with cross-hierarchy calling of protected methods as described in this answer. And in such situation one had to search through all the children of the most parent class that defines the member. And that would increase the scope.

PS. The same behavior is implemented in Java.