Rationale behind having type variables <A> for Collector's accumulator types in public APIs
Lukas Eder
lukas.eder at gmail.com
Mon May 7 09:00:25 UTC 2018
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
More information about the core-libs-dev
mailing list