搜索词

explicit infer return type

建议

为 infer 类型添加支持，该类型可用于明确表示函数的返回类型应从其实现中推断。对于函数(或箭头函数)具有显式的 infer 返回类型，其可观察行为与未指定返回类型相同：返回类型从实现中推断。
区别在于，现在技术上该函数确实有指定的返回类型，以指示开发人员明确决定允许返回类型被推断，而不是简单地忘记考虑返回类型应该是什么。

使用场景

在具有严格/显式代码风格的项目中，通常希望使用要求所有函数都有指定返回类型的linting规则(例如tslint的 "call-signature" typedef规则)。
然而，有些情况下，函数的返回类型是复杂类型(涉及泛型等),使得返回类型更自然地从方法的实现中推断出来，而不是提前知道预期的返回类型。
在这种情况下，如果能明确表示编译器推断函数的返回类型是有意义的，那将非常有益。这既能清楚地向其他阅读代码的开发人员传达这一明确意图，也可以用于满足要求函数具有指定返回类型的代码风格和linting规则。

为什么不能逐个禁用？

是的，可以使用tslint的行级规则禁用来临时禁用linting规则，让你在这种情况下省略返回类型。但我认为语言级别的显式 infer 返回类型支持会更有力、更清晰地表达意图。如果实现起来相对容易且风险较低，那就更加值得一试。
此外，没有足够的粒度来仅禁用 "typedef" 规则中的 "call-signature" 上下文。禁用该行上的 "typedef" 将同时禁用签名中的参数类型的检查，这是不希望看到的。

示例

一个简单的示例是单元测试中的辅助方法，使用 enzyme 。假设你有一个名为 MyButtonComponent 的自定义React组件，你想找到某个外部组件中的 "close" 按钮：

import { ReactWrapper } from "enzyme";
import { MyButtonComponent } from "./MyButtonComponent";
function findCloseButton(wrapper: ReactWrapper): infer {
    return wrapper.find(MyButtonComponent).filter(".close-button");
}

在这种情况下，上述 return wrapper.find(MyButtonComponent).filter(".close-button") 语句返回了一个严格类型的 ReactWrapper<P> 类型，其中 P 是 MyButtonComponent 组件的 Props 类型，这允许通过 ReactWrapper 's props() 方法安全地访问组件当前属性值。
手动编写上述辅助函数的正确返回类型将相当繁琐，而且带来的好处非常有限。特别是如果 MyButtonComponent 的 Props接口无法轻易获得(因为它没有导出),或者因为 MyButtonComponent 是复杂泛型高级组件(HOC)创建的。在这种情况下，正确写出返回类型的努力远远超过了它的好处。

从隐式中推断

在以下示例中，没有实现可以从中推断返回类型的部分：

declare function foo(a: number): infer;
interface Bar {
    bar(b: string): infer;
}

实际上， infer 类型在这里实际上是没有用的。也许只允许在存在可以推断的内容的情况下使用 any 类型会更有意义？如果是这样的话，那么上面的示例将是编译错误，因为没有任何东西可以推断。
另一个合理的选择可能是允许它以一种在 infer 编译器选项下会导致编译失败的方式推断隐式 any 类型。这种选项虽然不是最直接、最自然的选择，但完全可行且风险/努力最小。

部分推断类型

这是一个关于这个想法的扩展：

function foo(value: number): Promise<infer> {
    // return value must be assignable to Promise<any>
    // return type is inferred to be Promise<number>
    return Promise.resolve(value);
}
interface Pair<A, B> {
    a: A;
    b: B
}
function bar(value: number): Pair<infer, infer> {
    // return value must be assignable to Pair<any, any>
    // return type is inferred to be Pair<number, boolean>
    return {
        a: value,
        b: value % 2 === 0
    };
}

这将提供一个很好的结合点：在基本格式中验证你正在返回一些内容的同时让编译器推断复杂部分的类型，而这些复杂部分并不值得手动构造或编写。

待办事项清单

我的建议符合以下准则：

• 这不会对现有的TypeScript/JavaScript代码造成破坏性改变
• 这不会改变现有JavaScript代码的运行时行为
• 这可以在不根据表达式的类型生成不同的JS代码的情况下实现
• 这不是一个运行时特性(例如新的表达式级别语法)