Why can't a class extend its own nested class in C#?

Question

For example:

public class A : A.B
{
    public class B { }
}

Which generates this error from the compiler:

Circular base class dependency involving 'A' and 'A.B'

I always figured a nested class behaved just like a regular class except with special rules concerning accessing the outer class's private members, but I guess there's some implicit inheritance occurring between the two classes?

Answer 1

There's no implicit inheritance involved as far as I can tell. I would have expected this to be okay - although I can imagine weirdness if A and B were generic.

It's specified in section 10.1.4 of the spec:

When a class B derives from a class A, it is a compile-time error for A to depend on B. A class directly depends on its direct base class (if any) and directly depends on the class within which it is immediately nested (if any). Given this definition, the complete set of classes upon which a class depends is the transitive closure of the directly depends on relationship.

I've highlighted the relevant section.

That explains why the compiler is rejecting it, but not why the language prohibits it. I wonder if there's a CLI restriction...

EDIT: Okay, I've had a response from Eric Lippert. Basically, it would be technically possible (there's nothing in the CLI to prohibit it), but:

• Allowing it would be difficult in the compiler, invalidating various current assumptions around ordering and cycles
• It's a pretty odd design decision which is easier to prohibit than to support

It was also noted on the email thread that it would make this kind of thing valid:

A.B x = new A.B.B.B.B.B.B.B.B.B.B.B.B();

... but that would already (as noted by Tinister) be valid if B derived from A.

Nesting + inheritance = oddness...

Answer 2

I wonder, is there any particular reason that you would want to do this, or did you post it for the sake of discussion and learning? What would be the practical application if it were possible?

Answer 3

This makes no sense to me... You are trying to extend something that doesn't exist !!! Class B only exists in the scope of class A and because of this I think there is some kind of inheritance.

Answer 4

I think the nesting is meant to represent that the nested type is part of the definition of the nesting type. With that interpretation, the limitation makes sense because at the time the compiler hits the definition of A, A.B is not yet defined, and even at the end of A, it is already defined in terms of A.B.

Answer 5

This is not a C# thing as much as it is a compiler thing. One of the jobs of a compiler is to lay out a class in memory, that is a bunch of basic data types, pointers, function pointers and other classes.

It can't construct the layout for class A until it knows what the layout of class B is. It can't know what the layout of class B is until it finished with the layout of class A. Circular dependency.

Answer 6

When you declare a nested class, you are in essence saying that the nested class is a member of the containing class. That is: B is a member of A, and class B cannot exist outside of the scope of class A.

In other words, by nesting the classes you are stating that B should not exist outside of A's scope. Unlike a namespace, you cannot declare an object of type B. You can only declare an object of type A.B, since A's existence is required for B to exist. So while there is no inheritance, there is a direct dependence.

Additionally, as outlined in the specification in the Nested Types section, nested types have access to all of the container class's methods.

10.2.6.5 Access to private and protected members of the containing type
A nested type has access to all of the members that are accessible to its containing type, including members of the containing type that have private and protected declared accessibility.

So B can contain references to A that are private/protected, meaning B cannot be fully resolved and created unless A can be fully resolved and created, and if A depends on B you end up in a strange loop. So while it is not explicit, it is strongly implied that A cannot inherit from B due to this relationship.

If A could be derived from B, then A's definition would be recursive and the compiler might never be able to finish resolving A. While there might be ways to allow these sorts of constructs, they have been explicitly disallowed in C#.

Answer 7

Regarding questions about what I was attempting to do:

Basically, I wanted to create a class that had a composition relationship with itself, but I didn't want to have the contained object to contain other objects and therefore create a chain with many "A has-a A has-a A has-a A has-a..." relationships. So my thought at the time was do something like this:

public class A : A.AA
{
    public class AA
    {
     // All of the class's logic
    }

    private AA _containedObject;
}

Which at the time seemed pretty slick but in retrospect I'm not so sure...

I had rummaged through Google and didn't find any good discussion on it so I thought I'd post it here.

However, within the comments of a post at Eric Lippert's Blog he gives examples of a class implementing a nested interface as well as a class implementing a generic interface with a nested class as the type argument (which doesn't compile and he calls a "bug" in the current compiler). Both of those examples concern interfaces so I was wondering if there was some special rules with nested classes. And it seems there are.