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.

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

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

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

@j-f1
Copy link
Contributor

j-f1 commented Feb 13, 2019

type-assertion-style?

kaicataldo pushed a commit to kaicataldo/typescript-eslint that referenced this issue Aug 27, 2019
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

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
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
Development

Successfully merging a pull request may close this issue.

4 participants