Design Meeting Notes, 2026-09-15

首先阅读链接的 issue 64192、62180 和 62181，然后查看 PR 64172 和 64248，以了解现有的方法。这些注释讨论了循环类型推断、重载、约束以及类型参数泄漏的几种尚未解决的设计，但没有指出文件、测试或完成标准。

Better Type Inference Self-Referential Values

• https://github.com/microsoft/TypeScript/issues/64192
• https://github.com/microsoft/TypeScript/issues/62180
• https://github.com/microsoft/TypeScript/issues/62181
• https://github.com/microsoft/TypeScript/pull/64172
• https://github.com/microsoft/TypeScript/pull/64248

const Category = z.object({
    get subcategories() {
    //  ~~~~~~~~~~~~~
    // Subcategory implicitly has type 'any' because of circular
    // resolution.
        return z.array(Category);
    }
});

• Zod and similar libraries are motivation here.
• While processing the object literal, we normally defer return types for get accessors.
• But when validating the constraint, we start pulling on those very types.
• One idea: when we try to resolve a call that is already undergoing resolution, we say "don't check constraints".
• Why don't we disable constraint checking for all calls and do it in another pass?
  • We're not always interested in just generating an error, we're often trying to grab the constraint for other information (e.g. if there's no candidates, we have to fix to the constraint).
• How does this affect overloads? Because this would affect how we choose overloads, right?
  • Should not play in?
• Could we just return the original uninstantiated type parameter from the call when you detect this circularity?
  • How would that work? Isn't that a type parameter leak?
  • Yes, but the idea is there's an "outer" call and an "inner" call. The inner call would leak a type parameter (e.g. T) and the outer call would instantiate it after inference.
  • Scary, but maybe!
• Outstanding PRs are likely not quite what we're looking for, but may have a PR prototyping these ideas soon.