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 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 2

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 3

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.

Answer 4

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

Update 2017 (8 years later), while Non-nullable reference type is still not there... nullable reference type might.

Mads Torgersen (C# Language PM at Microsoft) does mention it in this tweet:

The prototype of nullable reference types is finally here!

This is detailed in "Introducing Nullable Reference Types in C#", and in this video "new features available C# 7.1 and 7.2".

This can be achieved if instead we add only one new “safe” kind of reference type, and then reinterpret existing reference types as being the other “safe” kind. More specifically, we think that the default meaning of unannotated reference types such as string should be non-nullable reference types, for a couple of reasons:

We believe that it is more common to want a reference not to be null. Nullable reference types would be the rarer kind (though we don’t have good data to tell us by how much), so they are the ones that should require a new annotation. The language already has a notion of – and a syntax for – nullable value types. The analogy between the two would make the language addition conceptually easier, and linguistically simpler.
It seems right that you shouldn’t burden yourself or your consumer with cumbersome null values unless you’ve actively decided that you want them. Nulls, not the absence of them, should be the thing that you explicitly have to opt in to.
Here’s what it looks like:

class Person
{
    public string FirstName;   // Not null
    public string? MiddleName; // May be null
    public string LastName;    // Not null
}

This class is now able to express the intent that everyone has a first and a last name, but only some people have a middle name.

Thus we get to the reason we call this language feature “nullable reference types”: Those are the ones that get added to the language. The nonnullable ones are already there, at least syntactically.

This is still a prototype, and might end up (or not) in the language.
See more at "The C# Nullable Reference Types Preview".

Answer 5

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