Unsigned Types

As you
may have seen on the roadmap (https://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx),
we've been working on several new language features for VB .NET. One of them includes unsigned types. Yes, VB is finally getting unsigned types,
and this will make some tasks a lot easier.

Specifically,
we are adding intrinsic support for four new integral types, three of them
unsigned, one of them signed. Here's a
table which describes the new types:

For
consistency with earlier versions of VB, the name of the original type makes up
the root of the new name, prefixed by a U (or S) to denote the signededness of the type. We used a similar approach to name the conversion operators and type
characters. SByte has no type character
because Byte has no type character.

Here's a
code snippet which uses each of these new types:

Module
Module1

    Sub Main()

       
Dim a As
SByte = -127

       
Dim b As UShort
= 65535

       
Dim c As UInteger
= 4294967295

       
Dim d As ULong
= 18446744073709551615UL

       
Dim o As Object

       
o = CSByte(42)

       
a = CSByte(o)

       
o = 42US

       
b = CUShort(o)

       
o = 42UI

       
c = CUInt(o)

       
o = 42UL

       
c = CULng(o)

    End Sub

End
Module

Of
course, this snippet is a contrived example demonstrating the new syntax. Here's a real-world example:

Module
ExternalFunctions

    Structure INFO

       
Public KIND As UShort

       
Public FLAGS As UShort

       
Public DATA As UInteger

    End Structure

    Declare Auto Sub GetData Lib "mylib" (ByRef Info As INFO)

    Declare Auto Function GetCount Lib "mylib" _

        (ByVal Index As UInteger) As UInteger

    Sub Enumerate()

       
For i As UInteger
= 0 To GetCount(10)

           
Dim Info As INFO

           
GetData(Info)

           
Console.WriteLine(Info.KIND)

           
Console.WriteLine(Info.DATA)

       
Next

    End Sub

End
Module

One final
note: unsigned types also affect method
overload resolution. If two methods are
equally applicable because the argument types do not exactly match the
signature, yet the methods differ only by the signededness
of a parameter, the method with the signed parameter wins (except for SByte and Byte, where Byte wins). This rule
reduces the occurrence of ambiguity errors.

Comments

• Anonymous
  August 25, 2003
  What work is being done with unsigned values and bit operations (and, or, <<, >>)? Today, we have the issue of the signed bit causing problems when using the signed values and trying to do bit manipulation on values over a certain ceiling. Unsigned values should solve this issue (as it does in languages that already have unsigned values). I just want to hear from someone that all will be as expected on this front.
• Anonymous
  August 26, 2003
  Correct, unsigned types will solve this problem. And, Or, <<, and >> will behave with unsigned types as they do in other languages.
• Anonymous
  October 14, 2003
  The comment has been removed
• Anonymous
  July 20, 2004
  When will this be incorporated into the Studio.Net?
• Anonymous
  July 20, 2004
  see here:
  http://www.panopticoncentral.net/archive/2004/06/29/1327.aspx
  
  - Cameron
• Anonymous
  May 31, 2009
  PingBack from http://outdoorceilingfansite.info/story.php?id=1303
• Anonymous
  May 31, 2009
  PingBack from http://outdoorceilingfansite.info/story.php?id=18939