> You seem to treat NULLs as if they have a specific meaning. Null is a word, it has a meaning. In programming that meaning is the absence of a value. For erg

> You seem to treat NULLs as if they have a specific meaning. Null is a word, it has a meaning. In programming that meaning is the absence of a value. For ergonomic reasons dynamic languages will cast it to 0 or false in some situations. But that doesn't change its meaning and it doesn't mean it has multiple meanings. That would be like complaining about how most languages treat 1 == true and 0 == false. > So then the question is this: what should count(NULL) be? No, the question isn't that. The question is what is null. It is null. Count(null) does not change what null is. Null is still null. If count wants to treat null like a 0 for ergonomics it can do that. If it wants to treat it like an empty set it can do that too. If count wants to treat null as U countable and throw an error it can do that as well. If it wants to treat it as a null operation and return null it can do that too. Personally, I find 2, and 3 fucking useless so if it was my language, I would define a countable interface for null and set null = 0. Because there are no usecases where you want that to error at runtime.