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