Take the 2-minute tour ×

Looking at this C# code...

byte x = 1;
byte y = 2;
byte z = x + y;   // ERROR: Cannot implicitly convert type 'int' to 'byte'

The result of any math performed on byte (or short) types is implicitly cast back to an integer. The solution is to explicitly cast the result back to a byte, so...

byte z = (byte)(x + y);   // works

What I am wondering is why? Is it architectural? Philosophical?

We have:

  • int + int = int
  • long + long = long
  • float + float = float
  • double + double = double

So why not:

  • byte + byte = byte
  • short + short = short ?

A bit of background:

I am performing a long list of calculations on "small numbers" (i.e. < 8) and storing the intermediate results in a large array. Using a byte array (instead of an int array) is faster (because of cache hits). But the extensive byte-casts spread through the code make it that much more unreadable.

share|improve this question
It's not Eric's knowledge of the standard that would be useful here - it's his knowledge of the design of the language; what not why. But yes, Eric's answer would be pretty definitive :) –  Jon Skeet Jun 2 '09 at 20:35
The various musings below are a reasonable approximation of the design considerations. More generally: I don't think of bytes as "numbers"; I think of them as patterns of bits that could be interpreted as numbers, or characters, or colors or whatever. If you're going to be doing math on them and treating them as numbers, then it makes sense to move the result into a data type that is more commonly interpreted as a number. –  Eric Lippert Jun 2 '09 at 20:57
@Eric: That makes a lot of sense for byte, but probably not as much sense for short/ushort. –  Jon Skeet Jun 3 '09 at 12:24
@Eric: byte1 | byte2 is not at all treating them as numbers. This is treating them precisely as patterns of bits. I understand your point of view, but it just so happens that every single time I did any arithmetic on bytes in C#, I was actually treating them as bits, not numbers, and this behaviour is always in the way. –  romkyns Dec 28 '09 at 11:46

15 Answers 15

The third line of your code snippet:

byte z = x + y;

actually means

byte z = (int) x + (int) y;

So, there is no + operation on bytes, bytes are first cast to integers and the result of addition of two integers is a (32-bit) integer.

share|improve this answer
I have tried code below but it still not working. byte z = (byte)x + (byte)y; –  Anonymous Jun 4 '09 at 5:51
that is because there is no + operation for bytes (see above). Try byte z = (byte)( (int) x + (int) y) –  azheglov Jun 5 '09 at 18:51
This has got to be the most correct, concise answer. There is no operand to add between bytes, so instead of explaining why "adding two bytes" works or not (it never happened), this clearly shows why the result is an int, because the only thing that happened is an addition of 2 ints. –  RichardTheKiwi Apr 3 '11 at 23:22

In terms of "why it happens at all" it's because there aren't any operators defined by C# for arithmetic with byte, sbyte, short or ushort, just as others have said. This answer is about why those operators aren't defined.

I believe it's basically for the sake of performance. Processors have native operations to do arithmetic with 32 bits very quickly. Doing the conversion back from the result to a byte automatically could be done, but would result in performance penalties in the case where you don't actually want that behaviour.

I think this is mentioned in one of the annotated C# standards. Looking...

EDIT: Annoyingly, I've now looked through the annotated ECMA C# 2 spec, the annotated MS C# 3 spec and the annotation CLI spec, and none of them mention this as far as I can see. I'm sure I've seen the reason given above, but I'm blowed if I know where. Apologies, reference fans :(

share|improve this answer
I'm sorry to say that, but I find this not the best answer. –  VVS Jun 3 '09 at 12:16
Have you downvoted every answer that you find not to be the best one? ;) –  Jon Skeet Jun 3 '09 at 12:23
(Just to clarify, I'm not really having a go at you. It seems everyone has their own criteria for downvoting, and that's okay. I only downvote an answer if I believe it to be actively harmful rather than just non-ideal.) –  Jon Skeet Jun 3 '09 at 12:26
I use the voting as an instrument to get the "best" answer to the top. Actually I found you didn't say much at all in your answer which was the main reason for my downvote. Another reason maybe my subjective feeling that your rep gives you a big bonus when it comes to voting and you're landing on top of "better" answers. –  VVS Jun 3 '09 at 12:56
IMO the best way to get the "best" answer to the top is to upvote that. To be honest, I think the most informative answer here is Eric's comment in the question... but other than that, for the design perspective (as opposed to the "what the compiler's doing" perspective) I don't think there is much answer beyond "performance". In particular, I really don't buy the "it prevents overflow" argument (17 votes) as that would suggest int+int = long. –  Jon Skeet Jun 3 '09 at 13:14

I thought I had seen this somewhere before. From this article, The Old New Thing:

Suppose we lived in a fantasy world where operations on 'byte' resulted in 'byte'.

byte b = 32;
byte c = 240;
int i = b + c; // what is i?

In this fantasy world, the value of i would be 16! Why? Because the two operands to the + operator are both bytes, so the sum "b+c" is computed as a byte, which results in 16 due to integer overflow. (And, as I noted earlier, integer overflow is the new security attack vector.)

