[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.