Concat and zip

Joe Bowbeer joe.bowbeer at
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> 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 mailing list