I'm surprised people still have problems with null pointers. I
for one am glad D has null by default makes life easy coming from
C++ and Java.
I may have missed something but what happens with the following
code if I could not have a null pointer?
int*[] pntrs = new int*[10];
Would I need to write something like?
Null!(int*)[] pntrs = new Null!(int*)[10];
Personally, I'd rather have null by default as I find it less
noisy and I don't need it spelled out in the code, it is implied.
No it sound like initalizing something to null, then
initialize it properly, assume all over the place that it is
initialized to something else, and in some rare code path it
blows up.
OK, so the D gurus kindly introduce for us NotNull!T, Maybe!T,
Option!T and SegFault!T (just for me). Now I want to access a
pointer, write code using it etc. But I need to manually track at
development time whether it is NotNull!T, Null!T, Maybe!T,
Option!T or whatever. I cannot just have a pointer anymore,
knowing it's initialised to null. Now I realise it needs to
change from NotNull!T to Maybe!T...great yet more refactoring. Ok
refactoring done (yay sed!) but you know what, now I need to find
every access to that pointer and check for null. More error prone
than this:
If you are in doubt (i.e. most multi-threaded apps) then check if
null, with the added comfort that D has initialised all pointers
to NULL for you. If still in doubt, don't use pointers.
If you want non-null pointers (please no) then it is all or
nothing. Allowing some pointers null and others not, via
Nullable!T or NotNull!T, immediately adds another layer of
complexity.
I don't want to hear: D pointers cannot be null...well ok, they
can sometimes, it depends, you'll have to read the code. But
don't worry, D is very easy to read...
My 1 cent. Disregard if I have totally misunderstood the thread,
possible as it is very late! :-)
Cheers,
Stewart
