Now you can't tell if it's empty or just not set.
Now I have to track another thing just to tell me if I have touched a thing.
Please don't tell me this is some kind of nulls were a mistake cargo culting?
Nulls are just option types with good usability. Not the languages fault if you decide to put a tripple meaning on it.
Here are some options:
1) count(NULL) = 0, so apparently NULL is just like an empty set at least some of the time. This means that some of the code will treat NULLs as empty sets and other code will not, leaving the burden on the programmer to keep in mind these implicit differences.
2) count(NULL) = 1 because NULL is a value, albeit a sentinel value. This can lead to tricky problems where a count() suggests that there's some data, while, in fact, there is none.
3) count(NULL) = NULL. If the idea behind this option is that sentinel value cannot be operated on, then this is pretty much like throwing an error at every NULL, which, in turn, will result in the necessity to guard many expressions with some error (NULL) handling code.
One of the things to note is that an empty set has rather unambiguous semantics, while a NULL presents options each of which can be justified depending on how a particular person thinks about this special value. The line between "a value has not yet been assigned", "no value has been assigned" and "a value has been unassigned" is very blurry. On the other hand, the line between "there is no value" and "there is a value" is pretty clear.
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.
Those are the same things in EdgeDB. You can have a "required link", in which case a relationship between two objects is required, and therefore the link cannot ever point to an empty set. Alternatively you can also declare your link as "optional", in which case you have it pointing to an empty set (essentially to "nothing"). You can coalesce that empty set with a non-empty set, if you need.
That is similar to SQL; the key differences here are:
* The boolean logic in EdgeQL is two-valued, it's "true and false", not "true, false, and NULL". Some people find it hard to guess what "true OR NULL" returns in SQL, because unless you are a DBA, this isn't something you deal with on a daily basis.
* Functions/operators in EdgeQL never return empty set to indicate an error condition. This is one of my personal pet peeves with SQL; in some situations it's hard to understand why a big and complex query yields slightly wrong results sometimes.
> Now I have to track another thing just to tell me if I have touched a thing.
I suggest you to try writing EdgeQL queries. The experience is usually quite the opposite, and I hope you'll end up liking it!
> Please don't tell me this is some kind of nulls were a mistake cargo culting?
While I do think that NULL is a hard to deal issue in many languages and I admire languages like Rust without NULL, EdgeQL is slightly different. As you noticed, we do have a concept of empty set, which in some ways is similar to NULL in SQL (with the caveats I explained above).
Why would you admire this? Dropping .unwrap().wrap() on all the things is not any better than doing the same thing on nullable types.
"duh you're meant to handle them straight away so its not an issue" - no shit? Do you think maybe the same could be said about null values?
Removing optionality from a type system is a mistake, it just leads to more gibberish to handle undefined/notset.
> EdgeQL is slightly different. As you noticed, we do have a concept of empty set, which in some ways is similar to NULL in SQL (with the caveats I explained above).
Yes, it is slightly different, no it is not similar to null. It is what you get when you don't have null and don't have options. i.e. no sentinel, just a maybe.
Very simple, you leave it out! Then you can query for this.
- You can define a `bool` property as "optional" and then it can have an empty set as its value.
- The 'exists' operator coverts sets into bools; you can use it with the 'if..else' operator to handle empty sets where needed.
- You can coalesce (the "??" operator) your potentially empty property with a non-empty set, say a "{false}".
- An empty set isn't some magical value like NULL in SQL. Functions and operators in EdgeQL are strictly defined if they accept sets as their arguments, or not. In the case of logical operators -- they don't; they are defined as element-wise operators, therefore no three-valued boolean logic. You learn the rules once and they apply to all functions and operators in all contexts.
This documentation page (and subsequent sections) explains how exactly EdgeQL is defined: https://edgedb.com/docs/edgeql/overview.