(non)nullable types

[Daniel Keep]

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.

  -- Daniel