Concat and zip

[Joe Bowbeer]

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.
>
>