null is a sentinel value that is not an integer, not a string, not a boolean - not anything really, except something to hold and be a "not there" value. Don't treat it as or expect it to be a 0, or an empty string or an empty list. Those are all valid values and can be geniunely valid values in many circumstances - the idea of a null instead means there is no value there.

Perhaps it's a little bit like a function throwing an exception instead of returning a value. Except instead of manufacturing and returning an ordinary value with a special meaning, it returns a special value that already has a special meaning. If a language expects you to work with null, then you can't really ignore it.

NULL is used to make it clear it is a pointer type.

Ideally, the C implementation would define NULL as ((void *) 0) or something equivalent, and programmers would always use NULL when they want a null pointer constant.

If this is done, then, when a programmer has, for example, an int *x and accidentally writes *x = NULL;, then the compiler can recognize that a mistake has been made, because the left side of = has type int, and the right side has type void *, and this is not a proper combination for assignment.

In contrast, if the programmer accidentally writes *x = 0; instead of x = 0;, then the compiler cannot recognize this mistake, because the left side has type int, and the right side has type int, and that is a valid combination.

Thus, when NULL is defined well and is used, mistakes are detected earlier.

In particular answer to your question “Is there a context in which just plain literal 0 would not work exactly the same?”:

• In correct code, NULL and 0 may be used interchangeably as null pointer constants.
• 0 will function as an integer (non-pointer) constant, but NULL might not, depending on how the C implementation defines it.
• For the purpose of detecting errors, NULL and 0 do not work exactly the same; using NULL with a good definition serves to help detect some mistakes that using 0 does not.

The C standard allows 0 to be used for null pointer constants for historic reasons. However, this is not beneficial except for allowing previously written code to compile in compilers using current C standards. New code should avoid using 0 as a null pointer constant.

You are probably looking for optionals. Here, for example, in TypeScript that you use:

http://dotnetpattern.com/typescript-optional-parameters

The idea is to have explicitly state:

• A) if an object can be null or not
• B) unwrapping nullable objects before using them to avoid null pointer exceptions (NPEs)

The TypeScript parameter example I linked does not really do B)

if (address == undefined) {
  // Do something with a
} else {
  // Address not found, do something else
}

Maybe you can find a better way in TypeScript like it is done in Swift:

if let a = address {
  // Do something with a
} else {
  // Address not found. Do something else.
}

Or Kotlin:

address?.let { a ->
  // Do something with a
} ?: {
  // Address not found. Do something else
}()

The difference is that in the TypeScript example above you can still forget the check and just address, leading to an NPE. Optionals like in Swift or Kotlin will force you to first check the value existence before you can use them.

A common mistake done then is to force unwarp the value because you think the value always exists:

address!.doSomething() // In Swift

address!!.doSomething() // in Kotlin

If you see code like this, run! Usually a value is an optional for a reason, so just skipping over that safety-measure and claiming "there is a value, I am sure" leads you back to the old NPE-coding we try to get rid of.

A quick search looks like you are not really able to do that in TypeScript without voodoo:

Is it possible to unwrap an optional/nullable value in TypeScript?