I agree with your sentiment, but not with adding a new function.
You want to filter out nil? I want to filter out empty strings too.
Now I have to rewrite it or add an additional Enum.reject.
Hermanverschooten
1
fmn
now what you are saying sounds to me a bit like “if any bloat was added in the past, surely you can add more bloat”, no?
0
dimitarvp
In the end it all boils down to what the core team deems bloat and what – a useful wrapper on top of the primitives. It’s subjective semantics really, though in their case I’d bet it’s more like based on a number of requests and plain old observation of feedback en masse.
I agree the most with @Hermanverschooten here – why is nil special? On a number of occasions I needed to remove empty strings or even empty maps as well. nil is not at all special in the group of “I want to remove a value I can’t act on” scenarios.
0
sodapopcan
Ya, I’m not trying to say anything definitive here, just theorizing.
Again I can just say that it comes down to expressiveness and utility—and that I’ve just never liked the name compact 
I don’t actually agree that stuff like sum and uniq are bloat since they give a clear name to common reductions, even if not used all the time in certain types of problems. Sure sum can be written as reduce(list, &1 + &2) but the problem with that is that the word reduce on its own doesn’t tell very much at all—you have to read the body with very little context as to what’s going to happen. Code would be exhausting to read if everything was reduce, especially when reading quickly! I know you aren’t arguing for that, my point is just that reject is already very expressive and gives you a lot of context as to what will be in the body. reject(&is_nil/1) is really easy to read and IMO even more expressive than compact.
In any event, I’m just bikeshedding since my stance here is indifference. Ultimately, I wouldn’t care very much if this made it into the language!
2