[Proposal] Allow members to have the same name as their enclosing type

[hamarb123]

Currently, the following code is not possible:

public class ClassName
{
    public void ClassName()
    {
        DoStuffHere();
    }
}

This is because the compiler doesn't allow you to have a member with the same name as the enclosing type, because that is how the constructor is declared in C# public ClassName() { ConstructorCodeHere() }
There is a similar problem in VB.NET, which is the New() method (VB.NET constructor), for example:

Public Class ClassName
    Public Sub New()
    End Sub
End Class

declares a class named ClassName, with a constructor that takes 0 arguments.
Note: members named ClassName are allowed in ClassName in VB.NET (but not C#)

But VB.NET has a solution for naming things with keywords, such as Object or Integer, which is to enclose the name in square brackets [], for example:

Public Class ClassName
    Public Sub Integer()
    End Sub
End Class

is not allowed, as Integer is a keyword, but

Public Class ClassName
    Public Sub [Integer]()
    End Sub
End Class

is allowed, and will compile into a void named Integer (without the square brackets), and can be accessed in C# as simply Integer, as it is not a keyword in C#.
In C#, there is a similar pattern, which is to add a @ character to the start of the member name, for example:

public class ClassName
{
    int string => 0;
}

is not allowed, whereas

public class ClassName
{
    int @string => 0;
}

is allowed and will compile into string instead of @string, as the @ symbol simply informs the compiler to not treat it as a keyword.
The difference of this pattern between VB.NET and C# is that in VB.NET, the following is completely legal:

Public Class ClassName
    Public Sub [New]()
    End Sub
End Class

and will compile as expected, whereas in C#, the following is not legal:

public class ClassName
{
    public void ClassName()
    {
    }
}

and the compiler simply complains saying "error CS0542: 'ClassName': member names cannot be the same as their enclosing type".
Using the @ symbol removes the ambiguity, so it should be allowed (but probably optional).
The C# language specification should allow this, if the member has an @ symbol at the start, it should be compiled without the @ symbol (just like everything else that starts with one).
The example above should be callable like so:

ClassName variable1 = new ClassName();
variable1.@ClassName();

which is the same usage as calling other @ members.
Note, I believe that

ClassName variable1 = new ClassName();
variable1.ClassName();

would actually work as well today if the type was declared in VB.NET.

The reason I specifically want this is because I have old code that requires libraries to have a Load() method in a Load class, if the method and class are not named exactly this, it will not work, so currently I am limited to 2 options: a VB.NET wrapper OR VB.NET code only. I would like to write this library completely in C#, and this is how it can be done. I'm sure there would also be other applications for this.

[FiniteReality]

This seems like a very edge-case usecase and more likely to cause maintainability issues than it is to solve.

Is there any reason you can't just rename the class or method? Using your example, a Load class seems extremely vague... What does it load? If you're grouping up multiple "loaders", couldn't you use, say, Loaders.LoadMyTypes()?

[hamarb123]

@FiniteReality firstly, the old library uses reflection to lookup the class 'Load' and then the void 'Load()' in that class, it cannot be changed for various reasons. Secondly, I don't think it would be that hard to change as you only have to change the test that says it cannot be named the same as the enclosing type.
Also, it appears that C# already can call these functions if they get declared, for example:
In VB.NET

Public Class Class1
    Public Sub Class1()
        Console.WriteLine("Message1")
    End Sub
End Class

and in C# (referencing VB.NET)

Class1 c = new Class1();
c.Class1();

will compile and produce the output as expected.
So all that needs to be changed in theory is this line here: https://github.com/dotnet/roslyn/blob/master/src/Compilers/CSharp/Portable/Symbols/Source/SourceMemberContainerSymbol.cs#L1188
to allow it if it was declared with an @ symbol.
Also the closing and reopening was an accident.

[gregory-seidman]

It isn't clear to me that even

public class ClassName
{
    public ClassName() { }
    public void ClassName() { }
}

...is ambiguous. The signatures are different. The intent is clear. It's appropriate and desirable to have a warning, since it isn't good practice, or even keep it as an error but allow it to be downgraded to just a warning instead of making it fatal.

[hamarb123]

I was saying that "Not be able to use this name unless you want to require all consumers to be on c#.next or above." is false, which it is since the consuming library only knows what C# version is being required through additional features that add more representable IL code than what is already representable for referencing in that C# version.

[hamarb123]

No. Declarations are only part of the story. It's necessary to be able to reference things as well, and there are names for which there is no facility at the reference point to ever access in C#.

For this error specifically is what I was saying. If you were able to declare it (specifically referring to CS0542) in any .NET language (like you can today and many years ago in VB.NET), you can consume it today from C# and probably any other .NET language today already.

I'm merely saying that we should be able to declare it in C# too.

[hamarb123]

IMO a sloppy generator does not a use case make. You can probably cause any number of those generators to fail for a given language given perfectly legal GraphQL metadata. I've seen the same with OpenAPI and WSDL before it. Code generators need to accommodate the naming rules of the underlying language, and those rules are generally not that difficult and often include reserved words.

My use case is different. My use case is trying to make a VB.NET library as a C# one, there are other things features that are not in C# as well, but many of them are avoidable and none of them (AFAIK) bar someone from switching to C# without changing the public API, except this one. I wouldn't be surprised if other business have this in VB.NET code today and are planning to switch in the future, not expecting a surprise like that.

This seems like a reasonable use case to me (not saying that the generator use case is not reasonable).

[HaloFour]

That may be an easier sell since it does put you into a tight spot. But I don't believe it's ever been considered a goal to enable porting between languages without incurring breaking changes, even at the public API. CLS covers calling between assemblies emitted by different languages but not porting between those languages, and the fact that C# allows calling those members when they are defined on VB.NET seems to tick that box.

[hamarb123]

But I don't believe it's ever been considered a goal to enable porting between languages without incurring breaking changes.

I think that would probably be fair enough if VB.NET was properly supported still, the issue is that it isn't and I'd say that C# is clearly the intended replacement. https://visualstudiomagazine.com/articles/2020/03/12/vb-in-net-5.aspx

[DavidArno]

From my experience, it's unusual, but far from a proper edge case to want a member with the same name as the type. Most recently, I wanted to create the type Type<T> like so:

public sealed class Type<T>
{
    private Type() { }

    public static Type<T> Type { get; } = new Type<T>();
}

In this situation, Type is the best name for the property in my view. But the C# language forbids this. So I ended up calling it Instance instead. This creates a classic "coding to the framework" code smell as I've picked a name because I've implemented a singleton, rather than the better "coding to the domain" approach of calling it Type.

So I for one would love to see this restriction removed. But sadly I don't think this would ever happen. There's a mistaken belief that this is bad practice (and it doesn't help the blood pressure that those that assert it's bad practice undermine that assertion by defending genuine bad practices like using goto and nested classes). But worse, it's a problem that is easily worked around., So it's nigh on impossible to find a compelling use-case that would justify the expense in terms of changing the compiler's behaviour and all the documentation that says it can't be done, in order to support this change.

This one is likely stuck on -100 points for all time and we just have to live with it, which is occasionally annoying but not really that hard to do.

[CyrusNajmabadi]

Yes. It would likely require delimitation syntax. @name would just be shorthand for that delimiter logic.

[hamarb123]

But I think/thought it was still worth giving it a go, just in case it's possible that they add it now or in the future

I would only push for this if we removed all restrictions entirely. In other words, we would be like JS/TS, and 100% of all value string values would be valid member names. I don't see why we shouldn't be allowed to use $ (like in JS/TS), or use spaces (like in Ocaml), etc. I'm not finding value in going halfway and solving a tiny one off case

That's not what I'm pushing. I'm happy with the rules that require keywords to be escaped for 2 reasons: 1. it is ambiguous in many cases what would be the identifier without the @, and 2. the list is fixed and is not based on the context of the member whatsoever - it is always the same disallowed words for member identifiers (other than that there's not another field with the same name for example).

