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

Skip to content

Rule proposal: prevent an explicit : boolean return type annotation if a predicate return type could be inferred #9764

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

Open
6 tasks done
bradzacher opened this issue Aug 9, 2024 · 5 comments
Labels
accepting prs Go ahead, send a pull request that resolves this issue enhancement: new plugin rule New rule request for eslint-plugin package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin

Comments

@bradzacher
Copy link
Member

Before You File a Proposal Please Confirm You Have Done The Following...

My proposal is suitable for this project

  • My proposal specifically checks TypeScript syntax, or it proposes a check that requires type information to be accurate.
  • My proposal is not a "formatting rule"; meaning it does not just enforce how code is formatted (whitespace, brace placement, etc).
  • I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

TS 5.5 introduced Inferred Type Predicates.
TS will try to infer a predicate return type if:

  • The function does not have an explicit return type or type predicate annotation.
  • The function has a single return statement and no implicit returns.
  • The function does not mutate its parameter.
  • The function returns a boolean expression that’s tied to a refinement on the parameter.

The first point is the kicker -- a lot of people (us included) annotate return types explicitly.
Or they'll annotate their own predicates.

We should introduce a rule that warns if:

  • the function matches the other 3 conditions
  • the function has an explicit return type

This would allow people to lean on TS's inference for much safer code -- explicit type predicates are horridly unsound! TS only enforces that the predicate is assignable to the variable's original type -- not that the predicate is correct.

For example this code is TS valid but it is WILDLY incorrect and will crash at runtime:

const x = [1, 2, null].filter((x): x is number => x == null);

Fail Cases

const x = [1, 2, null].filter((x): boolean => x != null);

Pass Cases

const x = [1, 2, null].filter(x => x != null);

// perhaps configurable to allow this?
// by default inferring the predicate would probably be better as it's more type safe
const x = [1, 2, null].filter((x): x is NonNullable<typeof x> => x != null);

Additional Info

No response

@bradzacher bradzacher added package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look enhancement: new plugin rule New rule request for eslint-plugin labels Aug 9, 2024
@kirkwaiblinger
Copy link
Member

+1. Though let's be conscious to try to avoid unresolvable conflicts with EFRT if we can. I'm pretty sure the most obvious use case, array callbacks, isn't a hard conflict. I'm not sure off the top of my head whether there are edge cases that would be unresolvable.

@kirkwaiblinger
Copy link
Member

Also, in the weeds, but the rule doc page should say clearly that this is only appropriate for TS >=5.5

@JoshuaKGoldberg
Copy link
Member

JoshuaKGoldberg commented Aug 10, 2024

Were we talking somewhere else about having a no-inferrable-types equivalent for function return types? A no-inferrable-return-types, perhaps? This feels like it'd be an subset of that. Maybe that should be the rule name & it should use isAssignableTo checking?

@Josh-Cena
Copy link
Member

=> #2673

But they are not equivalent. The rule proposed to #2673 would only report if the inferred type is exactly equivalent to the annotated type. Here : boolean is a supertype of : x is T, basically.

@JoshuaKGoldberg JoshuaKGoldberg changed the title Rule proposal: prevent an explicit : boolean return type annotation if a precidate return type could be inferred Rule proposal: prevent an explicit : boolean return type annotation if a predicate return type could be inferred Aug 22, 2024
@JoshuaKGoldberg JoshuaKGoldberg added accepting prs Go ahead, send a pull request that resolves this issue and removed triage Waiting for team members to take a look labels Aug 22, 2024
@kirkwaiblinger
Copy link
Member

For visibility: microsoft/TypeScript#60778 has been accepted, and should give us an easy escape hatch strategy for conflicts with explicit-function-return-types

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepting prs Go ahead, send a pull request that resolves this issue enhancement: new plugin rule New rule request for eslint-plugin package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin
Projects
None yet
Development

No branches or pull requests

4 participants