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

sub class method params assignability check doesn't give error with string vs literals #39571

Closed
LabhanshAgrawal opened this issue Jul 12, 2020 · 2 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@LabhanshAgrawal
Copy link

TypeScript Version: 3.9.2 (also tested in nightly)

Search Terms:
TS2416 literal
subclass methods literals

Code

class foo {
  fn(x: string) {
    return x;
  }
}

class bar extends foo {
  fn(x: 'a' | 'b' | 'c') {
    return '';
  }
}

class baz extends foo {
  fn(x: 'a' | 'b' | 'c' | undefined) {
    return '';
  }
}

Expected behavior:

Getting an error Property 'fn' in type <sub class> is not assignable to the same property in base type 'foo'.
As

Types of parameters 'x' and 'x' are incompatible.
      Type 'string' is not assignable to type <corresponding param type of fn in sub class>.

for both classes bar and baz

Actual behavior:

The error is only shown on class baz. It should also be there on bar as string is not assignable to 'a' | 'b' | 'c' also.

Playground Link: playground

Related Issues: couldn't find (#35151 came up in search and looked similar but it was a different issue.)

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jul 13, 2020
@RyanCavanaugh
Copy link
Member

Class method types are compared bivariantly; see comments in #18654

@typescript-bot
Copy link
Collaborator

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

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

3 participants