Why is internal protected not more restrictive than internal?

33
votes

I'd like to create an internal auto-property:

internal bool IP { get; protected internal set; }

I thought it would be possible to make the setter protected or protected internal - but I always get the error accessibility modifier must be more restrictive than the property. Isn't that the case? Private does not help me, here.

EDIT:
The question is: How do I implement an auto-property with a internal getter and a protected setter?

8
c#access-modifiers
Your error is in thinking of the modifiers as increasing restrictions. The modifiers in fact always decrease restrictions. Remember, things are "private" by default; only by adding modifiers do you make them less restricted. – Eric Lippert
+1 - eric lippert you always put it in the best way possible – JonH
Actually, the combination of modifiers is decreasing restrictions. Only setting a modifier is indeed increasing the restrictions such as public bool IP{get; private set;} – Dani

8 Answers

51
votes

It's effectively protected or internal, not and. It's accessible both by derived classes and types in the same assembly. It's a common misconception to think protected internal means accessible only to derived classes in the same assembly.

30
votes

At the .NET level, there are two similar but distinct access levels:

  • FamilyAndAssembly: more restrictive than either protected or internal
  • FamilyOrAssembly: less restrictive than either protected or internal

"protected internal" in C# means FamilyOrAssembly; there's no modifier for FamilyAndAssembly.

So, your protected internal setter is less restrictive than the internal overall property. What you could do is:

protected internal bool IP { internal get; set; }

But then your setter is less restricted than your getter, which is odd...

Another (somewhat equivalent) alternative is:

internal bool IP { get; set; }

protected void SetIP(bool ip)
{
    this.IP = ip;
}
5
votes

I would consider this cheating, since Eric Lippert is on SO himself, but he wrote an excellent blog post that considers this issue.

Why Can't I Access A Protected Member From A Derived Class, Part Three

Ultimately, his answer is largely the same as those given by the posters here, but he ads some interesting reasoning behind the desgin of the language and the implementation of these features.

5
votes

Considering what Jon Skeet mentioned (and user59808's comment), wouldn't this achieve the desired result?

protected internal bool IP { get; protected set; }

2
votes

protected internal is less restrictive than either protected or internal because it allows both its subclasses (protected) and anything in the same assembly (internal) to access something.

1
votes

protected internal means visible to classes in the same assembly, or to classes deriving from the containing class - in other words it is visible to those meeting the internal requirements OR the protected requirements, not AND. There is no access modifier meaning protected AND internal in this way.

1
votes

protected internal means protected OR internal, not protected and internal. So scope is limited to the same assembly OR derived classes, not necessarily both.

0
votes

accessibility modifier must be more restrictive than the property

Internal is more restrictive that protected: because protected things can be seen (by subclasses) outside the assembly.

The compiler is saying that there's no sense in saying that set is protected (i.e. visible to subclasses outside the assembly), when the whole IP property is internal (i.e. invisible outside the assembly).