无返回函数在 isolatedDeclarations

#58330

/** Inferred as void */
export function f() {
    g();
}

/** Inferred as never */
export const x = () => {
    g();
};

function g(): never {
    throw null;
}

• 在 --isolatedDeclarations 下，是让声明和表达式具有一致的行为更好，还是支持 isolatedDeclarations 上的更好的人体工程学？
• 在孤立的声明下，我们可能“不必要的”要求你将 f 注解为 void 。
• 这只是出于与函数表达式的一致性，它们可以被推断为 never 。
• 我们推断 never 的规则已经建立得很好。
• 我们会改变它吗？
• 呃......
• 为什么我们要这样做？
• 我们不想破坏抛出并被覆盖的代码，或者如果我们改变了想法。
• 如果我们这样做了，我们可能会锁定我们的行为的范围。
• 其他每个工具都需要改变行为，如果我们改变了主意的话。
• 也许 - 尽管如此，我们永远不会将这些更改为 never ,我们只会将它们更改为可能为 undefined 。
• 我们真的很喜欢保持设计空间对我们开放的想法。所以我们会保持一致地说“你必须在这里写 void ”。

将当前编译器选项的一部分暴露给类型系统

#58396

• Feature Request: Expose TS configuration and internals as Types #50196 被提议过。
• 相关： @phryneas/ts-version ,一个利用 typesVersions 告诉你正在使用的 TS 版本的包。
• 人们试图做类似这样的事情来弄清楚某些编译器选项。
• 我们想要讨论这与在 Iterable / IterableIterator 中使用 TReturn / TNext 的标志之间的关系，以及更广泛的用例，并确定这是我们想要走的方向，哪些选项应该暴露，以及应该如何命名这个类型。
• 这种工作可以让 lib.d.ts (或其他人)根据 TReturn / TNext 或其他类型的 --noImplicitAny 等来决定类型。
• 许多使用 TypeScriptSettings extends { strictFunctionTypes: T } ? T : never 或类似的例子。为什么不直接使用 x22n2x ?
• 在 x23n3x 中进行前向声明的代码可能没有给定的选项。
• 但现在你可能会意外地使用一个不存在的标志(拼写错误的标志名称)。
• 人们一直要求这样做很长时间了 - 但是条件编译使得诊断非常困难。
• 这种用法的误用可能性很高。将其发布是一个告诉人们使用它的绿灯。
• 拼写选项只是一个例子。
• 暴露 x24n5x - 将 x25n6x 作为处理这种问题的方法是否正确？
• x26n7x
• 虽然很广泛，但不够强大以表达条件编译无法解决大问题的地方。
• 例如依赖于上下文的全局变量。
• 有道理的是，主要的兴趣点是特定的类型检查选项。
• 如果有人打开了 x27n8x 并以一种聪明的方式影响了一些代码，这会有好处吗？
• 关于“发布它是告诉人们使用的绿灯”：可以将其命名为 x28n9x 吗？
• x29n10x
• 这种方法实际上是如何解决 x29n30n30 的问题的？??