Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression: something is wrong with type checking in dev.20180919 #27223

Closed
qwertie opened this issue Sep 19, 2018 · 5 comments
Closed

Regression: something is wrong with type checking in dev.20180919 #27223

qwertie opened this issue Sep 19, 2018 · 5 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@qwertie
Copy link

qwertie commented Sep 19, 2018

TypeScript Version: Version 3.1.0-dev.20180919

Code

This code compiles in v3.0.3 but fails in 3.1.0-dev.20180919.

/** Represents a React/preact component with a state property and setState method. */
export type StatefulComponent<S> = {
  state: S, setState: (s: any /*Partial<S>*/) => any
};

export function f<This extends StatefulComponent<S>, S=This["state"]>(component: This): void
{
  if (Math.random()>0.5) f(component);
}

Expected behavior:

Compiles without error.

Actual behavior:

hold.ts:8:28 - error TS2345: Argument of type 'This' is not assignable to parameter of type 'StatefulComponent<This["state"]>'.
  Type 'StatefulComponent<S>' is not assignable to type 'StatefulComponent<This["state"]>'.
    Types of property 'state' are incompatible.
      Type 'S' is not assignable to type 'This["state"]'.

8   if (Math.random()>0.5) f(component);

Playground Link: No error in Playground.

@qwertie qwertie changed the title Regression: something is going wrong with type inference Regression: something is going wrong with type checking Sep 19, 2018
@qwertie qwertie changed the title Regression: something is going wrong with type checking Regression: something is wrong with type checking in dev.20180919 Sep 19, 2018
@ghost ghost added the Bug A bug in TypeScript label Sep 19, 2018
@ghost
Copy link

ghost commented Sep 19, 2018

You can work around this for now by adding manual type arguments f<This, S>(component).

@ahejlsberg
Copy link
Member

This is actually working as intended. The error is caused by fixes in #26698 which improve accuracy of reasoning over constraints of indexed access types (types of the form T[K]).

The following simplified repro previously wasn't an error but now is:

function f1<S, T extends { state: S }>(s: S, t: T["state"]) {
    s = t;
    t = s;  // Error, S not assignable to T["state"]
}

The error definitely is correct--T["state"] constrained to S meaning that it is assignable to S, but not the other way around. It is essentially the same error as we report here:

function f2<S, T extends S>(s: S, t: T) {
    s = t;
    t = s;  // Error, S not assignable to T
}

@ahejlsberg ahejlsberg added Working as Intended The behavior described is the intended behavior; this is not a bug and removed Bug A bug in TypeScript labels Sep 20, 2018
@qwertie
Copy link
Author

qwertie commented Sep 20, 2018

Well, this raises the question: I want to say T extends StatefulComponent<S> for any S; is there a better way to do it that wouldn't cause this error? (Edit: I assume T extends StatefulComponent<any> would do the job well enough, even if it weakens type checking in some way...)

@ghost
Copy link

ghost commented Sep 20, 2018

Why not just f<S>(component: StatefulComponent<S>): void?

@qwertie
Copy link
Author

qwertie commented Sep 20, 2018

Good point, @andy-ms. I should mention that the repro example code above is not the real code, and in real code I may have a good reason to use a type parameter T to preserve a more specific type. By now I have uninstalled the dev build (since I only installed it to verify a different bug which, it turned out, was fixed in 3.1-dev.)

@qwertie qwertie closed this as completed Sep 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

2 participants