Type 'T' is not assignable to type 'T'. Two different types with this name exist, but they are unrelated

[alan-agius4]

TypeScript Version: 2.4.1

Code

interface myModel {
	prop: <T>(update: T) => void;
}

class myClass {
	test<T>(model: T) {
		const x = {
			prop: (model: T) => {
				// do something
			}
		}
		this.test2(x);
	}

	test2(model: myModel) {
		
	}
}

Expected behavior:
no errors

Actual behavior:
Type 'T' is not assignable to type 'T'. Two different types with this name exist, but they are unrelated.

[alan-agius4]

I also have the same error using rxjs

(operator: Operator<any, Action>) => Observable<Action>' is not assignable to type '<R>(operator: Operator<any, R>) => Observable<R>

[dozer75]

Also get the same error in the latest typescript release on rxjs.

I really starting to be frustrated over open source and the lack of quality checking on releases in different open source projects.

[HerringtonDarkholme]

TypeScript did find a bug in your code.

interface myModel {
	prop: <T>(update: T) => void;
}

The generic signature means myModel can accept "universally any" type. Because the type parameter T here is totally free, without any constraint.

However, in myClass.

test<T>(model: T) {
		const x = {
			prop: (model: T) => { 
                                  // T here is a usage, it refers to the type parameter above.
                                  // x.prop only accept the type `T`, which might be  `string`
			}
		}
		this.test2(x);
	}
test2(model: mymodel) {
        model.prop(123) // x might only accept `string`, but passed number
}

Note the comment, T is not free, it is "bound" to the outer declaration.

It is hard to explain. But TS is right here.

[alan-agius4]

So in reality here, from what I am understanding it's point less to use a generic type in such cases? Since the T in the model is "free"

…

On Wed, 28 Jun 2017 at 12:03, Herrington Darkholme ***@***.***> wrote: TypeScript did find a bug in your code. interface myModel { prop: <T>(update: T) => void; } The generic signature means myModel can accept "any" type. Because the type parameter T here is totally free, without any constraint. However, in myClass. test<T>(model: T) { const x = { prop: (model: T) => { // T here is a usage, it refers to the type parameter above. } } this.test2(x); } Note the comment, T is not free, it is "bound" to the outer declaration. It is hard to explain. But TS is right here. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#16786 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQv-Wlvk9jKQd3QD4RGTd5HzkkUMWT6Aks5sIiT0gaJpZM4OHhLN> .

[RyanCavanaugh]

The intent of prop: <T>(update: T) => void; is very unclear. There's not really anything distinguishing it from prop: (update: { }) => void; or prop: (update: any) => void; other than it looking more typesafe than it actually is.

[ahejlsberg]

See #16368 for more context. Note that you can use the --noStrictGenericChecks to turn off the new stricter checks as a stopgap solution.

[alan-agius4]

Cheers for the fast feedback, much appreciated.

…

On Wed, 28 Jun 2017 at 19:56, Ryan Cavanaugh ***@***.***> wrote: The intent of prop: <T>(update: T) => void; is very unclear. There's not really anything distinguishing it from prop: (update: { }) => void; or prop: (update: any) => void; other than it looking more typesafe than it actually is. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#16786 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQv-WoW6idr_CQgi1Srz0xv5vss-A1lOks5sIpPPgaJpZM4OHhLN> .

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

[khanhhc]

Why this bug is not fixed?????

[dave0688]

+1
Still having the bug... Why is it not adressed yet??

[ahejlsberg]

This is working as intended. It so happens there are two type parameters named T in the example, but they're distinct and not assignment compatible.