New CVal conversion operator for native integer conversions

[AnthonyDGreen]

This idea addresses scenarios #82 and #83.

This new operator would take the form: CVal(<Expression>, <Type>)

Where <Expression> can be of the following types:

• Object type: Object
• Signed integers: SByte, Int16, Int32, Int64
• Unsigned integers: Byte, UInt16, UInt32, UInt64
• Floating-Point: Single, Double, Decimal
• Character type: Char
• Any enumeration type

Note: This excludes type parameter types.

And <Type> can be any of the above types excluding Object.

Note: This excludes type parameter types.

The behavior is as follows:

• From Object to any valid target type, a native CLR unbox conversion shall be used.
• Between signed and unsigned integers, the bits of the integer shall be re-interpreted with the new type.
  • If the destination type has more bits than the source type the result shall be sign-extended.
  • If the destination type has fewer bits than the source type, the result shall truncate the excess bits.
• From any floating-point type to a signed integer type, the fractional portion of the floating-point value shall be truncated.
  • For negative values this truncates "up" to zero.
• From the character type to any signed or unsigned integer type, the result shall be the Unicode 16 value of the character.
• From any signed or unsigned integer type to the character type, the result shall be the character indicated by that Unicode 16 value.
  • For values larger than 16-bits, excess bits shall be truncated.
• Conversions to or from enumeration types shall behave as if those conversions were being performed to or from the underlying integer type of the enumeration.
• Conversion overflow/underflow checking is governed by the checked/unchecked settings of the project.

Open questions:

• Nullable/lifted conversions
• Conversions between Boolean and integer types
• Reconcile behavior being orthogonal to overflow/underflow settings with above behavior that truncates excess bits.

[KlausLoeffelmann]

How would this operator work? Like Ctype?

[AnthonyDGreen]

@KlausLoeffelmann I updated the description with a little more detail. That really should go into a speclet so that we can update it with PRs.

[Bill-McC]

Boolean to Int.... hmmmm. I'm sure I've heard that discussion (in length) before. Unless there is a serious performance differential in favour of the single bit, I'd say stick with all bits on/off.

[Bill-McC]

Re overflow checking: I thought the idea of cval was to avoid such things. Without that hard to see the difference between conversion operators.

If we get unchecked blocks, I'd expect CVal to work the same regardless. I'd even like ChrW to avoid bound checking if inside an unchecked block, but then again that'd mean you'd have to exit the unchecked block to get traditional chrw.

So I think I'd prefer conversion operators to remain consistent, with CVal focusing on high performance non bound check conversions, always.

[Nukepayload2]

Conversions between Integer and Boolean should behave like System.BitConverter .

Dim booleanValue = False
' Dim int32Value = CVal(booleanValue, Integer)
Dim int32Value As Integer = BitConverter.GetBytes(booleanValue)(0)

Dim int32Value = 1
' Dim booleanValue = CVal(int32Value, Boolean)
Dim booleanValue = BitConverter.ToBoolean(BitConverter.GetBytes(int32Value), 0)

[Bill-McC]

@Nukepayload2 the BitConverter.ToBoolean( bytes(), startindex) method compares each byte to zero and if it is non zero returns True. So rather than convert the integer to a byte array, it'd be simpler to write:
bool = If(value = 0, False, True)
In either case any non zero value is True. Logically: True = Not False.

So using bitconverter or the above if expression, 1, 2, 3, 4, 5, etc are all True.

[Bill-McC]

Sorry, I should have properly tested BitConverter.ToBoolean(bytes(), startindex)
It only tests the byte at startindex. So values 1 to 255, return true, but values 256 * n return False. I.E,
254 is True,
255 is True,
256 is False,
257 is True,
...
512 is False,
513 is True,

or basically it is testing just value And &HFF <> 0

[Nukepayload2]

The BitConverter.ToBoolean(Byte(), Integer) is testing value(startIndex) <> 0.

'==================================ToBoolean===================================
'        **Action:  Convert an array of bytes to a boolean value.  We treat this array 
'        **         as if the first 4 bytes were an Int4 an operate on this value.
'        **Returns: True if the Int4 value of the first 4 bytes is non-zero.
'        **Arguments: value -- The byte array
'        **           startIndex -- The position within the array.
'        **Exceptions: See ToInt4.
'        ==============================================================================

' Converts an array of bytes into a boolean.  
Public Shared Function ToBoolean(value As Byte(), startIndex As Integer) As Boolean
	If value Is Nothing Then
		Throw New ArgumentNullException("value")
	End If
	If startIndex < 0 Then
		Throw New ArgumentOutOfRangeException("startIndex", Environment.GetResourceString("ArgumentOutOfRange_NeedNonNegNum"))
	End If
	If startIndex > value.Length - 1 Then
		Throw New ArgumentOutOfRangeException("startIndex", Environment.GetResourceString("ArgumentOutOfRange_Index"))
	End If
	Contract.EndContractBlock()

	Return If((value(startIndex) = 0), False, True)
End Function

http://referencesource.microsoft.com/#mscorlib/system/bitconverter.cs,2af546f79a0b33fc

[Bill-McC]

Yep, so when you call BitConverter.GetBytes(int) and pass it to ToBoolean, it is effectively bitmasking the first byte, value And &HFF <> 0
The problem with that is you get the bizarre cases where 256 is False, but 258 is True.
The testing for zero is correct, it is the bitmasking that isn't. The definition for Boolean should be zero | non zero.