The filter function should return a boolean. In many cases I have seen things like .filter(x => x) which is just pointless redundancy. I use in this cases .filter(Boolean). It filters out anything falsy.
Currently the first argument for .filter is optional but I propose to just let the signature be like this instead:
filter (fn = Boolean, thisArg)
Should be simple to do, cannot break anything working and is easy to be polyfilled.
If the first argument is made optional would you expect the language to also change Array.prototype.filter.length from 1 to 0? If so this would have to be checked if it was web-compatible.
In terms of if this improves the experience of using the language, are there other languages where this is the default filter behaviour for lists that some communities would expect when coming to JS?
Yes, the length should change, and it would likely be web-compatible.
However, I don't think it's close to the most common use for filter (although .filter(Boolean) is indeed a common need) and I'm not sure it would be particularly valuable to allow someone to write .filter() instead of .filter(Boolean).
Do you think there's a more common scenario that would be a more common need? Like, maybe, filtering nullish entries? Or do you think this sort of filtering in general is uncommon?
I've found myself using .filter(x => x), or .filter(x => !!x), or .filter(Boolean) a number of times, and have actually wished for this same thing.
I've used .filter(Boolean) a few times myself, but I found that it is only useful for an array of objects-or-nulls since objects are truthy.
But for many other cases, .filter(x => x != null) is much more useful, to filter out undefined and null values from any array including arrays of primitives. I would expect [0, null, 1, 2, undefined].filter() to result in [0, 1, 2].
I actually can't remember the specific reasons I've used it in the past, but perhaps it was for a similar reason that you stated, that I just had an array of objects and null, and a truthy check was good enough to do the job. So in that scenario, a nullish check would be strictly better.
I'm opposed to introducing this kind of "magic", both here and as a general principle, where a reader of the code would have to know about this behavior already to understand it and the alternative explicit form is short and clear (as x => x or x => x != null are here).
Sometimes it makes sense to have a default for a parameter when a reader could reasonably guess what that default would be without already knowing it. (Number.prototype.toString's radix argument defaulting to 10, for example.) But there's no obvious default filtering operation.
(With regards to the identity function in proposal-function-helpers, more information on its rejection can be found in Other useful common functions · Issue #17 · tc39/proposal-function-helpers · GitHub and in notes/oct-28.md at 74518a4f9a4b186dcf1142f9a5d28bb7fa0bce77 · tc39/notes · GitHub. The main problem was that the omnibus proposal was too broad. I decided to focus first on the two sub-proposals that are most likely to succeed. I may tackle a standardized Function.identity again in its own dedicated proposal later, but it did get some pushback from some Committee members last October due to perceived lack of readability benefit compared to x => x; see the second link.)
I’ve encountered cases where I need to use . filter(x => x) many times and I find it redundant too. Making this argument optional definitely improves the convenience, though I’m sure someone will oppose it due to readability (and there already is).