Improve type inference for circular references in object initializers

When you have something like this (also see a playground):

function makeFoo<T>(fn: () => T): () => T {
  // do some work here ...
  return function() {
    // ... or here
    return fn() 
  }
}

const obj = {
  name: 'test',

  foo: makeFoo(() => obj.name.length)
}

type of obj will be infered as any, because in order to determine type of obj typescript first looks at return type of makeFoo(...) which uses obj.

The actual error is this: 'obj' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.(7022)

What if we could give some hint to a compiler to handle this case? Maybe like this:

const obj = {
  name: 'test',

  foo: makeFoo(() => obj.name.length) as prop  // or a better name
}

Right now I have a workaround for this:

function getter<T, R>(t: T, k: keyof T, value: R) {
  Object.defineProperty(t, k, {value, enumerable: true})  
  return value
}

const obj = {
  name: 'test',

  get foo() {
    return getter(obj, 'foo', makeFoo(() => obj.name.length))
  }
}

but it would be cool if it could be done more easily.

[theScottyJam]

this isn’t really compatible with the straightforward caching recursive descent

Yeah, this makes sense. TypeScript uses a recursive descent parsing algorithm, and the sort of algorithm I was describing would require an entirely different type of parsing algorithm. Not only would it take a whole lot of work to switch, it’ll also add a lot of complexity to the codebase, and this particular issue isn’t an extremely common one.

I don’t think I’ll try to actually make a PR - I can tell that this sort of thing would be a giant refactor, and it’s certainly not a task I would be capable of, especially considering that I currently know nothing about the TypeScript codebase.

Ok, thanks for helping me understand 😃

[RyanCavanaugh]

The mechanism you’re describing here where, upon detecting a possible circularity, we just sort of put the relevant question on pause and come back to it later - this isn’t really compatible with the straightforward caching recursive descent that the checker is written in.

It’s instructive to look at the call stack at the point that we log the circularity error and see how every caller in that path (of which the incoming call stack is could be practically any function in the checker) would have to be basically completely rewritten to handle the answer of “ask me again later”.

We also need to be able to detect circularities instead of looping forever. For example, if you wrote

function f1() {
  return [0, f2()] as const;
}
function f2() {
  return [0, f1()] as const;
}

then any sort of work-deferring mechanism needs to be able to detect when it’s looping forever so that it doesn’t attempt to infer an infinite sequence of [0, [0, [0, [0, [0, [0, ....

The relevant codepaths in the checker here are not especially complicated (relatively speaking) and I’d encourage you to try a PR to understand the problem more deeply. Not to be glib, but if this were low-hanging fruit, we would have done it already 😉. Again, it’s not impossible, but it’s not at all a straightforward fix - we’d have to rewrite very large portions of the entire checker.