zip2 (aka "zip") is present in Swift. zip3 is often useful, but not
built-in.
It can be achieved by using multiple copies of zip2:
for (one, (two, three)) in zip(list1, zip(list2, list3)) ...
It seems like either of these could make sense:
- Put some reasonable number of implementations, like zip2...zip10, in the
standard library, using gyb.
- Have the compiler generate them on the fly as requested by the user.
Or, some alternate approaches:
- Don't do this right now, but count it as motivation for a macro system.
- Consider making Swift's pattern-matching system extensible, which might
allow custom array-based patterns, like "for [one, two, three] in
zip(list1, list2, list3)". (I've been thinking of writing a proposal for
this anyway.)
Does anyone else care about zip3-and-higher? How do these options sound?
It's pretty easy to build your own Zips. Not sure the language really needs this. For example, I recently built a zip that produces (T?, T?) which fills one of the two with nil until both lists are consumed:
func longZip<S0: SequenceType, S1: SequenceType>(seq0: S0, _ seq1: S1) ->
AnyGenerator<(S0.Generator.Element?, S1.Generator.Element?)> {
var generators = (seq0.generate(), seq1.generate())
return anyGenerator {
let items = (generators.0.next(), generators.1.next())
if case (.None, .None) = items {return nil}
return items
}
}
I'm rather fond of this variant although I don't know if it's generally useful enough to be worth even considering for the language
-- E
···
On Dec 6, 2015, at 4:01 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:
zip2 (aka "zip") is present in Swift. zip3 is often useful, but not built-in.
It can be achieved by using multiple copies of zip2:
for (one, (two, three)) in zip(list1, zip(list2, list3)) ...
It seems like either of these could make sense:
- Put some reasonable number of implementations, like zip2...zip10, in the standard library, using gyb.
- Have the compiler generate them on the fly as requested by the user.
Or, some alternate approaches:
- Don't do this right now, but count it as motivation for a macro system.
- Consider making Swift's pattern-matching system extensible, which might allow custom array-based patterns, like "for [one, two, three] in zip(list1, list2, list3)". (I've been thinking of writing a proposal for this anyway.)
Does anyone else care about zip3-and-higher? How do these options sound?
Just wanted to point out that AnyGenerator has an inherent cost from the
type erasure. The implementation in the standard library uses generics and
is fully optimizable.
Dmitri
···
On Sun, Dec 6, 2015 at 3:34 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:
It's pretty easy to build your own Zips. Not sure the language really
needs this. For example, I recently built a zip that produces (T?, T?)
which fills one of the two with nil until both lists are consumed:
Is there an implementation in the stdlib for (T?, T?) like this?
···
On Dec 6, 2015, at 4:37 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Sun, Dec 6, 2015 at 3:34 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
It's pretty easy to build your own Zips. Not sure the language really needs this. For example, I recently built a zip that produces (T?, T?) which fills one of the two with nil until both lists are consumed:
Just wanted to point out that AnyGenerator has an inherent cost from the type erasure. The implementation in the standard library uses generics and is fully optimizable.
On 6 Dec 2015, at 23:44, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Is there an implementation in the stdlib for (T?, T?) like this?
On Dec 6, 2015, at 4:37 PM, Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>> wrote:
On Sun, Dec 6, 2015 at 3:34 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
It's pretty easy to build your own Zips. Not sure the language really needs this. For example, I recently built a zip that produces (T?, T?) which fills one of the two with nil until both lists are consumed:
Just wanted to point out that AnyGenerator has an inherent cost from the type erasure. The implementation in the standard library uses generics and is fully optimizable.
On 6 Dec 2015, at 23:44, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Is there an implementation in the stdlib for (T?, T?) like this?
On Dec 6, 2015, at 4:37 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Sun, Dec 6, 2015 at 3:34 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
It's pretty easy to build your own Zips. Not sure the language really needs this. For example, I recently built a zip that produces (T?, T?) which fills one of the two with nil until both lists are consumed:
Just wanted to point out that AnyGenerator has an inherent cost from the type erasure. The implementation in the standard library uses generics and is fully optimizable.
On 6 Dec 2015, at 23:44, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Is there an implementation in the stdlib for (T?, T?) like this?
On Dec 6, 2015, at 4:37 PM, Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>> wrote:
On Sun, Dec 6, 2015 at 3:34 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
It's pretty easy to build your own Zips. Not sure the language really needs this. For example, I recently built a zip that produces (T?, T?) which fills one of the two with nil until both lists are consumed:
Just wanted to point out that AnyGenerator has an inherent cost from the type erasure. The implementation in the standard library uses generics and is fully optimizable.
Yes, it would, but you also need the ZipSequence to be able to support that, which would actually need variadic generics. Which aren't supported :)
Aren't supported *yet*. I am hoping somebody writes a proposal to add them. This isn't the first use case that has been discussed here in the first few days. The TupleConvertible proposal would also require them to be implemented in a general fashion.