On Tuesday, 4 February 2014 at 14:54:35 UTC, Adam D. Ruppe wrote:
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.
Sounds awesome.
