Description 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 eitherThe type can resolve either way 👍 Changing the default type constraint from {} to unknownChange 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?
👍 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-specifiedString/string has a similar probleminterface - can't extend somethingKey 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?
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?
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)Reactions are currently unavailable
You can’t perform that action at this time.
Should we put
Omitin lib.d.ts? AddOmitas a known interface #30455Kin the official definition?Extractis not constrained eitherChanging the default type constraint from
{}tounknownChange the default type parameter constraints and defaults to unknown from {} #30637foo<T>(x: T) { x.hasOwnProperty(...)}JSDoc feature parity [Design Policy] Consider JSDoc feature parity with Typescript #30624
object: Fine to treat this asobjectin input positions, but in output positions this is fatal because JS is often under-specifiedString/stringhas a similar probleminterface- can'textendsomething::syntax/* ::widely-used amongst flow programmers?/** @ts ...as constshould work in JSDoc cast syntax (bug)