I read with great interest Paul Vick’s post on “The truth about Nullable types in VB“ vs. C# as I am talking about nullable types in my revised Whidbey BCL talk that I am doing at VTdotNET in a week and then at DevTeach in a few weeks.

I have played with nullable in the March preview bits, but not yet in the May and disappointed with the current (but slated for serious improvement by the bcl team!!!) performance when I compared the using nullable<t> over current options. So for example with value types: 

 – comparing myNullableInt.HasValue to (in VB) is myInt < 0

or with reference types

 – comparing myNullableThing.HasValue to “if not myThing=null”

the nullable type is currently much much slower. I have been promised by a few on the BCL team that the plan is to make the nullable MUCH more performant as it is their “best practices” suggestion (see Krzysztof’s Generics guidelines) to use nullable types.

I have also been given the hint that in the future, the following will be possible:

Nullable<T> Parse(string value);
Nullable<Int32> i = Int32.Parse( some String );

And will be more performant than TryParse. So that, too will be interesting.

It’s interesting to see all the groovy little shortcuts that C# is getting now and VB will be getting someday hopefully, though for now, all we really get of value (please correct me if there is more…) is the “hasvalue“ property which benefits us mostly for the value types coming back from databases.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!