Null values are a useful programming construct beyond simply recording the initial state of a class variable. In the database world, null conveys a notion of "no value recorded." In a survey, the answer to a question may be yes or no, but if a response isn't provided, isn't available, or isn't relevant to a particular respondent, you can record their response as null rather than a definite yes or no. Because many applications deal with data that's stored in databases, where null values can be quite common, the ability to express null values becomes quite important.

The inability to store nulls in value types can be a significant problem in C#. Value types, by definition, consist of bits that either are allocated on the stack when they're declared as a local variable or are allocated inline when they form part of heap-allocated types. Because a value type is always physically allocated, it has no ability to express an unallocated or null value type. Further, since value types don't have the luxury of an object header (like reference types do), they don't have a spare header bit that can indicate an instance is null.

Dealing with the inability to express nullability becomes particularly troublesome when dealing with data that originates from databases. Databases typically don't have separate concepts for reference and value types, and all data types can be null if the schema allows. Before nullable types, recording null values in value types was a difficult task. The following options existed:

• You could choose a special value to indicate logical null. For signed integers, -1 was often a reasonable choice; for floating points, NaN was popular. Finally, for dates, DateTime.MinValue was often used.
• You could use a reference type that stored the value type internally and leave it as null when appropriate. The types in System.Data.SqlTypes and various third-party libraries were used in this role.
• You could maintain a boolean variable for every value type variable that could potentially be null. The boolean would keep track of whether the accompanying value type was logically null.

All of these alternatives had problems. Special values were often hard to define and had the unfortunate tendency to end up back in the database if a developer wasn't careful with the update logic. This in turn created the painful problem of catering to both physical and logical nulls. Using reference types was effective, but this data-tier local implementation decision had a tendency of spreading through all tiers of an application, which meant that the performance benefits offered by value types weren't available. The third alternative was generally the cleanest and simplest option, but it was cumbersome to implement, particularly with method return values, and it also wasted space.

Because developers needed a general-purpose solution to value type nullability, and because the designers of C# 2.0 were empowered by the addition of generics, they extended the framework library to include the Nullable value type. Nullable can take any value type as a type parameter, and it internally stores a boolean to track logical nullness. This approach is essentially the same as the third option from the previous list but is simpler from a logistical point of view, as only a single variable needs to be tracked.

C# Language Nullable Types

The designers of the C# language figured the ability to convey nullability in value types was important enough to elevate nullable types from a generic type in the framework library into a fully fledged language feature. C# language nullable types map directly to the Nullable framework library type, so any other language that supports generics can use C# nullable types.