Why does nobody seem to think that `null` is a serious problem in D?

[Alex]

On Wednesday, 21 November 2018 at 21:05:37 UTC, aliak wrote:
> On Wednesday, 21 November 2018 at 17:46:29 UTC, Alex wrote:
>> compiled against 4.6.1 Framework.
>>
>> However, of course, there is a NullReferenceException, if c 
>> happens to be null, when calling baz.
>>
>> So the difference is not the compiler behavior, but just the 
>> runtime behavior...
>>
>> How could the compiler know the state of Random anyway, before 
>> the program run.
>
> The compiler would not be able to prove that something was 
> initialized and hence could give an error. Maybe c# doesn't do 
> it but swift certainly does:
>
> class C {
>     func baz() {}
> }
>
> func f() {
>     var x: C
>     if Int.random(in: 0 ..< 10) < 5 {
>         x = C()
>     }
>     x.baz()
> }
>
> error: variable 'x' used before being initialized

Nice! Didn't know that... But the language is a foreign one for 
me.

Nevertheless, from what I saw:
Shouldn't it be
var x: C?
as an optional kind, because otherwise, I can't assign a nil to 
the instance, which I can do to a class instance in D...
and if it is, it works in the same manner as C#, (tried this out! 
:) )

Comparing non-optional types from swift with classes in D is... 
yeah... hmm... evil ;)

And if you assume a kind which cannot be nil, then you are again 
with structs here...

But I wondered about something different:
Even if the compiler would check the existence of an assignment, 
the runtime information cannot be deduced, if I understand this 
correctly. And if so, it cannot be checked at compile time, if 
something is or is not null. Right?