建议

🔍 搜索词

• 通用函数添加参数
• 通用函数的参数
• 在通用函数前添加参数

✅ 可实现性检查清单

我的建议符合以下指导原则：

• 这不会对现有的TypeScript/JavaScript代码造成破坏性的改变
• 这不会改变现有JavaScript代码的运行时行为
• 这可以在不根据表达式的类型发出不同的JS的情况下实现
• 这不是一个运行时特性(例如库功能、带有JavaScript输出的非ECMAScript语法、新的JS语法糖等)
• 这个特性将与TypeScript's Design Goals的其他部分保持一致。

⭐ 建议

能够在不失去泛型类型参数的情况下操作泛型函数类型将会非常有用(参见下面的激励示例)。想出一种好的语法并不容易，但我看到了几种可能的方法(精确的语法/名称可能会有所改变):

1. 一堆实用类型(不雅观但能完成任务)

type F = <T, R>(t: T) => R;

type X1 = WithReturnType<F, number>; // X1 = <T, R>(t: T) => number;
type X2 = WithParameters<F, [x: number]>; // X1 = <T, R>(x: number) => R;
type X3 = PrependParameter<F, number>; // X1 = <T, R>(arg0: number, t: T) => R;
type X4 = AppendParameter<F, number>; // X1 = <T, R>(t: T, arg0: number) => R;
type X5 = ReplaceParameter<F, 0, number>; // X1 = <T, R>(t: number) => R;

2. 对extends进行增强(可能是最漂亮的解决方案，但在规范它时可能会带来挑战):

type F = <T, R>(t: T) => R;

type X1 = F extends (...args: infer Args) => infer R
    ? (x: number, ...args: Args) => R
    : never;
// ...

3. 对extends使用新的语法来声明意图(这要更广泛得多，但只有在与更广泛的“泛型泛型”或HKT特性结合时才有意义):

type F = <T, R>(t: T) => R;

type X1 = F extends <...infer TypeArgs>(...args: infer Args) => infer R
    ? (x: number, ...args: Args<...TypeArgs>) => R<...TypeArgs>
    : never;
// ...

// or maybe
type X1 = F extends <...infer TypeArgs>(...args: infer Args<...TypeArgs>) => infer R<...TypeArgs>
    ? (x: number, ...args: Args<...TypeArgs>) => R<...TypeArgs>
    : never;
// ...

4. 替代现有语法的扩展(一般来说，这里有一个可能性):

type F = <T, R>(t: T) => R;

type X1 = <...Args>(x: number, ...args: Parameters<F<...Args>>) => ReturnType<F<...Args>>;

📃 激励示例

考虑一种类似这样的API/中间件构建器：

builder
    .add('slow', { rate: 500 })
    .add('get', { query: ['abc'] as const }, ({ query: { abc } }) => {
        // ...
    };

当使用时，它可以被类型化为如下所示：

interface Builder {
    add(type: 'slow', options: { rate: number }): Builder;
    add<Q extends readonly string[]>(
        type: 'get',
        options: { query: Q },
        callback: (data: { query: { [K in Q[number]]: string } }) => void
    ): Builder;
    // ...
}

然而，现在我们希望第三方能够能够向构建器中添加自己的中间件类型。为它们提供API相对容易：

BuilderFactory.register('merge', (options, callback) => {
    // ...
    callback(...);
    // ...
} );

但是，类型化它就困难多了。通常，我们会使用模块增强来允许第三方对他们的中间件类型进行类型化：

interface Builder {
    add<T extends keyof BuilderMethods>(type: T, ...args: Parameters<BuilderMethods[T]>): ReturnType<BuilderMethods[T]>
}

// third party code
declare module '...' {
    interface BuilderMethods {
        merge: <Q extends readonly string[]>(
            options: { query: Q },
            callback: (data: { query: { [K in Q[number]]: string } }) => void
        ) => void;
    }
}

但是，如果我们这样做，就会丢失类型参数中编码的所有信息。这个功能将允许add方法保留其派生的函数类型的泛型类型信息。

💻 用例

我的用例与上面的激励示例相当相似。目前我的解决方法是只对第一方方法有一个良好的类型体验，但这并不是理想的情况。