Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)

[estew]

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