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.
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?
Sounds good, but the only problem is that the `@nullable` syntax
looks too clean - cleaner than `Nullable!`. That will mean that
some people will prefer it - enough to break all the benefits of
using the template.
I think the core language implementation should look more ugly
and cumbersome. How about `__traits(nullable, T)`? People already
know that traits are better used via wrappers whenever possible -
in contrast to attributes that are meant to be used directly.
