Forcing VB to not default to Int32 when shifting?

[Kumba]

I swear by the programming gods this is driving me insane. Consider the following function below:

    Public Function VBSucks(ByVal q As UInt32, ByVal z As UInt32) As Uint32
       Return (q << z)
   End Function

 

VB underlines 'z' in red and spits the following error:

Option Strict On disallows implicit conversions from 'UInteger' to 'Integer'.

 

Here's the thing, I want to left-shift/right-shift using UInt32, Int64, Byte datatypes. VB, on the other hand, tries to perform the arithmetic in Int32, and fails because the operands are not Int32. I'm not sure what the accepted workaround is for errant behavior such as this. UInts, Longs, etc, are valuetypes, so I can't force things like I can with BigInteger by going New BigInteger(q << z). I also do NOT want to accept VB's recommended fix of using CInt(z).

 

Wrapping the thing in CUint(), DirectCast(), or even wrapping the operands with either of those does not work. Did Microsoft forget to overload the << and >> operators for the unsigned and long data types in .NET 4.0? Or is there some obvious secret sauce that I am missing?

[snarfblam]

VB's bit-shift operator supports practically all integral types:

The data type must be an integral type (SByte, Byte, Short, UShort, Integer, UInteger, Long, or ULong).

[/Quote]

 

VB wants you to specify the number of bits to shift as an integer. If you change your code like so,

   Public Function VBSucks(ByVal q As UInt32, ByVal z As [color="Red"]Integer[/color]) As Uint32
       Return (q << z)[/color])
   End Function

it should behave exactly as you'd like. You're still shifting a UInt32. Unlike most binary operators, there's no need here for both operands to be of the same type here.

[Kumba]

VB's bit-shift operator supports practically all integral types:

 

 

VB wants you to specify the number of bits to shift as an integer. If you change your code like so,

   Public Function VBSucks(ByVal q As UInt32, ByVal z As [color="Red"]Integer[/color]) As Uint32
       Return (q << z)[/color])
   End Function

it should behave exactly as you'd like. You're still shifting a UInt32. Unlike most binary operators, there's no need here for both operands to be of the same type here.

 

This is what I figured, however, one would think MS would catch this usage better and display a general error message that more specifically states that VB expects the number of bits to shift to be Int32.

 

This ambiguity gets in the way when you're converting hashing functions from other languages, where it might declare say, x, y, & z to be uint32, and then do something like "x << y". If you re-implement that code in VB, and don't account for VB expecting that one operand to always be Int32, then you're left scratching your head (Like I was, and add that to being a tad frustrated on not finding a straight answer, leads to my inquiry here...).