(non)nullable types

[Nick Sabalausky]

"Daniel Keep" <daniel.keep.lists at gmail.com> wrote in message 
news:gn4tjj$197g$1 at digitalmars.com...
>
>
> Denis Koroskin wrote:
>> [snip]
>>>
>>> I still like this that someone else mentioned:
>>>
>>> T? x = something;
>>> if(x !is null)
>>> {
>>>     // x is implicitly "T" here, not "T?"
>>> }
>>> else
>>> {
>>>     // handle null condition (x is still "T?")
>>> }
>>>
>>>
>>
>> Or use an existing syntax:
>>
>> Foo? foo = ...;
>> if (Foo value = foo) {
>>     // value is a local variable that is only accessible if foo is not 
>> null
>> } else {
>>     // value is not accessible here
>> }
>
> Both of these syntaxes are solving a problem that doesn't exist.  This
> is why we have null dereference exceptions: accessing a null pointer is
> an error.  All this is doing is moving the onus for the check from the
> hardware to the programmer.
>
> Leave magic out of the language and let the hardware do it's job.  If
> you have a nullable type, it's because you WANT it to be nullable, and
> you shouldn't have to stand on one leg and jump through a burning hoop
> every time you want to look at the damn thing.
>
> The point here is not to make using null harder, it's to make not using
> null easier.
>

The entire point of all of this is to make dereferencing null (and I mean an 
actual null, not "nullable") either difficult or (preferably) impossible. 
The reason we want to do that is that dereferencing null is a runtime error 
and we want to eliminate runtime errors whenever possible, by either 
eliminating their possiblity or by turning them into compile-time errors.

Most null reference errors can be outright eliminated via non-null types, 
and the remaining cases can be turned into compile-time errors by forcing a 
check. Why would anyone want a runtime error when they could get a 
compile-time error instead?

The "burning hoop", as you describe it, of checking a nullable var for null 
before dereferencing is just simply something that the programmer should 
already be doing anyway. Take the following case:

void Foo(void delegate()? dg) //nullable
{
    dg();
}

If the programmer has a deliberate reason to *want* the dg paramater to be 
nullable, then why in the would would they ever want to dereference it like 
that without first checking for null? Just because they *want* their program 
to be spitting out runtime errors? I'm sorry, but I just don't buy that. 
(And the reason can't possibly be because they expected any possible nulls 
to be handled in the calling code, because that's exactly the type of 
scenario that non-nullables are intended for in the first place.)

Also, just to be clear, no one (as far as I'm aware) is advocating anything 
like this:

class Foo
{
    private void delegate()? dg; // nullable

    public void setDg(void delegate()? dg) // nullable
    {
        if(dg !is null)  // I don't think anyone is expecting this check to 
be required
            this.dg = dg;
    }
}

The forced check would only be on dereferencing and converting to 
non-nullable.