views:

482

answers:

3

I'm a little stumped by this little C# quirk:

Given variables:

Boolean aBoolValue;
Byte aByteValue;

The following compiles:

if (aBoolValue) 
    aByteValue = 1; 
else 
    aByteValue = 0;

But this will not:

aByteValue = aBoolValue ? 1 : 0;

Error says: "Cannot implicitly convert type 'int' to 'byte'."

And of course, this monstrosity will compile:

aByteValue = aBoolValue ? (byte)1 : (byte)0;

What's going on here?

EDIT:

Using VS2008, C# 3.5

+3  A: 
Hamish Grubijan
I'm sure it was just a typo but you declared the same variable twice.
Cory Charlton
@Hamish: I see what you mean. I could use const, but it's a workaround. This certainly doesn't deserve the vote down you got though.
MPelletier
+7  A: 

I'm using VS 2005, for and I can reproduce, for bool & Boolean, but not for true

 bool abool = true;
 Boolean aboolean = true;
 Byte by1 = (abool ? 1 : 2);    //Cannot implicitly convert type 'int' to 'byte'
 Byte by2 = (aboolean ? 1 : 2); //Cannot implicitly convert type 'int' to 'byte'
 Byte by3 = (true ? 1 : 2);     //Warning: unreachable code ;)

The simplest workaround seems to be this cast

 Byte by1 = (Byte)(aboolean ? 1 : 2);

So, yes, it seems that the ternary operator is causing the constants to "fix" their types as ints and disable the implicit type conversion that you would otherwise get from constants that fit within the smaller type.

John Knoeller
+1 for making a cast less ugly than mine :)
MPelletier
Your explanation makes sense. But why would the constants not fix in this circumstance? And doubly curious with Mendy's discovery. Someone at Microsoft should know, and might need to be argued with strongly...
MPelletier
I think Mendy discovered that when compiler can trivially detect that it can optimize the ternary operator away entirely, it the compiles code that is equal to `Byte by = 2` which preserves the ability to implicitly cast. (see my comment on the compiler warning above)
John Knoeller
I think Eric Lippert may have discussed the why of this already on his blog.
John Knoeller
@John Knoeller: can you find link?
Mendy
Heres a related link to his blog. http://blogs.msdn.com/ericlippert/archive/2009/03/19/representation-and-identity.aspxI havn't found the exact link, and I may have mis-remembered where I read about implicit casts anyway.
John Knoeller
@Mendy: Found it http://blogs.msdn.com/ericlippert/archive/2006/05/24/type-inference-woes-part-one.aspx
John Knoeller
@John: cool :-)
Mendy
+22  A: 

This is a fairly frequently asked question.

In C#, we almost always reason from inside to outside. When you see

x = y;

we work out what is the type of x, what is the type of y, and whether the type of y is assignment compatible with x. But we do not use the fact that we know what the type of x is when we are working out the type of y.

That's because there might be more than one x:

void M(int x) { }
void M(string x) { }
...
M(y); // y is assigned to either int x or string x depending on the type of y

We need to be able to work out the type of an expression without knowing what it is being assigned to. Type information flows out of an expression, not into an expression.

To work out the type of the conditional expression, we work out the type of the consequence and the alternative expressions, pick the more general of the two types, and that becomes the type of the conditional expression. So in your example, the type of the conditional expression is "int", and it is not a constant (unless the condition expression is constant true or constant false). Since it is not a constant, you can't assign it to byte; the compiler reasons solely from the types, not from the values, when the result is not a constant.

The exception to all these rules is lambda expressions, where type information does flow from the context into the lambda. Getting that logic right was very difficult.

Eric Lippert
My mind is blown. Thank you, sir, that is one part enlightening and two parts frustrating. One because it can't work the way it would *seem* to work, and two because it makes sense that it can't work that way. So... constants it is!
MPelletier
Thanks. I was looking for a post on this topic on your blog, but this is even better.
John Knoeller
@John: I talk about these issues a bit here: http://blogs.msdn.com/ericlippert/archive/2006/05/24/type-inference-woes-part-one.aspx
Eric Lippert