Home/ Questions/Q 8607993
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T03:30:03+00:00

I am aware that adding an optional parameter in a library method is a

  • 0

I am aware that adding an optional parameter in a library method is a breaking change,

void Foo(int x)             // OLD
void Foo(int x, int y = 5)  // NEW

because in the compiled code the new version is seen as Foo(int, int). Every call of Foo(0) (source code) is translated to Foo(0, 5) (compiled code) by the compiler. Thus, an old client, using a compiled call of Foo(0) would not find a suitable method.

What about the other direction?

void Foo(int x, int y = 5) { ... }    // OLD

void Foo(int x)        { Foo(x, 5); } // NEW
void Foo(int x, int y) { ... }        // NEW

Foo(0) (source code) would still compile, and Foo(0, 5) (compiled code) would still find a suitable overload, so, theoretically, this should work.

Does it work in practice, i.e., is this scenario “officially supported” by the .NET runtime and the C#/VB compilers? Or are calls to methods with optional parameters somehow “marked”, causing them to fail when the optional parameters are replaced by overloads?

EDIT: To clarify, I’m asking about binary compatibility: Is it possible to replace library.dll (old) with library.dll (new) without recompiling projectUsingLibrary.exe?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I thought that was a good question, so here goes my take.

    Using a quick client that does this:

            c1.Foo(1);
        c1.Foo(1, 2);

    When using optional parameter the client IL looks like:

        IL_0000: nop
IL_0001: newobj instance void [ClassLibrary1]ClassLibrary1.Class1::.ctor()
IL_0006: stloc.0
IL_0007: ldloc.0
IL_0008: ldc.i4.1
IL_0009: ldc.i4.5
IL_000a: callvirt instance void [ClassLibrary1]ClassLibrary1.Class1::Foo(int32, int32)
IL_000f: nop
IL_0010: ldloc.0
IL_0011: ldc.i4.1
IL_0012: ldc.i4.2
IL_0013: callvirt instance void [ClassLibrary1]ClassLibrary1.Class1::Foo(int32, int32)
IL_0018: nop
IL_0019: ret

    and when using overloads it looks like:

        IL_0000: nop
IL_0001: newobj instance void [ClassLibrary2]ClassLibrary2.Class2::.ctor()
IL_0006: stloc.0
IL_0007: ldloc.0
IL_0008: ldc.i4.1
IL_0009: callvirt instance void [ClassLibrary2]ClassLibrary2.Class2::Foo(int32)
IL_000e: nop
IL_000f: ldloc.0
IL_0010: ldc.i4.1
IL_0011: ldc.i4.2
IL_0012: callvirt instance void [ClassLibrary2]ClassLibrary2.Class2::Foo(int32, int32)
IL_0017: nop
IL_0018: ret

    So, if you changed the implementation from optional to overloads, but left the client as it was originally, it would be effectively adding the default parameter for you, and always calling the the function that has two arguments, which may or may not be the desired behaviour.

    • 0