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();
}

Yes, you understood this well, it isn't breaking. Coming up with a scenario where it is breaking is difficult, I can't readily come up with a late binding scenario where it does. — Hans Passant
– Hans Passant, Commented Nov 5, 2011 at 8:34

AaronLS · Accepted Answer · 2013-02-13 21:26:32Z

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.

Reed Copsey · Accepted Answer · 2011-11-05 01:07:09Z

14

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.

answered Nov 5, 2011 at 1:07

Reed Copsey

567k80 gold badges1.2k silver badges1.4k bronze badges

2 Comments

Max Toro Over a year ago

Yes, I understand it's a compiletime breaking change.

Reed Copsey Over a year ago

@MaxToro: That's all it means. The public contract is fixed, because you'll break (at compile time) other callers. It isn't a runtime breaking change, though (like adding a parameter would be), since the substitution is all handled at compile time. Note that changing the default, however, will not cause the other caller to update, since it's all handled at compile time. (Optional/Named arguments are purely a compile time trick)

Collectives™ on Stack Overflow

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

2 Answers 2

Comments

2 Comments

Your Answer

Linked

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

Comments

2 Comments

Your Answer

Sign up or log in

Post as a guest

Linked

Related