Microsoft/TypeScript

Adding an overload to .filter breaks specific inference with nested functions

Open

#56,013 创建于 2023年10月6日

在 GitHub 查看
 (0 评论) (2 反应) (0 负责人)TypeScript (6,726 fork)batch import
BugDomain: check: Type InferenceHelp Wanted

仓库指标

Star
 (48,455 star)
PR 合并指标
 (平均合并 6天 17小时) (30 天内合并 9 个 PR)

描述

🔎 Search Terms

"filter inference overload", "filter boolean"

🕗 Version & Regression Information

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about inferred types

⏯ Playground Link

https://tsplay.dev/wQbrvN

💻 Code

type NonFalsy<T> = T extends false | 0 | "" | null | undefined | 0n
    ? never
    : T;

// Comment this out
interface Array<T> { filter(predicate: BooleanConstructor, thisArg?: any): NonFalsy<T>[]; }

const id = <T,>() => (t: T) => !!t;

['foo', 'bar'].filter(id())
//                    ^?

🙁 Actual behavior

Nested function inference works (type parameter is string) without the additional overload, and fails (type parameter is unknown) with the overload (even though the added overload isn't the one in use).

🙂 Expected behavior

Nested function inference should work regardless of whether an overload is added to .filter or not.

Additional information about the issue

Adding the overload is described in https://github.com/microsoft/TypeScript/issues/50387 and made popular by ts-reset. It's possible the overload order may matter in this instance, but difficult to test when the main overloads are coming from lib definitions.

贡献者指南