Why is it not "inconsistent accessibility" to use a private nested type inside a generic type in the interface list?

Question

In case the title is not completely self-explanatory, here's the code that puzzles me:

public interface IFoo<T>
{
}

public class MyClass : IFoo<MyClass.NestedInMyClass>
{
  private class NestedInMyClass
  {
  }
}

I'm suprised this compiles with no error. It feels like I'm exposing a private type. Shouldn't this be illegal?

Maybe your answers will simply be "There's no rule against that, so why wouldn't it be OK?" Perhaps it's equally surprising that MyClass.NestedInMyClass is even in "scope". If I remove the MyClass. qualification, it will not compile.

(If I change IFoo<> into a generic class, which should then become base class of MyClass, this is illegal, for a base type must be at least as accessible as the type itself.)

I tried this with the C# 4 compiler of Visual Studio 2010.

Answer 1

No external code can cast the object to this interface, so it's not an accessibility issue.

public classes are even allowed to implement private or internal interfaces - and similarly, no cast can actually occur from external code.

Re: discussion about implementations that depend on T - you'll be allowed it if you use explicit interface implementation - because the methods for the interface are effectively private in that case. E.g.:

public interface IFoo<T>
{
  void DoStuff(T value);
}

public class MyClass : IFoo<MyClass.NestedInMyClass>
{
  void IFoo<MyClass.NestedInMyClass>.DoStuff(MyClass.NestedInMyClass value)
  {
  }
  private class NestedInMyClass
  {
  }
}

works (because the interface implementing method isn't exposed by the class itself).

Answer 2

The fact that a class implements an interface means that code which can create a storage location of an interface type can store a reference to that type in that storage location, and can use interface members on that storage location. It does not give any new ability to code which would not otherwise have the ability to create a storage location of that type.

Having a public class Foo implement an interface of a private or internal type IBar enables code which has access to IBar to cast Foo references to IBar. The fact that Foo is accessible to code which doesn't have access to IBar in no way implies that it isn't also going to be used by code which does have such access. Indeed, it would be quite normal that the assembly or class where Foo is defined would want to use features of Foo which are not available to the outside world; the fact that it implements IBar would merely be one such feature.