Records primary constructor - argument camel casing?

[davidroth]

When defining a record using a primary constructor:

public record Person(string Forename);

This results in the following class (shortened):

public class Person
{
   public Person(string Forename) => this.Forename = Forename;
   public Forename { get; init; }
}

Great. But it feels strange that we now have a PascalCased constructor parameter. (Forename)
Usually, C# method parameters are camelCased.

Question: Did the team consider automatically camelCasing constructor parameters when using primary constructors?

Ex.:

public record Person(string Forename);

would result in:

public class Person
{
   public Person(string forename) => Forename = forename;
   public Forename { get; init; }
}

[Richiban]

I'd imagine that it's because changing case is not a trivial issue (it's not too bad if you assume English).

E.g. in English big and BIG are equal when you ignore case, but in Turkish they're not. Since unicode identifiers are allowed it's almost impossible to automatically change case on behalf of the programmer.

[HaloFour]

I recall this conversation happening fairly early on in the design of records but I can't find notes or comments about it. Apart from the culture concerns with casing it's also not always obvious how acronyms or the like should be treated. The .NET naming guidelines allow for capitalization of two-letter abbreviations, e.g. IOFoo.

[Joe4evr]

Somewhat relevant quote from Immo:

Someone asked why our naming guidelines have to be so complex instead of simply recommending PascalCase everywhere.
I answered "Because then System.Io would look like a namespace for manipulating a moon around Jupiter."

[YairHalberstadt]

You could achieve this using source generators. You write:

partial record A(int myInt, string myString)

And the source generator generates:

partial record A(int myInt, string myString){
    private int myInt { get; init; } = myInt;
    private string myString { get; init; } = myString;
    public int MyInt { get => myInt; init => myInt = value; }
    public string MyString { get => myString; init => myString = value; }
}

This works correctly for withers, equality, and printing prints A { MyInt = 42, MyString = Hello World }

[CyrusNajmabadi]

We discussed this at length in the ldm. Final conclusion was that it was entirely it if scope of the language to drive any casing policy or system here.

[HaloFour]

Was there a conversation with the CoreFX/BCL team? I'm curious if they had any opinions as to how positional records might be adopted in their APIs, especially if they are the building blocks for discriminated unions. Although I can imagine if the parameter/property naming is that much of a concern they could define them as nominal records with PascalCase property names and add constructors/destructors manually with camelCase parameter names.

[333fred]

Several BCL members listen in regularly, and Stephen Toub is on the the language design team itself. I believe they were there for this discussion.