Q:

Whats wrong with non nullable objects? 

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. 

Spec# seemed to have lots of nice language features built in so why was it abandoned? 
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? 
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? 

A:

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.