Disallow null references in safe code?
Idan Arye
GenericNPC at gmail.com
Tue Feb 4 14:57:05 PST 2014
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.
More information about the Digitalmars-d
mailing list