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

[estew]

On Monday, 20 May 2013 at 14:57:17 UTC, Dicebot wrote:
> On Monday, 20 May 2013 at 14:49:32 UTC, estew wrote:
>> 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.
>
> Yes and this is awesome. This is correctness enforced by type 
> system. Because if you _don't_ track this, you have a possible 
> error in your code. Only difference between nullable and 
> non-nullable pointers by default is that latter _force_ you to 
> write correct code. Which is good.

True I grant you that, it was late when I posted :-) I've 
actually come around a bit on this after sleeping on it and 
rereading some of the posts. I am starting to like NotNull!T idea 
but I'm a bit hesitant still with Maybe!T, Option!T.

I cannot remember the last time our team had NULL pointer issues. 
We have 102 devs on four integrated products. Big enough to not 
know context your code might be used in nor the implementation 
details of all libraries. The only pointer troubles we see are 
forget to init to NULL or reset to NULL after freeing resources. 
All devs know raw pointers are initialised to NULL. We are C/C++.

So non-null pointers wouldn't make much difference to us here, 
although it may make the code more readable which is always a 
good thing. D needs nullable pointers though, of some form.

But I'm not convinced it would cost us less to have NotNull!T and 
Nullable!T. I feel it is cheaper to mindlessly write "if(a is 
null) {}" when using pointers than to worry at design time what 
the behaviour of a pointer should be.

Design time is the second most expensive developer time for us. 
The most expensive dev. time is changing a design that turned out 
to be incorrect, or is now outdated for whatever reason. Moving 
pointer behaviour to be a design time issue rather than "knowing 
it could be NULL so check it" could increase the probability of 
redesign bugs creeping in.

Still, I am loving the discussion in this thread it's very 
interesting from both sides.

Stewart