Can someone explain the best use of filter function?
Discussion posts and replies are publicly visible
Filter and reject go the way of most of the looping functions in the wake of the vast superiority of a!forEach.
It's still useful sometimes. It can make an exceptionally short, readable, nice bit of code when you want to use a helper rule you wrote (which outputs a boolean) on a list of items.
filter(rule!myBooleanRule, local!myList, ri!extraParameterThatsAlwaysTheSame)
If you have 2 inputs that change each iteration, now you've got to use the merge function to merge 2 arrays, now you might need partial evaluation with underscores _, now it's getting really hairy and you might just want a!forEach.
You can use a!forEach always to mimic filter or reject, making them essentially worthless unless they're part of legacy code. No need to remove them, so worth understanding how they work. But no real need to use them either.
I find that the looping functions are all sort of redundant and a little clunky now, except for the reduce() function. all() or none() function might be a little easier to pull out than crafting a special a!forEach I suppose. But I never used those before or after a!forEach.
As an aside: reject() does one thing that a!forEach() can't handle for whatever reason, which is to create an empty array when all members of said array are rejected. a!forEach does this until the array is almost empty, by returning an empty set for each member of the array that gets "rejected", but then if it actually gets empty (ie all members are rejected), the result becomes a list of empty sets [iirc] instead of a single empty list. Meaning that, in the global utility expression rule I often create that strips blank entries from arrays, i still have to use reject(), sadly.
Feels like a!flatten needs to be used a little bit more frequently than I would like
I seem to remember even trying that and it not solving the issue I had. But now that I try it, it looks like it might just. Thanks.