Design Meeting Notes, 1/31/2024

Ryan Cavanaugh (@RyanCavanaugh)

JSDoc `import *`

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

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 instead of Set (good)
- Nongeneric: strs.intersect(nums) gets detected as an error
After much debate: Use generics

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(x: Set): Set<T & U>
- generic, unconstrained, this is what most people wanted
Set<T> and intersect(x: Set): Set<T & U>
- generic, constrained, this is what I probably would have wanted