Array.prototype.filter definition forces a boolean

[denis-sokolov]

It is natural to use Array.prototype.filter to filter items with missing information:

type Foo = { prop: string }

const a: Foo[] = [
    { prop: 'bar' },
    { prop: null },
    { prop: 'baz' }
] 

a.filter(x => x.prop)

Unfortunately, this does not compile, as filter definition requires the result of the filter function to be strictly boolean. Would it make sense to make the filter definition less strict?

[mhegazy]

how about:

a.filter(x => !! x.prop)

Alternatively, you can define a new signature for filter in a file in your project as such:

interface Array<T> {
    filter(callbackfn: (value: T, index: number, array: T[]) => any, thisArg?: any): T[];
}

[denis-sokolov]

how about a.filter(x => !! x.prop)

Well, yes, type casting is the current way to appease the compiler.
My point was that we probably would want to not need to appease the compiler.

you can define a new signature for filter in a file in your project

Sure, thanks for the suggestion. I know how to do that.

My point was not how to workaround this limitation in my project, I have no problem with that.
My point was to suggest an improvement to the core for the benefit of everybody.

[DanielRosenwasser]

We've run into this sort of problem with lib.d.ts a few times now (e.g. #4002). JavaScript is technically okay with a lot of things, but basically it comes down to trying to help users catch mistakes when we can. Forgetting to perform some condition is an easy mistake, and !! is such an easy remedy for when you want to say "It's okay, I know what I'm doing."

If we did ever want to fix this, we couldn't just change the return type to any, because users could accidentally forget to return something in their callback. A more appropriate return type would be the (fairly awkward) boolean | string | number | symbol | Object.

[denis-sokolov]

@DanielRosenwasser, you’re right, this is a judgement call about inconvenience vs catching errors.
It is up to you, of course, to make the call.

Do consider, that in my point of view, .filter is equivalent to an if statement. And surely you do not plan to enforce mandatory type conversion in an if condition? But the same could be said about that: ‘Forgetting to perform some condition is an easy mistake (if (foo) {}), and !! is such an easy remedy (if (!!foo) {}).’

[RyanCavanaugh]

I'm with @denis-sokolov on this one. We shouldn't pretend if (arbitrary_expr) is safe for if and dangerous for filter.

[adidahiya]

+1, it is inconsistent to have different levels of strictness for if and filter. I'd love to implement a TSLint rule to flag implicit coercion for users who want the additional safety though: palantir/tslint#625