Nullable!T with T of class type

[Jonathan M Davis]

On Thursday, June 28, 2018 19:45:52 kdevel via Digitalmars-d-learn wrote:
> On Thursday, 28 June 2018 at 19:22:38 UTC, Jonathan M Davis wrote:
> > Nullable makes sense in generic code, because the code isn't
> > written specifically for them, but something like
> > Nullable!MyClass in non-generic code is pointless IMHO, because
> > a class reference is already nullable.
>
> It is already technically nullable. But how do you signify to the
> reader of the code that a class member in a struct or in a class
> may intentionally (not purely technically) be null?
>
> If I had written
>
>      class R {
>
>         S s;
>
>      }
>
> with S being a class. The reader of the code cannot spot if s is
> optional. In my code I could not have declared S as a struct
> since it implements an interface.

That's something that you have to worry about with all code involving
classes. Putting Nullable on a class reference does seem like it would make
it clear that you want it to be nullable, but it doesn't really, and the
lack of nullable doesn't mean that it can't purposefully be null. If
Nullable couldn't contain a null, or it didn't have a separate bool for
null, then maybe it would help clarify, but that would result in subtle bugs
in generic code whenever null is involved, and there are cases where code
purposefully uses Nullable to indicate that the variable has not been
initialized yet but where null is considered a reasonable value for the
type. So, the fact that Nullable is there doesn't really clarify matters. It
just opens up the question of what happens with null.

In my experience, it's usually pretty clear from the API or design of a
piece of code whether it's intended to accept null or not (usually, the
answer is no) and that folks document what happens if null is provided if
it's supposed to be accepted, but regardless, any case where it's not clear
needs to be documented so that it is clear. Certainly, relying on Nullable
for that is going to be error-prone, because Nullable allows null and can
take advantage of the fact that isNull has nothing to do with the value of
null. So, if the intention is that a Nullable!MyClass never have a value of
null, then that needs to be documented, essentially defeating the purpose of
putting it in a Nullable in the first place. At that point, it would just be
more user-friendly to let it be null and document it as such than to use
Nullable and require that someone provide an uninitialized or cleared
Nullable instead of just using null.

Now, some folks do use Nullable to try and handle whether a class reference
is null, but given that it doesn't really solve the problem of what happens
with null and still requires documenting the intent, I think that it's more
misleading than enlightening to use Nullable on class references. If you're
going to wrap class references to try and indicate whether they can be null
or not, it makes far more sense to wrap a class reference in a wrapper
intended to indicate that it _can't_ be null than one that's intended to
indicate that it can be.

- Jonathan M Davis