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

Omit should throw error if not existing key try to remove #40262

Closed
4 of 5 tasks
pahuta opened this issue Aug 26, 2020 · 2 comments
Closed
4 of 5 tasks

Omit should throw error if not existing key try to remove #40262

pahuta opened this issue Aug 26, 2020 · 2 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@pahuta
Copy link

pahuta commented Aug 26, 2020

Search Terms

Omit inexistent key

Suggestion

Let's consider next code where we omit inexistent key from interface Todo :

interface Todo {
    title: string;
    description: string;
    completed: boolean;
}

type TodoPreview = Omit<Todo, 'not_existed_key'>; // currently error is not thrown

Use Cases

Let's imagine that previously interface Todo had property not_existed_key and we had variable such as

const todoItem: TodoPreview = {...}

but then not_existed_key was removed and developer forgot to remove TodoPreview because it became redundant.

Examples

From my point of view will be better to have more strictly behavior of Omit.

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Aug 26, 2020
@RyanCavanaugh
Copy link
Member

See discussion at #30825

@pahuta
Copy link
Author

pahuta commented Aug 26, 2020

Thanks @RyanCavanaugh !

@pahuta pahuta closed this as completed Aug 26, 2020
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