Extending iterators adaptors working with references

The problem

I am trying to replace this chain :

/// Trait provided by an external dependency
/// Works with num::complex::Complex64
trait DependencyTrait<T> {
    fn func1(&self) -> Box<[T]>;
}

pub fn foo(
    array_ref: &[Complex64],
    array_ref1: &[Complex64],
    array_ref2: &[Complex64],
) -> Vec<Complex64> {

let a: Vec<Complex64> = operator_1(
    array_ref1,
    array_ref.func1()
);

let b: Vec<Complex64> = a.func1().collect();

operator_2(
    b,
    array_ref)
} 

by something resembling more an iterator chain like this one :

// In foo
array_ref
    .func1()
    .operator_1(array_ref1)
    .func1()
    .iter()
    .operator_2(array_ref2)
    .collect()

Notes :
foo is used in a loop hence the references in the arguments of the function :

  1. I need to be able to re-use array_ref1 and array_ref2,
  2. I should not mutate array_ref hence the shared borrow.

Examples

I found this blog post that explain how to extend iterators but could not apply it without hitting a barrage of compiler errors (see playground link n°1 below to be submerged too)

I saw this method from the Itertools trait that was related (but not exactly) what I wanted to do (it takes another iterator instead of a reference slice) but faced errors on type systems that no one should see (see playground link n°2 to see unholy errors)

Tests

I have tested multiple implementation that (all) failed, I provide their playground link for people to test them :

What do you think is particularly "unholy" in those error messages? On the contrary, they are very clear about what the problem is. Box<[T]> is not an iterator. In fact it's not even IntoIterator.

Your code has quite a few other problems, too, such as trying to re-use a moved value, moving out of the referent of a reference, and creating a new iterator upon every call to next(). I don't really understand what you are trying to do with this, but after fixing these errors, your second snippet can be made compile.

As for your first snippet, it can be made work too – I changed the implementation of Ext to what I think you meant. You can't just re-create a new iterator upon every iteration, because then you won't ever get past the first item. You have to store and wrap the zipped iterator itself.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.