Concat and zip
joe.bowbeer at gmail.com
Wed May 1 13:03:41 PDT 2013
In defense of zip: I think it is fairly important. Ease of expression (and
productivity) are still the most valuable benefits of new features, and zip
is important for a class of problems. zip exists in Python, Scala, and
Groovy (as "transpose" method), to name a few.
I would keep zip without Int/Long/Double versions. This also avoids all
the varieties of mixed primitive/Object pairings in zipped streams.
On Wed, May 1, 2013 at 11:01 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> We're almost finished syncing the Streams code from the lambda sandbox
> into the jdk8 repositories. One of the last items on the list are the
> "concat" and "zip" methods we've currently got in "Streams".
> First, these aren't "done" because we only have reference versions, not
> Int/Long/Double versions. So more work would be required to finish these,
> or we'd have to take the hit for only having reference versions (and
> endless requests to add specializations. And we're also missing the SAMs
> that would be needed for primitive versions of zip.)
> Second, I'm starting to have YAGNI thoughts on these, especially zip. Zip
> shows up all over the place in functional languages, but the efficacy of
> these idioms relies on tuples being cheap. Also zip parallelizes basically
> not at all.
More information about the lambda-libs-spec-observers