zip can only zip iterables of the same type

[mreichelt]

The zip method is especially useful when we can zip items of different types - but zip in dartx is implemented to only accept a right-hand iterable of the same type. So things like this work:

final numbers = [1, 2, 3];
final multipliers = [3, 4, 5];

final multiplied = numbers.zip(multipliers, (number, multiplier) => number * multiplier).toList();
print(multiplied); // prints [3, 8, 15]

But this doesn't:

final countOfFruits = [1, 2, 3];
final fruits = ['bananas', 'apples', 'oranges'];
final combined = countOfFruits.zip(fruits, (count, fruit) => '$count $fruit').toList();

We can try to change the implementation of the original zip, but then we must make sure we don't break any calling code. So let's test this thoroughly. 🤓

[mreichelt]

Rough new implementation that works for me:

extension IterableZip<E> on Iterable<E> {
  Iterable<V> zipWith<R, V>(Iterable<R> other, V Function(E a, R b) transform) sync* {
    final it1 = iterator;
    final it2 = other.iterator;
    while (it1.moveNext() && it2.moveNext()) {
      yield transform(it1.current, it2.current);
    }
  }
}

[mreichelt]

Yep - this works, but unfortunately it also breaks consumer code:

The second parameter will now become dynamic - which is sad, because every info for Dart to find out the generic R is available at build time. It just won't pass that as generic for parameter b in transform. And Dart doesn't have operator overloading, so that doesn't work as well.

@leisim @passsy it would be great if you can add some guidance on how you would like this to be handled. I basically see two options:

1. Keep the existing implementation, and add the new one under a different name (i.e. zipWith). That works, but then we'll have two methods where one is more broad than the other. And we'll loose the nice naming, which I would like to stay similar with Kotlin. We could deprecate zip, but still we would not be able to keep the name.
2. Leverage the fact that dartx is still a 0.x version, and as such, can add breaking changes. Maybe we should ask the community first before we do this. I added a PR for this, just to show how this would look like and to start the discussion.

[simc]

@mreichelt Thanks for the detailed proposal.

Is it only me or is this a bug in Dart? In my opinion Dart should be able to infer the types correctly without manual annotations.

I don't think we should add a zipWith() method that basically does the same as the zip() method. It is not great that type annotations will be necessary in the future but I think we should replace the existing zip() method with the proposed one.

[mreichelt]

Ok, thanks! Then, at least I'll add some docs to the zip method later so people know how to make their code working again :)

[mreichelt]

@leisim I added an example in the .zip() documentation as stated. It's ready to be merged now IMO :-) https://github.com/leisim/dartx/pull/94

[passsy]

That's a problem I've also ran into when building kt.dart.

Definitely a dart issue

I think right now would be a good time to open a dart-lang/sdk issue about this. I searched for quite a while but haven't found anything related.

details

First guesses: It seems like Kotlin evaluates generic type parameters (T) in the arguments starting with the first argument. If types are provided, it will assume those types for all following arguments, also when an argument is a lambda of type (T) -> Any In Dart the generic types in the arguments don't seem to have precedence. The compiler doesn't forward previously defined generic types (T) to lambdas which are defined as dynamic Function(dynamic).

TODO: come up with an easier example than zip() for the bug report

Split zip in two methods

Since we're doing a breaking API change, I was thinking about aligning the zip functionality from kt_dart with dartx.

In kt_dart I've split zip into two methods

• zip<R>(KtIterable<R> other): KtList<KtPair<T, R>> src Returns a pair with T and R
• zipTransform<R, V>(KtIterable<R> other, V Function(T a, R b) transform): KtList<V> src Same as the proposed zip here.

I decided against it because Dart doesn't offer tuples in the Dart SDK. Therefore we are left with a single zip method and don't have to think about the naming conflict.

Going forward

• [x] Let's do the breaking change
• [ ] Create a Dart SDK bug report
• [x] Document the new required type information adequately
• [ ] Wait for Dart SDK fix to make our documentation obsolete