[taeric]

Funny, I'm the opposite. The more experienced I've become, the more I've found that nil-punning is ultimately what I actually wanted.

And I'm all for the idea that relational fields should be NOT NULL. I also fear that this doesn't really work for backwards compatible thinking. If I serialized some data down to disk before a field existed, I don't expect it to be there when I check it later.

You can be tempted to think it should just be the zero value of the type you are using. Or you can add some extra boilerplate around accessing. I think either works. Just make sure you aren't getting carried away. And, try to do anything that cares about the absence or presence of something at a layer from where you get that something. Don't punt the decision down your codebase.

(That is, Optionals are great at the layer, don't pass them as parameters to inner code, though. Obviously, YMMV. And, quite frankly, probably will go further than mine.)

[cousin_it]

Agree completely. Google removed "required" fields from proto3 because they cause problems for compatibility and version skew. And even in proto2, which had "required" fields, people quickly learned to avoid them. Anything that goes on the disk or wire should have only "optional" and "repeated" fields (as a bonus, "optional" is encoded the same as "repeated" with zero or one values).

[nerdponx]

I'm all for the idea that relational fields should be NOT NULL

What if the data is actually missing? How else do you record that information?

[zupa-hu]

You use the default empty value, and have an extra field for missingness. Than you have real type safety.

[TheDong]

Real type safety is sum types. If I need to express something that is present or missing, I should use a Maybe monad.

Having an extra field for "missingness" is less safe because the type system won't enforce that it is either missing or set, you could have it set to a value but marked as missing which is still ambiguous.

[sorkin2]

That's a "cure" worse than the disease.

[taeric]

If missing data is a valid value, pick a valid way to encode it. Null might work, but realize you could have to reason for the value. Actually missing, or just not collected it recorded.

I concede there may be no difference in those meanings.