Not sure what is needed to get this PR reviewed - please let me know.

Hi, the code itself looks ok but don't think i've heard anyone ask for such addition before. Maybe other maintainers have? we're usually quite conservative with adding new functions.

@wader wrote:

we're usually quite conservative with adding new functions.

Not so long ago, there was a major performance issue that justified such conservatism. It's my understanding that the performance overhead problem has been largely resolved. Does anyone know what the performance overhead these days is?

Even setting aside general considerations concerning bloat, the argument against adding filter is quite strong, so let me articulate two points that may not be obvious. One is that 'select' is a filter that actually filters in a way that is already quite confusing to anyone steeped in SQL's SELECT, so adding 'filter' to jq can be seen as making a potentially confusing situation even more complex.

Another, though admittedly lesser, point concerns the wisdom of having two ways to say (in words) the same thing. ("In words" because I do not mean to include symbolic expressions like [.[]] as a word or phrase.) The cadence of maps and selects in a program has a certain appeal that would be interrupted by an interloper such as filter.

Not so long ago, there was a major performance issue that justified such conservatism. It's my understanding that the performance overhead problem has been largely resolved. Does anyone know what the performance overhead these days is?

Don't know but it's my understand also that performance of builtins.jq is not a big issue now. I was mostly thinking about the same issues you also pointed out, adding on to already confusing names and partially overlapping functionality.