Design Meeting Notes, 4/23/2021

[DanielRosenwasser]

TC39 Update

• Class fields to stage 4
  • useDefineForClassFields?
  • Nicer emit ESNext, ES2022
• Import assertions
  • Semantics are implementation-defined
  • Uh, so just parse and do nothing with it?
  • Strange.

Optional vs undefined

#13195

• Can't distinguish whether a property is present vs. when it's undefined.

• Comes up in functions like React's setState.

  • You don't want certain properties to be explicitly undefined. setState just allows you to omit properties of existing state.

  • Specifically:

    this.setState({
        foo: "hello",
        bar: undefined
    });

    has a different meaning in React than

    this.setState({
        foo: "hello"
    });

• Previously were considering missing as an alternative to undefined to describe the distinction. It's kind of messy and confusing for people to have another type.

• Idea: have undefined affect reading values (i.e. read side of a type), write type only describes the explicitly given type.

  • Means obj.a = obj.a is not always allowed! But kind of correct.
  • This behavior now also allows you to narrow by in and then perform the obj.a = obj.a assignment.

• Breaking change - but if we did it all over again, we'd do it this way.

  • So strict flag?

• Automated addition of | undefined to a property avoids breaking changes.

• Maybe the case that optionality not including an explicit undefined is actually what users meant...but maybe not really? Many (most?) programs probably just check the value of a property.

  • Similar to whether you want to have an "optional" type that doesn't distinguish between null and undefined. Most programs don't care, but it was useful for us to distinguish between that!

• Ship a codemod?

• Do we support delete in control flow analysis?

  • Don't think so.
  • This might kind of force people to do that?
  • Could consider doing it.

• Could also have ? to mark optionality on an index signature which piece-meal allows you to opt into noUncheckedIndexedAccess.

• Very hard to understand how this works on higher-order with mapped types (e.g. Partial, Pick, Required).

• A way to opt into new semantics?

  • ??
  • { x??: string }

• Mapped types?

  type Partial<T> = {
      [K in keyof T]?: T[K]
  }

  • Does this mean partial includes undefined in every property? Does this break existing code that assumes otherwise?
  • Could have a default type argument that specifies whether you wanted to include undefined or not.

TSConfig Categorization

#13195

• We like it generally.
• Command line?
  • Make sure flags all have --
  • No "from", just "values", "arguments", "one of" for option values?

[DanielRosenwasser]

@jack-williams, @ahejlsberg mentioned that you had brought up some of the ideas around optional vs. undefined in a few places if you would be able to link to them here.

[robpalme]

The "TSConfig Categorization" issue link needs updating.

[orta]

#42514 was the first draft for the categorization, I'll need to give it a second look over with the new version looking like https://www.figma.com/file/nlPfnmBwRRleIKGhJ9Aj9S/TSConfig-Categories

[orta]

And the tsc --help drafts are in the GH actions for https://github.com/orta/tsc-cli-example/runs/2422727602?check_suite_focus=true

[jack-williams]

@DanielRosenwasser, a couple of links:

comment (from the issue thread and the longest comment)
comment (from the PR thread I started)

Looking back at what I wrote, I think I still agree with most of it. To pick out some things:

---

Pairing any language change with a tool to update source files to semantically preserving syntax is going to be very helpful. This as assuming you don't use a new syntax like ??.

{ foo?: Type } ~~~> { foo?: Type | undefined } // if undefined not in Type

If anyone is like me then they haven't used ? properties consistently across their projects to mean the same thing (sometimes missing, sometimes undefined, sometimes both).

---

I still feel that a missing type is fundamentally wrong (more elaboration in the first link I post). Maybe there is a nice implementation that works in practice, but it seems hard.

---

Idea: have undefined affect reading values (i.e. read side of a type), write type only describes the explicitly given type

I have an old PR here (#33089) that introduced read and write indexed access types for other reasons (type simplification), but I never considered it in the context of dealing with undefined. Another comment here. That could be an interesting thing to pursue. Something like?

{ x??: number }['x'] --> number | undefined (read type)
{ x??: number }:=['x'] --> number (write type)

Seems like this may be mandatory for soundness?