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.
