C# Target-Typed Conditional Expression

Looking at the documentation for Target-Typed Conditional Expression in C# 9.

A reference is made to ambiguity in the documentation for the following scenario after the introduction of this feature, but it still appears to call M(long, long) every time. i.e. no ambiguity?

> M(b ? 1 : 2, 1); // calls M(long, long) without this feature; ambiguous with this feature.
>
> static void M(short i, short ii) => Console.WriteLine("short");
> static void M(long i, long ii) => Console.WriteLine("long");

Compiles to:

public static void Main()
{
    M(1L, 1L);
}

private static void M(short i, short ii) { Console.WriteLine("short, short"); }
private static void M(long i, long ii) { Console.WriteLine("long, long"); 

The crux here is the ternary operator. In this case, it will upcast to Int32 (int):

Console.WriteLine((b ? 1 : 2).GetType().Name);

Given the rules of overloading, the only valid overload available of M is M(long, long)

If you explicitly type the numbers, then the ternary will resolve to Int16 (short):

const short one = 1;
const short two = 2;
		
Console.WriteLine((b ? one : two).GetType().Name);

In this case, the closest overload of M is M(short, short)

Another way:

Console.WriteLine((b ? (short)1 : (short)2).GetType().Name);

The ambiguity in the case you describe it entirely internal. It is not exposed to the user.

For clarity, this is the case:

static void Main()
{
    M(1, 2); // Case A
    M(true ? 1 : 2, 3); // Case B
    bool b = true;
    M(b ? 1 : 2, 3);  // Case C
}
static void M(short a, short b) => Console.WriteLine($"{a} {b} {a.GetType()}");
static void M(long a, long b) => Console.WriteLine($"{a} {b} {a.GetType()}");

Case A and B can be evaluated by the builder (Case B generates the IL code M(1, 3); - the conditional is not even presented to the runtime), so both resolve to the short implementation, but case C is where the ambiguity lies.

When the runtime needs to decide which version to call, it does a first pass and determines that both expressions resolve to different types. b ? 1 : 2 resolves to an int when considered on its own, and 3 also resolves to an int, but in the context of this problem, the pattern matcher needs to either resolve both to short or long.

The pattern matcher doesn't want to fully evaluate b ? 1 : 2, (or even determine the possible types - remember that this could be an expensive and nested case) but it has been predetermined to be of type int. 3 can be expressed as short to match the first case, but int can't be implicitly cast to short, only to long, so it makes that first step.

Therefore we have a call to M of type M(long, short), which is ambiguous. This can be solved by either:

1. Implicitly casting the second argument 3 to a long
2. Evaluating the first parameter b ? 1 : 2 to see if it can be expressed as a short

When presented with these options, the runtime will always do the first one if that option exists. From the proposal you posted, this is 'clarified' by:

The updated terminology referenced (the new proposal is here), C1 in this case is option 1 in that list above (not a conditional expression conversion - i.e. implicit), and C2 is option 2 (IS a conditional expression conversion), so C1 is considered 'Better'.

The last line in the link is what clarified things for me:

> Therefore we treat the conditional expression conversion as a last resort in a cast, to preserve existing behavior.

Basically, it guesses what the best fit will be, and in b ? 1 : 2, both outcomes resolve to int, so when it comes to deciding which method to call, the last thing it will do is evaluate that conditional to figure out that a short works better, and both int and short are implicitly convertible to long

Of course, this can be forced with M((short)(b ? 1 : 2), 3);, but where's the fun in that?

Hope this helps.