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

[aliak]

On Tuesday, 20 November 2018 at 03:24:56 UTC, Neia Neutuladh 
wrote:
> On Tue, 20 Nov 2018 00:30:44 +0000, Jordi Gutiérrez Hermoso 
> wrote:
>> On Monday, 19 November 2018 at 21:57:11 UTC, Neia Neutuladh 
>> wrote:
>> 
>>> Programmers coming from nearly any language other than C++ 
>>> would find it expected and intuitive that declaring a class 
>>> instance variable leaves it null.
>> 
>> What do you think about making the syntax slightly more 
>> explicit and warn or possibly error out if you don't do it 
>> that way?
>
> The prevailing idea is that warnings are either non-problems, 
> in which case they shouldn't be emitted, or things you really 
> need to fix, in which case they should be errors.
>
> Things that are sometimes errors can be left to lint tools.
>
>> Either
>> 
>>    SomeClass c = null;
>> 
>> or
>> 
>>    SomeClass c = new SomeClass();
>> 
>> and nothing else.
>
> That would work, though it would be mildly tedious.
>
> However, the general philosophy with D is that things should be 
> implicitly initialized to a default state equal to the `.init` 
> property of the type. That default state can be user-defined 
> with structs, but with other types, it is generally an 'empty' 
> state that has well-defined semantics. For floating point 
> values, that is NaN. For integers, it's 0. For arrays, it's a 
> null array with length 0. For objects and pointers, it's null.
>
>> Nulls/Nones are always a big gap in a language's type system. 
>> A common alternative is to have some Option/Maybe type like 
>> Rust or Haskell or D's Variant.
>
> Variant is about storing arbitrary values in the same variable. 
> Nullable is the D2 equivalent of Option or Maybe.
>
>> How about making that required to plug the null gap?
>
> That's extremely unlikely to make it into D2 and rather 
> unlikely to make it into a putative D3. However, if you feel 
> strongly enough about it, you can write a DIP.
>
> I've used Kotlin with its null safety, and I honestly haven't 
> seen benefits from it. I have seen some NullPointerExceptions 
> in slightly different places and some NullPointerExceptions 
> instead of empty strings in log messages, but that's it.

Think this would highly depend on your usecase. Having crashing 
mobile apps mostly leads to bad reviews because it's a UX 
nightmare for e.g. And with webservices it's a pain a lot of the 
times when it just crashes as well (analytics workers for e.g.).

Kotlin's null safety stops you from this quite well as long as 
you don't interface with java libraries - then it's near useless 
because your compiler guarantees go out the window. But Swift... 
so far  ... 👌

It's also a code review blessing. You just know for sure that 
this code won't crash and the object is "valid" because they've 
properly unwrapped a nullable. I can't even count the number of 
times (and I'd wager there're millions of similar commits) where 
I've put up a commit (during my c++ days) that says "fix crash" 
and the code is just "if(!ptr) { return; }" or a variant of that.

Ok, sorry, I rambled a bit :p

Cheers,
- Ali