Why can't an interface contain types?
c#
Solution
Why can't an interface contain types?
Before digging into the question let me clear up a couple of things.
First, the CLR type system does permit nested types inside interfaces. It would be entirely possible to create a version of C# or VB or whatever tomorrow that supported interfaces, delegates, classes, structs and enums to be declared inside interfaces, and it would run on the existing CLR.
Second, I will give you my usual pushback on questions of the form "why does the C# language not implement feature X?" The answer is the same for all values of X. In order to be implemented a feature must be: thought of, designed, specified, implemented, tested and shipped to customers. If any one of those six things does not happen then there is no feature. Feature X is not implemented because one or more of those things did not happen.
Third, the C# compiler team (which I am no longer on) does not have to provide any explanation for not implementing a feature. Features cost money, the budget is finite, and therefore the onus is on the person requesting the feature to justify its benefits against its costs.
Fourth, "why" questions are hard to answer and "why not" questions are even harder.
So, with that said, I'll reject your question and replace it with a question I can answer:
Suppose this feature request had been proposed to the C# design team. What arguments would you have made against it?
The feature, though legal in the CLR, is not legal in the CLS. There are lots of features in C# that are not legal in the CLS, but since the CLS guidance is specifically do not nest types in interfaces because most languages do not support it, implementing the feature in C# is essentially encouraging people to write libraries that cannot be used in other languages. The proposed feature encourages a bad programming practice.
Nested types give you three main advantages. First, they have access to the private members of their enclosing types. This is not a benefit for interfaces, which have no private members. Second, they provide a convenient way to contain a specific private implementation detail of the outer type. This is not a benefit for interfaces, which presumably could not have a private nested type, and which do not have implementation details by definition. Third, they provide a convenient way to associate one type with another; however, this is better done by namespaces.
No one else to my knowledge is requesting the feature. Let's not spend money on a feature that hardly anyone wants when there are plenty of features that customers do want.
Implementing the feature doesn't make the language more powerful or more expressive in any way in of itself.
Implementing the feature is not a stepping-stone to some more awesome feature that I am aware of. The feature doesn't tie into any other "theme". It's a "completionist" feature that eliminates a small non-orthogonality, not a useful feature.
There exists an easy workaround for the lack of the feature; just make the nested type a top-level type.
That's the case against. Without someone to advance a case for the feature, it's not going to last in the design committee meeting for more than maybe five minutes tops. Do you care to advance a case for the feature?
Problem
This has caught me out once or twice in C#. I can write code such as this ``` class Node { class Connection { public Connection(Node node, string label) { this.Node = node; this.Label = label; } public Node Node { get; private set; } public string Label { get; private set; } }; IEnumerable<Connection> IncomingConnections() // ... IEnumerable<Connection> OutgoingConnections() // ... } ``` but if I write ``` interface INode { class Connection { public Connection(INode node, string label) { this.Node = node; this.Label = label; } public INode Node { get; private set; } public string Label { get; private set; } }; IEnumerable<Connection> IncomingConnections(); IEnumerable<Connection> OutgoingConnections(); } ``` I get the compile error error CS0524: 'Connection': interfaces cannot declare types I understand the restriction, but what I'm interested in is why. I can certainly have nested types in a C++ "interface" (which is just a class with abstract members so no surprise), and apparently it's possible in Java too, see Interfaces Cannot Declare Type Issue C#. So given that C# learnt some things from Java, why is it lacking in this respect (if indeed it is lacking)? (Apologies if this has already been addressed elsewhere. I also found Interfaces cannot declare types and Why can't I put a delegate in an interface? but they didn't seem to address my question directly.) Edit I thought I'd just add a note to say that in the Java world it seems at first sight to be an open question as to whether it's ok to nest a class within an interface. See https://stackoverflow.com/a/9098321/834521. I don't think I'm being silly in asking why the same can't apply to C#. Edit Brief summary / quotes from Framework Design Guidelines, 2ed, section 4.9 pp115-117. - Do use nested types when e.g. the nested type needs access to private members of the enclosing type. - Don't use public nested type for grouping; use namespaces for this. - Avoid publicly nested types unless you really know what you're doing. (Main motivation: explicitly creating nested types is confusing for less skilled developers. However implicitly creating, e.g. via collection enumerators, is ok.) - Don't use nested types if the nested type is it is going to be used or instantiated outside of the containing type (both of these argue for independence of the nested type from the containing type). - Don't use as a member of an interface.