readonly modifier

#29435

• Today, the Readonly<T> mapped type does nothing when given a tuple or array.
  • You don't get ReadonlyArrays, and we don't have a readonly version of a tuple.
  • We've had requests for readonly tuples since tuples were a thing.
• Introduces a readonly modifier that goes on array types and tuple types.
• Also, when a mapped type specifies a readonly modifier, regular arrays and tuples are mapped to their readonly form.
  • This means Readonly<T>, given an array or tuple, gives you a
• Another improvement - a (...args: ReadonlyArray<Whatever>) => any now just works.
• Should we consider a general-purpose readonly type operator/modifier that applies for every type.
  • Could, but we need some manifest syntax to represent these special tuples.
• readonly modifier is a special thing for arrays and tuples, but Readonly is a general purpose type alias.
  • What do you recommend to people?
• If we just had a new tuple syntax, maybe this wouldn't be as unintuitive?
  • But then people would expect the same syntax in expression space.
  • Also, the existing syntax are already familiar.
• Why not just have readonly mean Readonly for now?
  • Not open for later work on stripping mutating methods.

Infer contextual types from generic return types

#29478

• Problem is that in functions, we don't take into account-

[[Couldn't follow what the explanation of the original complications were.]]

globalThis - the global environment handle

#29332

• New global identifier.
• It can be shadowed.
• Means you can reach it from within any function as well.
• window has the type Window & typeof globalThis
• Do we polyfill this outside of ESNext?
  • Slightly complicated because of CSP, but it's not crazy and it's provided in the proposal.
  • globalThis is a property on globalThis
    • So you can write globalThis.globalThis.globalThis.globalThis.foo
    • Can you assign to globalThis.globalThis?
      • No
    • Does the implementation enforce that?
      • Not at the type-checking level.
        • Gotta add SymbolFlags.Const
      • Right now we had a __globalThis() in mind
        • But then at runtime __globalThis().globalThis won't work.
    • Related: do we enforce that const-declared globals are considered readonly properties?
• How should people be changing the global namespace?
  • TypeScript users can do global augmentations and it will be reflected on window
  • Doesn't work that well for JavaScript users; how do they augment the global scope?
• Right now when we print the type of the global scope, we print out typeof globalThis
  • Seems good
• In modules, this has the type undefined, but it used to be implicitly any.
  • Maybe that should be in separate PR.

const contexts

• In a const context, all literals become singleton types, properties become readonly, arrays become tuples.
• Uses the type assertion syntax:
  • [number, string] as const
  • <const>[number, string]
• Things that can be affected are:
  • object literals, and their property values
  • array literals, and their element values
  • the expression within a parenthesized expression
• What about the comma operator?
  • Ehhh?
  • Hmmm...
• Why const and not readonly?
  • const is a stronger guarantee - means nobody ever can change the value, whereas readonly is a strong guarantee on the handle to a value.
• We are allowing these as constraints on type parameters?
  • T extends const?
    • Maybe could see readonly constraint, but that's separate and it seems strange that it would be non-local?
• How is this represented in the AST?
  • Just hijacks the fact that you had a type reference named const
  • So it doesn't break anything.
  • Would be nice to have a better value returned for API consumers.
• Maybe we need a type operator for deep readonly?
  • You can mostly do this with DeepReadonly.
• "This gives me a lot of const-ernation"
  • "You're so clever Daniel!"
  • "Thank you, I know, I'll be here all week! ...wait, it's Friday."