Int8 and UInt8 types instead of Byte and SByte

  • Thread starter Thread starter Leon_Amirreza
  • Start date Start date
L

Leon_Amirreza

Just a Naming Convention and uniformity question:

Why not to have a Int8 and UInt8 types instead of Byte and SByte in .Net
framework?!

it makes adding code to the program at run time easier and more uniform! ;)
 
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.
 
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).


VB.NET supports SByte, UInt, et al. Has done since 2005 IIRC.

-Alex
 
Alex said:
VB.NET supports SByte, UInt, et al. Has done since 2005 IIRC.
Wow, you're right -- introduced all the way back in VB.NET 2.0. You can tell
I don't read the "What's New" lists for VB that closely. :-)

That said, these types are still not CLS-compliant, so don't expose them on
public interfaces if you want them to be interoperable with all .NET
languages (though if even VB has support these days...)
 
Back
Top