As I continue working through Leetcode, I find a lot of problems that are not conducive to immutable data structures, such as sliding window problems using two pointers. What I have found is that I can usually circumvent this by using a reduce function to track any “mutable” variables. For instance this problem I solved in Rust with:

pub fn min_operations(nums: Vec<i32>, x: i32) -> i32 {
        let max = nums.len();
        let target: i32 = nums.iter().sum::<i32>() - x;
        if target == 0 {
            return max as i32
        }
        let mut i = 0;
        let mut sub_sum = 0;
        let mut max_len = 0;
        let mut found = false;
        for j in 0..max {
            sub_sum += nums[j];
            while i <= j && sub_sum > target {
                sub_sum -= nums[i];
                i += 1;
            }
            if sub_sum == target {
                found = true;
                max_len = max_len.max(j - i + 1);
            }
        }
        if found {
            (max - max_len) as i32
        } else {
            -1
        }
    }

You have to track the two pointers i and j as well as the sub_sum and max_len values. This implementation iterates over the end of the subarray with appropriate sum, but it could be implemented to iterate over the beginning. In either case you know the range of values to iterate over, which takes care of tracking one variable. To track the other 3 variables I used a 3 tuple accumulator in a reduce function like so:

defmodule Solution do
  @spec min_operations(nums :: [integer], x :: integer) :: integer
  def min_operations(nums, x) do
    max = Enum.count(nums)
    target = Enum.sum(nums) - x 
    if target == 0 do
      max
    else
      nums_arr = nums |> Enum.with_index() |> Map.new(fn {v, k} -> {k, v} end)
      max_len = 
        0..max - 1
        |> Enum.reduce({-1, 0, 0}, fn j, {ml, ss, i} ->
                          
                      {uml, uss, ui} = find_max_sub(nums_arr, i, j, ml, target, ss + nums_arr[j]) 
                        {max(uml, ml), uss, ui} 
                    end)
        |> elem(0)
      if max_len < 0 do
        max_len 
      else
        max - max_len
      end
    end
  end
  
      
  def find_max_sub(_nums, start, finish, max_len, target, sub_sum) when start > finish or sub_sum < target, do: {max_len, sub_sum, start}
  def find_max_sub(_, start, finish, max_len, target, target), do: {max(max_len, finish - start + 1), target, start}
  def find_max_sub(nums, start, finish, max_len, target, sub_sum) do
    find_max_sub(nums, start + 1, finish, max_len, target, sub_sum - nums[start])
  end
end

I have two questions:

1. Is this an anti-pattern that should be avoided and if so, why?
2. How can I implement this sort of algorithm in a more functional style?