Better type inference in conditional expressions

[Pyrdacor]

I hope this isn't covered somewhere else, but if so please feel free to close this with a duplicate reference.

I found that the following simple code won't compile:

bool foo = false;
uint z = foo ? 1 : 2;

The same is true for switch expressions:

uint z = x switch
{
    _ => foo ? 1 : 2
};

The error is that an int can't be implicitly converted to uint. I understand that in general but here it is very clear that in any case the value is a valid uint.

Is this not possible to allow for some reason? I know I can use casts or literal suffixes like 1u. But I would prefer to avoid that as in some cases a type might change later and it should work without it imo. And suffixes won't work for smaller types like byte.

The same is true for any other integer type like byte etc which has no implicit conversation from int. So type long will work of course for obvious reasons.

[bernd5]

The result type of the non-const conditional expression foo ? 1 : 2 is int.

But you can write:

using System;

bool foo = false;
uint z = foo ? 1u : 2;

which changes the result type to unit. And because of implicit constant conversion the value 2 does not need an explicit conversion - just a single cast / literal suffix needed.

If you change your code to:

const bool foo = false;
uint z = foo ? 1 : 2;

Than implicit constant conversion would apply here, too.

[CyrusNajmabadi]

The question is why the compiler can't just treat this as an uint?

Compat. We tried this at one point and it broke lots of stuff due to code changing meaning. So we preserve the meaning exactly if the conditional has branches all of which are compatible with each other.

[Pyrdacor]

So as each branch is a Int32 literal, it will keep this type regardless of the left hand type?

Can't think of any circumstance were it breaks but I guess you have encountered much more use cases.

Thanks for the explanation.

[CyrusNajmabadi]

So as each branch is a Int32 literal, it will keep this type regardless of the left hand type?

Yes.

[333fred]

Can't think of any circumstance were it breaks but I guess you have encountered much more use cases.

The big things are overload resolution and generic type inference. It would change what overloads are called and what types are inferred, breaking existing code.

[Pyrdacor]

While the initial answer isn't that satisfying, the comments are. Should I mark the initial answer as "the answer"?