Deprecate tupleNZipped operations

[julienrf]

These operations have been replaced by lazyZip:

// old style
(xs, ys).zipped.map((x, y) => x + y)

// new style
xs.lazyZip(ys).map((x, y) => x + y)

We should deprecate the implicit conversion that makes the zipped operation available.

[joshlemer]

@julienrf does this mean that all of these are deprecated?

• Tuple2Zipped
• ZippedIterable2
• Tuple3Zipped
• ZippedIterable3

[joshlemer]

And of course, the conversion that enables (xs, ys, zs).zipped

[SethTisue]

ALL THE THINGS

[joshlemer]

For now I have not deprecated the above 4 classes, just the implicit conversions, but will if that's what's wanted.

[SethTisue]

direct usages of these classes are almost certainly exceedingly rare or nonexistent, but regardless, I don't see a downside to deprecating them

[SethTisue]

anyway deprecating them will help us remember to delete them later

[manojo]

Butting in a bit late, for sure, but what is the reasoning behind deprecating zipped? It feels so much more intuitive to write (x, y, z, a).zipped over x.lazyZip(y).lazyZip(y).lazyZip(a). Is there a performance issue whereby it is discouraged to zip many collections together?

[SethTisue]

good question!

I don't remember all the details, but we've all (most of us?) had a pretty dim opinion ofzipped for a long time, so at the time of deprecation, there doesn't seem to have been a lot of discussion about it, I think because the deprecation reflected a longstanding consensus

as best I can recall off the top of my head,

• uniformness and discoverability (e.g. via autocompletion) are both good reasons to have methods on collections directly whenever possible, rather than adding extension methods to unrelated types such as tuples. (also, conversely, extension methods on frequently-used types have an annoying way of turning up in annoyingly unrelated situations: Scaladoc, autocompletion, error messages, and so forth, though I don't recall if this was a concern for zipped in particular)
  • related: it isn't clear to me — in fact, I think I disagree — that (x, y, z, a).zipped is "intuitive". it became familiar, perhaps. familiar things have a way of coming to seem "intuitive", but designwise, especially when doing a sweeping redesign, we're more concerned with newcomers than with people are who accustomed to familiar things
• yes, performance, we avoid making the tuple, which is especially a win in the common Tuple2 case (I would think? not sure anyone ever actually benchmarked it)
• we wanted to add lazyZip anyway for largely unrelated reasons, some discussion is at Add lazyZip operation (formerly zipWith) collection-strawman#223
  • and then once you have lazyZip, the case for keeping zipped around as an additional way of doing the same thing diminishes a lot
• the reason zipped ever existed in the first place was to make the operations lazy, but there wasn't a good way to do that in the old collections, so we added zipped and some custom types to make it work. in the new design, laziness is well-supported and so that permitted a cleaner design

if you search for zipped here in scala/bug you might uncover some additional data

maybe @julienrf has something to add; the original ticket (scala/collection-strawman#221) gives the impression of being the product of in-person discussion

[tpolecat]

FWIW, if you're using Cats the parallel applicative instances for list-like types have zipping behavior, which is a lot like the old .zipped.

@ (List(1,2,3), List("a", "b"), List(true, false)).parTupled 
res6: List[(Int, String, Boolean)] = List((1, "a", true), (2, "b", false))

@ (List(1,2,3), List("a", "b"), List(true, false)).parMapN((n, s, b) => s"$n $s $b") 
res7: List[String] = List("1 a true", "2 b false")

[manojo]

Thank you for the explanations, and the alternatives available at cats.

The reasoning behind having a cleaner design makes sense indeed. Regarding the familiarity question, from a user point of view I still think that having something like parTupled in cats, or maybe even an explicit TupleOps.zipN is easier on the eyes.

Then again, maybe the deprecation and lack of such methods is deliberate in discouraging such constructions.