Question about method overloads with optional parameters ambiguity in C#/.NET

[mikezw]

Background:

In C#, consider the following method overloads:

public void Test(string id, string id2 = "")
{
}

public void Test(string id2 = "")
{
}

From my understanding, method overloads should have distinguishable parameter signatures, and relying only on optional parameters for distinction can lead to ambiguity. I expected that such definitions would result in a compile-time error due to ambiguous overload resolution, especially when calling Test("").

However, in practice, I have noticed that sometimes the compiler does not report an error for such code.

My questions are:

1. How does the .NET compiler/runtime resolve such method overloads with optional parameters? Why does it sometimes not report an error?
2. Is there any detailed documentation or design notes on how overload resolution works with optional parameters in C#?
3. Are there existing issues or discussions in .NET or Roslyn repositories that cover this ambiguity?

Thank you for your help and clarification!

[huoyaoyuan]

Generally, overload resolution is a language topic and should go to https://github.com/dotnet/csharplang/discussions. Different languages can have different rules.

I expected that such definitions would result in a compile-time error due to ambiguous overload resolution, especially when calling Test("").

This is an incorrect expectation. It's often encouraged to provide shorter overloads with less parameters to make an optimal path that don't need to deal with optional parameters.

1. How does the .NET compiler/runtime resolve such method overloads with optional parameters? Why does it sometimes not report an error?

You can use Visual Studio to get assisted about overload resolution. Visual Studio runs the actual compiler and would highlight/navigate you to the selected overload.
In this case, the second method wins because it is an exact match when ignoring the optional parameters.

2. Is there any detailed documentation or design notes on how overload resolution works with optional parameters in C#?

The full spec of overload resolution is at https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#1264-overload-resolution. Optional parameter is a very old feature so there wouldn't be fresh design notes.

3. Are there existing issues or discussions in .NET or Roslyn repositories that cover this ambiguity?

People don't encounters this as ambiguity. Exact match always wins over anything else.

[mikezw]

Thank you for your answer.
This question originated from a commit in our team and actually caused a bug. Originally, there were two methods, both without optional parameters.

public void Test(string id)
{
}

public void Test()
{
}

Later, one of our team members added default (optional) parameters to both methods. As a result, all places where we called the method with a single argument started to behave incorrectly. This issue is quite confusing for people who are new to c# or optional parameters.

I also see https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/named-and-optional-arguments. The last part of this article is also very understandable to me

I will learn more in the c# Specifications, If there are still any questions, I will bring up a new discussion on the csharplang side.

[huoyaoyuan]

Simply speaking, for a method that provides some syntax sugar for callers, including default parameter, extension method and params, the form removing all the sugars is called its original shape. The original shape is always participating in overload resolution, and will win over other methods that applies syntax sugar.

Later, one of our team members added default (optional) parameters to both methods. As a result, all places where we called the method with a single argument started to behave incorrectly.

You can somehow override the behavior using OverloadResolutionPriority. Debug.Assert utilizes this to deprioritize the message-less overload. However if you do so, there will be no way to call the overload with fewer parameter.

Additionally, it's not a good practice to make overloads, especially the ones differ by default parameters, to have different behaviors.