Repository: TypeScript
Issue: Design Meeting Notes, 8/16/2024
Labels: Design Notes


# API for exposing inferred type arguments of calls

https://github.com/Microsoft/TypeScript/issues/59637

* Is the proposed API correct? A signature is the target of the call, but is independent and the specific type arguments correspond to the signature itself.
* Is `Signature -> Type[]` right? Or do you need something else? You have type arguments of signatures, but there are other type parameters in question.
* What is it?
* Whatever the language service does. Go to definition can be used for this.
    * Go to definition isn't a stable API for this.
* If you have a way to get the signature as it is, you can get the type arguments.
* Can basically use `getResolvedSignature`, grab the type arguments, followed by `instantiateTypes` with the original signature's mapper? As suggested in the isssue.
* Yes, that sounds like the suggestion for the API.

# Flag for Banning TypeScript-Specific Runtime Constructs

* #2261
* #59601
* Long-standing question: how can we ban constructs that have no runtime impact (or are not trivially erasable)?
* Possibly more impetus for this now that Node has `--experimental-strip-types` which replaces type constructs with whitespace.
* What would it be called?
    * `--noTranspiledFeatures`
        * We transpile ESXXXX features.
    * `--typeSyntaxOnly`
    * `--disallowRuntimeSyntax`
    * `--noLegacySyntax`
    * `--noRegerts`
* Does this flag imply `--verbatimModuleSyntax` and `--isolatedModules`?
    * The use-cases overlap a lot. We don't know why you would turn this flag on without those.
* People seem to like `typeSyntaxOnly` the best.
* This sort of thing is always weird because implementers are free to add new TS-specific constructs.
    * Well this is also about staying "pure" with ECMAScript.
* Which are clearly not okay?
    * `class C { constructor(public prop: number) {} }`
    * `enum` of any form
    * `namespace` of any form
* Are the following allowed?
    * `import foo = require("foo");`
    * `import foo = bar.baz;`
    * `export =`
* Some of these can't just get erased to whitespace!
* This is all wacky because the only reason we're revisiting this is `--experimental-strip-types`, which seems motivated because Node's sourcemap support is slow.
    * This is also speculative for a feature that hasn't shipped in stable.
    * Not fully true, there is also future-proofing against syntax conflicts in ECMAScript as a concern.
* Lots of this could just be a lint rule which enforces ideological purity.
* Some mixed feelings on whether this is a good thing to do, but there is a feel that this is not what we would do today.
* Presumably this would be only in `.ts`, not `.d.ts`
* Feels bad that we'd disallow enums, what is the substitute there?
    * Enums being nominal, having individual type members, etc. are all nice.
    * `const foo = {...} as enum`.
        * Wouldn't be a full substitute.

          ```ts
          const x = {
            a: 1,
            b: a, // can't do this
          } as enum;
          ```
* What about `import foo = require(...)`?
    * Could support `const foo = require(...)` in some way, but would need a flag since a lot of code assumes this is `any`.
    * Is this really necessary? The hope is ESM/CJS interop will save us all.
    * A flag to add this flag? Just turn off this flag if you really need that or write `const m = require("m") as typeof import("m")`.