I think the basic rule C# allows now as identifiers is quite reasonable (ie. any identifier is allowed if it doesn't start with a number and only consists of specific character groups and the _ from memory), but the CS0542 rule IMO stands in the way of this because every single other name out of those allowed names is representable in C# and gets compiled to IL accordingly. The @ symbol in these cases are completely fine since they don't get compiled into the IL code so they would be perfectly accessible from other languages and reasonable to get via reflection etc. But there is exactly one name out of all of these names that isn't representable (for declaration) in C#, which is what my issue with the error is.

This (ie. completeness), along with it not always being a bad practice, the fact that there are consumers wanting it (I want it so I can make one of our internal library use C# without having breaking changes), and that is probably not being hard to implement makes it seem like a reasonable feature to me.

[CyrusNajmabadi]

I think the basic rule C# allows now as identifiers is quite reasonable

It seems like it puts you in teh same problem you have with the type name. You have to know which actual names are not valid, and you have to adjust accordingly. Your generator always needs to deal with this. So unless we allow all names, you have to write name validation logic. And if you have that, having that validation logic add the check for the type name seems trivial.

[hamarb123]

I think the basic rule C# allows now as identifiers is quite reasonable

It seems like it puts you in teh same problem you have with the type name. You have to know which actual names are not valid, and you have to adjust accordingly. Your generator always needs to deal with this. So unless we allow all names, you have to write name validation logic. And if you have that, having that validation logic add the check for the type name seems trivial.

Not sure why you think I have a generator. Also, I don't see why you seem to think it has to be either "the current allowed identifiers" or "all possible identifiers". What I'm asking for is literally "the current allowed identifiers" + 1. Why would it have to be all or nothing?

Also if I did add validation logic to check for the type name (to a theoretical generator), what's my solution then? Add an underscore to the name? In my opinion, anything besides manually choosing a different name for each thing would be a sloppy solution to the problem, none of which would be necessary if this was implemented since it's already consumable from C#, VB.NET and probably F# too.

[CyrusNajmabadi]

What I'm asking for is literally "the current allowed identifiers" + 1. Why would it have to be all or nothing?

Because it's much easier to just handle the +1 case in the code that runs into this. So it's much cheaper and easier than making the language change. It also doesn't substantively improve things for enough cases to be worth it IMO. if this a least solved all cases i would be more amenable to this being doing.

Add an underscore to the name? I

Sounds good to me. It's similar to how tools would have to deal with any other characters that might not be valid in C#.

In my opinion, anything besides manually choosing a different name for each thing would be a sloppy solution to the problem

Yes. Hence why i said i was more amenable to a solution that just allowed for 100% of all names to be usable in C#.

[gregory-seidman]

I'm going to try a different approach. Never mind the existing code generator or inconsistency between VB.NET and C# or how keywords can be used as member names with an @ prefix. Instead, let's talk about programmers new to C#. They name things as best they can and they hit this unexpected error about naming. It doesn't make sense to them. If they're familiar with other languages, they might wonder why there is any issue with naming a member the same as the type. They may do some googling and discover that it isn't even a CLR/.NET restriction but is exclusive to C#. They may even find this discussion.

Ultimately, though, it's like having one stair in a staircase that is just a little bit taller than the others. It trips you up. It's unexpected. It makes no sense. Sure, you learn to watch your step on the staircase to handle that one special case, but it's just a little more friction, a little more frustration, with what is an otherwise pleasant language to use. Worse, there doesn't seem to be any benefit to keeping the restriction (and I retract saying it isn't good practice; I don't think that's defensible).

Why wouldn't we want to streamline the language with this one simple improvement?

[hamarb123]

Also, it is actually allowed in Java

There are many things allowed in other languages that we consider problems, and so we do not support them at all (for example, implicit fallthrough in switch cases that already have statements in them). We genuinely often feel like it's better to cut off rare positive cases, when overall the value is negative.

That's fine, I was just pointing out that other similar languages do allow it.

[CyrusNajmabadi]

recent progress in C# has been to reduce friction in the language.

Sure. But we do assess that friction, esp against any value it provides. When there are areas of high-impact friction (either on common use cases, or on size of customer segment hit) we often do look into addressing things. The case of friction because the rare case of TypeName+MemberName comes up (which is very easily solvable with a different name), doesn't rise to that level for me.

[CyrusNajmabadi]

That's fine, I was just pointing out that other similar languages do allow it.

Right... but i'm saying: I think it's a bad thing that they do that :)

[hamarb123]

I'd argue guard rails are preferable to straightjackets.

That's fine to have that perspective. I don't personally agree, and in the language design so far i've taken the perspective that this should be discouraged.

I think that it isn't a bad perspective to avoid what is essentially allowing programmers to disable errors, but I think that since the reason that the reason exists is essentially "the programmer might be doing something wrong" and "it's probably a bad practise" it's reasonable that the programmer should be able to override this behaviour if they want to.

I'd also say that keeping CS0542, but changing it to a warning with a default severity of error would be a good solution.

Also, I've said that I'm happy to try to implement everything myself, so don't worry about the effort that it may take to implement too much.

Edit: I feel I was a pain when discussing this, sorry about that. I'm going to leave my comments here. I would still like this feature at some point, but I am sorry about the way in which I argued about it.

[CyrusNajmabadi]

but I think that since the reason that the reason exists is essentially "the programmer might be doing something wrong" and "it's probably a bad practise" it's reasonable that the programmer should be able to override this behaviour if they want to.

I disagree. The language is replete with cases where we could let the user override the behavior and we do not allow it. Indeed, i would say that a modus operandi of ours to not allow this.

When we think something is bad almost all the time, we make it an error. We recognize that that might occasionally mean that for some user that wants it, they cannot get it. But that's ok.

[koenbeuk]

I already have a code analyzer in place that reports constructor methods as their type name.

class Foo {
     public Foo() { }
}

Will report method 'Foo()' within type 'Foo'. down the line, this pattern is recognized. Implementing this proposal would break this analyzer and probably a whole lot more as this restriction has been in place since day 1.

[hamarb123]

That's a fair point.

[CyrusNajmabadi]

I already have a code analyzer in place that reports constructor methods as their type name.

Can you clarify this (possibly by pointing at the analyzer). As this is already illegal today, it's unclear what the analyzer would be doing on top of this.

[koenbeuk]

@CyrusNajmabadi I would love to but it's in a development stage (soon.... to be released). Regardless, it's not a typical C# code analyzer but rather a static code analyzer that generates a report (think excel) of what external dependencies a codebase is relying on. Given this detail: If I were to report the string, System.Int32.Int32(System.Int32) as a constructor dependency, would that be classified as 'illegal' and is there a suggested form of reporting this dependency?

[erik-kallen]

@hamarb123 The issue you are having can probably be solved with https://github.com/Fody/Fody

[markjerz]

Chipping in a little.....

It does seem odd that this is a restriction in C# despite being possible in IL. I wonder what the original reason was for doing it (other than avoiding confusion)?

Where I just came up against it makes it more annoying (in my opinion). I'm creating a razor component in aspnet core. This component is for a Basket (so the file is named Basket.razor) and I pass in the data using a [Parameter] also called Basket (as that makes sense). Except I can't, because the class that is generated for my razor component is called Basket. So, now I have to name my parameter something else ("BasketData" ??) even though I wouldn't expect this.

[iam3yal]

@markjerz

other than avoiding confusion

Isn't this reason sufficient?

This component is for a Basket (so the file is named Basket.razor) and I pass in the data using a [Parameter] also called Basket (as that makes sense)

This is an issue that the Blazor team should address with Razor imo because it should be a lot easier for them to add a feature to support this scenario and more than making the change in C#. They should allow us to name parameters independently from the property's name or have some sort of an alias and I already suggested it to them here

p.s. If the component is called Basket I don't think that naming the property Basket makes a lot of sense maybe Items? but to each his own but then I don't know the semantics to actually suggest something meaningful so you might be right. :)