Code Contracts in .NET 4.0, no joy for non-nullable reference types fans?

Question

I've been playing with Code Contracts on VS2008 (http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx).
They surely are nice and provide a solid alternative to if-then-throw checks inside methods.

Nonetheless I've been hoping that they could satisfy the need that I strongly feel for non-nullable reference types.
Alas, from what I could see this doesn't seem to be the case.
This is what I understood:

• Something like this will still cause issues at runtime:
  MyClass a = null;
a.ToString();

• I still have to explicitly write checks, even if in a more concise and streamlined way.

• Unless you use VS Team System you can only use code contracts to check things at runtime, no benefits at compile time.
  Meaning that you still have to handle things when something goes wrong.
  Not much different from handling a simple exception.

• Even with VSTS static analysis isn't as a good as the one done at runtime.
  This is perfectly understandable, still it's another sign that this feature is meant for runtime usage.

Please correct me if I'm wrong but from what I see there's no way Code Contracts can make my life easier, and my programs more robust, like non-nullable reference types would.

Don't get me wrong, I don't dislike code contracts.
They are a very nice enhancement to the whole framework.
It's just that if this doesn't fill the gap that C# leaves by not having non-nullable reference types, at this point I'm afraid that nothing will.
What do you think?

Answer 1

I'm not sure what problem is solved by "non-nullable reference types". Ok so this code is much less likely to throw an exception:-

a.ToString();

However is it anymore likely to be correct because a it non-nullable? What would be the initial value of a? Probably some default "Empty" instance of the type. In that case isn't it more likely to make things more difficult to debug since values which should've been assigned a value haven't. Just having some default behaviour rather than causing an exception doesn't sound like something I'd want.

Answer 2

I think you're correct about this. Non-nullable reference checking at compile time was the killer feature I was waiting for in Code Contracts, and it isn't really there.

For those wondering what this means, consider an analogy with value types. They were not nullable originally, but now they are if you put a question mark after the type name:

int? n;

For consistency it would be ideal if the same was true of reference types. But that would break all existing C# programs and so isn't an option. In the research language Spec# they went with using an exclamation mark suffix to mean non-nullable:

string! s = "Hello";

As with ordinary value types, the compiler statically checks that a string! variable is not used on any code path before it has been initialised (I believe Spec# requires declaration and initialization to occur in the same statement).

It also bans the assignment of null to that variable.

And of course, it bans the assignment of an ordinary string to a string!. So how do bridge the gap between the two kinds of type? By writing a check:

string x = GetStringFromSomewhere();

if (x != null)
    s = x; // okay because compiler sees null check

The sad truth is that the majority of reference variables in most programs are likely to be non-nullable if the program is correct. Nullable variables are in the minority. And yet they are the default.

Another bad idea from the 1960s!

Answer 3

rather than using null you can use a default like string.empty there is no need for nulls

Answer 4

I think the concept of a non-nullable reference type would be really useful for ORM generated properties that map to database fields. Often you can't tell from the property (usually type string) whether the underlying field is nullable or not. With nullable value types you can, just by looking for the question mark.

I'm not too worried about static checking, apart from obvious foo! = null; failing, but the intellisense would be very useful as a hint to variable intent, I think.