EDIT: Raymond is defending, essentially, the approach C and C++ took originally. In the comments, he defends the fact that C# takes the same approach, on the grounds of language backward compatibility.

share|improve this answer
With integers if we add them and it overflows it doesn't automatically cast it as a different datatype though so why do it with byte? –  Ryan Jun 2 '09 at 20:06
With ints it does overflow. Try adding int.MaxValue + 1 you get -2147483648 instead of 2147483648. –  David Basarab Jun 2 '09 at 20:13
@Longhorn213: Yep, that's what Ryan's saying: int math can overflow, but int math doesn't return longs. –  Michael Petrotta Jun 2 '09 at 20:15
Exactly. If this is meant to be a security measure, it's a very poorly implemented one ;) –  Jon Skeet Jun 2 '09 at 20:15
@Ryan: "lazy" is a pretty hefty charge to make against the C# language designers, for something as basic as primitive math. If you want to accuse them of anything, make it "excessive backwards compatibility with C/C++". –  Michael Petrotta Jun 2 '09 at 20:33


ECMA-334 states that addition is only defined as legal on int+int, uint+uint, long+long and ulong+ulong (ECMA-334 14.7.4). As such, these are the candidate operations to be considered with respect to 14.4.2. Because there are implicit casts from byte to int, uint, long and ulong, all the addition function members are applicable function members under We have to find the best implicit cast by the rules in

Casting(C1) to int(T1) is better than casting(C2) to uint(T2) or ulong(T2) because:

  • If T1 is int and T2 is uint, or ulong, C1 is the better conversion.

Casting(C1) to int(T1) is better than casting(C2) to long(T2) because there is an implicit cast from int to long:


Hence the int+int function is used, which returns an int.

Which is all a very long way to say that it's buried very deep in the C# specification.


The CLI operates only on 6 types (int32, native int, int64, F, O, and &). (ECMA-335 partition 3 section 1.5)

Byte (int8) is not one of those types, and is automatically coerced to an int32 before the addition. (ECMA-335 partition 3 section 1.6)

share|improve this answer
That the ECMA only specifies those particular operations would not prevent a language from implementing other rules. VB.NET will helpfully allow byte3 = byte1 And byte2 without a cast, but unhelpfully will throw a runtime exception if int1 = byte1 + byte2 yields a value over 255. I don't know if any languages would allow byte3 = byte1+byte2 and throw an exception when that exceeds 255, but not throw an exception if int1 = byte1+byte2 yields a value in the range 256-510. –  supercat Jul 6 at 20:28

The answers indicating some inefficiency adding bytes and truncating the result back to a byte are incorrect. x86 processors have instructions specifically designed for integer operation on 8-bit quantities.

In fact, for x86/64 processors, performing 32-bit or 16-bit operations are less efficient than 64-bit or 8-bit operations due to the operand prefix byte that has to be decoded. On 32-bit machines, performing 16-bit operations entail the same penalty, but there are still dedicated opcodes for 8-bit operations.

Many RISC architectures have similar native word/byte efficient instructions. Those that don't generally have a store-and-convert-to-signed-value-of-some-bit-length.

In other words, this decision must have been based on perception of what the byte type is for, not due to underlying inefficiencies of hardware.

share|improve this answer
Cool. I did not know that. –  PeterAllenWebb Oct 15 '09 at 14:27
+1; if only this perception wasn't wrong every single time I have ever shifted and OR'd two bytes in C#... –  romkyns Dec 28 '09 at 11:43
There shouldn't be any performance cost for truncating the result. In x86 assembly it is just the difference between copying one byte of out the register or four bytes out of the register. –  Jonathan Allen Aug 8 '10 at 4:55

I remember once reading something from Jon Skeet (can't find it now, I'll keep looking) about how byte doesn't actually overload the + operator. In fact, when adding two bytes like in your sample, each byte is actually being implicitly converted to an int. The result of that is obviously an int. Now as to WHY this was designed this way, I'll wait for Jon Skeet himself to post :)

EDIT: Found it! Great info about this very topic here.

share|improve this answer
Nice find--that's a good reference –  Michael Haren Jun 2 '09 at 20:22

From the C# language spec Binary numeric promotions it converts both operands to int if it can't fit it into several other categories. My guess is they didn't overload the + operator to take byte as a parameter but want it to act somewhat normally so they just use the int data type.

C# language Spec

share|improve this answer

This is because of overflow and carries.

If you add two 8 bit numbers, they might overflow into the 9th bit.


  1111 1111
+ 0000 0001
1 0000 0000

I don't know for sure, but I assume that ints, longs, anddoubles are given more space because they are pretty large as it is. Also, they are multiples of 4, which are more efficient for computers to handle, due to the width of the internal data bus being 4 bytes or 32 bits (64 bits is getting more prevalent now) wide. Byte and short are a little more inefficient, but they can save space.

