Instead of an error, why don't both operands get a float or double?

Question

1) If one operand is of type ulong , and the other operand is of type sbyte/short/int/long , then a compilation error occurs. I do not see the logic in this. So, why would it be a bad idea for both operands to upgrade to double or float instead?

  long L = 100; ulong UL = 1000; double d = L + UL; // error saying + operator can't be applied to operands of type ulong and long 

b) The compiler implicitly converts int literal to byte type and assigns the resulting value b :

 byte b = 1; 

But if we try to assign a literal of type ulong for input long (or for types int , byte , etc.), the compiler reports an error:

 long L = 1000UL; 

I would have thought that the compiler would be able to figure out if the result of a constant expression can fit into a variable of type long ?!

Thank you

Answer 1

To answer the question marked (1) - adding long unsigned debt signs is probably a mistake. If the intent of the developer is to flow into inaccurate arithmetic in this scenario, then something that they should do explicitly by dropping both arguments to double. Doing this implicitly hides mistakes more often than doing the right thing.

To answer question (b) - of course, the compiler could understand this. Obviously, this is possible because he does it for whole literals. But then again, this is almost certainly a mistake. If you intended to do this for a long time, then why did you mark it as unsigned? This seems like a mistake. C # has been carefully designed so that it searches for strange patterns like this and draws your attention to them, rather than suggesting that you wanted to say this strange thing and glow ahead, as if everything was fine. The compiler is trying to get you to write reasonable code; reasonable code does not mix signed and unsigned types .

Answer 2

Why should it be?

Typically, 2 types are incompatible because it is signed for a long time. You describe only a special case.

For byte b = 1; 1 has no implicit type as such and can be forced into bytes

For long L = 1000UL; "1000UL" is an explicit type and is incompatible and see my general case above.

Example from "ulong" on MSDN :

If an integer literal does not have a suffix, its type is the first of these types in which its value can be represented: int, uint, long, ulong.

and then

There is no implicit conversion from ulong to any integral type

The "long" on MSDN (my bold)

If an integer literal does not have a suffix, its type is the first of these types in which its value can be represented: int, uint, long, ulong.

It is quite common and logical and absolutely predictable.

Answer 3

 long l = 100; ulong ul = 1000; double d = l + ul; // error 

Why would it be a bad idea for both operands instead to upgrade to double or float?

Which one? Floats? Or doubles? Or maybe decimal numbers? Or thirst? The compiler does not know what you think. Also, type information usually results from expressions not in them, so it cannot use the destination for selection.

The fix is ​​to simply indicate which type you want by placing one or both arguments in that type.

Answer 4

The compiler does not take into account what you do with the result when it determines the type of result of the expression. The rules for using types in an expression take into account only the values ​​in the expression itself, and not what you do with the value later.

In the case when you assign the result to a variable, you could use this information, but think about the following:

 Console.Write(L + UL); 

The Write method has overloads that accept several different types of data, which makes it difficult to decide how to use this information.

For example, there is an overload that takes a string, so one of the possible ways to promote types (and a good candidate, since it does not lose any precision) was to convert both values ​​to strings first and then combine them, which is probably not the result of what you were after.

Answer 5

The simple answer is how the language specification is written:

http://msdn.microsoft.com/en-us/library/y5b434w4(v=VS.80).aspx

You can argue about whether the rules for implicit conversions are logical in each case, but at the end of the day these are only the rules that the project committee adopted.

Any implicit conversion has the disadvantage that it does what the programmer cannot expect. The general principle with C # seems to be a mistake in these cases, and then tries to guess what the programmer had in mind.

Answer 6

Suppose one variable was 9223372036854775807 and the other was -9223372036854775806? What should be the result of the addition? Converting two values ​​to double will round them to 9223372036854775808 and -9223372036854775808, respectively; doing the subtraction will then give 0.0 (exactly). On the contrary, if both values ​​were signed, the result will be 1.0 (also accurate). You could convert both operands to Decimal type and do the exact math. However, converting to double after the fact will require an explicit cast.