Design Meeting Notes, 2026-09-15

[DanielRosenwasser]

Better Type Inference Self-Referential Values

• Recursive inference through self-referential object literals #64192
• Confusing missing property error in a circular situation #62180
• Ghost error in a circular situation #62181
• Infer recursive types through object literal getters #64172
• Infer recursive types through self-referential object literals #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.