On Friday, 18 October 2013 at 10:44:11 UTC, Regan Heath wrote:
This comes up time and again. The use of, and ability to distinguish empty from null is very useful. Yes, you run the risk of things like null pointer exceptions etc, but we have that risk now without the reward of being able to distinguish these cases.
In C# code null strings are a plague. Most of the time you don't need them, but still must check for them just in order to not get an exception. Also business logic makes no difference between null and empty - both of them are just "no data", so you end up typing if(string.IsNullOrEmpty(mystr)) every time everywhere. And, yeah, only one small feature in this big mess ever needs to differentiate between null and empty. I found this one case trivially implementable, but nulls still plague all remaining code.
Take this simple design: string readline(); This function would like to be able to: - return null for EOF - return [] for a blank line but it cannot, because as soon as you write: foo(readline()) the null/[] case merges.
This is a horrible design. You better throw an exception on eof instead of null: this null will break the caller anyway possibly in a contrived way. It works if you read one line per loop cycle, but if you read several lines and assume they're not null (some multiline data format), you're screwed or your code becomes littered with null checks, but who accounts for all alternative scenarios from the start?
If readline returns empty string on eof, I don't expect it to break any business logic. If the empty string doesn't match, ok, no match, continue. You can check for eof equally, but at *your* discretion, not when the external data wants you to do it.
There are plenty of other such design/cases that can be imagined, and while you can work around them all they add complexity for zero gain.
I believe there's no problem domain, which would like to differentiate between null and empty string instead of treating them as "no data".
