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

Loosen strictness of Array.prototype.includes() and Set.prototype.has() #60559

Closed
6 tasks done
sod opened this issue Nov 22, 2024 · 7 comments
Closed
6 tasks done

Loosen strictness of Array.prototype.includes() and Set.prototype.has() #60559

sod opened this issue Nov 22, 2024 · 7 comments

Comments

@sod
Copy link

sod commented Nov 22, 2024

🔍 Search Terms

Example:

const values = ['foo', 'bar', 'baz'] as const;
type ValidValue = (typeof values)[number];

function isValueValid(value: string): value is ValidValue {
    return values.includes(value);
                          // ^^ ts error: Argument of type 'string' is not assignable to parameter of type '"foo" | "bar" | "baz"'
}

This error seems counter intuitive as the entire point of includes is to check if value in foo.includes(value) is one of foo.
A Set and mySet.has(...) has the same issue.

playground

✅ Viability Checklist

⭐ Suggestion

I'd expect typescript to not show an error here.

💻 Use Cases

Now having to deal with the removal suppressImplicitAnyIndexErrors: true in typescript 5.6

@sod sod changed the title Loosen strictness of Array.prototype.includes() Loosen strictness of Array.prototype.includes() and Set.prototype.has() Nov 22, 2024
@MartinJohns
Copy link
Contributor

MartinJohns commented Nov 22, 2024

Duplicate of #60073 and many many more. Your search terms seem excessive, no wonder you didn't find any of them. I suggest limiting your search terms to a few related word, often with the in:title modifier.

IMO a type assertion is an appropriate workaround if this is intentional code.

@sod
Copy link
Author

sod commented Nov 22, 2024

sorry. Thank you for your time.

I didn't see that improving this was already discussed and/or rejected.

@sod sod closed this as completed Nov 22, 2024
@sod
Copy link
Author

sod commented Nov 22, 2024

reopen because it's not a duplicate of #60073.

This ticket is not about making Array.prototype.includes() smarter. It's about not throwing an ts-error for 100% valid and deterministic usecase.

@sod sod reopened this Nov 22, 2024
@MartinJohns
Copy link
Contributor

This is a duplicate of #60073, #26255 and many others, ending up with #14520.

Your issue is the accepted type for includes(), same as the other.

And I have no clue what "strict property access" (from your use case) is about, that's completely unrelated.

@sod
Copy link
Author

sod commented Nov 22, 2024

This is a duplicate of #60073, #26255 and many others, ending up with #14520.

I aggree that this is a duplicate to #26255. A 6 year old, with 27 upvotes closed duplicate. But a duplicate non the less.

Then I guess i have to write:

+ const inArray = (haystack: readonly any[], needle: string): boolean => haystack.includes(needle);
+ inArray(values, value)
- values.includes(value)

I hope nobody follows the recommendation on https://www.typescriptlang.org/tsconfig/#suppressImplicitAnyIndexErrors to use @ts-ignore, as that IMO is even worse.

And I have no clue what "strict property access" (from your use case) is about, that's completely unrelated.

Yes, strict property access made no sense. Removed that now from the description. This issue appeared when flicking "suppressImplicitAnyIndexErrors": true to false. A setting change that became mandatory with typescript@5.6.

Sadly I can't show it in the playground, because "suppressImplicitAnyIndexErrors": true isn't available anymore, even if you select an older version.


Fell free to close this issue.

@MartinJohns
Copy link
Contributor

Again, you can just use a type assertion, IMO the cleanest approach: values.includes(value as ValidValue)

@sod
Copy link
Author

sod commented Nov 22, 2024

values.includes(value as ValidValue)

Indeed that works. Not sure why. I internalized that whenever I had to restort to typecasting, that my underlying types or generics are incorrect.

Thank you.

@sod sod closed this as completed Nov 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants