On Tuesday, 4 February 2014 at 14:34:49 UTC, Idan Arye wrote:
Probably because `Nullable!` suggests that's it's a library
solution - and it isn't.
It should be. The way I'd do it is
Object o; // not null
@nullable Object o; // like we have today
BUT, user code would never use that. Instead, we'd have:
struct Nullable(T) if(__traits(compiles, (@nullable T) {}) {
@nullable T;
}
// and a corresponding one so stuff like Nullable!int works
This gives us:
* Implementation help - no binary cost for Nullable!Object since
it just uses null directly instead of a bool isNull field (the
optimizer also knows this)
* Consistency with all other types. Nullable!int works,
Nullable!Object can be passed to a template, inspected, etc.
without new traits for isNullable and everything.
* Library functionality so we can also make other types that do
the same kind of thing
Then, if we did the Type? syntax, it would just be rewritten into
Nullable!Type. Nullable's definition would probably be in the
auto-imported object.d so it always works.
