Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Rule proposal: Prefer non-null assertion operator over type assertion #202

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.

Sign up for GitHub

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

Jump to bottom
Closed
sindresorhus opened this issue Feb 3, 2019 · 4 comments · Fixed by #2624
Closed

Rule proposal: Prefer non-null assertion operator over type assertion #202

sindresorhus opened this issue Feb 3, 2019 · 4 comments · Fixed by #2624
Labels
enhancement: plugin rule option New rule option for an existing eslint-plugin rule package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin

Comments

@sindresorhus
Copy link

sindresorhus commented Feb 3, 2019 •
edited
Loading

I have the following code:

function foo(count: number) {}

// …

foo(count: lookup);

Where lookup is number | undefined.

In this code path, I know for sure that lookup will be a number, so I have done the following:

foo(count: lookup as number);

But a better solution would have been to use the non-null assertion operator:

foo(count: lookup!);

I would like a rule that enforces this.

It should be noted in the rule docs that this conflicts with the no-non-null-assertion rule.

Alternatively, the no-non-null-assertion could be renamed to non-null-assertion and handle both ways. That might be even better.
@sindresorhus sindresorhus added package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look labels Feb 3, 2019
@bradzacher bradzacher added enhancement: plugin rule option New rule option for an existing eslint-plugin rule and removed triage Waiting for team members to take a look labels Feb 4, 2019
@bradzacher
Copy link
Member

this would probably be better suited being rolled into a rule like no-object-literal-type-assertion

@bradzacher bradzacher mentioned this issue Feb 11, 2019
Closed
@j-f1
Copy link
Contributor

j-f1 commented Feb 13, 2019

type-assertion-style?

@sindresorhus sindresorhus mentioned this issue Mar 18, 2019
Merged
kaicataldo pushed a commit to kaicataldo/typescript-eslint that referenced this issue Aug 27, 2019
@armano2 @JamesHenry
[FIX][no-use-before-define] cleanup logic (typescript-eslint#202)
23a8171 
This PR changes logic behind `no-use-before-define` to traverse all scopes

fixes: typescript-eslint#141
@JoshuaKGoldberg
Copy link
Member

JoshuaKGoldberg commented Sep 15, 2020 •
edited
Loading

Now that no-object-literal-type-assertion is renamed to consistent-type-assertions, is it still preferable to add to that rule? This issue's proposal is a type system check whereas consistent-type-assertions is just a syntax standardizer.

Edit: oh, and while this technically does intersect with no-non-null-assertion, that feels fine -- this issue's complaint about overly permissive type system assertions is a lesser form of the general unwanted type system assertions overall, no?

@bradzacher
Copy link
Member

because this requires type information, I'd lean towards this being a new rule.
there's a non-trivial number of users that don't use type-aware linting, which means introducing it into an existing rule is a breaking change which will cause a lot of pain for users as they won't be able to use the rule any more.

@JoshuaKGoldberg JoshuaKGoldberg mentioned this issue Oct 2, 2020
Merged
@glen-84 glen-84 mentioned this issue Dec 16, 2020
Closed
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
enhancement: plugin rule option New rule option for an existing eslint-plugin rule package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(eslint-plugin): add rule non-nullable-type-assertion-style JoshuaKGoldberg/typescript-eslint
4 participants
@sindresorhus @JoshuaKGoldberg @bradzacher @j-f1