[jflwyasdf]

null would just mean the zero value instead of the absence of a value

  String foo = null;

  String bar = "";

  foo.equals(bar) --> true

This works well provided the data type has a sensible zero value like collection types

EDIT: I'm blocked from posting so I won't be responding further, thank you for discussion.

[alkonaut]

A null collection and an empty collection are two different things. A nullable collection is one that has the state “no collection” semantically separate from “empty collection”.

Similarly an Option<byte> has 257 different values while a byte has 256 different values. That the byte has a good zero value doesn’t change that - the whole reason for choosing a maybe-byte is having 257 values, not 256.

[jflwyasdf]

Right that depends if you subscribe to the belief that null means the absence of a value `Option<T>` or does it mean the zero value `T`.

[tsimionescu]

That just gets us back to the problem for which Null is introduced in almost every lamguage: indicating the absence of a value. This is an important feature in every language, and null is the most popular solution to it (the only significant alternative is the Maybe monad).

To put this in more concrete terms, if this change were integrated in Java, how would you indicate the difference between a JSON document which doesn't contain a field VS one where the field is an empty string?

[codebje]

I dare say there's a lot more use of a magic value to indicate no value than a distinguishable representation of it :-)

I base this mostly on an assumption of C still being one of the most widely used languages for the code that's running out there in the world. In C, after all, NULL is just a magic value rather than a distinguishable representation of no value, though that's just one example out of a host of others, all the way down to the venerable NUL-terminated string.

As for your question: something like 'keys(jsonobject).contains("fieldName")' ? Or 'NoSuchFieldException' thrown if you do 'jsonobject.get("fieldName")' ?

(The latter of which, given the general uneasiness NullPointerException creates in us devs, is often how a Java API will work anyway! Checked exceptions won the day! Until the Functional interface was made, at least.)

Or to answer it in the same spirit as this overall comment, why would you need to distinguish between missing and empty? Can't you just define the semantics of the document s.t. those two things having the same effect?

[golergka]

In the end, you'll have a mixture of NULL and "" in your DB, and a couple of years later a piece of logic written in another language will fail spectacularly.

[skissane]

One response to this is issue is a CHECK constraint LENGTH(column) > 0, so you can’t have empty strings.

Rarely do you have a textual database column where the empty-vs-NULL distinction is semantically meaningful in the application domain. Most of the time, either the column value is missing (arguably better represented by NULL) or has a non-blank value. “Present but blank” is rarely meaningful or useful

Sometimes I pair that with (TRIM(column)=column) to prevent leading or trailing whitespace being saved, which also stops all-blank values being saved

This works really well if you have an RDBMS which supports CREATE DOMAIN, so then you can attach these constraints to a user-defined type and don’t have to repeat them for each column, you just set the type of the column to that user-defined type

[jflwyasdf]

This is how I would do it.

  Go: *string

  Java: Option<String> or @Nullable String

  Rust: Option<String>

  TypeScript: string | undefined (or string | null)

[lmz]

> In the end, you'll have a mixture of NULL and "" in your DB

Not if you use Oracle.

[codebje]

It took many years to eliminate all the instances of "NULL" from the database.