Extra generic parameters incorrectly make generic types compatible

[cutthroat]

TypeScript Version: 4.0.5

Search Terms:
generic, incorrect, assignable, multiple, multi, two, parameter, compatible, unsound, unsafe

Expected behavior:
The type NotOk<number, number> below should not be assignable to NotOk<string, string>

Actual behavior:
It is.

Code

// Ok

interface I1<X> {
  m1: Ok<X>;
}

class Ok<X> {
  constructor(public x: X) {}

  fOk(i1: I1<X>) { i1 = i1; }
}

// !!! Fails to type-check as expected
const ok: Ok<string> = new Ok(0);


// Not ok

interface I2<X, Y> {
  m2: NotOk<X, Y>;
}

class NotOk<X, Y> {
  constructor(public x: X) {}

  fNotOk(i2: I2<X, Y>) { i2 = i2; }
}

// !!! Type-checks but should not
const notOk: NotOk<string, string> = new NotOk(0);

Playground Link: Provided

Related Issues:
Somewhat related: #30634, #31006

Extra:
The interface I2 is needed for when inlined the type-checker fails correctly:

class NowOk<X, Y> {
  constructor(public x: X) {}

  fNowOk(i2: { m2: NowOk<X, Y>; }) { i2 = i2; }
}

// Fails to type-check as expected
const nowOk: NowOk<string, string> = new NowOk(0);

However, this behavior could simply be due to a limitation of the unification mechanism used by the type checker.

[MartinJohns]

Working as intended. You're not using Y anywhere.

What is structural typing?
Why is A<string> assignable to A<number> for interface A<T> { }?

I did not read correctly and was mistaken.

[cutthroat]

I believe Y is not needed to cause a structural difference since the class NotOk already contains the field x: X, and instantiating it with say X = number and X = string should be a structural difference. Isn't this the reason why the ok assignment above fails to type-check?

In any case, adding a field of type Y to NotOk (which I believe qualifies as an use) still type-checks:

// Not ok

interface I2<X, Y> {
  m2: NotOk2<X, Y>;
}

class NotOk2<X, Y> {
  constructor(public x: X, public y: Y) {}

  fNotOk2(i2: I2<X, Y>) { i2 = i2; }
}

// !!! Type-checks but should not
const notOk2: NotOk2<string, string> = new NotOk2(0, 0);

Because NotOk and NotOk2 type-check, I can cast, e.g., a number to a string:

// !!! Type-checks but should not
const notOk: NotOk<string, string> = new NotOk(0);

// !!! undefined
console.log(notOk.x.length);

[MartinJohns]

You're right, I misread the code. This really seems strange.

const val1 = new NotOk<number, string>(0);
const val2: NotOk<string, string> = val1;
val1.x // number
val2.x // string

Interestingly the error shows up when you remove the fNotOk2 method.

[cutthroat]

Yes, fNotOk2 seems to be essential, as well as the interface I2. NotOk is the simplest example I could get.

[RyanCavanaugh]

See #39947 - this is fixed in the nightly build