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

[Lukas Eder]

Thanks a lot for digging this up. Interesting, so the implementation
"leaked" into the API after all.

Sometimes I wish that it would be possible for an implementation to
"capture" a wildcard in a local type variable, as such:

void foo(List<?> list) {
  <X> List<X> local = list;
  local.add(local.remove(0));
}

It would seem cleaner for such a method not to have a generic type variable
on the signature level, if it is used only in its internals...

2018-05-09 2:30 GMT+02:00 Paul Sandoz <paul.sandoz at oracle.com>:

> Hi Lukas,
>
> See this thread:
>
>   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
>
>
>