noImplicitAny confusion

bad title but i don't know how to better describe it

TypeScript Version: 2.4.2 and 2.5.0-dev.20170808

Code

// needs noImplicitAny

function get123 () {
	return 123;
}

/**
 * @param original    some function
 * @param replacement another function with the same type
 */
function test <T> (original: T, replacement: T) {
	// ...
	return original;
}

// 'get123_' implicitly has type 'any' because it does not have a type
// annotation and is referenced directly or indirectly in its own initializer.
const get123_ = test(
	
	get123,
	
	// Function implicitly has return type 'any' because it does not have a
	// return type annotation and is referenced directly or indirectly in one
	// of its return expressions.
	function () {
		return get123_();
	}
);

Expected behavior:

i don't think there should be any errors at all, and get123_ and the anonymous function should have the same type as get123

the test function is meant to take two things with the same type but it's like it thinks they're the same value

Actual behavior:

it says the get123_ variable is referenced in its own initializer when its value is just get123

it says the anonymous function is referenced in one of its return expressions, when it's only referencing another function with the same type (get123_ which is just get123 returned from the test function)

(at least that's how i see it)

---

i was trying to write a function that would do Object.assign to an object's property descriptor and return its previous value, and using it would often give this error even though there's no circular references going on like it thinks

you'd use it like this:

const open = patchDescriptor(window, "open", {
	value: function open (url?: string, target?: string) {
		// Reflect.apply returns `any` so this doesn't error
		return Reflect.apply(open.value, this, arguments);
	}
});

[masaeedu]

@epicgirl1998 There is a circular reference here. Perhaps you meant function () { return get123() } instead of function () { get123_() }?

it would be a circular reference (infinite recursion) if test returned the second argument (the anonymous function using the return value) but it's returning the first one which is just get123

this modified version of the example works when pasted to a javascript console (no infinite loop):

function get123 () {
	return 123;
}

let replacement;

function test (original, replacement_) {
	replacement = replacement_;
	// ...
	return original;
}

const get123_ = test(
	
	get123,
	
	function () {
		return get123_();
	}
);

console.assert(replacement() === 123);
console.assert(get123_() === 123 && get123_ === get123);

---

this is closer to what i was doing when i found the bug (maybe it'll make more sense):

const myObject = {
	get123: function () {
		return 123;
	}
};

function replaceProperty <
	TTarget,
	TKey extends keyof TTarget
> (
	target: TTarget,
	key: TKey,
	newValue: TTarget[TKey]
) {
	const oldValue: TTarget[TKey] = target[key];
	target[key] = newValue;
	return oldValue;
}


console.log(myObject.get123()); // 123


// 'get123_' implicitly has type 'any' because it does not have a type
// annotation and is referenced directly or indirectly in its own initializer.
const get123_ = replaceProperty(
	
	myObject,
	
	"get123",
	
	// Function implicitly has return type 'any' because it does not have a
	// return type annotation and is referenced directly or indirectly in one
	// of its return expressions.
	function () {
		return get123_() * 2;
	}
);


console.log(myObject.get123()); // 246

[masaeedu]

@epicgirl1998 There's a difference between a circular reference and infinite recursion (e.g. it is possible to write let x = 10; function f() { return --x ? f() : x }, which is finitely recursive, but still runs into this issue). TypeScript doesn't actually evaluate your program, so it has no idea whether the circular reference will actually cause infinite recursion.

The problem from TypeScript's perspective is that the type of the variable get123_ depends on the type of the function expression function () { return get123_() }, for which the return type depends on the type of get123_; it can't reason its way out of this circle and gives you an error.

[j-oliveras]

Looks like a duplicate of #17711, solved by @ahejlsberg at #17771.

[RyanCavanaugh]

In some super-ideal world we could detect when the type of an expression "doesn't matter" for purposes of type inference, or detect a closed loop, but this turns out to be rather difficult for reasons described above. get123_ definitely references itself in a position that matters for the purposes of inferring its type and I don't see any way out of that.