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

strictFunctionTypes option should strictly check callback parameters of override methods #19007

Closed
falsandtru opened this issue Oct 7, 2017 · 2 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@falsandtru
Copy link
Contributor

falsandtru commented Oct 7, 2017

As @aluanhaddad mentioned at #19004 (comment).

cc @ahejlsberg

TypeScript Version: master

Code

class C {
  a(f: (a: C) => C): void {
  }
}
class D extends C {
  p: boolean = true;
  a(f: (a: D) => D): void { // should throw an error here.
    console.log(this.p);
    this.p = f(new D()).p; // type is boolean, but value is undefined.
    console.log(this.p);
  }
}

const c: C = new D();
c.a(() => new C());

Expected behavior:

error

Actual behavior:

$ node built/local/tsc.js index.ts --strictFunctionTypes && node index.js
true
undefined
@falsandtru falsandtru changed the title strictFunctionTypes option doesn't strictly check callbacks strictFunctionTypes option should strictly check callback parameters of override methods Oct 7, 2017
@ahejlsberg
Copy link
Member

This is working as intended. As explained here, in --strictFunctionTypes mode we still check parameters of methods and constructors bivariantly. So, there is no error here:

interface C {
  a(f: (a: C) => C): void;
}
interface D extends C {
  p: boolean;
  a(f: (a: D) => D): void;
}

But an error is reported here:

interface C {
  a: (f: (a: C) => C) => void;
}
interface D extends C {
  p: boolean;
  a: (f: (a: D) => D) => void;
}

As I explain here, we can't tighten this any further without causing Array<T> and other core types to become invariant.

@ahejlsberg ahejlsberg added the Working as Intended The behavior described is the intended behavior; this is not a bug label Oct 7, 2017
@falsandtru
Copy link
Contributor Author

I see, thanks for your explanation.

@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
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