(non)nullable types

[Christopher Wright]

Jarrett Billingsley wrote:
> On Wed, Feb 11, 2009 at 5:23 PM, Christopher Wright <dhasenan at gmail.com> wrote:
>> Or add an invariant. You know which field is null when it shouldn't be, so
>> that should be simple enough. Or use a property rather than a field and add
>> a contract.
>>
>> This covers the same cases that non-nullable types do, though admittedly
>> with slightly less granularity.
>>
>> A complex datastructure might have a complex initialization process that is
>> best spread across a few lines of code rather than happening all at once. If
>> that is the case, you *can't* use non-nullable types, because that
>> restriction isn't valid until the object is fully initialized. But you can
>> still use contracts here.
> 
> What is your response to the part of my post that was cut off?  You
> know, the part about having to write stupid contracts and how the
> compiler can and should be checking this kind of thing?

You'll eventually need to convert between nullable(T) and 
not_nullable(T). This requires runtime checks. A struct NotNull(T) could 
do the same, with some significant disadvantages.

But making not_nullable the default, I'm not sure how much work that 
would add for me. I know it would add a fair bit for Walter. Having it 
as an option and not the default would probably make it sufficiently 
annoying that people would not use it, in which case it's no better than 
adding an invariant.

On the one hand, not_nullable by default would probably do me no good. 
On the other, it would cost me little effort in most cases, most likely, 
unless I got sufficiently annoyed at all the little cases that I gave up 
and made every variable nullable by default.

It would be cool if we could accompany these discussions with sample 
compilers that implement the feature in question. That way, I could 
speak with some certainty when I said that a proposed feature would be 
annoying.