Is there anything wrong with making nullability of a reference type explicit by wrapping it in a value type?

Question

When I program in Java, I make all nullability explicit; that is, an instance of Foo is assumed to be non-null, and if I want it to be null, I use a @Nullable annotation (or better, Optional<Foo>). But C# doesn't natively support annotations, and Nullable<> is only for value types.

But what if I did something like this?

struct Value<T> where T : class {
  T value;
}

And then use Value<Foo>? as the type for a field. What impact would this have on performance/memory, and is there something that makes this a very bad idea?

Answer 1

References are already passed by value in .net. And since value can be null, you’re not gaining much. You can’t even force a nice constructor to guarantee that value is non-null since structs require a public nullary constructor.

You’re doing work to gain nothing but confusion.

Answer 2

There are few C# Option/Maybe implementations : here, here or here

There is also a proposal to make non-nullable references in C#, in which case there will be need for some kind of Nullable/Option type for reference types.

So your idea is perfectly sound and supported by many people. Its just your implementation is not that great. You don't need to wrap a reference in structure and then use Nullable. Just make the structure behave like Nullable. Which is what all other implementations are doing.

As for performance, I wouldn't worry too much. Better performance is often achieved using better structures and algorithms and not micro-optimizing your types. And any performance hit will be out-weighted by improved stability and readability of your code, due to explicit handling of null states.

Answer 3

Looks like you're reinventing wheels there - why can't you simply use T? as the nullable value type? I imagine under the covers exactly what you are suggesting is happening already. As the nullability is explicitly defined in the type definition using the ?, then you have what you want already.

As for types that are already nullable, I'd say making a nullable generic type that can itself contain a null to be a particularly bad idea just because it will confuse people, add lots of extra code and provide no benefit.

If you really must have an annotation, use a naming convention.