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/31/2024 #57254

Closed
DanielRosenwasser opened this issue Jan 31, 2024 · 1 comment
Closed

Design Meeting Notes, 1/31/2024 #57254

DanielRosenwasser opened this issue Jan 31, 2024 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Notes from @RyanCavanaugh

JSDoc import *

#41825

  • Annoying to have to write import()s over and over again
  • @importType * as Foo from "bar"
  • @importType { destr } from "bar"
  • Or just @import instead? It's unambiguous
  • Peeps generally preferred the latter
  • What about an inverted from x import y ?
    • Ehh, mirroring ES syntax is better even if it's worse for completion
  • type modifier seems unnecessary since it's implicitly in a type context
    • Should we allow it as a no-op?
      • Start with no, see what happens
  • Do we support trailing comments at the end of lines?
    • How do we know when the code ends? New keywords can and have appeared after the module specifier
    • Just lookahead
    • Need many testcases around various whitespace/newline combinations
  • Do we really need to support multiline variants? Seems complex
    • We already have helpers to correctly deal with eating the start of line

Set methods

#57230

  • Should the set boolean algebra functions enforce matching, or be generic?
  • Many trade-offs
    • Generic: s.intersect(t) matches t.intersect(s)
    • Generic: sup.intersect(sub) produces Set<sub> instead of Set<sup> (good)
    • Nongeneric: strs.intersect(nums) gets detected as an error
  • After much debate: Use generics
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jan 31, 2024
@DanielRosenwasser
Copy link
Member Author

I'll note that it's not really just generic vs. non-generic. It's more constrained vs. unconstrained.

  • Set<T> and intersect(x: Set<unknown>): Set<T>
    • non-generic, unconstrainted, nobody wanted that
  • Set<T> and intersect(x: Set<T>): Set<T>
    • non-generic, constrainted, this seems safer, but is less flexible and doesn't gain any information
  • Set<T> and intersect<U>(x: Set<U>): Set<T & U>
    • generic, unconstrained, this is what most people wanted
  • Set<T> and intersect<U extends T>(x: Set<U>): Set<T & U>
    • generic, constrained, this is what I probably would have wanted

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