Did I tell you I went to the SDNUG meeting last night? There were two presentations on the night the first being the new "nulltable types" feature in the runtime which also has first class syntax support in the updated version of C#. Troy Magennis did a fantastic job talking about the new language feature - and coped well with the roudy and opinionated audience (not me, honestly!).

I think doing revisions to a language spec has to be one of the hardest things you can possibly do. Its not hard to update a few BNF grammars, but it is hard to balance the wants and desires of a legion of developers.

One of the most common challenges for business application developers targetting the .NET platform is the impedance mismatch between database type definitions and runtime types. The problem you see is that most database system types allow things like integers to have a null value. In .NET an integer is a value-type which means that it cannot be set to null - its default value like other numeric types will be zero.

So what do you do when you try to get an integer from a data-reader (for example) that has a null value and stuff it into a runtime type? Bang! Exception! That is why methods like IsDBNull haven't found their way to the scrap heap and most data access providers support a proprietary type system (check out System.Data.SqlTypes).

Well, as you are probably aware the .NET Framework is going to support generics in the next drop and some bright spark came up with the idea of having a generic type (Nullable<T>) which can be used like this:

Nullable<int> myNullableInt = new Nullable<int>();

The idea is that whenever you need to work with integers that may be null you can use this syntax instead of doing some hairy branching to do something like insert a magic number instead (never an elegant solution).

The C# folks, being the developer friendly folks that they are have provided a shortcut syntax which is a little more succinct.

int? myNullableInt = null;

The syntax certainly raised a few eyebrows at the user group meeting and I guess I can understand why. The primary concern seems to be that over time most C# code will evolve to use the new syntax and it'll start to look like the Riddler came to decorate (if they could make the ? highlight to green that would be too cool!).

Personally however I think that this is a little bit overstated because code that would need to deal with nullable types like this is more likely to be constrained to data handling code than you straight-forward algorithmic code (why would I need to use a nullable integer as an indexer for a for-loop?).

I think that the C# and runtime teams had a few via options:

• Do nothing, make 'em suffer!
• Provide a short-hand way to declare a nullable type.
• Intoduce some new types (nint, ndouble etc).
• Make value-types nullable by default.

I'll tackle the last ones first. Assuming that the underlying performance challenges which lead to the split type system still exist the runtime team would need to do an almightly kludge to differentiate between value-types that had the potential to be null and those that didn't.

Introducing new types is an option, in fact last night I came out in favour of this but on further reflection I think that it would actually make things more complex, for example - you would need "nuint" - and lets face it NUnit is already hard enough to type! The fact is that the question mark syntax makes things easier to understand - especially when you consider how it will work with your own value-types.

The second option from the top is what they have done, and give that the first option is the only other alternative I'm glad thats the approach they took. I think the C# team will know they have gone too far when Perl wonks start singing its praises.