dereferencing null

[Timon Gehr]

On 03/05/2012 05:39 AM, Adam D. Ruppe wrote:
> On Monday, 5 March 2012 at 03:24:32 UTC, Chad J wrote:
>> News to me. I've had bad runs with that back in the day, but maybe
>> things have improved a bit.
>
> Strangely, I've never had a problem with gdb and D,
> as far back as 2007.
> (at least for the basic stack trace kind of stuff).
>
> But, yeah, they've been improving a lot of things
> recently too.
>
>> Non-nullable types would be really cool right about now.
>
> Huh, I thought there was one in phobos by now.
>
> You could spin your own with something like this:
>
> struct NotNull(T) {
> T t;
> alias t this;
> @disable this();
> @disable this(typeof(null));
> this(T value) {
> assert(value !is null);
> t = value;
> }
>
> @disable typeof(this) opAssign(typeof(null));
> typeof(this) opAssign(T rhs) {
> assert(rhs !is null);
> t = rhs;
> return this;
> }
> }
>
>
> This will catch usages of the null literal at
> compile time, and other null references at runtime
> as soon as you try to use it.
>
> With the disabled default constructor, you are forced
> to provide an initializer when you use it, so no
> accidental null will slip in.
>
> The alias this means NotNull!T is substitutable for T,
> so you can drop it into existing apis.
>
>> It's that I simply cannot expect users to run my code in a debugger.
>
> :) I'm lucky if I can get more from my users than
> "the site doesn't work"!
>
>> The problem is that they don't help me when I missed a spot and didn't
>> use assertions, contracts, or invariants.
>
> Aye, I've had it happen. The not null types might help,
> though tbh I've never used anything like this in practice
> so maybe not. I don't really know.

This is quite close, but real support for non-nullable types means that 
they are the default and checked statically, ideally using data flow 
analysis.