Is there a way to either move iterator back or don't create new iterator everytime?

    pub fn two_sum(nums: Vec<i32>, target: i32) -> Vec<i32> {
        let mut indices: Vec<i32> = Vec::<i32>::new();
        let mut iter = nums.iter();
        
        while let Some(cur_val) = iter.next()
        {
         if let Some(find_result) = iter.find(|&&x| x == target - *cur_val)
         {
             let mut iter_2 = nums.iter();//I "HAVE TO?" create iterator here and
              indices.push(iter_2.position(|&x| x == *cur_val).unwrap() as i32);
              let mut iter_3 = nums.iter();//I "HAVE TO?" create iterator here???
              indices.push(iter_3.position(|&x| x == *find_result).unwrap() as i32);
              break;
         }
        }
        indices
    }

Is there a way to use just one iterator and simply move it back?

Why do you want to avoid creating a new one? Creating a new iterator is free, and it doesn't have to go on its own line.

pub fn two_sum(nums: Vec<i32>, target: i32) -> Vec<i32> {
    let mut indices: Vec<i32> = Vec::<i32>::new();
    let mut iter = nums.iter();

    while let Some(cur_val) = iter.next() {
        if let Some(find_result) = iter.find(|&&x| x == target - *cur_val) {
            indices.push(nums.iter().position(|&x| x == *cur_val).unwrap() as i32);
            indices.push(nums.iter().position(|&x| x == *find_result).unwrap() as i32);
            break;
        }
    }
    indices
}

I'm also wondering what this function is intended to do. It looks like if there isn't a number that adds to the first to get the target, then nothing is returned. I'm guessing that the first find was also supposed to be a new iterator, so you could get all pairs.

It also looks like you could improve the code by using position rather than find for the first use of find, unless you really need to return the index of the first match for that number, but only when that number follows the other...

enumerate could also be your friend, again unless it's important to return the first instance for duplicate numbers.

Here's a few notes to consider. I'll build off of @alice's solution, which maintained your logic and general approach.

First, when working on sample projects like this, it's a good idea to set up the test cases they give you. Here's a starting point, which you can note fails the second test case, but passes the first.

So what happens in the second test case? To begin, the while condition gets the first value (3) from the iterator. Then it uses iter.find(...) to look for another 3 in the rest of the iteration -- "find a 3 that comes after the current point in the iteration". It doesn't find one, and now the iterator has been exhausted. The while condition runs again and gets None.

You can think of looking through the rest of the iterator as simultaneously increasing your current position. One way to fix this would be to clone the iterator before running find(...) on it, so that you exhaust the cloned iterator instead of your while-loop iterator.

(This ended up being a long reply, but the last two paragraphs are the most pertinent to your original question. I suggest working through this to make sure you understand how the iterators are consumed and why cloning fixed that part of the problem.)

But what you're ultimately trying to do is look through the rest of the vector beyond the current position. So another approach would be to keep track of the current position as you go, and create a new iterator "from scratch" instead. This also means you don't have to calculate the index of the current value once you've found a solution. Here's a version with those changes. Because we don't need to use or clone the iterator within the loop anymore, we can also use for to consume the iterator instead.

Now the second test case succeeds, but the third one is failing. When you look up the second position, you're iterating over the entire vector again. So when the second value is the same as the first value, you get the index of the first value. You could use skip(cur_index + 1) again, but instead of iterating twice inside the loop, let's just use enumerate() a second time, when we look for a match.

Things look pretty good at this point, but I'll throw in a final algorithmic observation for extra credit. Instead of looking for a match among the values that come after the current value, you could check for a match among the values that came before. The advantage is that you can record the values as you go in a way that's quicker (and cleaner looking, IMO) to look up than iterating over the vector each time.

Thanks, I appreciate it.