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

[aliak]

On Wednesday, 21 November 2018 at 23:27:25 UTC, Alex wrote:
> 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! :) )

This is true. But then the difference is that you can't* call a 
method on an optional variable without first unwrapping it (which 
is enforced at compile time as well).

* You can force unwrap it and then you'd get a segfault if it 
there was nothing inside the optional. But most times if you see 
someone force unwrapping an optional it's a code smell in swift.

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

Hehe, maybe in a way. Was just trying to show that compilers can 
fix the null reference "problem" at compile time. And that flow 
analysis can detect initialization.

>
> 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?

Aye. But depending on how a language is designed this problem - 
if you think it is one - can be dealt with. It's why swift has 
optionals built in to the language.