It is entirely feasible. But, that’s not the criteria for adding it. There are frequent calls for fusing methods that are commonly used together, such as filter+map. Our position has been that the stream API is better served by providing mostly orthogonal primitives, and letting developers compose them as they see fit. This keeps the API simpler, and reduces the maintenance burden, allowing us to focus on more significant improvements. (Imagine how this goes; we add this one, which is inevitably used as justification for a thousand others, each of which is desired by at least one person. And the result is an unusable API.)
> On Nov 8, 2018, at 1:57 AM, Jacob Glickman <jhg...@bucknell.edu> wrote: > > Hello! > > I see myself having to often call count() as a terminal operation on a > Stream immediately after performing a filter operation. How feasible would > it be to add an overloaded count() method that accepts a Predicate, which > it uses as a filter before returning the count of elements in the Stream? > If this is supported, I'd gladly create the webrev & tests for it! > > I suppose the method signature can be something along the lines of: > > long count(Predicate<? super T> predicate) > > It would also seem reasonable to give this method to IntStream, > DoubleStream, and LongStream, but allowing them to use IntPredicate, > DoublePredicate, and LongPredicate respectively. > > Thanks, > > Jacob Glickman
