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