Question

protected internal:

The union of protected and internal accessibility (this is less restrictive than protected or internal alone)

The CLR has the concept of intersection of protected and internal accessibility, but C# does not support this.

So my question is:

What’s the meaning of omitting this Access Modifier, is there a concrete reason? So why C# should not support it?

Answer 1

Update: C#7.2 is introducing this with the access modifier private protected, which seems wrong in a few ways but does avoid much of the potential for confusion I describe below, so is perhaps the best of a bad bunch.

Personally, I’ve wanted this quite a few times. There are times when one exposes a class and one or more classes derived from it as public in an assembly, and there are times when some member of the base class is only used by those derived classes and should not be exposed to protected classes in other assemblies (quite often the constructor, so as to prevent other assemblies from having classes that derive from it at all).

It is of course always good to define your access as restrictively as possible, and so the intersection of protected and internal is precisely what is wanted here.

Instead, I’ve had to kludge it by declaring the member internal. There is now a potential for bugs in my code that wouldn’t have been there if I used a language that allowed me to use that intersection.

However, consider the downside.

As it is, there’s some confusion about the way that protected internal gives the union of protected and internal. It’s probably the most misunderstood access, judged by questions on sites like this.

What should we call it? internal protected? Can you imagine how often people would get that confused with protected internal? We’d want something more clearly differentiated, and we’d want the same for internal protected (because we’ve still increased its potential for confusion). It’s not an impossible problem to answer, but keeping the number of keywords down is a good idea too.

Even if a perfect answer is found to the naming question, the potential for confusion by introducing yet another level of access is not entirely defeated.

So with that in mind, let’s look at the upside again. We no longer have to kludge the times we need it by using internal, reducing bugs caused by inappropriately using such a member. Okay, how often does that come up, and how likely would such bugs actually be? Not very often really, and not very likely.

On balance therefore, while I do find myself occassionally wishing C# had this, a moment’s pause normally makes me glad they did not.