Skip to content

Array.filter accepts any #20033

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
ghost opened this issue Nov 15, 2017 · 5 comments
Closed

Array.filter accepts any #20033

ghost opened this issue Nov 15, 2017 · 5 comments
Labels
Duplicate An existing issue was already created

Comments

@ghost
Copy link

ghost commented Nov 15, 2017

TypeScript Version: 2.7.0-dev.20171114

Code

function f(xs: number[]) {
    xs.every(x => x + 1); // Error
    xs.some(x => x + 1); // Error
    xs.find(x => x + 1); // Error
    xs.filter(x => x + 1); // No error?
}

Expected behavior:

All are errors.

Actual behavior:

The callback passed to filter is not type checked.

@ghost
Copy link
Author

ghost commented Nov 15, 2017

This was changed in #7779. But it seems like if developers want that behavior we should just have a flag to make boolean behave like any (and enable it by default for jsconfig.json) instead of trying to avoid using the boolean type ever.

In --strictNullChecks we could also check that the value is actually potentially truthy/falsy, so string and Node | undefined would work but not just Node.

It's not really possible for a lint rule to check this kind of situation because the signature of the function doesn't indicate that the value is meant to be a boolean. So it seems like the correct solution is to write declaration files with specific types and allow users to have more loose behavior.

@thorn0
Copy link

thorn0 commented Nov 15, 2017

The flag sounds like an interesting idea. Would it affect all the instances of boolean or only those in the return type position? Or would there be some special type for signatures like filter, an alias for boolean in the 'normal' mode and for any if the flag is set?

@aj-r
Copy link

aj-r commented Nov 16, 2017

I'm a little uneasy about a global flag that changes the behaviour of all boolean types. Having it only affect boolean callback return values is a bit better, but I feel like it should be up to the function itself to decide whether it wants a real boolean (true/false) value.

Maybe a new type (BooleanLike? TruthyFalsy?) would do the trick? It would indicate that the value is meant to be a boolean, but would allow other truthy/falsy values based on the rules that @Andy-MS described. It means that libraries will need to update to use this new type, but I think that's a good thing, because it allows each library to choose whether they want that functionality or not. And we won't be breaking anything for them in the meantime.

Re: @thorn0: I don't think we want to allow any value if this flag is set (or BooleanLike is used). Some return types like void should not be allowed.

@mhegazy
Copy link
Contributor

mhegazy commented Nov 16, 2017

Duplicate of #19456

@mhegazy mhegazy marked this as a duplicate of #19456 Nov 16, 2017
@mhegazy mhegazy added the Duplicate An existing issue was already created label Nov 16, 2017
@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

4 participants