Whats wrong with non nullable objects?

Question

I have been looking at DbC lately and Spec# which seem to have support for non nullable objects. Unfortunately Spec# seem to have been abandoned.

1. Spec# seemed to have lots of nice language features built in so why was it abandoned?
2. Would there be any problem with letting all objects be non-nullable by default so you would have to write int?, string? and even MailMessage? if you really wanted a nullable object?
3. I see kind of a Sql analogy here where you could check class properties as nullable or non nullable. Could you even put constraints on properties as you can with sql table columns?

I don't see the problems with having features like this built in to the language. Could anybody enlighten me on this?

Answer 1

Have you seen the new Contracts framework will will be part of .NET 4.0?

The benefit of making it a library rather than language feature is that it becomes immediately available in all languages, with no work on the part of the language teams. Obviously there are disadvantages too...

Links:

• BCL team blog post
• And another
• PDC 2008 video

Having said all that, I'd like to be able to write:

public Stream! Foo(string! x)

as well, indicating that Foo must not receive a null reference, nor will it return one. Having an extra bit of syntax for just that type of contract would be handy, I think.