Is a parameter name change in C# a runtime breaking change?

Question

I read a couple of articles that say that with the introduction of named arguments in C# 3.0, the name of parameters are now part of the public contract. Is this true, and what does it mean exactly? I ran a simple test and changing a parameter name in MyLib.dll did not break MyApp.exe which called the method using a named argument with the original name, I think because the C# compiler did overload resolution at compile time, and the generated IL knows nothing about the parameter name. This is what the disassembled code looks on Reflector:

private static void Main()
{
    bool CS$0$0000 = true;
    Class1.DoSomething(CS$0$0000);
    Console.ReadKey();
}

...and this is the original source code:

static void Main() {

    MyLib.Class1.DoSomething(a: true);

    Console.ReadKey();
}

Answer 1

I read a couple of articles that say that with the introduction of named arguments in C# 3.0, the name of parameters are now part of the public contract. Is this true, and what does it mean exactly?

It is true that argument names are part of the public contract, but the statement contains two errors.

The most obvious error is that named arguments were introduced in C# 4.0, not C# 3.0.

But the more subtle error is far more important. The introduction of named arguments in C# 4.0 did not now make names of parameters part of the public contract of a method. Names of parameters were always part of the public contract because languages other than C# had the named arguments feature. In particular, VB has always supported named arguments.

Therefore changing the name of a parameter in a library was always a breaking change for VB recompilation. Now it is also a breaking change for C# recompilation, but that doesn't mean that it was safe before and now it is dangerous. It was always dangerous.

C# is not the only .NET language, not by far. When you change part of the publically visible surface of a type, you risk breaking programs in every language. C# having or not having a feature doesn't change that fact.

Answer 2

The problem is, say you have a public API like so:

public void Foo(bool a = false)
{
    //....

The caller can write an application that uses it, like so:

Foo(a: true);

If you then change the method to:

public void Foo(bool aBetterName = false)
{
    //....

Now, all of a sudden, the caller's code will no longer compile, as the compiler (as soon as they update to your new library) will no longer see a parameter named a.