Add a padded version of zip to complement the current zip

[jeremyp (Jeremy Pereira)]

@bzamayo

IMO, anything that includes a way to specify replacement values for the different sequence types is overkill, and an enum is an even fancier strand of that diversion. Fancy, but unwieldy and not justifying the API surface.

How is it unwieldy?

A simple zipLongest(a, b) covers 99% of the problem space, elegantly and simply.

But you'll end up with sequence of tuples of optionals. That's pretty unwieldy.

[dennisvennink]

@jawbroken

I personally think it's a little strange to have a type that just constructs either of two other types, rather than just constructing either one directly or having the two different top level functions.

I see your point. Do take in mind that these ideas are not yet fully formed. Currently, I see the Zip type as an abstraction that has different views on the same base Sequences, similar to String with its unicodeScalars, utf16 and utf8 properties.

[dennisvennink]

My proposal can be found in its new thread. Thoughts are welcome.