Rationale behind having type variables <A> for Collector's accumulator types in public APIs

[Paul Sandoz]

Hi Lukas,

See this thread:

  http://mail.openjdk.java.net/pipermail/lambda-dev/2013-June/010115.html <http://mail.openjdk.java.net/pipermail/lambda-dev/2013-June/010115.html>

Paul.

> On May 7, 2018, at 2:00 AM, Lukas Eder <lukas.eder at gmail.com> wrote:
> 
> Hello,
> 
> I'm currently designing API that I'd like to keep somewhat consistent with
> the Stream API and I've stumbled upon Stream.collect(), whose signature is:
> 
>  <R, A> R collect(Collector<? super T, A, R> collector);
> 
> For most common usages, I would imagine that this signature would have
> worked just as well:
> 
>  <R> R collect(Collector<? super T, ?, R> collector);
> 
> In fact, it seems to be a nicer signature for the caller in edge cases
> where a type witness for <R> is needed, because in the current API, a
> witness for <A> has to be supplied as well, which seems unnecessary, if not
> for even rare edge cases.
> 
> I understand that the ReferencePipeline's implementation is happy about
> being able to name the accumulator type rather than capturing it in a
> private auxiliary method or resorting to raw types, but I doubt that this
> is really an implementation detail having leaked into the API, given that
> much of the Collectors API also exposes the accumulator type as a type
> variable.
> 
> What's the reason for <A> being in the public API?
> 
> Thanks,
> Lukas