TypeScript 3.7 beta distinguishes missing values from falsy values

A numeric setting of zero can be intentional. A fallback written with logical OR can replace it anyway, because that operator tests truthiness. TypeScript 3.7 beta introduces nullish coalescing to express the narrower condition that a value is null or undefined.

The October 1 beta announcement pairs that operator with optional chaining. The beta is described as feature complete for the developing 3.7 release. These additions let a program state which absence condition should stop an access or trigger a fallback.

The optional-chaining proposal defines the corresponding access behavior. If the value to the left of the optional operator is null or undefined, evaluation returns undefined for that chain. Otherwise, the access or call follows its ordinary behavior.

I find these distinctions useful in web interfaces because empty input and missing input often require different behavior. A type system cannot choose that product decision for the author. The syntax can at least make the chosen condition explicit instead of expressing it accidentally through truthiness.

A fallback can preserve zero

Nullish coalescing uses the left value unless it is null or undefined. Only the missing case evaluates the expression on the right. It therefore preserves zero, false and the empty string where logical OR would choose a fallback.

A typed numeric example avoids confusing storage representation with the fallback condition.

interface Preferences {
    volume?: number;
}

function selectedVolume(preferences: Preferences) {
    return preferences.volume ?? 0.5;
}

If volume is zero, the function returns zero. If the optional property is absent, it returns the default. The distinction comes from the operator's absence test, not from treating zero as a special application exception.

The right operand can also perform work, as in a function that calculates a default. The announcement's equivalent conditional shows that this calculation occurs only when the left operand is nullish. It is not an eagerly computed backup that is then discarded.

This makes replacement of an existing OR expression a semantic decision. If false or an empty string should also trigger the default, nullish coalescing expresses a different rule. The appropriate operator follows the meaning of the value, not the apparent neatness of the syntax.

Optional access protects the selected base

Optional property access uses the same null-or-undefined distinction. An expression such as account?.profile.name checks account. If account is missing, the chain returns undefined. If account exists but profile is missing, the later ordinary access can still fail.

Adding another optional access states that the intermediate value can also be absent. The operator does not infer that every subsequent property is optional merely because one earlier access was optional. The position of each check carries meaning.

Optional element access applies the same rule to a computed key. The beta announcement illustrates retrieving the first array element only when the array exists. The computed expression belongs to the chain, so short-circuiting can skip its evaluation when the base is missing.

Optional call likewise checks whether its target is nullish before calling it. It does not make every present value callable. A present target still needs an appropriate callable contract, which keeps absence handling separate from an invalid operation on the wrong kind of value.

Short-circuiting has a syntactic boundary

The announcement specifically warns that optional chaining does not suppress surrounding arithmetic. If an optional property access supplies undefined to a division, the division still occurs. A separate function call used as the other operand also still occurs.

That boundary matters because the chain is an expression within a larger expression. Handling absence while traversing an object does not automatically determine how the caller should combine the result with another value. Under strictNullChecks, the compiler can report the possible undefined operand.

For a numeric result, an explicit fallback can supply the missing-value policy before arithmetic. A program might instead return early because absence should prevent the calculation entirely. Those policies are different, and the optional operator deliberately does not choose between them.

This is also why a mechanically shorter chain may still need surrounding control flow. The syntax removes repeated checks only for the path it actually describes. It does not turn every downstream operation into an optional one.

The beta also models assertion functions

The same announcement introduces assertion signatures. A function can declare that successful return establishes a condition or narrows a supplied value's type. This lets the checker understand a helper that throws when its requirement is not met.

The implementation still needs to perform the promised check. An assertion signature describes the function's contract to the compiler. It does not generate the body that validates an unknown value. That remains distinct from optional access, which performs a defined runtime nullish check.

I prefer keeping these responsibilities separate. Optional operators express a narrow absence condition in executable code, while assertion signatures communicate what a validation function guarantees after it returns. The beta gives authors more precise ways to represent both relationships.

For code adopting the preview, the immediate gain is an explicit vocabulary for missing values. A zero-valued preference can survive a fallback, and a chain can stop at a chosen nullable base. The result still needs an application decision wherever absence affects arithmetic or another operation outside that chain.