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

Type 'string | number' is not assignable to type 'never'. Type 'string' is not assignable to type 'never'. #44909

Closed
Azevedo-Dani opened this issue Jul 6, 2021 · 3 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@Azevedo-Dani
Copy link

Bug Report

πŸ•— Version & Regression Information

  • Compilation error
  • This is the behaviour in every version I tried. Since 3.5.1

⏯ Playground Link

Playground link with relevant code

πŸ’» Code

interface IItem {
    id: number
    name: string
}

const item: IItem = {
    id: 1,
    name: 'item1'
}

const fun1 = (item: IItem, value: IItem[keyof IItem], name: keyof IItem) => {
    item[name] = value
}

const fun2 =  <T extends IItem>(item: T, value: T[keyof T], name: keyof T) => {
    item[name] = value
}

πŸ™ Actual behaviour

There's an error in fun1. We can't do item[name] = value otherwise we have the error Type 'string | number' is not assignable to type 'never'. Type 'string' is not assignable to type 'never'.

But the fun2 works perfectly.

πŸ™‚ Expected behaviour

We should have the same behaviour in fun1 and fun2.

@whzx5byb
Copy link

whzx5byb commented Jul 6, 2021

Related: #30769

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

This is correct behavior. fun1 would corrupt its item during a legal call:

const n: "id" | "name" = "id";
fun1(item, "item1", n);

@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

4 participants