Nullish Coalescing and Logical Compound Assignments (??=, ||=, &&=)

[danielrentz]

Search Terms

Nullish coalescing assignment

Suggestion

A new operator ??= to assign some default to a variable/property if it is nullish.

It's also avaibale in PHP: https://wiki.php.net/rfc/null_coalesce_equal_operator

Examples

obj1.obj2.obj3.x ??= 42;
instead of
obj1.obj2.obj3.x = obj1.obj2.obj3.x ?? 42;

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[IllusionMH]

This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)

Most likely this one should be unchecked, because this syntax is not supported by ES.

However there is proposal https://github.com/tc39/proposal-logical-assignment which is in Stage 2 and TS usually start implementation if proposal reaches Stage 3.
@DanielRosenwasser might provide more info about Stage 3 of that proposal :)

[danielrentz]

Hm negation confusion :) I checked this item because "This isn't a runtime feature" as in "This is a compile-time feature" because TSC needs to compile it to something else. Or what else is intended behind this item?

Thanks for the TC pointer. Makes sense to extend this to all logical operators!

[DanielRosenwasser]

It's in a good direction in the standards pipeline. Iif I recall correctly, I was the only one who had some minor objections around tc39/proposal-logical-assignment#3 which I've changed my mind on. We'll look into implementing it when it hits stage 3.

[Kingwl]

Could I take a try on this one after stage3?🙋🏻‍♂️

[DanielRosenwasser]

It looks like it'll be discussed tomorrow. I've given my review approval and I can let you know when it moves forward. I've put together a write-up to consider for any implementations:

---

This new proposal adds a few new productions:

LeftHandSideExpression &&= AssignmentExpression

LeftHandSideExpression ||= AssignmentExpression

LeftHandSideExpression ??= AssignmentExpression

These roughly correspond to the following respectively:

LeftHandSideExpression && (LeftHandSideExpression = AssignmentExpression)

LeftHandSideExpression || (LeftHandSideExpression = AssignmentExpression)

LeftHandSideExpression ?? (LeftHandSideExpression = AssignmentExpression)

An implementation for TypeScript should at least test the following:

• JavaScript emit where the LeftHandSideExpression is
  • an Identifier
  • a property access or element access where
    • the target is an Identifier (e.g. a.b, a["b"])
    • the target is not an Identifier (e.g. a.b.c, a.b["c"], foo().c) - to ensure that side effects don't get retriggered
  • a parenthesized LeftHandSideExpression
  • at least one example where AssignmentTargetType of the LeftHandSideExpression in the spec is not simple.
• Control flow analysis within
  • the right side of each operator
    • (see &&= example below)
  • the code following each operator

    • function foo(result: number[] | undefined) {
          results ||= [];
          results.push(100);
      }

    • function foo(result: number[] | undefined) {
          results ??= [];
          results.push(100);
      }

    • interface ThingWithOriginal {
          name: string;
          original?: ThingWithOriginal
      }
      function doSomethingWithAlias(thing?: ThingWithOriginal | undefined) {
          if (thing &&= thing.original) {
              console.log(thing.name);
          }
      }

• the evaluated type of each operator

  • function foo(result: number[] | undefined) {
        (results ||= []).push(100);
    }

  • function foo(result: number[] | undefined) {
        (results ??= []).push(100);
    }

[DanielRosenwasser]

It just hit stage 3!

[Kingwl]

Yes, I saw your approve at tc39😳

[aminpaks]

Is this a bug or am I missing something?

let x: { a?: boolean } = {};

x.a ??= true;
x.a &&= false;
^^^ Type 'false' is not assignable to type 'true'.(2322)

Playground (Nightly build)

[Kingwl]

@aminpaks seems a bug. I'll take a look on it.

[kolpav]

@Kingwl is this bug too?

Playground

I don't see how props.size can be undefined

[danielrentz]

@kolpav I think this is unrelated but caused by the fact that narrowed types do not flow into callback functions.

You can workaround that by creating a local const size = prop.size ?? 'base'; and use that.

[kolpav]

@danielrentz Thats unfortunate. I would like to keep react props on props object because using your solution I need to have two ways how to access props based on them having default value or not. props.<propWithoutDefaultValue> and special variables (size etc) for every other prop. I know there are ways how to get around that but they are usually lot of code and not as readable and nice as props.size ??= 'base'. Is it something worth creating issue for or is it expected TS behaviour? My mental model must be wrong because I was bit surprised by it.

[gustavopch]

@kolpav I'm in the same situation. I don't see how props.size could be undefined. A workaround is to assign the default value using a function with an assertion signature:

type NonNullableProp<
  TObject extends { [key: string]: any },
  TKey extends keyof TObject
> = Omit<TObject, TKey> &
  {
    [key in TKey]-?: NonNullable<TObject[key]>
  }

function assignDefault<TProps>(
  props: TProps,
  key: keyof TProps,
  value: TProps[typeof key],
): asserts props is NonNullableKey<TProps, typeof key> {
  props[key] ??= value
}

const Component = (props: {
  size?: 'small' | 'medium' | 'large'
}) => {
  assignDefault(props, 'size', 'medium')
  // From this line, size is not considered optional anymore
  // ...
}

[kolpav]

@gustavopch Is exactly something I was trying to avoid

I know there are ways how to get around that but they are usually lot of code and not as readable and nice as props.size ??= 'base'

Your solution looks nice but in my case I am not willing to write code doing "nothing" just to please our type checking overlords. TS usually forces you to write better code but this time it doesn't seem to be the case.