API for暴露调用的推断类型参数

#59637

• 提议的API是否正确？签名是调用的目标，但它是独立的，并且特定的类型参数对应于签名本身。
• Signature -> Type[] 对吗？还是你需要其他的东西？你有签名的类型参数，但还有其他的问题类型参数。
• 它是什么？
• 语言服务可以做到这一点。可以使用 go to definition 进行此操作。
• go to definition 对于这个API来说并不稳定。
• 如果你有一种获取签名本身的方式，你就可以得到类型参数。
• 可以基本上使用 getResolvedSignature ,获取类型参数，然后用原始签名的Map器加上 instantiateTypes 吗？就像在问题中建议的那样。
• 是的，这听起来像是API的建议。

禁止TypeScript特定运行时构造的标志

• Opt-In Language Features to prevent Embrace and Extend -- Compiler options on tsc.js #2261
• Tsconfig option to disallow features requiring transformations which are not supported by Node.js' --strip-types #59601
• 长期问题：我们如何禁止没有运行时影响(或不是可以轻易擦除)的构造？
• 现在Node有了 --experimental-strip-types ,它用空格替换了类型构造，这可能会给这个标志带来更多的动力。
• 这个标志会叫什么名字？
• --noTranspiledFeatures
• 我们转译 ESXXXX 特性。
• --typeSyntaxOnly
• --disallowRuntimeSyntax
• --noLegacySyntax
• --noRegerts
• 这个标志是否意味着 --verbatimModuleSyntax 和 --isolatedModules ?
• 使用场景重叠很多。我们不知道为什么在没有这些的情况下你会打开这个标志。
• 人们似乎最喜欢 typeSyntaxOnly 。
• 这种事情总是很奇怪，因为实现者有自由添加新的TS特定构造。
• 这也是关于保持与ECMAScript的“纯粹”。
• 这些显然是不被允许的吗？
• class C { constructor(public prop: number) {} }
• enum 的任何形式
• namespace 的任何形式
• 下面的情况是否被允许？
• import foo = require("foo");
• import foo = bar.baz;
• export =
• 其中一些不能只是擦除为空白！
• 这都是疯狂的，因为我们重新审视这个问题的原因是因为 Node 的 sourcemap 支持很慢。
• 这也是一个尚未在稳定版本中发布的功能的推测。
• 不完全正确，还有一个关注点是作为对 ECMAScript 语法冲突的未来保护。
• 很多这都可以只是一个强制执行意识形态纯洁性的lint规则。
• 对于这样做是否是一个好事有一些矛盾的感觉，但有一种感觉认为这不是我们现在会做的事情。
• 假设这只会在 .ts 中，而不是 .d.ts 中。
• 感觉不好的是，我们会禁止枚举，那替代品是什么？
• 具有名义成员、单个类型成员等的枚举都是很好的。
• const foo = {...} as enum 。
• 它不会完全替代。