Option Infer in VB.NET 2008

In VB6, we could use a variable without declaring it as ...

myVar1 = "whatever"
myVar2 = 666

The variables were compiled as Variant types, which could hold anything.

This was carried over into .NET as Object types. If Option Explicit is Off, then you can write the same code and the variables became Object types. Again, they could hold anything. But the default changed in .NET (Option Explicit is On by default) and we were strongly encouraged to declare everything. Not only did it help the compiler catch errors so the application didn't crash at runtime, but the code ran faster because the variables were "early bound" instead of "late bound". With late binding, the compiler has to add code to figure out what a variable is before using it and that slows everything down. VB 6 was slower for the same reason.

But you and I can see that myVar1 should be a string and myVar2 is an integer. Why can't the compiler see this? That has been fixed in VB.NET 2008. Now it can.

There are a few rules, however. You still have to declare variables but you can leave out the Type description. In other words, you can now code something like:

Dim myVar1 = "whatever"
Dim myVar2 = 666

Instead of creating them both as Object types, VB.NET 2008 will assume that the first is actually a String and the second is an Integer, like it should. But if you code it like this:

Dim myVar1
myVar1 = "whatever"

myVar1 is still compiled as an Object type.

This saves you a few keystrokes, but that isn't the reason Microsoft did it. This new behavior was required by another new feature of VB.NET 2008: anonymous types. And this, in turn, was required by the new LINQ feature: Language INtegrated Query.

Using LINQ, you can now code a query directly in VB.NET that looks something like this:

Dim myCustOrder = From myOrder In Orders _
Where myOrder.Name = "About Visual Basic"

myOrder.Name is never declared. Actually, it is, but the compiler does it automatically and you don't have to. To make this work, Microsoft had to add the capability to their compiler to figure out what a type is from the context. Once they did that, several other advantages became possible too.

If you code something like ...

Dim myCustomer = GetCustomer(myCustNumber)
myTextBox.Text = myCustomer.Name

... and there is no Name member in myCustomer, VB.NET 2005 will crash at runtime. VB.NET 2008 will catch it as a compiler error.