Type inference in Visual Basic (part 1)

  • Article

If you play around with the LINQ CTP, you will notice that in order to support the LINQ scenarios quite a lot of features were added to the language. A lot of these features, if not all, are useful in scenarios other then LINQ. In this post, I will talk about type inference, which is one such feature.

What is type inference? Simply put, type inference is the compiler's ability to infer the type of an expression and use it for some purpose. In staticly typed languages, the compiler has the ability to perform compile-time type checking; that is, does the use of the type match the requirement? In the simplest form, you can think of this as "does the block match the hole." The compiler typically validated things like:

  • Assignment - does the rvalue expression type match the target variable type?
  • Function call - do the argument expressions match the function signature? What about the return type?

In these cases (and more), the compiler has a type for the lvalue and a type for the rvalue, and it ensures that the two types are compatible (based on various conversion semantics that differ from language to language and platform to platform).

Type inference, thus, is the ability for the compiler to infer the type of the lvalue by using the type of the rvalue. What does this mean? This means that instead of doing type checking (by validating that the type of the lvalue matches the type of the rvalue), the compiler will take the type on the rvalue and tweak the lvalue's type and make it match.

Here is a simple, type checking assignment statement:

dim x as integer = 15

The compiler sees this statement and asserts that the type of x and the type of 15 match (or that the RHS is convertible to the LHS); in this case, they do, and everything proceeds as normal. If they do not, a statically-typed compiler will generate a compiler error.

Here is the same statement using type inference:

dim x = 15

In this case, the compiler looks at 15, determines its type to be an integer, and because no type was specified on the left-hand-side, then the compiler "infers" that the type of x is integer. Note: it's important here to distinguish between the late binding scenarios and type inference. When late binding is "turned on", the above statement in Visual Studio 2005 compiled, but the type of x was System.Object. With type inference "turned on", the above statement gives x the type integer. It is as if you had explicitly declared the type of x to be integer, but instead the compiler is doing that for you.

Turn it on, turn it off

In the LINQ May 2005 CTP, type inference was on all the time. This means that late bound scenarios did not work (this was ok, since the LINQ May 2005 CTP was a preview for LINQ). In the latest Visual Studio Orcas CTP, you will be able to do either/or through an option toggle.

The syntax is:

Option Infer On

And this will turn on type inference.

Next time, I will write about all the cool things that you can do with type inference, and I will also show how using type inference can save you typing time, but keep your program statically type correct.