Question: I have a class containing a number of properties, something like:

```
public class Update
{
    public int Quantity { get; set; }
    public decimal Price { get; set; }
    public string Name { get; set; }
}

```

Each instance of `Update` does not necessarily have each property set, and another part of the system needs to know which have been set, and which haven't.

One option I've got is to make all the value types `Nullable` and so a `null` value would represent the concept of not being set. Whilst this would work, I don't really like the idea of having some properties explicitly `Nullable` (the value types) and some nullable by virtue of being a reference type. The class definition would look ugly and I'm not convinced a null check is semantically the best approach.

I could create a class very similar to `Nullable<T>` that has no constraint on the `T` with an `IsSet` property. I prefer this option to using `Nullable`, but I'd still like to see if anyone has an alternative representation that's better than the options I've suggested.

Answer: 
You really should stick to the preexisting idiom here. Use the built-in nullability.

I see your concern with nullability being different for value and ref types. Your workaround would work. But it is just a cosmetic change which gains you litte. I recommend that you change yourself instead of changing the code in this case. Try to fit yourself to the existing conventions.

Edit: Sometimes you need to be able to make a value optional in generic code. In this case you need to use some custom option type. By from experience I can tell that this is pretty nasty to use. It is not my solution of choice.
The reference types are *already* nullable, effectively - if you use `int?`, `decimal?` and `string` then every one of your properties can be null.

The problem comes if you ever want to set the `string` value to a null reference - if null is effectively a valid value which *is* set.

You certainly *could* write a `Maybe<T>` type, but I'm not sure I would - I would *probably* just use null... aside from anything else, it'll be more familiar for others reading the code who are used to C# idioms. For all the "anti-null" sentiment around (which I *do* share in many situations) there are cases where it's the simplest approach.