Proposal: Let's fix casting, unboxing and converting in VB with "As Type"

[KlausLoeffelmann]

This idea addresses scenarios #82, #83, #84, and #87.

UPDATE: This is an animated Gif of a prototype which demonstrates the feature in more detail.

Casting, Boxing/Unboxing and type converting in Visual Basic is currently an inconsistent mess. We have TryCast, DirectCast, CType and Casting/Converting Keywords based on individual types (CInt, CString, CChar, CShort, CUShort, CByte, CSByte etc.). So, folks often do not know, which Operator to use in what situation, particularly since CType and DirectCast generate not only different code, the CType code is also considerable slower, for example when unboxing value types. Only few VB developers now this:

Unboxing Integer Value CType vs. DirectCast:
DirectCast:

intvalue = DirectCast(objectInt, Integer)
Resulting IL:

IL_002c: ldloc.2
IL_002d: unbox.any [mscorlib]System.Int32
IL_0032: stloc.1

CType:

intvalue = CType(objectInt, Integer)

Resulting IL:

IL_0079: ldloc.2
IL_007a: call int32 [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.Conversions::ToInteger(object)
IL_007f: stloc.1

On top, DirectCast and CType make it hard to read and write VB code for CSharp developers, and also for VB Developers whose teams prefer CType over DirectCast or vice versa. Apart from aesthetics and differences which lead to differently performing code (up to factor 2,5!), what’s really bad is this: Although there are way too many Casting/Converting/Unboxing operators, a few scenarios cannot even be applied at all in Visual Basic.

#1: Pure conversion from Double/Float in Int16/32/64 is not possible in VB.
C# Sample:

            double doubleVar = 3.14159;
            int inVar = (int)(doubleVar / 42);

Resulting IL:

  IL_0001:  ldc.r8     3.1415899999999999
  IL_000a:  stloc.0
  IL_000b:  ldloc.0
  IL_000c:  ldc.r8     42.
  IL_0015:  div
  IL_0016:  conv.i4
  IL_0017:  stloc.1

VB Sample:

        Dim doubleVar As Double = 3.14159
        Dim intVar = CInt(doubleVar / 42)

Resulting IL:

IL_0000:  nop
IL_0001:  ldc.r8     3.1415899999999999
IL_000a:  stloc.0
IL_000b:  ldloc.0
IL_000c:  ldc.r8     42.
IL_0015:  div
IL_0016:  call       float64 [mscorlib]System.Math::Round(float64)
IL_001b:  conv.ovf.i4

There seems to be no way in VB to not make a trip to Math.Round in the conversion from floating point to integer. This is most probable to keep legacy behavior from VB6 code.

#2: Convert an integer to a character with the specified value.
CSharp Code:

            var charVar = (char)65;

Resulting IL:

  .locals init ([0] float64 doubleVar,
           [1] int32 inVar,
           [2] char charVar,
           [3] string stringVar)
.
.
.
  IL_0018:  ldc.i4.s   65
  IL_001a:  stloc.2

VB Code:

        'Error:
        'Dim charVar = CChar(65)
        'Dim charVar = CType(65, Char)
        'Only way:
        Dim charVar = Convert.ToChar(65) ' or, of course, ChrW(65) - thx Bill!

#3: TryCast Unboxing to Nullable Value Types.
CSharp Code:

            object iAso = 42;
            var iN = iAso as int?;

Resulting IL:

  IL_0001:  ldc.i4.s   42
  IL_0003:  box        [mscorlib]System.Int32
  IL_0008:  stloc.0
  IL_0009:  ldloc.0
  IL_000a:  isinst     valuetype [mscorlib]System.Nullable`1<int32>
  IL_000f:  unbox.any  valuetype [mscorlib]System.Nullable`1<int32>
  IL_0014:  stloc.1

Visual Basic Code:

        Dim iAso As Object = 42
        'Does not work!
        'Dim iN = TryCast(iAso, Integer?)

Proposed Solution:
Let’s introduce As Type as a universal conversion, unboxing and TryCast Operator that would work similar to C# casting (type) and As Type. This way, we would not break any existing code. Adding As at the end of an expression currently produces a syntax error, so this new usage should not break any existing code. On top, ForEach loops already allow As Type, so this usage would become more consistent and would feel kind of right. Here are a few examples:

        ‘Conversion, and we do not need to take legacy into account
        Dim doubleVar As Double = 3.14159
        Dim intVar = (doubleVar / 42) As Integer

        ‘ In contrast to CType however, As Type would result in a TryCast…
        Dim c As Contact = New Employee With
            {.FirstName = "Adriana",
             .LastName = "Löffelmann",
             .Employer = "ActiveDevelop"
            }

        Dim e = c As Employee ' TryCast(c, Employee), same as in CSharp!
 
        ‘…to be consistent with Try-Cast-Unboxing, which was not possible before:
        Dim iAso As Object = 42
        Dim iNull = iAso As Integer?

       'we could even leave this „bug“ as it is, because this line would be easily understood:
        Dim iNull = If(Nothing, 1 As Integer?, Nothing)

[Bill-McC]

Re case 2, the current solution is to use ChrW. n.b this is a type conversion, not a cast.

Re case 3, yep it's a pain. TryCast( object, Integer?) should work, IMO. Think this is a bug in it wasn't updated with nullable types. Would also like to see CInt? et al.

Re case 1, I think this hasn't been "fixed" due to bankers rounding rules . Not sure on this. If
CType( 1.5, Int32) does the same as CInt(1.5)
, but different from
`1.5 As Int32

The trunating of integers can be a performance issue. If we can't introduce a CTrunc(var) or Trunc(var) because it may break code that has implemented their own CTrunc or Trunc, then I guess yet another syntax is the only way. But I do worry in how discoverable it would be and feel it would increase the incosistent mess by adding yet another way. Would like to see initial focus on fixing what we have.

[KlausLoeffelmann]

2: True. ChrW is the current solution. I added that in a comment, thx Bill! (I guess, I blocked it out, cause I hate it! ;-) )
Still, it is much (and unnecessary) slower than the C# like solution.

3: CType(1.5,Int32) does the same. No direct (int) floatValue would be possible in VB currently without the bankers rounding, AFAIK. With As Type we could also introduce As Type? - yet another advantage! :-)

Given the fact, that 60% of the active VB Devs are also doing C#, I'd say As Type would be pretty much self-discoverable. It certainly would be an elegant solution, since it is "one for all", and does not need new Keywords.

[Bill-McC]

ChrW can be optimal if it is a constant, eg ChrW(42). Probably a perf hit with ChrW(int32) due to range checking .( not sure)

I'm not against the "As Type" solution, in fact I think it is more fluent. But I think we need to fix what's broken as best as we can, first. The example of TryCast(value, Int32?) is a case where a developer gets a negative experience, wondering why that doesn't work.

[KlausLoeffelmann]

ChrW is a Strings Class Method. Can it be optimized as perfect as using a Keyword? (char) value results in IL just writing the value to a char local - so no method call, no conversion involved, if I understood correctly (but I'm only getting slowly better in IL!) And yes, TryCast(value, struct?) should be fixed, anyway!

[Bill-McC]

chrw use to be compiled fully optimised with constants. (I haven't checked latest builds) With variables I guess it could be optimized too although it'd be more an issue with what kind of resulting error is raised if the number is greater than int16.

[KlausLoeffelmann]

ChrW is still fully optimized with constants, I just checked it. (Did not know that!)
But with variables, Strings.ChrW is called.

This

    Public Function SimpleCasting() As String

        Dim doubleVar As Double = 3.14159
        Dim intVar = CInt(doubleVar / 42) ' As Integer

        intVar = CType(doubleVar / 42, Int32)

        'Dim iNull = If(Nothing, 1 As Integer?, Nothing)

        'Error:
        'Dim charVar = CChar(65)
        'Dim charVar = CType(65, Char)

        'Only way:
        Dim aInt = 65
        Dim charVar = Convert.ToChar(aInt)

        Dim t = Strings.ChrW(aInt)
        Return {charVar, t}.ToString

    End Function

C#-Decompiles to this:

       public static string SimpleCasting()
        {
            double num = 3.14159;
            int num1 = checked((int)Math.Round(num / 42));
            int num2 = checked((int)Math.Round(num / 42));
            int num3 = 65;
            char charVar = Convert.ToChar(num3);
            char t = Strings.ChrW(num3);
            return (new char[] { charVar, t }).ToString();
        }

[xieguigang]

As Type type casting makes the vb code style more elegant, awesome!

[DualBrain]

I've been noodling this for a bit of time now; so I haven't responded earlier. Something about this was just bothering me but I was having a difficult time trying to figure out exactly what it was....

Option Infer On

Dim value = 3.9
Dim r As Integer = value
Dim w = value As Integer

Print(value)
Print(r)
Print(w)

Would result in:

3.9
4
3

Wait!!!! WHAT?????

Using As Integer before an equal sign does one thing, but using it after a value does another?????

This breaks the language.

For context, some history...

In VB, we have 3 different (historical) ways to convert a number from a fraction to a whole number.

1. CInt() - the most commonly known and used. This method takes a number and converts it to the nearest whole number... aka "Bankers Rounding".
2. Int() - the most historical. This function can be traced back to the original version of BASIC; and, I can only assume, Bill Gates misunderstood it's purpose and thus we have how it works today versus how it originally worked in "Dartmouth" BASIC circa 1964. This function, in Microsoft BASIC -> VB Current "truncates" the value if it is a positive number, however, if it is a negative number it "rounds up". (This, by the way, is not the original Dartmouth design.)
3. Fix() - "Fixes" the incorrectly incorporated Int() function. ;-) It does what Int() should have done in the first place... it literally truncates the value, positive or negative, to the existing whole number.

Back to the original subject...

Language design is hard. Adding any additional keywords is hard. Changing the behavior of existing keywords is wrong.

Having As Integer do one thing when used before an equal and work differently when on the other side of the equal sign is wrong.

Now that that is out of the way, I have some additional background to why this proposal exists in the first place as I was there when the original problem was brought to the surface... it's an issue of performance penalty when, in VB, you attempt to truncate a number. There is already an existing way to truncate a number in VB that is widely used not only by us mortal but also conversion tools that convert C# to VB (for example).

There are two problems where... the first being that we need to truncate a floating point value to it's existing whole number value (no rounding).

This is done using Fix(). (Full disclosure, there are other ways in the framework... I'm sticking to common scenario here.)

The problem with Fix() (and the rest of the Math functions...) is that it gives us the number, be we still have a floating point value to contend with. What we really want is to take this number, now that we have it, and convert it to a different type (Integer). To do so, we then use the C(onvert)Int() or C(ast)Int() function. CInt() takes a value and converts/casts it to a different type (an Integer). As a convenience in VB, this function accepts several different types and "does the work for us" (less thinking on our part). It accepts both floating point and non-floating point values. If provided a floating point value, it will convert it to the nearest whole number. This is awesome and right; don't let the curly brace crowd tell you any differently. ;-)

So, to get the result we are looking for...

Dim i = CInt(Fix(value))

This is the way it's always been done... now to the original underlying problem...

If you are doing this a lot (ie... image manipulation, CPU emulation, etc.), we as VB developers are penalized compared to C#'s Int(value) as the VB version that is functionally equivalent is provably "slow".

To add, every conversion tool that I've utilized will do the convert C#'s Int(value) to CInt(Fix(value)) as, again, they are functionally equivalent... however, there is a performance hit to achieve the same result.

My recommendation is to not change the language, but fix (pun intended) the underlying problem. There is a performance hit and this can "easily" be addressed with a compiler optimization by short circuiting CInt(Fix(value)) to utilize the same Conv.I4 that C#'s Int(value) uses.

I want to be clear here, this is not a C# vs VB discussion... this is a SELECT CASE has compiler optimizations that are applied when possible to improve performance, I want to see something similar with CInt(Fix(value)) as there are real-world situations where everyone would benefit if it were done.

With that said, this is also an edge case scenario... MOST developers using VB will NEVER notice this; however, MACHINES will. If this optimization is put in place, EVERY machine that is running code where this conversion/casting is necessary, EVERY CPU doing so would benefit from the optimization. The beauty here is that developers would need to do NOTHING to benefit and those people who do need this would also be the same people that would have eventually understood that using SELECT CASE one way is "slow" and another way is "fast".

Adding something to the language that is confusing is wrong; even if at first it looks "right". I did mention that language design is hard, right?

[DualBrain]

The short version:

"But I do worry in how discoverable it would be and feel it would increase the incosistent mess by adding yet another way. Would like to see initial focus on fixing what we have." -- Bill-McC April 8th, 2017