> There’s basically never a real distinction between string absent and string blank
On the contrary, this comes up all the time; there are plenty of times when blank really is a valid value, and even if blank isn't a valid value, abusing it as a representation for "unknown" is bad for all the usual reasons in-band signalling is bad.
> you would need to record it as a bool or enum that clearly lays out “this is really blank and not just we don’t know it” or whatever.
An actual sum type is a million times better than using two awkwardly coupled fields. Type systems without sum types are a joke and there's no excuse for using them in the current millenium.
Give examples. I have never seen a case where there was a business reason to distinguish a null vs blank string. Dates? Yes. Numbers? Yes. Strings? Nope, never.
Let’s start with the most common false example: middle names. What are you going to do differently in your app if some one has an unknown vs a blank middle name? … Nothing. The displays will be the same. The search will still have to account for ignoring middle names because missing middle name might show up as “NMI” in an external system. There are no implications to having a missing middle name vs no middle name. You might need a flag for “date that the user verified that this is their full name” but that has nothing to do with null strings.
Error message "" is very different from no error message. Any legitimate use case for a null/absent string is an example; all those use cases are arguable and domain-specific, but they're a different thing from blank. For example if you're using null/absent to represent "unknown" then your search behaviour should be different from empty - for your example of middle names, a search with first=William/middle=Henry/last=Gates should return records with middle=null, but should not return records with middle="".
I don’t understand what the structure you’re proposing is. There are a lot of ways of doing form validation. Typically you’ll have field levels errors and form level errors. In those cases, the no error state is represented by an empty list. I have never seen errors represented in a way that null means no error but blank string means unknown error. That would be a weird way to represent it.
On the contrary, this comes up all the time; there are plenty of times when blank really is a valid value, and even if blank isn't a valid value, abusing it as a representation for "unknown" is bad for all the usual reasons in-band signalling is bad.
> you would need to record it as a bool or enum that clearly lays out “this is really blank and not just we don’t know it” or whatever.
An actual sum type is a million times better than using two awkwardly coupled fields. Type systems without sum types are a joke and there's no excuse for using them in the current millenium.