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, 4/3/2019 #30738

Closed
RyanCavanaugh opened this issue Apr 3, 2019 · 0 comments
Closed

Design Meeting Notes, 4/3/2019 #30738

RyanCavanaugh opened this issue Apr 3, 2019 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@RyanCavanaugh
Copy link
Member

  • Should we put Omit in lib.d.ts? Add Omit as a known interface #30455

    • In principle, no objections
    • What are the breakages?
      • 1 package on DT was impacted
    • BigTsQuery found 3 programs
    • The fix is trivial
    • Should we constrain K in the official definition?
      • Nah
      • Extract is not constrained either
      • The type can resolve either way
    • 👍
  • Changing the default type constraint from {} to unknown Change the default type parameter constraints and defaults to unknown from {} #30637

    • Zero breaks on DT because Wesley fixed them
    • Breaks in RWC were in places where things actually could be null/undefined
      • 2-3 files where this happened
      • Typically e.g. foo<T>(x: T) { x.hasOwnProperty(...)}
    • Should we issue custom error messages?
      • Nah
    • 👍
  • JSDoc feature parity [Design Policy] Consider JSDoc feature parity with Typescript #30624

    • object: Fine to treat this as object in input positions, but in output positions this is fatal because JS is often under-specified
    • String/string has a similar problem
    • interface - can't extend something
    • Key question: Should everything you can write in TS have a JSDoc equivalent?
      • You want something like "Let me write TS in this JSDoc comment"
      • We don't want to be inventing JSDoc syntax for all of our stuff
      • "Inline declaration file"
        • Why not make a .d.ts file?
          • Scoping alignment
        • Comparison with flow's :: syntax
          • Is /* :: widely-used amongst flow programmers?
        • /** @ts ...
          • What is the lexical scoping of this?
          • What are the legal positions of this sort of comment?
            • Legal at positions where a declaration would have been permitted
        • Type arguments (?)
        • Is this for annotation of functions, or for top-level declarations?
          • Both
        • How do you write module-scoped types?
          • Merge module scopes .js and .d.ts files of the same name?
        • What about the straightforward parser limitations?
        • What are the use cases?
          • "We exist on a line, not a square"
          • But this complicates the transitional story
            • It's important that we not add "false paths" of syntax that can't be transitioned
        • We started out to understand JS Doc, not invent new syntax
          • We're not going to support everything
          • Need to stop adding new JSDoc-specific behavior
        • Stake in the ground: Full feature parity is not a goal
        • We should be supporting extant JSDoc
    • as const should work in JSDoc cast syntax (bug)
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

2 participants