[Proposal] Internal and external method parameter names

[daiplusplus]

(Reposted from the Roslyn repo)

I'm proposing new syntax for C# to allow methods to optionally have internal (scoped) names for parameters that are different to the exposed external names that consumers see.

This is based on my experiences with Swift and Objective-C where parameters have separate "parameter name" and "argument labels" (which better translates to "internal names and external names" in my opinion).

This is most useful if you need to use verbose parameter names for external callers but inside the function scope those long names get tedious, for example:

public void ExecuteBankTransfer(Int32 fromAccountId, Int32 toAccountId, Decimal transactionAmount)

I advocate using an inline syntax for alternative names, instead of the use of attributes seen in the original Rosyln issue, so this would become:

public void ExecuteBankTransfer(Int32 fromAccountId from, Int32 toAccountId to, Decimal transactionAmount amount)

...The external caller would still specify fromAccountId: toAccountId: and transactionAmount: but the author of the function definition would use the more succint from, to and amount names.

I find Swift and Objective-C's mandatory labels a bad design choice (though Swift allows the use of underscores), but using a triple Type externalName [internalName] syntax is succint, easy to read, and doesn't conflict with any existing or proposed syntax constructs I'm aware of.

As a bonus, this could be combined with a possible future Record-type syntax, to ensure the public member names and parameter names have the preferred names (mostly thinking of PascalCase vs camelCase):

public class EmployeeRecord(Int32 id Id, String employeeName Name, Image photo Photo);

Becomes:

public class EmployeeRecord {
    public Int32  Id { get; set; }
    public String Name { get; set; }
    public Image Photo { get; set; }
    public EmployeeRecord(Int32 id, String employeeName, Image photo) {
        this.Id = id;
        this.Name = employeeName;
        this.Photo = photo;
    }
}

I'm hesitant to refer to the differing external and internal names as "aliases" because the compiler could actively prevent code in the consumer from using external names internally - or vice-versa: consumers using internal names - I have no strong opinions either way:

ExecuteBankTransfer( fromAccountId: 123, toAccountId: 456, transactionAmount: 123.00 )

ExecuteBankTransfer( from: 123, to: 456, amount: 123.00 )

(I'm prepared to develop this into a prototype fork of Roslyn, though it would be my first foray into modifying the compiler.)

---

Another advantage is that it allows the public API surface to be kept constant and so not breaking any existing consumers (especially those using overload selection by argument-name) while changing internal details.

[Unknown6656]

I think the best practise would actually be using document comments and/or good parameter names to begin with.......
I can understand that long names are tedious, but that is partly why we have auto-completion in our IDEs.
But I think I can understand, why this would be a feature that many developers could use.....

[am11]

I like the inline syntax better. Attribute syntax was mostly inspired by PowerShell's [Alias] attribute, [DisplayName] in serialization and [Route] attribute in ASP.NET; which exist to provide similar functionality.

[jnm2]

Ideally parameters have really communicative names, not short names, both for consumers and implementation.

[morob05]

I personally hate the naming conventions with internal and external parameter names in swift. I guess it's all a matter of preference.

[jonaskeisu]

Long time C# enjoyer here. After adding experience with Swift I did find myself missing internal/external parameter names in C#. In the external context of a method call longer parameter names have the ability to make the call of a method read like a sentence which makes the code easier to read and understand. However, in the local context of the method implementation, long parameter names are not adding to the readability of the code unless the method implementation is long, in which case it should be refactored using sub methods anyway. Instead, for a nice short implementation, long parameter names often make the algorithm harder to read and understand. Therefore I really appreciate to have the opinion to separate the names between call and implementation and hope this will be added to the language.

[spydacarnage]

If it bothers you that much, just create a local variable with the shorter name - the resulting compiled code is the same

void DoSomething(int reallyReallyLongParameterName)
{
    int shortName = reallyReallyLongParameterName;
    Console.WriteLine(shortName);   
}

[daiplusplus]

I note this approach would have gotchas with ref and out parameters, though. I'd love to see C# get ECMAScript-style const-locals though.

[jnm2]

You can do ref var localName = ref publicName;.