littledan etc: is there a types-as-comments chat room or call or something I could join? I have a followup thesis from the discussion earlier:

• Making almost all of TS runnable is a bad goal.
  • It's too big to reasonably specify.
  • TS adds new keywords more frequently than our process would allow, and that's good. The constraints on evolving the grammar of TS are genuinely different from the constraints on evolving the grammar of JS.
  • And given the existence of things like Svelte, JSX, --experimentalDecorators, etc, you're never going to reach a point where almost all TS projects can stop using transpilers anyway, so there's nothing particularly special about "almost all of TS".
• Making it more practical to use type checkers without transpilation is a good goal. The current jsdoc support in TS is bad enough that people will put up with the cost of transpilation rather than use it except in extreme cases (e.g. Svelte), and that could be improved.
  • But that only helps people in specific circumstances (i.e., those who otherwise would not have a transpilation step).
  • Flow's comment syntax actually gets used, which means that there's room for something between "only jsdoc-style comments" and "all of TS".
  • By far the largest painpoint with Flow's comment syntax is inline type annotations on variables and parameters. Multiline comment syntax is verbose and awkward to type for something used so frequently.
• Therefore, the proposal ought to drop the "un-fork JS" goal and instead set a goal of 80-20'ing the types-without-transpilation experience using a more minimal grammar, omitting (e.g.) any keywords other than maybe type. There's a handful of issues on the repo already proposing something like this. Those users who would benefit can opt in without much more pain, and those who would not can continue to benefit from TypeScript's full syntax being able to evolve outside our process.
  • This doesn't need to be a subset of the TS grammar, particularly if automated translation from full-TS to this subset is easy (which it ought to be).
  • This should be general enough to allow ~any type system to opt in to using only this grammar, but shouldn't aim to have parity with the grammar of any existing type systems. It's OK if this grammar is somewhat more awkward than those available when using a transpiler.
  • Concretely, this might look like :: [nlth] (.? IdentifierName [nlth])* MatchedBraces being allowed in a few places, and maybe a new top-level type declaration form. Possibly with one or two more forms for e.g. imports, but only a couple more at most.
    • This solves some but not all of the ambiguities in the current grammar; the remaining ones (e.g. FunctionBody braces) would need fixing either way.
    • Yes, this means a lot of nontrivial types will need parentheses. That is a significant cost. I think the cost is worth it.