Leon_Amirreza said:
Just a Naming Convention and uniformity question:
Why not to have a Int8 and UInt8 types instead of Byte and SByte in .Net
framework?!
You mean SByte and Byte. Int8 would be signed SByte, UInt8 would be unsigned
Byte.
This also highlights the problem: some languages (notably VB.NET) have no
support for unsigned integers (they're not CLS-compliant). On the other
hand, they do all support Byte. Conversely, they don't have to support SByte
(and, predictably, VB.NET doesn't support it). This is one mismatch that
justifies a different type name: integers are mostly signed, bytes are
mostly unsigned, and language support reflects this.
Although you're technically right that a byte is an unsigned 8-bit integer,
it's rarely considered that way, and a signed 8-bit integer is even less
obvious. For example, you don't often perform arithmetic on bytes -- you
copy them around and manipulate their bits. This is another reason why it's
Byte and not UInt8.
Finally, Java started the tradition with byte, and it's no secret that the
CLR was heavily inspired by the JVM. The difference is that .NET actually
got it right by making "byte" unsigned. Java went for a foolish consistency,
eliminated unsigned types altogether, and made programmers' lives miserable
everywhere by forcing them to deal with signed bytes (which complicate code
for the vast majority of cases).
Of course, I didn't work on the CLR, so this is just my justification. I'd
repeat the decision if I were designing the type system.
