Stream Gatherers (JEP 473) feedback

[Anthony Vanelverdinghe]

When writing factory methods for Gatherers, there's sometimes a 
degenerate case that requires returning a no-op Gatherer. So I'd like a 
way to mark a no-op Gatherer as such, allowing the Stream implementation 
to recognize and eliminate it from the pipeline. One idea is to add 
Gatherer.defaultIntegrator(), analogous to the other default… methods. 
Another is to add Gatherers.identity(), analogous to Function.identity().

Sometimes a factory method returns a Gatherer that only works correctly 
if the upstream has certain characteristics, for example 
Spliterator.SORTED or Spliterator.DISTINCT. One idea is to add methods 
like Gatherers.sorted() and Gatherers.distinct(), where the Stream 
implementation would be able to recognize and eliminate these from the 
pipeline if the upstream already has these characteristics. That way 
we'd be able to write `return Gatherers.sorted().andThen(…);`. Another 
idea is to provide a Gatherer with a way to inspect the upstream 
characteristics. If the upstream is missing the required 
characteristic(s), it could then throw an IllegalStateException.

The returns clause of Gatherer.Integrator::integrate just states "true 
if subsequent integration is desired, false if not". In particular, it 
doesn't document the behavior I'm observing, that returning false also 
causes downstream to reject any further output elements.

In the Implementation Requirements section of Gatherer, rephrasing 
"Outputs and state later in the input sequence will be discarded if 
processing an earlier partition short-circuits." to something like the 
following would be clearer to me: "As soon as any partition 
short-circuits, the whole Gatherer short-circuits. The state of other 
partitions is discarded, i.e. there are no further invocations of the 
combiner. The finisher is invoked with the short-circuiting partition's 
state." I wouldn't mention discarding of outputs, since that's implied 
by the act of short-circuiting.

Anthony