"Nullable Types"

Update: More concerns from Wesner Moise's blog on "Why elevate Nullable Types?". The interactions of complex features just create more complexity. Rigid languages resist change. Flexible languages rarely need to change...

The new nullable types syntax points to a weakness in the design of generics.

The constraints mechanism in CLR generics currently disallows C# operators from being lifted from the underlying base type to their nullable versions.

An explanation of Nullable Types which is a new concept in C# 2.0, as far as I can tell because the language designer did not get the concept of objects quite right. (For earlier evidence, consider the C# concepts of boxing and stack allocated structs vs. objects, read up on their justifications, and then consider the languages that don't expose boxing to the typical developer.)

I assume Nullable Types is a kludge for supporting database programming, because some column for some row might have a value or might be null. Of course, database nulls are themselves a bit of a kludge. They muck up database programming and should generally be avoided. So why move that muck up into the programming language? Again, I guess this is because C# can be used to write stored procedures in the next version of SQL Server. There's enough muck to spread around, hopefully something beautiful might grow from this, but I'm skeptical as usual.

Further muck...

There is special treatment for booleans. Nullable bools are a form of ternary boolean values, which can safely be used in if, for, while conditions and logical expressions without throwing exceptions.

This is assuming one wants Null and False to behave the same. (I assume this is the intended behavior.) This is questionably useful.