Design Meeting Notes, 1/20/2023

[DanielRosenwasser]

const Type Parameters in Object.freeze

#52317

• Gets rid of weird signature - fakes a contextual type with everty literal type in its domain.
• Not quite correct - the original signature keeps literal types at the top level.
• Object.freeze is top-level immutability, but this PR implies deep immutability.
• Unfortunately this is not the right PR. Feels like it would be though!
• Users can always add a signature to Object.freeze if they consistently use it that way.

Can we remove resolution-mode from import type ... assert { }?

#49055

• Can we remove this?
• It breaks our automation for builds.
• Could we support import type foo = require("foo") instead?
  • But still can't opt in for module resolution mode within a CJS file.
• Sounds like Deno suppresses the error - do Deno users rely on it?
  • Would like to hear from them.
• We don't see that much usage.
  • Also, most usage is a /// <reference ...> version of this.
  • GitHub Code Search

Improvements

#52282

• Unfortunate cases where users are left with an asserted type: Type guard affects type of variable in surprising way #50916

• Change to ensure that that false cases preserve the original type.

• Also changes the "strict subtype relation" to ensure any is a strict supertype of unknown.

  • Consistent because any always had a lower type ID than unknown, so even when they were mutual subtypes, any always won.

• Does this fix Second use of type guard produces different result #52232?

  • Partially.
  • Lots of issues with any vs. unknown resolved; however, the signature of isValidElement needs to be fixed. That type parameter is unwitnessed and probably needs a different generic default.

• Also changing (...args: any[]) => any to be the supertype of all function types.

  • What about (...args: never) => any or (...args: never[]) => any or (...args: any) => any
    • Example of such a use-case at Regression causes Function top-type to be callable with no arguments #48840
    • Aside: never vs never[]
  • Really feels like (...args: never) => any and (...args: never) => unknown should be considered "toppy" types across functions.
    • Also need to give some thought to constructor functions.

• Have been able to remove the stripping of "freshness" in assignment expressions.

  // Before this proposed change.
  function fx10(
    obj1: { x?: number },
    obj2: { x?: number, y?: number }): { x?: number } {
      // Error ✅
      obj2 = obj1 = { x: 1, y: 2 };
  
      // No error?
      obj1 = obj2 = { x: 1, y: 2 };
  
  
      if (Math.random()) {
          // Error ✅
          return { x: 1, y: 2 }
      }
      else {
          // No error?
          return obj2 = { x: 1, y: 2 }
      }
  }

  • These all produce errors now.

• All of these changes are also good for incremental build and language service changes - because results are less surprising based on checking order.