Skip to content

Design Meeting Notes, 1/31/2024 #57254

New issue

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

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

Already on GitHub? # to your account

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

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants