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?
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.