Nullable Types in C#

The updated C# 2.0 specification has been released. It looks like C# has gained another significant feature, extended syntax and support for nullable types.

To refer to a nullable type, the base value type T needs to be followed by a question mark, which is shorthand for Nullable. Nullable types have just two methods, Value and HasValue.

int? var = 1; 

Nullable types can be assigned and compared to the value, null.

var == null

Nullable types can be implicitly and explicitly converted to and from the base type. There is a safe (non-throwing) conversion operator, ??, that provides for a default value if the nullable variable is null.

var ?? 1

Nullable types also support all the native unary and binary operators of their underlying type, returning a null if any of the operands are also null, or, in the case of comparison operators, returning false.

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.

The specification makes no mention of other features that currently exists in the Community Technology Preview, such as fixed arrays.

Comments

[Peter William Lount]

I wonder if the addition of Null Types in C#2.0 are the impact of Microsoft's collaboration with S# (Smalltalk Sharp at http://www.ssharp.org )?

Smalltalk has had "nil" (or if you prefer "null") based programming since the beginning. The "nil" object is the only instance of the class "UnknownObject" class. The "true" and "false" objects are the only instances of the "Boolean" subclasses "True" and "False" respectively.

This enables statements such as:

anObject := nil.
...
anObject ifNil: [ ... ] ifNotNil: [ ... ].

Where "..." is some arbitary other code that does something real.

The above is the equilivant of and much nicer than saying the following.

anObject isNil ifTrue: [ ... ] ifFalse: [ ... ].

The reason that I prefer using "nil" or "object existance" based logic rather than "boolean" logic is that I'm able stay within "object existance" logic without converting it to boolean logic. It improves the "cognative" resonance and makes the statements easier to write, read and debug.

It's easy to add control structures into Smalltalk so I often use "trinary logic" that mixes "boolean" and "existance" logic together:

anObject ifTrue: [ ... ] ifFalse: [ ... ] ifNil: [ ... ].

or the more general

anObject ifTrue: [ ... ] ifFalse: [ ... ] ifNil: [ ... ] ifNotNil: [ ... ].

In this case the appropriate code is executed depending on what the object is. (Note that in this particular case the "ifTrue:" and "ifFalse:" blocks have precedence before the "ifNotNil:", although some might prefer it to execute as well - it could be done that way but I prefer that only one block gets executed in this case).

Programming with "nils" is actually a pleasure. The distinction between "boolean logic" and "existance logic" is very important in an object oriented language.

It's important that "nil" is not the same as "false" since they represent entierly different concepts. Keeping the distinction seperate enables clear expression with object programs.

Not all object languages make this distinction however and that makes them more difficult to program with.

It's nice to see the adoption of this concept into C#2.0. I'm not yet sure if C# has a full impementation but it's an important distinction that more languages would benefit from seriously considering.

Oh, they've also added "closures" to C#2.0 which come from LISP closures and Smalltalk "block" closures. This is an essential concept in modern languages. Hopefully their implementation is useable. It sure would be nice if it could be used to add my own control structures to C#! Would that be asking too much?

[Bill Bozeman]

One comment on your statement above.

"Nullable types can be implicitly and explicitly converted to and from the base type. "

While it's true that you can implicitly cast a base type to it's nullable type, you can't implicitly cast a nullable type to it's base type. You either have to explicitly cast it or use the null coalescing opertor as you have shown.