Disallow null references in safe code?
Adam D. Ruppe
destructionator at gmail.com
Tue Feb 4 19:12:56 PST 2014
On Tuesday, 4 February 2014 at 22:57:06 UTC, Idan Arye wrote:
> So what you are saying is that it should be implemented in the
> core language(`@nullable`), and than wrapped in the standard
> library(`Nullable!`) so we can have the benefit of using D's
> and Phobos' rich template-handling functionality?
That was my first thought but deadalnix mentioned a union with
typeof(null) which would achieve the same thing.
so I think @nullable is useless and we should just focus on the
library type Nullable!T.
There's lastly the question of
if(nullable_ref) {
// nullable_ref is implicitly converted to not null
}
and meh, as far as I'm concerned, this is already a solved
problem:
if(auto not_null = nullable_ref) {
// use not_null
}
But if we wanted the same name's type to magically change, I'd
prefer to add some kind of operator overloading to hook that in
the library too. Just spitballing syntax but
struct Nullable(T) {
static if(__traits(potentiallyNullable, T)) {
union {
T payload;
typeof(null) _;
}
alias payload if;
} else {
struct {
T payload;
bool isNull;
}
T helper(out bool isValid) {
isValid = isNull;
return payload;
}
alias helper if;
}
/* other appropriate overloads/methods */
}
The last line is the magic. Unlike the existing technique,
opCast(T:bool)() {}, it would allow changing types inside the if.
Note that something can be done right now using opCast, a helper
type, and alias this:
http://arsdnet.net/dcode/notnullsimplified.d see checkNull
(thanks to Andrej Mitrovic for showing this to me)
So I'm generally meh on it, but if we do want to do magic
changing types, I definitely want it available in the library for
more than just nullability.
More information about the Digitalmars-d
mailing list