In Example A, we get type mismatch errors on both lines: Dim s As String, v As Variantīut in Example B, these lines both succeed: Dim s As String, v As VariantĪ lot of implicit type conversion is going on here. With arithmetic operators, there is neither an advantage nor a disadvantage to using Variants instead of simple data types in either case, it's the value, not the data type, that determines whether the operation can take place. Does this also apply to the use of Visual Basic's own built-in functions and operators? The answer is, "It depends on the operator or function involved."Īrithmetic operators All the arithmetic operators (such as +, -, *, \, /, and ^) evaluate their parameters at run time and throw the ubiquitous type mismatch error if the parameters do not apply. I have already suggested, for the purposes of assignment and function parameters and return values, that using Variants cuts down on problematic run-time errors. Returning to our survey of how Variants behave compared to simple data types, we now look at expressions involving Variants. Of course, it's not necessarily so obvious by looking at the declaration what the parameters mean, but then that's what the parameter name is for. Now no run-time errors or compile-time type mismatch errors occur. The problem is that you might reasonably expect that after assigning 6.4 to x in the procedure subByRef, which is declared in the parameter list as a Variant, Debug.Print would show 6.4. Instead, the procedure could be defined using Variants: Sub f(ByVal i As Variant, ByVal s As Variant) With pre-OLE versions of Visual Basic you get a Parameter Type Mismatch error at compile time, but in Visual Basic 4, 5, and 6 the situation is the same as in the previous example-a run-time type mismatch, depending on the value in s, and whether the implicit CInt could work. You'll notice I put the parameters in the wrong order. This procedure is called by the following code: Dim i As Integer, s As String Sub f(ByVal i As Integer, ByVal s As String)