share|improve this answer
But the larger data types dont follow the same behavior. –  Inisheer Jun 2 '09 at 20:04
Issues of overflow are an aside. If you were to take your logic and apply it to the language, then all data types would return a larger data type after addition arithmetic, which is most definitely NOT the case. int + int = int, long + long = long. I think the question is in regards to the inconsistency. –  Joseph Jun 2 '09 at 20:05
Agreed, I re-read my post and edited it. –  samoz Jun 2 '09 at 20:06
That was my first thought but then why doesn't int+int = long? So I'm not buying the "possible overflow" arguement... yet <grin>. –  Robert Cartaino Jun 2 '09 at 20:07
Oh, and about the "possible overflow" argeument, why not byte + byte = short? –  Robert Cartaino Jun 2 '09 at 20:08

My suspicion is that C# is actually calling the operator+ defined on int (which returns an int unless you are in a checked block), and implicitly casting both of your bytes/shorts to ints. That's why the behavior appears inconsistent.

share|improve this answer
It pushs both bytes on the stack, then it calls the "add" command. In IL, add "eats" the two values and replaces them with an int. –  Jonathan Allen Aug 8 '10 at 5:21

This was probably a practical decision on the part of the language designers. After all, an int is an Int32, a 32-bit signed integer. Whenever you do an integer operation on a type smaller than int, it's going to be converted to a 32 bit signed int by most any 32 bit CPU anyway. That, combined with the likelihood of overflowing small integers, probably sealed the deal. It saves you from the chore of continuously checking for over/under-flow, and when the final result of an expression on bytes would be in range, despite the fact that at some intermediate stage it would be out of range, you get a correct result.

Another thought: The over/under-flow on these types would have to be simulated, since it wouldn't occur naturally on the most likely target CPUs. Why bother?

share|improve this answer

This is for the most part my answer that pertains to this topic, submitted first to a similar question here.

All operations with integral numbers smaller than Int32 are rounded up to 32 bits before calculation by default. The reason why the result is Int32 is simply to leave it as it is after calculation. If you check the MSIL arithmetic opcodes, the only integral numeric type they operate with are Int32 and Int64. It's "by design".

If you desire the result back in Int16 format, it is irrelevant if you perform the cast in code, or the compiler (hypotetically) emits the conversion "under the hood".

For example, to do Int16 arithmetic:

short a = 2, b = 3;

short c = (short) (a + b);

The two numbers would expand to 32 bits, get added, then truncated back to 16 bits, which is how MS intended it to be.

The advantage of using short (or byte) is primarily storage in cases where you have massive amounts of data (graphical data, streaming, etc.)

share|improve this answer

I think it's a design decission about which operation was more common... If byte+byte = byte maybe much more people will be bothered by having to cast to int when an int is required as result.

share|improve this answer
I for once am bothered the other way :) I always seem to need the byte result, so I always have to cast. –  romkyns Dec 28 '09 at 11:53
Except you don't have to cast to int. The cast is implicit. Only the other way is explicit. –  nikie Mar 15 '10 at 8:31
@nikie I think you didn't understand my answer. If adding two bytes would produce a byte, in order to prevent overflows someone would have to cast the operands (not the result) to int prior the addition. –  fortran Mar 15 '10 at 11:04

Addition is not defined for bytes. So they are cast to int for the addition. This true for most math operations and bytes. (note this is how it used to be in older languages, I am assuming that it hold true today).

share|improve this answer

In addition to all the other great comments, I thought I would add one little tidbit. A lot of comments have wondered why int, long, and pretty much any other numeric type doesn't also follow this rule...return a "bigger" type in response to arithmatic.

A lot of answers have had to do with performance (well, 32bits is faster than 8bits). In reality, an 8bit number is still a 32bit number to a 32bit CPU....even if you add two bytes, the chunk of data the cpu operates on is going to be 32bits regardless...so adding ints is not going to be any "faster" than adding two bytes...its all the same to the cpu. NOW, adding two ints WILL be faster than adding two longs on a 32bit processor, because adding two longs requires more microops since you're working with numbers wider than the processors word.

I think the fundamental reason for causing byte arithmetic to result in ints is pretty clear and straight forward: 8bits just doesn't go very far! :D With 8 bits, you have an unsigned range of 0-255. That's not a whole lot of room to work with...the likelyhood that you are going to run into a bytes limitations is VERY high when using them in arithmetic. However, the chance that you're going to run out of bits when working with ints, or longs, or doubles, etc. is significantly lower...low enough that we very rarely encounter the need for more.

Automatic conversion from byte to int is logical because the scale of a byte is so small. Automatic conversion from int to long, float to double, etc. is not logical because those numbers have significant scale.

share|improve this answer

From .NET Framework code:

// bytes
private static object AddByte(byte Left, byte Right)
    short num = (short) (Left + Right);
    if (num > 0xff)
        return num;
    return (byte) num;

// shorts (int16)
private static object AddInt16(short Left, short Right)
    int num = Left + Right;
    if ((num <= 0x7fff) && (num >= -32768))
        return (short) num;
    return num;

Simplify with .NET 3.5 and above:

public static class Extensions 
    public static byte Add(this byte a, byte b)
        return (byte)(a + b);

now you can do:

byte a = 1, b = 2, c;
c = a.Add(b);

share|improve this answer

Your Answer


