Design Meeting Notes ,12/9/2022

[DanielRosenwasser]

const contexts for generic type inference

#30680

• Many times where you want a type to refer to the most "precise" type - usually implies you need to reuse its literals, don't intend to modify the values.

• You can use as const, but that pushes the burden to the use-site instead of the declaration-site.

• Lots of instances where a parameter wants to hint that it prefers precise and read-only literal types.

• Several different approaches - could annotate the parameter, could annotate the type parameter

• Can even sort of do it today with complex types - but those look pretty bad.

• Idea we're experimenting with: a const prefix modifier for type parameters.

  declare function freeze<const T>(x: T): T;
  
  // Type is `["a", "b", "c"]`.
  let x1 = freeze(["a", "b", "c"]);
  
  // Type is `{ a: 10, b: 20 }`.
  let x2 = freeze({ a: 10, b: 20});

• Is this deep immutability?

  • Well it's like as if you had written as const.
  • But what if one of those values was a string[] (which is not immutable)?
    • Well that's allowed.
    • That's a little different from as const

• Could also imagine that if you had written a readonly T[] constraint, maybe that could imply you want the more precise types?

  • Eh, not necessarily.

• Why type parameter? Why not parameter?

  • const would sort of mean something different if it appeared on a parameter.
  • Intrinsic to the type.
  • [[Discussion around in and out variance annotations]]
  • Wait, can you write const on the type parameters of a type?

    • No.

      class C<const T> {} // ❌
      interface I<const T> {} // ❌
      type TA<const T> = {} // ❌

• Aside: we will end up calling getContextualType more often. Should try to optimize that.

• What do we do in the fact of multiple type parameter targets in a union type? One is const, one is non-const.

  • Likely the case that all type parameters will get the consty thing.

• People will likely want a set of overloads where one overload takes a consty type parameter.

  • That's fine, we infer different types for the same object literal across different overloads.
  • Well, the functions in the object literal may have their parameter types fixed.

• How does the constness of a signature's type parameter affect relationship checking of that signature?

  • It probably shouldn't for things that are based more around rough substitutability.
    • So subtype, assignability, comparability - those succeed bidirectionally.
    • Strict subtype and identity need more thought for things like union ordering.

Deprecating module keywords for namespaces

#51825

• Deprecating in implementation files is easyish. Deprecating in declaration files is harder.
• Also, what would the declaration emit be for ES module declarations? These would conflict. Is there any way to make that work?
  • Don't have any conflict technically if only the expressions proposal lands; we are a bit skeptical that the declaration form is necessary. So maybe there's no conflict?
• But if module declarations made it through, we really don't like the possibility that these would be ambiguous.
  • Well... for a person, is it really that hard to differentiate between an ES module declaration written in 202x vs. early TypeScript written in 2012?
    • Some disagreement on this.
    • [[Editor's Note]]: you'll know it when you see it. 😄
• Back to the topic - do we have an idea of how common module namespaces are on npm?
  • We don't!
  • We really should be able to answer this question.
• 236 occurrences of module-declared namespaces on DT, 41 unique packages! 😲
  • [[Editor's Note]]: seems like possibly more.
• So conclusions?
  • Want to see if we can still deprecate in implementation files, but...
    • we came in with some assumptions that DT had no module-keyword-declared namespaces.
    • we have no data about usage of module-keyword-declared namespaces otherwise.
  • Would like to get some more data to inform the decision here.