Relax "member names cannot be the same as their enclosing type" for nested generic classes

[mikernet]

I tend to run into this type of pattern quite often:

public static class Cache
{
    public T GetObject<T>(string key) => Cache<T>.GetObject(key);

    private static class Cache<T> // Error: name cannot match enclosing type
    {
        private Dictionary<string, T> _lookup = ...;

        public T GetObject(string key) => _lookup[key];
    }
}

Obviously I can find a different name for the inner class but sometimes that's annoying in terms of code readability and in the case of nested generic types there is only an ambiguity if the number of generic parameters is the same, so it would be nice to lift the matching name restriction for that particular case.

[mikernet]

I'm not entirely sure why this is an issue to begin with - isn't the "name" of Cache<T> technically ``Cache1 which is different than `Cache` anyway? Using it's actual name instead of just the non-generic part of the name for the purpose of nested member name analysis seems like a relatively simple change to make that would fix this.

Is there any reason not to allow that? If you are allowed to have Cache and Cache<T> in the same namespace, I don't see why you shouldn't be allowed to have one nested inside the other. Allowing this doesn't introduce any ambiguity issues as far as I can tell.

[CyrusNajmabadi]

I'm not entirely sure why this is an issue to begin with - isn't the "name" of Cache technically ``Cache1

No, that's an internal implementation detail of the runtime. There is nothing aobut C# that considers it that.

[mikernet]

I mean, kind of but not really. I consider an internal implementation detail something that doesn't leak out but Type.Name returns the "real" CLR name and that internal implementation detail is what determines name collisions. I guess what I'm saying is that the CLR won't have a problem with it and it doesn't actually cause any ambiguities because every generic type with a different number of parameters has a unique identity so it should be a relatively minor change with no unintended side-effects that I can think of.

[CyrusNajmabadi]

Type.Name

That is part of the CLR, it's not part of C#.

returns the "real" CLR name and that internal implementation detail is what determines name collisions.

No, the C# language specification determines name collisions for C# :)

and it doesn't actually cause any ambiguities because every generic type with a different number of parameters has a unique identity

That's true today. But may not be in the future. We've def considered at time the idea of type-arg inference for types (just like it exists for methods). So it's not an open and shut case of this being trivial :)

[mikernet]

returns the "real" CLR name and that internal implementation detail is what determines name collisions.

No, the C# language specification determines name collisions for C# :)

*and that internal implementation detail is what determines name collisions at the CLR level so C# should be able to support that without a problem.

I can maybe kinda see your point about possible type-arg inference for types but I feel like it was more or less realized that it isn't going to happen, so I'm talking about this from today's perspective. I also don't think that this would impede that at all - like I kind of alluded to, if you can have Cache and Cache<T> in the same namespace and still figure out type-arg inference then you can definitely figure it out for a Cache with a nested Cache<T>.

[CyrusNajmabadi]

but I feel like it was more or less realized that it isn't going to happen

When did that happen?

[mikernet]

It didn't explicitly happen. Just the particular nature of the proposal and the lack of it going anywhere for years felt that way, but my feelings are ultimately irrelevant here given the position that I don't think this would affect that in any way since you're already going to have to deal with varying generic parameter count types in the same namespace if it ever comes to fruition and I believe the same logic can be applied to nested types that are in scope.