Soundness issue with overloaded methods and literal types

[ghost]

It seems there is a soundness issue with overloaded methods and literal types. See the code below.

Tried with release 2.5.3 and ^2.6.0-dev.20171015.

Code

class T<X extends "a" | "b"> {
  constructor(readonly x: X) {}
  m(this: T<"a">): "b";
  m(this: T<"b">): "a";
  m() { // should fail to typecheck
    switch (this.x) {
      case "a": return "a";
      case "b": return "b";
      default: throw new Error();
    }
  }
}

// const good: "a" = new T("a").m();
const bad: "b" = new T("a").m();

Expected behavior:

T.m should fail type-checking. bad should fail type-checking.

Actual behavior:

T.m passes type-checking. bad passes type-checking. good fails type-checking.

[mhegazy]

For back compat purposes, the this argument on a function is not checked unless it is explicitly specified.

    m(this: T<"a">): "b";
    m(this: T<"b">): "a";
    m(this: T<X>) { // should fail 
        ....

[ghost]

Is there a setting to force that this is always checked?

Adding the annotation does indeed cause m to fail to check, which is good. But now if the definition is changed to the following (which should pass type-checking) it still complains:

class T<X extends "a" | "b"> {
  constructor(readonly x: X) {}
  public m(this: T<"a">): "b";
  public m(this: T<"b">): "a";
  public m(this: T<X>) {
    switch (this.x) {
      case "a": return "b";
      case "b": return "a";
      default: throw new Error();
    }
  }
}

Now it says Overload signature is not compatible with function implementation. So is even possible to type m correctly at all in the current typescript implementation?

[DanielRosenwasser]

See #7968

[mhegazy]

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