Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 1/18/2019 #29568

Closed
DanielRosenwasser opened this issue Jan 24, 2019 · 0 comments
Closed

Design Meeting Notes, 1/18/2019 #29568

DanielRosenwasser opened this issue Jan 24, 2019 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

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."
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

1 participant