[clusmore]

My problem with null is that it doesn't nest. For example, if I do a DB search for a particular column of a particular row and get null, does that mean the row doesn't exist, or it does but the column is empty? With optionals, you can distinguished between this with e.g. `Nothing` vs `Just Nothing`.

[mjevans]

In databases NULL does exist; it is an explicit statement of having no contained value. (There is a container here, the contents were not specified. A distinct statement from /knowing/ the contents to be empty. (zero, zero-length string, etc))

Conceptually NULL or nil is an appropriate concept for results that have no meaning, such as if an error occurred or if a passed value is not required or valid. (Though some structures can contain data that is 'incomplete' or 'not checked' and thus while a valid structure might not be 'validated' in the sense of conforming to a more specific set of expectations.)

[maerF0x0]

kind of like having

field_is_set = true, field = "123"

field_is_set = false, field = 0 (some zero value or uninitialized value)

[biztos]

Sort of... and it seems to me that Go wants you to think this way about values within a struct (i.e. the "zero" values).

But isn't that a really clunky way of checking whether field is set? You can't just check field because the "zero value" could be a legit value, e.g. zero. So you have to first check field_is_set -- and now you have to make sure that's always correct and that nobody ever sets field by itself.

[mjevans]

Or worse having to inspect a specific field value (or worse compare the whole thing to a reference object) to determine if the result is actually valid or not.

The question I ask in these circumstances: Will a method/function //always// return valid work if the program continues to run?

How about a 'find' function of some type? Find the nth thing, find matches of X, etc.

That's one type of function that might return no answer.

If a list or set of some sort is expected I'm happy with a zero-length list in this case. However lists aren't the only time this happens. The most recent example to come to my mind is finding the Nth item in an arbitrary sequence. That item might be out of bounds (not exist). Nil is appropriate for that case.

[abtinf]

Can't that be determined by looking at the row count? A row count of zero means it doesn't exist. A row count of 1 with a null in the selected column means the row exists the column is null.

I avoid the word "empty" when referring to anything SQL related, as it is ambiguous in three value logic.

[mjevans]

SQL syntax, at least what I'm familiar with offhand, makes you explicitly say things such as WHERE (a.cola = b.colb OR a.cola IS NULL OR b.colb IS NULL) or similar syntax but with distinct variations for joining 'left' and 'right' tables on an expression (which, BTW, can be noticeably slower than the WHERE version, depending on which database you're using).

[marcus_holmes]

I think they're referring to outer-joined tables.

SELECT a.id, b.name FROM a LEFT JOIN b ON a.id = b.id

If you get a NULL in the name field, you don't know if that's because there's no record in b for that id, or if there is a record in b for that id but it has a NULL name value. Sometimes that difference will be important.

[sorkin2]

While admittedly this could be seen as a mistake in SQL, you can differentiate by looking at whether b.id is NULL or not.

[marcus_holmes]

true, but that's not the point the OP was making, I think :)